アジャイル手法での要件収集
優れた本 適用されたユーザーストーリー で、著者はユーザーストーリーの形式でトロール要件の次のプロセスを指定しました。
ユーザーの役割（ペルソナ）を作成する->各役割のユーザーの目標をブレーンストーミングする->ユーザーストーリーを書く->
すべてのユーザーストーリーを推定する->ストーリーを優先する->最初のリリースのユーザーストーリーをいくつか選択します->
各ストーリーの承認基準を記述->各ストーリーをタスクに分割->タスクの見積もり
ただし、理由はわかりません[〜＃〜] all [〜＃〜]ストーリーを最初に推定する必要があり、なぜ推定する必要があるか作業に移るときまで、受け入れ基準をストーリーから外しますか？
次は、受け入れ基準自体についてです。本の受け入れ基準では、単純なステートメントは次のようになります。
- マスターカードで支払いをテストします。
- visaで支払いをテストします。
Given ... When ... Then ...形式は受け入れテストを記述するのに適していませんか？
最後に、ユーザーストーリーをタスクに分割することについて説明します。タスク自体がストーリーポイントで推定されたときに、なぜタスクを再推定する必要があるのでしょうか。
最初の見積もりのポイントは、ストーリーを実装する際の複雑さの順序について（大まかに）全員に同意してもらうことだと思います。これは、ストーリーの優先順位付けに役立ちます。
私たちのチームがアジャイルに切り替えたとき、ACを書く方法について多くの議論がありました。
私たちが最終的に結論付けたのは、「支払いのためのマスターカードによるテスト」と「与えられた...いつ...その後...」形式の両方にメリットがあるということです。前者は自然言語であるため、明らかに記述が簡単です。後者は、前提条件、アクション、および期待を明示的に設定するため、より正確です。
スピードを上げるために、ACは最初は自然言語で書かれていることがわかりました。この後もあいまいな要素が残っている場合は、正式な形式に変換されます。また、ACを自動テストとしてコーディングする予定の場合は、正式な形式にする必要があります。
ストーリーのタスクへの分解について：私たちはそのアドバイスにも少し従いましたが、それは不必要なオーバーヘッドであることがわかりました。
ストーリーを正確に見積もるのは大変です（多くはありませんが、合計されます）。正確な見積もりには、お客様にとって直接的な価値はありません。したがって、計画に必要なだけ（正確に）見積もりを行ってください。
長期的には、「小/中/大」で問題を回避できます。それを行う。受け入れ基準、テスト、タスク、またはスパイクを正確に推定するために時間をかけることは、2か月間ストーリーに取り組む予定がない場合、時間の無駄です-ストーリーを再訪するときまでに、その可能性はコンテンツ、コンテキスト、または知識が変わった。
スプリント/反復では、かなり正確な見積もりが必要です。タスクと詳細AC（チームが最も好む形式で）は、追加の作業の価値があります。
ストーリー（概算）を見積もり、次にタスク（個別の細かい見積もり）を個別に見積もるという考えでは、必要に応じて見積もりを調整するプロセスを順を追って説明します。
また、「与えられた...いつ...その後」にはメリットがあるだけでなく、「フーとして、私はしたい...」と「それを機能させるだけで、誰もが何を話しているのかを知っています」と言います。私にとって、フォーマットは1つではありません。ストーリーとコンテキストによって異なります。
見積もりについては同意します。私の会社では、非常に形式化された要件プロセス（お客様の指示による）があり、多くのユーザーストーリーが生成されています。私のようなビジネスアナリストがこれらの記事を書いており、多くの場合、実際にそれらを見積もる技術的な知識がありません。私たちにとって、推定ステップは、スクラムチームがバックログからストーリーをピックアップすることを決定した後に発生します。その時点で、私たちは技術計画をリードし、私たちのBAが私たちが取り組む予定のストーリーについてスプリントする簡単な計画/グルーミングセッションを開催し、開発者は「計画ポーカー」または特定のスクラムに適した方法を使用しますチームにストーリーのサイズの見積もりを提供します。私は（BAとして）スクラムチームに組み込まれているにもかかわらず、計画ポーカーに投票しないことをポイントにしています。
ACはストーリーの一部である必要があることにも同意しますbefore推定されます。開発者が価値の声明だけを見て、すぐにそれから出てくるすべての論理的な必要性を完全に見るのではなく、ストーリーを不正確に見積もることは完全に可能です。私には、受け入れ基準が明記されていない限り、ストーリーは「完了」しません。明らかな理由により、「試合中」のストーリー（チームが既に承諾している）のためにACに触れなければならない場合にも非常に注意しています。これは、サッカーの試合中にゴールポストをいじるようなものです。 ACを変更する必要がある場合は、そのストーリーを所有する開発者の同意を得て、バックログに新しいストーリーを作成するだけかどうかを慎重に検討した後（理想的には、常にそれを行う必要がありますが、 t理想的な教科書アジャイルな世界に住んでいます）。
テストの目的に最適な記述形式については、どちらの方法でもかまいません。古典的な「Xとして、私はYが必要なので、Zができるように」が最も効果的であることがわかります。 正しくと書けば、テストケースを導き出すのはいつでも簡単です。多くの場合、ユーザーストーリーを書いているときに、「これをどのようにテストするのですか？」私はまた、私たちのテスターを見つけて、できる限りいつでも彼らの頭脳を選ぶことは、要件の男として非常に有益だと思います。多くの場合、BAとはアプリケーションの見方が異なるため、「テスターのように考える」ことで、優れたユーザーストーリーを作成するときにロジックループを閉じることができます。
私のプロジェクトのBA間でユーザーストーリーのピアレビューを行っています。これは良い習慣だと思います。結局、標準化された方法で書くのはかなりお粗末です。これは、私たちの顧客（または誰でも）がユーザーストーリーをたどることができ、複数の種類のユーザーストーリー形式に取り組む必要がないため、私たちのプロジェクトと同じくらい大きなプロジェクトに適しています。
タスクに関する限り、それは実際には組織固有の質問です。私たちにとって、タスクは、複数の開発者が単一のユーザーストーリーで作業することになる場合に最も役立ちます。タスクは、各開発者が何をしているかを追跡するのに役立ちます。私たちのスクラムマスターは、開発者がストーリーをタスクに分割することを好んでいます。このプロジェクトでは、時間単位でタスクを追跡しますが、ストーリーはポイントで追跡します。 100％アジャイルスクラムの「コーシャ」ではありませんが、プロジェクト管理チームに役立ちます。実際、タスクで何をするか、何をしないかは、追跡しようとしていること、それをどのようにしたいか、そしてどのように組織化されているかに大きく依存します。