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

道草道

大崎上島での移住の記録(2016年4月~):子育て・古民家改造・裏山開拓・造船所・たまにプログラミング

レガシーコード体質改善 2 見積もり

 

レガシーコード漂流記 島が見えた?? - 道草道

 

これの続きです。

見積もりについて書きたいと思います。

 

よく見積もりで問題になりませんか?

納期に遅れる、期限を守れない、なぜ、正しく見積もれないのか?など、など。

 

レガシーコードになる原因として、

  • コーディングの技術の前に、見積もりが正しくないため、どんどん時間がなくなる
  • そもそも、コードをメンテナンスする時間など、コーディング以外の時間を密mれていない

など、見積もりが原因な部分が多々あると思います。

 

見積もりって、結構、早い段階で出さないといけないですよね。

予算取りに必要とか、スケジュールが決まっているとか。

情報が不十分な段階で、とりあえず出してと言われ、とりあえず出したが最後、それが最終見積もりとなってしまう。。。

 

何の根拠もない適当見積り、なぜ、その適当見積もりでソフトが作れると思うのか?きっと、それで作れると思いたいんだろうな。。。

自分の会社だけ?かもしれませんが、それほど、他社も変わらないんじゃないかな?と思います。

 

アジャイル侍なんかにも書いてありますが、見積もりなんて当てずっぽうでしかないと思います。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

 

 1時間、2時間、の見積もりなら結構正確ですが、1週間となると相当怪しい、1カ月先なんて誰も分からない気がしています。

それでも、1か月、線を、ぴゅーーっと引いて、これがスケジュールです。

って出さないといけない、それは、見積もり通りに行かなくて当然じゃないですか?

 

 最近見つけた、これいいなと思える見積もり方法が、この本に書かれているPFDを使った見積もり方法。

プロジェクトマネジャーのためのプロセスデザイン入門

プロジェクトマネジャーのためのプロセスデザイン入門

 

 

PFD(Process Flow Diagram)とは、成果物とプロセスの連鎖を表現して整理を行うプロセス改善のためのツールの1つです。

http://homepage3.nifty.com/koha_hp/process/PFDform3.pdf

まだ、PFDを十分に理解したとは言えないですが、最近よく書いてます。

 

アジャイル侍」にも書いてある内容ですが、人は作業が何日かかるか?見積もるのは下手ですが、2つの作業の比較は得意らしいです。

それは経験上なんとなく分かる気がします。

 

「プロセスデザイン入門」に書かれている方法は、PFDを使って、プロジェクト終了までに必要なプロセスを描き出す。

 

描き出したプロセスには、成果物があるので、その成果物の工数を見積もる。

そのプロセスの合計が見積もり工数となる。

そんな感じです。(自分流の解釈が入っていますので、正確には本見てください)

 

その他、工数管理の方法やバッファの使い方など、参考になる部分は多いですが、今のところ、そこまでは試せていません。

 

特にバッファの管理の部分で、

「学生症候群」:期間に余裕を持たせても人は余裕を使ってしまう

などは、面白いなあと思います。

 

この本で、なるほど~っと思ったのは、

p111 見積もれるのは「サイズ(量)」です。サイズは測れるからです。

と言う部分。当然と言えば当然なのですが。

 

仕様書を作成するという場合、漠然と2日とか見積もってしまっていました。

 

過去のプロジェクトの仕様書があれば、今回の規模と比較して仕様書何ページと見積もれる。過去のプロジェクトで1ページ当たりに何時間かかっているか分かるから、今回はこれくらいと見積もれる。

これでも、正確ではないですが、ざくっと2日より全然精度はいいと思います。

 

今回の仕事では、PFDで見積もるのが初めてだったこともあり、どうやってそこまで細かく細かく書いていいのか分からなかったので、そこまでの細かい見積もりはしていません。

 

今回、やりたかったことは、工期的には約3か月×1人のプロジェクトを、だいたい把握可能な大きさのプロセスに分割してもらって、全体の見通しを立ててもらうこと。

 

週単位くらいのプロセスに分割してもらって、そのプロセス毎に計画を立ててもらって、作業してもらっている感じです。

 

それでも、見積もりのズレは当然ありますが、プロセスを分割することにより、見積り精度はかなりよくなると思います。何より自分がしている工程が全体のどの部分なのか、自分にも周りにも説明しやすくなります。

 

PFDで、始まりから終わりまでのプロセス全体を見通せるようして、USDMで、作成しようとしているプログラムの全体を見通せるようする。

 

PFDでプロジェクト全体の進捗を監視して、USDMで仕様の実装率の監視。

TDDで、作ったところを壊していないことを確認しながら作業を進める。

こんなイメージで仕事を進められたらいいのではないかと思っています。