scrum - SCRUM推定精度

Question

ある時点で見積もりが間違っていることが判明する場合が多いと思います。バックログ項目の核心にドリルダウンするとすぐに、ほとんどの場合、計画中に考えていなかった何かが見つかるからです。これは、タスク レベルのスプリントの見積もり中または実際のスプリント中に発生する可能性があります。

タスク レベルの見積もり中に、ストーリー/バックログ アイテムの非常に多くのタスクが検出される可能性があるため、最初の見積もりを調整する必要があります。 これでどうしますか？プロダクト オーナーに戻って、バックログ アイテムの優先度を再設定する必要があるかもしれないと伝えますか? 基本的には、チーム全体がストーリー レベルの見積もりに戻って、ストーリーを再編成する必要があるということでしょうか?

スプリント中に、実装には当初考えていたよりもはるかに多くの労力が必要であることに気付くかもしれません。 これでどうしますか？計画どおりに完了できないことを知って、静かにスプリントを続行しますか? そして、今後はすべての見積もりに「セキュリティ バッファー」を追加しますか?

一般的に、SCRUM は見積もりの​​精度全体にどのように対処しますか?

私の理解が正しければ、SCRUM 開発者チームはプロダクト オーナーに、計画どおりに提供することを「約束」しているようなものです。しかし、それは彼らが正確に見積もった場合にのみ可能です。したがって、見積もりは SCRUM の成功にとって非常に重要であると同時に、非常に難しいことでもあります。

Answer 1

単純な真実は、推定精度が矛盾しているということです。ユニコーンのように、それは存在しません。定義上、見積もりは正確ではありません。

それを念頭に置いて、スクラムやその他のアジャイル方法論は、風車を打ち負かすのではなく、その制限を回避しようとします。スクラムでは、プロダクトバックログ アイテム(ユーザー ストーリー、要件など)の複雑さをアプリオリに推定して、プロダクト オーナーが次のスプリントで完了する予定のストーリーの数を概算します。PBI をタスクに分解した後、各タスクは、完了までにかかると思われる時間に従って見積もられます。チームのキャパシティが満たされると、スプリントの終わりまでに何を提供できるかについて、(わずかに) より良い見積もりが得られます。

これらの見積もりはまだ正確ではありません。

アジャイルな製品所有者がこの不正確さに対処する方法は、製品の提供の遅延によるコストを削減することです。PO は、製品の最も重要な部分をできるだけ早く提供し、(まだ不完全な) 使用可能で価値のある製品をできるだけ早く作成するように、ストーリーを定義して優先順位を付けます。このようにして、時間どおりに行われなかったもの (スプリントの終了日またはリリース日) は、依然として提供された可能性のある最高の製品であり、多くの場合、十分に優れたリリースが時間前に作成され、残りの最も重要でない機能が提供されます。すぐに小さなバッチ。

これが、スクラムが見積もりの​​ (不) 正確さを処理する方法です。

Answer 2

一般的に、SCRUM は見積もりの​​精度全体にどのように対処しますか?

その場で調整することによって。サイズと複雑さの尺度としてストーリー ポイントを割り当てます。同等のサイズと複雑さのタスク間で同様の基準でポイントを割り当てるために、レベルに最善を尽くします。

最初の数回のスプリントでは、間違いを犯すことは避けられません。時間が経つにつれて、プロジェクト全体の明らかな「速度」によって将来の見積もりを調整します。

コンセプトは、そのスプリントのストーリー ポイントの値を調整するためのフィードバック ループを作成し、不確実性を受け入れることです。Mike Cohn の著書Agile Estimating and Planningに良い議論があります。

バックログ項目の核心にドリルダウンするとすぐに、ほとんどの場合、計画中に考えていなかった何かが見つかるからです。

見積もりに含まれていないタスクは、開発プロジェクトで 2 番目に多い見積もりエラーの原因です (1 番目は... 要件の変更です!)[1]。これは、一般的に「計画の誤謬」の根本原因の可能性でもあります。アジャイル プロセスは、あまりにも前にタスクを分解することに反対する傾向があります。

