process - スクラムによる要件の収集

Question

私の開発チームは、スクラムの方法論に取り組んでいます。優先順位の高い製品バックログがあり、バーンダウンチャートで追跡されるスプリントに分類されます。

問題は、製品マネージャー（利害関係者から要件を収集する）が、スプリントまたは一連のスプリントの開始の数日前などに、要件の概要を教えてくれることです。

次に、それらを調べ、実行可能なもので（技術的かつ妥当な時間内に）修正します。これは、経営陣、他の製品管理者、および利害関係者によるレビューのために送られ、通常はさらに修正/微調整されます。これは、すべてが落ち着くまで円を描くように進む傾向があります。

その間、スプリントの開始日が迫っており、安定していると確信している要件を把握し始めます。これらが完了すると、要件がわずかに変化するため、コードを微調整するための無限の日数が残ります。

要件が修正されたと見なされるべきではないことは承知していますが、これをうまく管理しておらず、ウォーターフォール要件アプローチをアジャイル開発に適合させようとしているように感じます。

誰かがこの種の問題の改善の提案や経験を持っていますか？

編集：これはおそらく私たちにとって最悪のシナリオです-要件がかなり安定していて、実際にスクラムを適切に使用している場合があります！ただし、スプリントで上記のシナリオが頻繁に見られるため、質問をしました。私は上記が本当に適切なスクラムではないことを知っています、それは一種の問題です:)

Answer 1

はい。そして、これは重要です。スプリントの開始後にストーリーへの変更を受け入れないでください。

これは、スクラムマスターに代わって、これが許可されていないことを製品所有者に伝えるために多大な労力を要します。彼らに強調する重要なことは、開発者として、指定されたとおりにストーリーを見積もり、提供することを約束し、変更を加えるとその努力が無効になるということです。

場合によっては、スプリントの開始後に要件が合法的に変更されます。ここで、スプリントを完全に中止することを検討してください。（それは彼らの注意を引くはずです。）

プロダクトオーナーがこれに柔軟性がないことに気付いた場合は、スプリングの長さを短くすることを検討してください。ストーリーが非常に小さかったので、1週間のスプリントを使用したショップで働いていましたが、これは最小限だと思います。

詳細については、KenSchwaberによるScrumを使用したアジャイルプロジェクト管理を参照してください。

Answer 2

利害関係者をスクラムに連れて行きます。それらを呼び出すと、製品マネージャーを通じて「中国のささやき」がなくなります。また、開発者ではなくバックログを優先する必要があるのは彼らです。利害関係者がスクラムにいるとき、彼らはまた、変更の影響をよりよく理解し、変更を行うことをやめない一方で、彼らの変更が反復にどのように影響するかについてのより良い概念を持ちます。

要件の変更について; アジャイルマニフェストを参照してください...「変化を受け入れる！」

親切、

ダン

Answer 3

「その間、スプリントの開始日が迫っており、要件が安定していると確信しています。要件がわずかに変化するため、要件が完了すると、コードを微調整するための無限の日数が残ります。」

それをアジャイルメソッドやスクラムとは呼ばないでください。

それはただの狂気です。

スプリントが始まった後に物事を微調整している場合、あなたはそれを正しく行っていません。

あなたは（確かに、あなたの励ましの）悪い行動を可能にしている。スプリントが開始する前に要件を取得できない場合は、2つの選択肢があります。

1. 待って。これには何の問題もありません。長期的には安いです。

2. 始める。でも。スプリントの期間中は要件が固定されているため、「微調整」せずにスプリントを終了する必要があります。変更はバックログの一部になります。

   • あなたはより短いスプリントをすることができます。

   • 彼らが彼ら自身の問題を引き起こしているという考えを得るまで、あなたは単に微調整をバックログすることができます。

また、多くの管理レビューはあまりアジャイルではありません。それ自体は間違っていません。しかし、それは信頼の欠如を示しています。アジャイルとは、開発者と製品所有者の間のコラボレーションと相互作用を意味します。それは、マネジメントレビューの別の層を意味するものではありません。

Answer 4

チームには、プロダクトオーナーに代わって要件の修正を担当する人がいます。ジャストインタイムの要件がある場合もあれば、やり直しが必要な場合もあります。QAは、リリースの最新のスプリントで要件が正式にレビューされていることを受け入れます。

チームは、プロダクトオーナーによって明確に定義されたタスクにのみコミットする必要があります。そうしないと、それらを見積もることができません。おそらく、安定した要件のみを計画できるように、反復を短縮することができますか？

プロセスでこのレビューサイクルが義務付けられている場合は、スプリント可能なアイテムを製品マネージャー/管理者/利害関係者によって承認されたものに制限することができます。

Answer 5

誰も実際に製品バックログを所有していないようです（つまり、一意の製品所有者がいない）。また、最も重要な製品バックログアイテムは、各反復の前に準備ができていないようです。これらは明らかな主要な障害であり、解決する必要があります。スクラムマスターがそれらに取り組む必要があります。

Answer 6

私は他の人に同意します。プロダクトオーナーは存在しません。コミットメントを行うのに十分な確固たる要件があり、プロダクトオーナーがそのコミットメントに同意するまで、スプリントを開始することはできません。コミットメントが行われると、スプリントを放棄して再計画しない限り、どちらの当事者もスクラムのコンテキスト内でそれを変更することはできません。もちろん、あなたはこれをしていません。

私はさらに、あなたのスクラムマスターがプロセスのキーパーとしての彼または彼女の責任に従わないことを述べたいと思います。スプリントバックログアイテムを選択するための有効な製品バックログがないのに、なぜ彼はあなたにスプリントを開始させているのですか？スクラムマスターもいますか？

あなたのチームはただ仕事を成し遂げようとしていると理解していますが、実際に起こっているのは、明確に定義されたユーザーストーリーを備えたバックログを用意する必要がないプロダクトマネージャーの側で悪い行動を可能にしているということですスプリントの開始前。

スクラムにスクラムマスターとプロダクトオーナーがいるのには理由があり、スプリントを開始する前に、プロダクトオーナーとチームの間でスプリントバックログについて合意する必要があります。これらの割り当てられた役割がなく、スクラムプロセスに従わないと、問題が発生します。はい、悪い行動を指摘するスクラムの部分を避ける方が簡単ですが、それが認められるまで悪い行動を変えることはありません。狂気の定義は、異なる結果を期待しながら同じことを何度も繰り返していることを忘れないでください。結果を変更したい場合は、何をするかを変更する必要があります。