スパイクのアウトラインの例（アジャイルモデリング）

Question

私は要件分析を行っており、スパイクの良い例を見つけようとしていました。私はそれが何であるかの説明を見つけることができるように思える。

• 名前：名前が明示的にユーザの意図やユースケース
• 短い説明の機能的目的を表現する必要があります。

  システムユースケースのために私は、アウトライン、以下のいる短い説明を強く表現しなければなりませんいくつかの行では、主要な通常の&代替フロー アクティビティ（俳優が何を望んで説明する！）。

• トリガー：トリガーは、ユースケースを開始させるイベントを記述します。このイベントは、外部の一時的な または内部イベントです。これはバッチジョブにとって重要です。
• 主要アクター：各ユースケースには、最低限1つの主要アクターがありますが、より多くの主要アクターが関与する可能性があります。
• セカンダリアクター：該当する場合は、ここに記載してください。
• 前提条件：ユースケースシナリオを開始する前に、常に真でなければならないことを前提条件としています。
• 通常のフロー：これは、代替フローと一緒に、ユースケースの主要部分です。
• 代替フロー：通常の処理/処理のケースでは、代替案は許容範囲外であり、結果として使用例のゴールを達成した結果は となります。
• 例外：これは不要ですが必要なバリエーションですが、ユースケースの目標を達成するものではありません。
• ポスト条件：ポスト条件では、ユースケースが正常に完了した場合、常に何を真にしなければならないかが述べられています。 これは、通常のフローまたは代替フローの結果である可能性があります。
  • タイトル：ユーザーストーリーの目的を説明するユーザーストーリーについては

  は、私は次のアウトラインを持っています。

• Rational/Objective：ユーザーストーリーによって作成される値を記述する。
• 実装の詳細：
  • コンテキスト：：営業日言語に日に書かれた、彼らは以下のサブセクションが含まれているこの物語は始まり、他のどのような情報は、開発を開始する前に考慮すべき場所を、システム内の記述します。
  • 通常のフロー：希望の結果につながるハッピーパスを記述します。
  • 代替フロー：考えられる代替案。
  • 例外：通常/代替フローが失敗する可能性のある状態を記述する。
  • 備考：開発者がユーザーストーリーを正しく理解するのに役立つ、技術的でない追加の技術情報。
• テスト：開発後にストーリーが検証されたときに実行されるテストのリスト。すべてのテストは、 に期待される回答を含める必要があります。

私はスパイクのために同様のアウトラインを見つけようとしています。 スパイクの説明から、私は以下のものが少なくとも含まれているべきだと思う： *タイトル *時間スパン *ユーザストーリー：スパイクが由来するユーザストーリー（ただし、これは常にケース）。

スパイクのアウトラインには他に何が必要ですか？

Answer 1

あなたのチームメンバーが必要とするだけです。チームは準備完了（DoR）の定義を定義し、それを自己責任で実施する必要があります。