ただし、このリスクを管理する通常の方法は、見積もりチェックリストを作成することです。McConnell のSoftware Estimation: Demystifying the Black Artは優れたリソースです。表 4.2、4.3、および 4.4 (pp. 44-45) は、独自のチェックリストの出発点として最適です。

[1] ヴァン・ゲンクテン、ミヒエル。「ソフトウェアはなぜ遅れるのか? ソフトウェア開発の遅れの理由に関する実証的研究」. ソフトウェア工学に関するIEEEトランザクション、1991年6月。

Answer 3

スクラムは見積もりを素晴らしく簡単に処理します。「全体として」とおっしゃいましたが、それは 1 つのスプリントのことです。あなたは、1 回のスプリントで約束したことについて話しているのです。想像してみてください: 最初のスプリントでの約束が失敗し、2 番目のスプリントでの約束が失敗しました。では、3 番目のスプリントはどうなるでしょうか。3 番目のスプリントの約束をどのような基準で行いますか? あなたの質問への答えはこれに基づいています

最初のスプリントでの約束が実現したらどうしますか? それからあなたはただラッキーでした！つまり、見積もりスキルはスクラムでは必要ありません。誰もあなたに約束/約束を求めませんでした。とにかく見積もりをするのに十分な時間が与えられなかったのに、なぜわざわざするのですか? :)

滝では、それは正反対です。あなたには時間が与えられ、約束し、責任があり、約束を守るために地球を動かします。

Answer 4

SCRUM で最も難しいのは見積プロセスです。チームと一緒に会議室に座って、特定のストーリーを完成させるためにどのような努力をする必要があるかを話し合うのに、最大で 1 日かかる場合があります。最初の数回のスプリントで正確な見積もりを得ようとは思わないでください。これを事実として受け止めて、前に進むべきです。ストーリーの詳細度とチームの協力期間に応じて、このプロセスはスプリントごとに改善され、見積もりはより正確になります。これまでのところ、速度を計算するか、チームの現在の速度として 0.5 を使用できます。最初のスプリントを終えると、より正確な速度が得られ、それを使用して次のスプリントの範囲を構築できます。

私のチームは、プロジェクトの最初の段階で正確な見積もりを出すことに大きな問題を抱えていました。プロジェクトには信頼できるものは何もありませんでした。アーキテクチャがなく、システムが非常に大きく複雑であるため、正確に何を構築する必要があるか誰も知らなかったので、誰も見積もりを出すのを恐れていました。この問題は、システム アナリスト (SA) を会社に導入することで解決しました。SA は、受信したすべての要求を分析し、ビジネスの観点からすべてが明確になるまで開発に渡しません。SA の主な目的は、新しい機能を理解し、それをどのように実装できるかを確認し、既に実装されている機能への依存関係を考慮し、今後のスプリントで実装する予定の機能を念頭に置いて、高レベルのソリューションを提案することです。最初の分析が完了した後、SA はストーリーを作成し、バックログに追加します。その後、これらのストーリーはデザイナーに渡されます。画面をデザインし、ストーリーに結び付けます。その後、ストーリーは製品所有者に渡され、承認とビジネス価値の設定が求められます。

上記のすべての手順により、チーム全体が見積会議に費やす時間が大幅に短縮されました。会議が始まると、必要なものはほとんどすべてそろっています。すべてのストーリーが詳細に説明されており、開発者はそれが既存の機能にどのように影響するかを確認し、デザインを確認できるため、技術的な質問のみに集中することが容易になります。そのため、進行中の結論として、SA を構築し、デザイナーは次のスプリントで計画されている機能に取り組んでいますが、開発者と QA はアクティブなスプリントに焦点を当てています。これにより、アクティブなスプリントの終わりまでに、すべてのストーリーを分析し、次のストーリーの設計を行うことができます。