- 作者: スティーブマコネル,久手堅憲之,Steve McConnell,田沢恵,溝口真理子
- 出版社/メーカー: 日経BP社
- 発売日: 2006/10/07
- メディア: 単行本
- 購入: 31人 クリック: 472回
- この商品を含むブログ (91件) を見る
当たり前のこともだいぶあるんだろうけど自分が強く思ったのは以下の点。
- 見積りは推測じゃなく計算。
- インプットを定義すればアウトプットが出るはず。
- 推測するのはアウトプットではなくインプット。
- 組織の見積りプロセスを定義する
- これをやらないと過去の見積りデータが使えない
抜粋メモ
- 見積りの考え方
- 不確実性のコーン
- 工程が進むとコーンが狭くなる
- 開発者の見積りを削ってはいけない。なぜなら、既に十分に楽観的すぎるからだ。
- 即興の見積りはやめよう。たった15分の見積りでさえ、もっと正確だ。
- 不確実性のコーン
- 見積り技法の基礎
- プロジェクトの規模
- 5人以下 => 小規模
- 半年から1年以上、25人以上 => 大規模
- 3ヶ月から1年程度、5〜25人程度 => 中規模
- 開発サイクルの早い時期に手に入るものを探す
- 数えたものを計算して見積もる
- 組織の過去のデータを使う利点
- 組織の影響を想定できる
- 主観や根拠のない楽観主義を回避できる
- 見積りの政治力学が減る
- プロジェクトが終わったら、出来るだけ早くプロジェクトの過去データを収集しよう。
- 1点見積りは最良のケースに近くなりやすい
- 最良ケースと最悪ケースの見積りを作成して、起こり得るすべての範囲の結果について考えるきっかけにしよう。
- グループレビュー
- それぞれのチームメンバーがプロジェクトの各部分を個別に見積り、その後、ミーティングを開いてお互いの見積りを比較する
- 単純に見積りの平均をとって、それでよしとしてはいけない
- グループ全員が見積り受け入れられるように合意に達する
- 単なる見積り技法によって別々の結果が生じるときは、その結果が生じる原因を探してみよう。異なる技法から生じる結果の差が5%いないに集中するまで、再見積りしよう。
- うまくいかないプロジェクトの見積りのフロー
- インプット：この見積りのためだけに定義されたインプット
- プロセス：場当たり的な見積りプロセス
- アウトプット：？
- うまくいくプロジェクトの見積り
- インプット：技術的スコープ、優先度、制約条件、過去のデータ
- プロセス：標準的な見積り手順
- アウトプット：工数見積り、スケジュール見積り、コスト見積り、機能見積り
- 出来る限り、「判断する」ことよりも「数える」ことと「計算する」ことを重視する。
- その場しのぎの見積り手順を使用すると、見積りを改善するのは難しい。なぜなら、どの見積りプラクティスが不正確な見積りを作成したのか本当にはわからないからだ。
- プロジェクトの規模
