「多すぎる」設計を行うことなく、スプリント計画中に有効な時間の見積もりをどのように提供しますか？

私のチームはスクラムに慣れてきていますが、ほとんどの人は非アジャイルまたは「疑似」アジャイル手法に慣れています。私たちにとって最大のハードルは、効率的なスプリント計画会議を実行することです。この会議では、バックログ項目をタスクに分割し、時間を見積もります。（私はVS2010スクラムテンプレートの用語を使用しています。どこかで間違った単語を使用した場合はお詫びします。）

タスクにかかる時間を把握しようとすると、コードレベル（テーブルレイアウト、インターフェイスなど）で機能を設計するという罠に陥ることがよくあります。 。

ここはそのようなデザインをするのに適した場所ではないと私は確信しています。スプリント中にこれらの設計会議のタスクをスケジュールする必要があります。ただし、タスクの意味のある推定値を他にどのように作成するかを理解するのに苦労しています。

実践的な習慣/テクニックなどはありますか？機能の実装計画を知らずに、機能の所要時間を判断するため 設計が完了した後で時間の見積もりが大幅に変更される場合、事前にスプリントバックログを適切に予算化するにはどうすればよいですか？

編集：

明確にするために、コメント/回答のいくつかは非常に有効ですが、私は間違った質問に対処すると思います。

私たちがやっていることは正しくなく、このデザインのスプリントに時間を組み込む必要があることはわかっています。概念的には、すべての開発者がそれを理解しています。また、スクラムの経験を持つチームメンバーを招いて、雑草に入ってしまった場合でも順調に進んでいます。

問題は、この設計プロセスを実行しないと、何かの具体的な時間の見積もりを提供することが難しいことに気づいていることです。私たちは常に「このように設計すると8時間かかるかもしれませんが、代わりにこれを別の方法で行う必要がある場合、約32時間かかりますが、書き始めたらそれほど悪くはないかもしれません。 ...」

また、これから作業する歴史的な速度が得られれば、このプロセスはより良くなると思いますが、私たちが使用しているテクノロジーやアーキテクチャパターンの多くは、私たちにとって新しいものです。しかし、非常に間違っている可能性のある見積もりが、このプロセスの適応の自然な部分である場合は、それを受け入れるように自分自身を調整する必要があります:)

1. これらの設計に関するディスカッションを行う定期的な「グルーミング」会議をスケジュールします。私がいるチームは、計画の前日に、スプリントごとに1回それらを持っています。そこにある目標は、チームがストーリー全体の時間の見積もりに同意できるように、デザインを十分に釘付けにすることです。この会議でタスクの内訳を行うことを検討することもできます。これにより、計画は、どれだけピックアップするかを決定するための純粋な練習になります。つまり、実際の作業を開始する前に、スプリントでデザインを行う必要があります。

2. プランニングポーカー、つまり工数ではなく「努力」のポイント/単位を使用してタスクを見積もることを検討してください。また、できる限りストーリーを分解するようにしてください。ストーリーが長く/複雑になるほど、見積もりが正確になる可能性が低くなります。

3. 計画を立てる際、スクラムマスターは、「解決」に行き過ぎている議論を停止するよう呼びかけることで、計画を順調に進める必要があります。その時点で、チームメンバーは見積もりにすぐに合意する必要があり、通常は上限/最悪のケース番号を示します。計画よりも時間がかかるタスクや複数のスプリントにストーリーがロールオーバーするためにスケジュールがずれて対処するよりも、タスクが計画よりも簡単になる場合は、より多くの作業を選択する方がはるかに簡単です。

4. スプリントの最後の回顧で見積りがどのように機能したかについて話します。特に、著しく離れているものがあった場合。チームは、ストーリーがどのように進んだのか、それがどのように予想されるのかから何かを学びましたか？スクラムマスターは、設計/評価プロセスに加えることができる実用的な変更に焦点を合わせ続ける必要があります。

問題はあなたが時間を見積もろうとしていることだと思います。しないでください。

複雑さを推定します。要件（できればユーザーストーリー）を見て、他の要件やユーザーストーリーの複雑さと比較して、チームがそれを構築してテストする方法を理解するのがどれほど複雑であると考えるかを評価します。時々あなたは間違っているでしょうが、多くの場合、何かがどれほど難しいかについて良い考えを得るでしょう。また、ほぼ同じ複雑さのアイテムは、完了するのに同じ量の労力を費やす傾向があることがわかります。

したがって、複雑さのランキングは、製品バックログのユーザーストーリーに関連付けられた「ストーリーポイント」になります。いくつかのスプリントを処理した後、スプリントで何個のストーリーポイントを通過できるかがわかります。それが速度です。その時点で、各アイテムにかかる時間について、はるかによく理解できます。

Mike CohnのUser Stories Appliedを強くお勧めします。

あなたの質問は、特に計画の際にデザインを回避することについてです。しかし、これは一種のXY問題です。

私はあなたがいるところに行ってきました。段階的な改善をもたらす可能性のあるものを提供するのではなく、これらの中間状態のいくつかを飛躍的に向上させたいと思います。

ここに、私たちのチームが特に作業の計画と実行に関連して行う3つのことを示します。これらは、設計のスラッシングを回避し、不正確な時間の見積もりから逃れるのに役立ちました。

