ずいぶんと以前にどこかで知ったことをメモったもの。
おおむかしの話にはなるけども、今も変わりはないと感じる。
あたりまえだろ、みたいなところなんだが、
ここは権威を借りて記しておくことに意味がある。
すでに出典がわからなくなってるものもあるし、少し自分で文章をいじったものもありそうだけど。
・過度のスケジュールプレッシャーは、
エラー対策に極端に費用がかかるモジュールを生み出す最大の原因である
(Jones1991)
・スケジュールプレッシャーが極端なときにリリースされた製品は、
プレッシャーが少ないときに開発されたものと比べて約4倍の不良が発生する
(Jones1994)
・期限に対するプレッシャーはソフトウェアエンジニアリングの唯一最大の敵である
(Costello1984)
・過度、または不条理なスケジュールは
ソフトウェアすべてに対して唯一最大の破壊的な影響がある
(Jones1991,1994)
・見積もり結果を疑うのは有効な手段の一つだが、
明らかに無理な期間や費用の（切望する）見積もりに書き換えることは
自殺行為なのにそれを行なうことが多いのはばかげている。
（出典不明）
・楽観的すぎるスケジュールは、少しの遅延では終わらない。
平均的な小さなプロジェクト見積もりでは、100%以上の遅延になる
(Standish Group1994)
・楽観的で達成不可能なスケジュール設定は、
プロジェクトが計画なしで実行されるリスクを増大させる。
→そして上流工程（要求分析・設計）の手抜きの原因となる
→かつ下流工程では余分なテスト、不良修正、再設計、やり直しが多発
→結果、最初から適切に作業を行なった場合より10～100倍の費用がかかる
(Fagan1976,Boehm and Papaccio1988)
・楽観的すぎるスケジュールとそれに付随したプレッシャーは、
転職希望率を極端に高める原因になりがち
そしてプロジェクトを離れていく人達は、
高いパフォーマンス評価を持つ有能な人達であることが多い
(Jones1991)
・（遅延など）失われた時間を取り戻すのはほとんど不可能であり、
プロジェクトはさらに遅れる傾向にある
(Van Genuchten1991)
・プログラマはプロジェクトを20％～30％少なめに見積もりがちである
(Van Genuchten1991)
まずはこの本を読め！
『ソフトウェア見積り 人月の暗黙知を解き明かす』
内容はこんなかんじ。
