スクラムでの要件収集。最初のスプリントで高レベルの要件について話すことは受け入れられますか？
スクラムではどの段階で要件が収集されますか？
プロジェクトに関するレポートを書いていますが、高レベルの要件をどこに配置するかを決定するのに苦労しています。
Sprint 0というセクションがあると考えています。小見出しがあるところ
- 分析
- 設計
- 実装
- テスト中
- 評価
分析では、これまでに収集されたすべての要件について話します。これは、システムが実行する必要があることの概要を意味します。
もう1つのオプションは、問題を分析し、クライアントとのミーティングで収集した要件を書き込む製品バックログと呼ばれるセクションを用意することです。
これに対する理想的なアプローチは何ですか？
スクラムでは、要件はユーザーストーリーに含まれます。製品の所有者は、すべての利害関係者と話し合い、要件を収集する責任があります。一般に、単一の要件ドキュメントはなく、説明に類似したプロジェクト全体のレポートもありません。
ユーザーストーリーは、正規化された形式の単一の機能を備えた最高レベルの要件を説明します。 「$ Xとして$ Yにしたいので$ Zができます」。例えば：
「合法的な盲目のユーザーとして、自分の画面を拡大して小さな画面要素を見ることができます」
これは、付箋に記載されている高レベルの説明です（物理的、またはRallyなどのツールで比喩的）。この後、通常はより詳細な説明を入力し、最後に「承認基準」を入力します。受け入れ基準は、実際の具体的な要件です。通常私はこれを箇条書きとして書きますが、これらはストアが完全であると見なされるために真実でなければならないものです。
アジャイルの理論では、「システムが実行する必要があること」を含むレポートは作成しません。代わりに、あなたはプロダクトオーナーとして、すべてのストーリーを取り上げ、それらを優先します。次に、スプリントが始まると、チームはそれらのストーリーをポイントし、それらに適合して機能するスプリントにストーリーを取り込みます。
スプリントの最後に、何が行われたかを関係者に示し、作成して繰り返す必要がある新しいストーリーを作成します。ソフトウェアをリリースする準備ができていると関係者が思ったときはいつでも、一般にリリースします。
利害関係者がリリースするために特定のセットが必要であると言うのはまったく問題ありませんが、それはそれらのものが危機に瀕していることを意味します。アジャイルの要点は、これらのことはプロセス中に、スプリント間で変更できることです。つまり、最終的なプロジェクトについて過度に話すと、アジャイルについての細かさに反することになります。そのため、あなたが説明しているレポートは、アジャイルプロジェクトでこれまで行われたものではありません。
私はスクラムを使用するチームの製品所有者であり、長期的なドキュメントは一般的に私が説明するストーリーのリストです。設計について説明したドキュメントは1つもありません。代わりに、PMソフトウェアとWikiのようなシステムの両方で、次のリリースで見たい機能を関係者がリストするさまざまな場所があります。これらは、しばしば最新のドキュメントに変わります。リリース前にスプリント。
私はプロダクトオーナーとして、常に要件を収集しています。アジャイルとスクラムの要点は、要件が変化することです。特定の「段階」で要件を収集すると、リリース時に要件が古くなるため、利害関係者のニーズを満たしません。
要約すると、スクラムでは：
- 最初に書かれたプロジェクトを説明する単一のドキュメントはありません。
- 現在の要件をカプセル化した多くの生きた文書があります
- 要件を集める段階は特にありません
- 次のスプリントの計画のために要件が常に収集されています
- ステークホルダーがソフトウェアをリリースするのに良いと言う時点まで、リリースする実際の要件が何であるかは確かにわかりません。