読者です 読者をやめる 読者になる 読者になる

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)


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

広告を非表示にする