いいかげん疲れた
- ある修正によって発生した副作用をその場で検知し対応しておかないと、後々にバグ探知で無駄な時間を費やすことになるよね。
- そして、バグ探知と対策ほど「作業見積りをしにくい」工程はないよね。
- プロジェクト計画管理で一番困るのは作業見積りと実績の大幅な乖離のはず。
生産性を考える - 今日も反省の色なし(masayangの日記
- にも関わらず、ウォーターフォール開発では「テスト」という期間があらかじめ計画され、そこの範囲内で作業を終わらせようとする。
- つまり、バグがいくつ出るか、それらのバグの探知対策に要する時間がどれくらいか、最初から見積もられているわけだ。
- すごいよね。凡人の俺様にはできない。
- というか、多分ほとんどの人には、できない。
- テストで検知された問題点にはそれなりに対処するけど、「与えられた時間内でできるだけバグを拾う」域をでない、というのが現実。
うちはバリバリのWF開発です。上で書かれているように、開発量に対してどれくらいバグが潜んでいるか、バグ密度を見積もります。バグ密度は、開発内容の難易度とか担当者のスキルなどから、計算式で自動的に算出されます。
- そしてこの見積もり、2件〜3件/1KLOCとかいう値になるときがあります。
- 2〜3件って、、、その差1ですか。
- そして、例え±1件見積もりが外れたとしても、上への報告ができないだろごるぁっ！となぜ乖離したか説明を求められる
- そんな変な説明を考えるくらいなら面倒なのでごにょごにょとする人も・・・。
