不確実性下での見積もり

不確実性下での見積もり

不確実性はソフトウェア開発に内在しています。問題は不確実性が存在するかどうかではなく、見積もりでそれをどう正直に考慮するかです。

不確実性コーン

プロジェクトの開始時、見積もりはどちらの方向にも4倍ずれる可能性があります。チームが学ぶにつれて、不確実性は縮小します：

フェーズ              不確実性の範囲
─────────────────────────────────────
初期コンセプト        0.25x – 4.0x
要件完了             0.5x  – 2.0x
設計完了             0.67x – 1.5x
コード完了           0.8x  – 1.25x

高い不確実性への戦略

1. まずスパイク、それから見積もり

問題がよく理解されていないため見積もれない場合、推測しない。不確実性を減らすためにスパイクをタイムボックスし、より良い情報で見積もる。

2. 単一の値の代わりに範囲を使用

「これは5」の代わりに「レガシーAPIがバッチ処理をサポートするかどうかによって、5から13の間」と言う。仮定を文書化し、答えが分かったら再確認。

3. 既知を見積もり、未知を認識

ストーリーを理解している部分と理解していない部分に分割。既知の部分は通常通り見積もり。未知の部分はスパイクかバッファを追加。

ストーリー: 「パートナーXのAPIと統合」
  既知: アダプターレイヤーの構築 (3 pts)
  既知: 統合テストの作成 (2 pts)
  未知: パートナーのAPIの負荷時の動作 → スパイク (1日)
  → 既知の作業を5と見積もり、スパイク後に再確認

4. 信頼度レベルを使用

「50%の確信でこれは5ですが、データベース移行が予想より難しい場合、30%の確率で13になります。」

5. 早期かつ頻繁に再見積もり

見積もりには賞味期限がある。理解を変える何かを学んだら、古い数字がまだ有効なふりをするのではなく、すぐに見積もりを更新。

最も重要なルール

見積もりが不正確だったことでチームを罰してはならない。見積もりが罰に使われると、チームは防御的にパディングし、システム全体が価値を失う。