良く、「経理に詳しい者を運転手にしてはならない。それは間違った人材配置だ」ということを言うが、プロジェクトでも一緒である。作業者のスキルと担当作業を一致させることが大切である。 失敗例 デザイン担当者にXDでデザインを作ってもらい、フロントエ…

■ 当初の目的 ソフトウェアプロジェクトのスケジュールに対する見積もりを改善する。 ■ やったこと ソフトウェアプロジェクトのスケジュールを作成したとき、当初予定の工数、つまり見積もり工数を記録しておく。プロジェクトが終わったら、実際にかかった工…

これはドラフトである。まだまとまっていないが、書きながら整理していきたい。 状況 0.5人日~3人日程度の規模の小さなタスクが多い。 定例作業があり、0.5H~4H程度かかる。 納品日や作業期日は厳しくなく、ずらす事ができる。ただし、時々、外部システム連…

5章以降の話は、本格的な規模の大きいプロジェクトでは使えそうだ。しかし、自分の所属する開発チームは7人日程度の工数が最大だ。そのため、あまり5章以降の話ですぐに生かせそうな話題がない。そこで、自分が気になったポイントをピックアップしてここに書…

■見積もり誤差の発生要因 プロジェクトに関する不正確な情報 開発チームに関する不正確な情報 プロジェクトの混乱→ 移動するターゲットの見積もりは困難であるため 見積りプロセスが適切でない ■ 見積もりの不確実性はプロジェクトの決定事項に依存する 不確…

この素晴らしい本の内容を忘れてはいけない。 そういう強い思いから、ここに自分が特に覚えておきたいと思う、ソフトウェア見積もり技術の要点を書き記す。 ■見積もり、ターゲット、コミットメント ○ 見積もり ソフトウェアプロジェクトにかかる以下を予測す…