人月の暗黙知の本 - hitode909の日記

見積りについて興味が出てきたので読んだ．コードコンプリートを書いたスティーブマコネルの本．
具体的な見積りの技法が紹介されているけど，それよりも，いい話がたくさん書いてあって良かった．

見積りとターゲット見積り=作業量とか規模とかターゲット=いつまでにほしいとか
- 数ヶ月後の発表会のための開発なら，その規模のものは作れませんではなく，間に合うような物を一緒に考える
- 技術的な知識を使っていろんな代案を出すのは技術者の責任
即興で見積りしてはいけない→正確ではない
専門家の判断は品質が低い→正確ではない
計算できるなら計算しなければならない
見積りに幅を持たせるこの期間で終わる確率は何%とか，最良で何週間，最低で何週間，とか
- そのときも計算する
高く見積るとプロジェクトが却下されるからといって安く見積ってはいけない
- 正しい情報を提供できないので，意思決定できなくなってしまう
- リソースが本来コストに見合うプロジェクトから，コストに見合わないプロジェクトに流れてしまう
見積りについての議論では交渉ではなく問題解決するパイの奪い合いではなく，テーブルにいる全員が勝つか負けるか
- 最後の章が良かった

僕は「普通にやるとこの日までにはできます，すごく急げばこのくらい」みたいな話をよくしていて，見積りとコミットメントを一緒に話していた．2日で終わる作業だけど，他のタスクのすき間にやるので1週間かかります，これだけやればうまくいけば2日です，みたいな．
どちらが良いか分からないけど，最速ではここ，最悪でここ，みたいな話をできるとよいかもしれない．しかし，最良の場合と最悪の場合を伝えると，まさか最悪の状態に至るとは思いにくい，俺たちはいつでも最高でしょ，みたいなイメージもありそう．
よく言われてることだけど，過去のデータを取っておいて見比べよう，という話があって，簡単でもいいのでデータ貯めていきたい．ところで，規模をどう見積るかという話もあって，GitHub時代ならpull requestのdiffの行数とかだと見やすいけど，コンパイルすると増えるファイルなどが混ざっていると難しくなりそう．そしてたいていコンパイルすると増えるファイルはけっこうな勢いで増えたりする．そういうものはリポジトリから除いていきたい(すでにだいたい除いている)．
Kindleで読める．おすすめです．