自動化された受け入れ基準

私たちのストーリーは、自動化された受け入れ基準の数によって指摘されています。つまり、ストーリーが完了したことを確認するための自動テストを作成するとしたら、それらはどうなるのでしょうか。

たとえば、「ユーザーがiOS 6以降を実行しているiPadで「再生」をクリックすると、ビデオの再生が始まります。」このテストを実際に自動化するのは難しいかもしれませんが、それはストーリーの受け入れ基準（AC）であり、1つのポイントを提供します。

フィボナッチスケールを使用し、常に切り上げます。したがって、ストーリーに4つの自動化可能な受け入れ基準がある場合、それは5ポイントのストーリーです。

ストーリーポイントの最大サイズは8ポイントですが、ほとんどありません。ストーリーに自動化可能な5つ以上の受け入れ基準がある場合、それらを分割する方法を見つけます。

プレグルーミング

月曜日にキックオフミーティングがありますが、グルーミングミーティングはチームプランニングが行われる場所です。グルーミングの前に、チームメンバーは結果を説明し、自動化された受け入れ基準を試してストーリーを事前グルーミングします。

グルーミングは、チームの専門知識を活用して、グルーミング前のストーリーに対応し、詳細不明の要件を特定し、ストーリーを分割します。

受け入れ基準に加えてタスクをリストすることもありますが、これらは推定時間ではありません。時間を見積もることはありません。タスクは、基準をサポートするために実行する必要がある作業のステートメントです。

進行中の作業の制限

従来のスクラムは、作業時間をスプリント期間に制限しようとします。これにより、スプリントが金曜日に終了するため、スプリントの締め切りに間に合うように急いで駆り立てられ、週末が殺されたことがわかりました。

別のアプローチは、進行中の作業をいつでも制限することです。私たちは後者に移行し、かなり満足しています。

ストーリーがバックログから進行中の作業に移行したら、それをいくつかの状態の1つとして特徴付けます。

• 保留中-いくつかのチーム外アクティビティを待っているため、チーム作業は発生しません
• 開発中-受け入れ基準の達成に取り組んでいます
• テストが必要-他の誰かが確認するのを待って、ACに会ったと信じています
• テスト中-ストーリーはACに対して評価されており、バグが解決されています
• 導入準備完了-次の利用可能な機会に、それはライブになります

次に、各州のストーリー数を使用して、チームの焦点を動かします。たとえば、開発者は新しいストーリーを引き受けることができるかもしれませんが、テストに多くのストーリーがある場合は、既存のストーリーを手伝うのが良いでしょう。

まず、これらの状況下では正確な推定は不可能であることを認識してください。間違えてもストレスを感じないでください。ただし、計画を立てるにはまだ大まかなアイデアが必要です。完全な不確実性を説明する実際の唯一の方法は、推定にストーリーポイントを追加することです。5か13かわからない場合は、13を使用してください。

ストーリーをできるだけ小さく分解することも役に立ちます。私たちは、機能の実行方法をよりよく理解するのに十分な作業を行うことを唯一の目的とする研究/デザインストーリーを持っていることが多く、その後、機能ストーリー自体が後続のスプリントに入ります。これが機能する理由を考えてください。どれほど難しいかわからない場合でも、通常、過去の経験から、見つけるのにかかる時間はかなり正確にわかります。

ここでできることは2つあります。

最初に、ディスカッションを監視し、自分がいるときに「ねえ、またデザインしているよ」と言うのが、ある種のスクラムマスターです。見た目よりも難しいです。人々を日々回転させ、最初は全員がスクラムマスターになるようにして、だれでもパイプできるようにします。

第2に、スプリントの計画中に設計している場合は、タスクの期間を呼び出すのに十分な知識がないこと、またはより楽しいので設計しているだけであるかどうかを区別できるようにする必要があります。

繰り返しになりますが、スクラムマスターはここで開始し、スケジュールを立てるのに十分なことがわかるまでアイテムを保留にするか、設計を中止して元の質問に回答するよう指示します（どのくらいかかりますか）。

したがって、スプリントの計画を立てている場合は、ビジネススポンサーにバックログを調べてもらい、最初にやりたいことを優先することは理にかなっています。そうすると、セッション中に設計することが難しくなります。なぜなら、彼らは落ち着きがなくなり、最終的には来たくないからです。

私たちは、スプリント計画の段階で、「限られた」ストーリーを推定することを基にして、限られた議論のみを行っています。かなり狭い範囲に焦点を当てたチームの設定にもかかわらず、見積もりは本当に非常に不正確です...主に、実際に何が起こっているのかについて完全に理解されていない、ドキュメント化されていない、コメントされていないレガシーコードがたくさんあるためですオリジナルが書かれてから大きく変わったスタッフ。

私たちが今試みているのは、各ストーリーの調査を計画する前に少し時間を費やすことです-そして、ここでは1人の開発者だけが1つのストーリーを調査します...これは、調査した開発者がいくつかの説明と洞察を提供できることを意味します推定に役立ちます。これまでのところ、これは試みられた機会に役立ちました。

追加の調査により、見積もりが本当に正確になり、コストを正当化できることを確信していませんが、いくつかのスプリントで確認します。