Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

スケジュールにまつわるエトセトラ。

ずいぶんと以前にどこかで知ったことをメモったもの。
おおむかしの話にはなるけども、今も変わりはないと感じる。

あたりまえだろ、みたいなところなんだが、
ここは権威を借りて記しておくことに意味がある。
すでに出典がわからなくなってるものもあるし、少し自分で文章をいじったものもありそうだけど。


・過度のスケジュールプレッシャーは、
 エラー対策に極端に費用がかかるモジュールを生み出す最大の原因である

 (Jones1991)

・スケジュールプレッシャーが極端なときにリリースされた製品は、
 プレッシャーが少ないときに開発されたものと比べて約4倍の不良が発生する

 (Jones1994)

・期限に対するプレッシャーはソフトウェアエンジニアリングの唯一最大の敵である
 (Costello1984)

・過度、または不条理なスケジュールは
 ソフトウェアすべてに対して唯一最大の破壊的な影響がある

 (Jones1991,1994)

・見積もり結果を疑うのは有効な手段の一つだが、
 明らかに無理な期間や費用の(切望する)見積もりに書き換えることは
 自殺行為なのにそれを行なうことが多いのはばかげている。

 (出典不明)

・楽観的すぎるスケジュールは、少しの遅延では終わらない。
 平均的な小さなプロジェクト見積もりでは、100%以上の遅延になる

 (Standish Group1994)

・楽観的で達成不可能なスケジュール設定は、
 プロジェクトが計画なしで実行されるリスクを増大させる。
 →そして上流工程(要求分析・設計)の手抜きの原因となる
 →かつ下流工程では余分なテスト、不良修正、再設計、やり直しが多発
 →結果、最初から適切に作業を行なった場合より10~100倍の費用がかかる

 (Fagan1976,Boehm and Papaccio1988)

・楽観的すぎるスケジュールとそれに付随したプレッシャーは、
 転職希望率を極端に高める原因になりがち
 そしてプロジェクトを離れていく人達は、
 高いパフォーマンス評価を持つ有能な人達であることが多い

 (Jones1991)

・(遅延など)失われた時間を取り戻すのはほとんど不可能であり、
 プロジェクトはさらに遅れる傾向にある

 (Van Genuchten1991)

プログラマはプロジェクトを20%~30%少なめに見積もりがちである
 (Van Genuchten1991)


まずはこの本を読め!
『ソフトウェア見積り 人月の暗黙知を解き明かす』
内容はこんなかんじ

広告を非表示にする