見積り: 2007年9月アーカイブ
見積りの議論を、「交渉」ではなく、「問題解決」としてとらえよう。プロジェクトのステークホルダーたちは、全員がテーブルの同じ側にいる。全員が勝つか、全員が負けるかどちらかだ。
「ソフトウエア見積もり」
コミットメントは交渉できるが、見積もりを交渉の対象にしてはならない。
「ソフトウエア見積もり」
ごくわずかな可能性しかないプロジェクトの見積りなら、プロジェクトのステークホルダーには提示しない。
「ソフトウエア見積もり」
バッファ計画の出発点として、顕在化したリスク（RE)の合計を使おう。プロジェクトの具体的なリスクの詳細を見直したうえで、REの合計よりも大きなバッファを計画すべきか、小さなバッファを計画すべきかを最終的に判断しよう。
「ソフトウエア見積もり」
「信頼性を95%から99%に向上させたいなら、スケジュールの本体に25%を加えるべきである。」「信頼性を99%から99.9%に改善したいなら、スケジュールにもう25%を加えるべきである。」
「ソフトウエア見積もり」
最終的に、開発者とテスト担当者の構成比は、見積もりよりも計画によって安定する。つまり、あなたが「そうなるだろう」と予測することよりも、「そうあるべきである」と思っていることによって決まる。
「ソフトウエア見積もり」
計画パラメータの見積りは、あくまでも見積りである。つまり、粒度を細かくしたターゲットの設定と、粒度を細かくした見積りとが強く相互作用しながら、何度も繰り返されるべきものである。この段階における見積りのゴールは、初期の計画が現実的であることを確かめることであり、そこから先は、見積もりよりも、計画とプロジェクトコントロールが優先するはずだ。
「ソフトウエア見積もり」
中規模の業務システムプロジェクト（35,000〜10万LOC）では、チームの人数が7人を超えてはならない。
「ソフトウエア見積もり」
スケジュールを長くして、小さなチームでプロジェクトを実行して、コストを減らそう。
「ソフトウエア見積もり」
スケジュールの見込値を25％以上短くしてはならない。すなわち、見積もりを不可能ゾーンに入れてはならない。
「ソフトウエア見積もり」
適正な見積もり技法を使えば、規模の見積もりは他の見積もりの基礎となる。構築中のシステムの規模は、単体として最も大きなコストドライバである。正確に規模を見積もるためには、複数の見積もり技法を使おう。
「ソフトウエア見積もり」
具体的な開発タスクを配分して割り当てる準備ができしだい、ボトムアップ見積りに切り替えよう。
「ソフトウエア見積もり」
まず、規模の見積もりに焦点を合わせよう。次に、工数、スケジュール、コスト、機能を、規模の見積もりから計算しよう。
「ソフトウエア見積もり」
見積りのアウトプットについて議論してはいけない。アウトプットはそのまま受け入れよう。アウトプットを変更してよいのは、インプットに変更があったときか、または再計算した場合だけである。
「ソフトウエア見積もり」
複数の見積もりが一致したのに、ビジネスターゲットが一致しなかった場合は、見積もりの方を信頼しよう。
「ソフトウエア見積もり」
異なる見積もり技法によって別々の結果が生じるときは、その結果が生じる原因を探してみよう。異なる技法から生じる結果の差が5%以内に集中するまで、再見積りしよう。
「ソフトウエア見積もり」
見積りの焦点は、正確さに合わせるべきで、慎重な保守主義をとればよいというものではない。見積もりの焦点がいったん正確さから離れると、さまざまな原因から先入観が混入し、見積もりの価値を下げてしまう。不確実性に最もうまく対処するためには、見積もりから先入観を排除することだ。それと同時に、根底にある不確実性を正確に表現することも必要だ。
「ソフトウエア見積もり」
新しいプロジェクトを見積もるときは、過去の似たようなプロジェクトと比較して、できれば5つ以上の部分に分解して見積もろう。
「ソフトウエア見積もり」
最良ケースと最悪ケースの見積もりを作成して、起こり得るすべての範囲の結果について考えるきっかけにしよう。
「ソフトウエア見積もり」
タスクレベルの見積もりを行うときは、長くても2日程度の工数のタスクにまで見積もりを分解する。それより大きいタスクだと、想定外の作業が隠れる場所が多すぎる。見積もりは4分の1日、2分の1日、丸1日といった粒度で行うとよい。
「ソフトウエア見積もり」
タスクレベルの見積もりは、実際に作業に携わる者が見積りを作成しよう。
「ソフトウエア見積もり」
できるだけプロジェクトのデータまたは過去のデータを使用して、見積もりを補正しよう。できれば業界平均データは避けよう。過去のデータを使用して補正すると、より正確な見積もりができるだけでなく、生産性に関する前提の不確実性から生じる見積りのばらつきを減らすことができる。
「ソフトウエア見積もり」
できるときはいつでも、まず数えよう。数えられないときには、計算しよう。判断だけに頼るのは最後の手段だ。
「ソフトウエア見積もり」
見積りにとって重要なことは。完璧なまでに正確であることより、有用な情報を提供することである。
「ソフトウエア見積もり」
見積りを求められたときは、実際に見積もりを行うのか、ターゲットの達成方法を尋ねられているのかを判断すること。
「ソフトウエア見積もり」
「見積り」「ターゲット」「コミットメント」はそれぞれ異なるものであると認識しよう。
「ソフトウエア見積もり」
開発者の見積もりを削ってはいけない。なぜなら、既に十分楽観的すぎるからだ。
「ソフトウエア見積もり」
縮尺の錯覚：大きなシステムは､小さなシステムと似たようなもので､単により大きいだけだ。
「ワインバーグのシステム思考法」
ソフトウエアのサイズが増加すると、それ以上の比率で作業が増加するため、サイズを削減することは開発速度のかなりの向上につながる。普通の大きさのプログラムを半分の大きさに削減すると、一般的には必要な作業の2/3近くを削減できる。
「ラピッド デベロップメント」
プロジェクトの関係者が最初から再見積の必要性を理解していないと、再見積を行うことはスケジュールの遅れを容認することだと認識されてしまう。
「ソフトウェア プロジェクト サバイバル ガイド」
初期の段階でプロジェクトの規模を過小評価したり、プロジェクト チームの生産性を過大評価したりするのは仕方ないが、プロジェクトが進んだ時点で、見積違いを発見せず修正しないのは問題である。
「ソフトウェア プロジェクト サバイバル ガイド」
