見積りの最近のブログ記事

見積りの議論を、「交渉」ではなく、「問題解決」としてとらえよう。プロジェクトのステークホルダーたちは、全員がテーブルの同じ側にいる。全員が勝つか、全員が負けるかどちらかだ。

「ソフトウエア見積もり」

コミットメントは交渉できるが、見積もりを交渉の対象にしてはならない。

「ソフトウエア見積もり」

ごくわずかな可能性しかないプロジェクトの見積りなら、プロジェクトのステークホルダーには提示しない。

「ソフトウエア見積もり」

バッファ計画の出発点として、顕在化したリスク（RE)の合計を使おう。プロジェクトの具体的なリスクの詳細を見直したうえで、REの合計よりも大きなバッファを計画すべきか、小さなバッファを計画すべきかを最終的に判断しよう。

「ソフトウエア見積もり」

「信頼性を95%から99%に向上させたいなら、スケジュールの本体に25%を加えるべきである。」「信頼性を99%から99.9%に改善したいなら、スケジュールにもう25%を加えるべきである。」

「ソフトウエア見積もり」

最終的に、開発者とテスト担当者の構成比は、見積もりよりも計画によって安定する。つまり、あなたが「そうなるだろう」と予測することよりも、「そうあるべきである」と思っていることによって決まる。

「ソフトウエア見積もり」

計画パラメータの見積りは、あくまでも見積りである。つまり、粒度を細かくしたターゲットの設定と、粒度を細かくした見積りとが強く相互作用しながら、何度も繰り返されるべきものである。この段階における見積りのゴールは、初期の計画が現実的であることを確かめることであり、そこから先は、見積もりよりも、計画とプロジェクトコントロールが優先するはずだ。

「ソフトウエア見積もり」

中規模の業務システムプロジェクト（35,000～10万LOC）では、チームの人数が7人を超えてはならない。

「ソフトウエア見積もり」

スケジュールを長くして、小さなチームでプロジェクトを実行して、コストを減らそう。

「ソフトウエア見積もり」

スケジュールの見込値を25％以上短くしてはならない。すなわち、見積もりを不可能ゾーンに入れてはならない。

「ソフトウエア見積もり」