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

WEB+DB PRESS Vol.93 実践見積り

WEB+DB PRESS Vol.93

WEB+DB PRESS Vol.93

見積りの不確実性とかアジャイルとか具体的な見積り法などについて。
 
個人的には認知バイアス、Mob Programmingの話が面白かったです。 また、利用したことのなかったファンクションポイント法について記載されているのも良かったです。
以下は個人的に気になったとこ。

認知バイアス

そこで出された数字によって後から出す数値の判断が歪められ、最初の数字に近くバイアスがかかること。

営業「だいたい100万円くらいでできる?」
幹部「5日くらいで作れる?」

これ超あるある。無意識にこの数字に寄せようとしてしまいます。
 

認知バイアスを避ける方法

ワイドハンド・デルファイ法

グループによる費用見積もり。

  1. まとめ役が仕様書と見積書のフォームを見積り者に提示
  2. 見積り者はそれぞれ単独で見積りを行う
  3. まとめ役がミーティングを開催し、ここで見積り者同士が内容について議論。
    (議論があまりなく結論に合意した場合は、反対役を割り当てて議論を促す)
  4. 見積り者は3での議論を踏まえて自分の見積りを無記名で提出する
  5. まとめ役は提示されたものをまとめて全員に渡し、比較できるようにする
  6. まとめ役は見積り者を集めて、まとめた結果について議論させる
  7. 見積り者は平均値を受け入れるかどうか無記名で投票する。

これ凄い良さそうだけど、見積り作業のコスト自体が高そう。 でも複数人で見積もるのは取り入れてみたい。

Mob Programming

これからの見積り方法として紹介。
5人のプログラマーが1つの機能開発に15分くらいずつ交代で開発するというもの。 残りの4人はスムーズに開発できるようにナビゲートする。

No Estimates(見積りしない手法) と組み合わせた場合、
10倍以上の生産性の向上が見られたという報告もある。
機能の作成プロセスがわからなくて、チームメンバーのそれぞれの納涼区が不明の場合は、
まず全員で同一の課題に取り組み、問題を全員で理解し、
全員でプロセスを考えるのが有効です。

PoCのコード書くのは、大抵プロジェクトで一人だったりするのですが
これを全員でやってみるという発想が面白いです。
技術検証は面白いのですが、時々孤独を感じるので、こういうのやってみたいですね。
 
いずれにせよ、見積りの精度をあげるための作業はサボりがち。振り返りのテーマに入れたいところ。
(振り返り自体もすっ飛ばされることも多々あるけど)