見積り誤差がなぜ起きるか
プロジェクトの見積りはプロセスの各段階における予測可能な量の不確実性に支配される 不確実性のコーンが表すのは最良の状況であり、見積り者の熟練度やその他の要因によりもっと悪くなる可能性 不確実性を反映させる (範囲で見積もる) ための 2 つの方法
1. もっともありそうな値を一点で見積り、係数をかけて範囲を表す
2. ひとりに最良ケースと最悪ケースを見積もってもらい、別の人に一点見積りしてもらってその範囲に入るか確認
「いくらかかるか」 と 「いかに不確実か」 を見る能力は別
各反復の開始まで要求を定義しないと、長期の予測可能性を諦めざるを得ない どうする？ → より少ない反復か、別の反復 (反復しないのは効果がない)
採用されがちな折衷案 : プロジェクトの初期に大部分の要求を定義して、設計・構築・テスト・リリースを短い反復で実行
ユーザーインターフェイス設計の完了まではシーケンシャルで、その後は反復型
不確実性のコーンから発生するばらつきが ± 25 % まで小さくなってから反復型の利点を活かす優れた方法
混乱した開発プロセス
良い見積りプラクティスを行うよりも、プロセスの混乱を修正する方が優先
不安定な要求
要求が不安定なことはある種のプロジェクトの混乱を表す
要求変更は追跡されないことが多く、再見積りされるべきところなのに再見積りされない
要求の増大や要求の変化に対する許容量を見積りに加えるという方法もある
これを織り込んだ不確実性のコーンでは、見積り値の 1.5 倍に収束するぽい
見積りプラクティスから生じる誤差
見落とし (プロジェクトの計画レベルでも個々の作業者レベルでも)
開発者は必要な作業の 20 ～ 30 % を見落とす傾向
3 つの分類
要求の見落とし
ソフトウェア開発アクティビティの見落とし
ソフトウェア開発アクティビティ以外の見落とし (休暇や祝日、全社ミーティングなど)
楽観主義 : 開発者によって作られる見積りは常に楽観的
主観と偏見
見積りの偏見 (バイアス) は、見積りを意図的にある方向に進めようとするもの
主観は、経験に影響された判断 (意識・無意識とわず)
例えばコントロールノブが多いほど正確になると思いがちだが、実際はそうではない
コントロールノブは主観を持ち込む場所になりがちで、現実の正確性を低下させる
即興の見積りは誤差が大きい
即興の見積りはやめろ
人は過去のプロジェクトの実績よりも見積りを覚えている
nobuoka.icon そもそも実績をちゃんと出してないとかあるんだよなぁ
正確性 (どれだけ実際の値に近いか) と精度 (数字がどれだけ精密か) の区別 ステークホルダーは精度によって正確性を想定するので、適切な精度にすること
(例えば 「日」 の単位を使うと日単位の正確性を持っているように見える)
参考文献