Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
34 lines (24 sloc) 2.97 KB
title tags
ジャンケン見積り
project planning
collaboration
estimation

http://martinfowler.com/bliki/ThrownEstimate.html

XPスタイルで計画を行っているのであれば、 見積りに関する開発者間の合意を素早くとる必要があるだろう。 こんなときは、ジャンケンで見積りだ。 ジャンケンで見積りを行えば、みんなの見積りが一致していかどうかがすぐに分かる(一致してればそれを記入し、作業に入ろう)。 また、意見の不一致もすぐに分かる(一致してなければ、機能の詳細についてさらに議論を重ねる必要があるということだ)。

顧客が見積りの必要があるストーリーをまとめている。 以下は、それぞれのストーリーに対する基本的な流れである。

  • 顧客はストーリーの概要を開発者に手早く伝える。

  • 開発者は顧客に質問し、ストーリーへの理解を明確にする。ここでは、どうやって実装するかといった技術的な議論はすべきではない。顧客の視点から見たスコープについて尋ねること。

  • 開発者たちは、そのストーリーが何NUTsかかるかを、エイヤと指の数を出し合って示す。私はこれを「ThrownEstimate(ジャンケン見積り)」と呼んでいる。というのも、指の出し方がジャンケンと同じだからだ。

  • 見積り結果が同じようだったら、書記がそれを書き留める。明らかにバラつきがあったならば、そのストーリーについてさらに深く話し合おう——いまこそ、どのように実装するかといった技術的な問題を取り上げるのだ。

指を何本立てるかについては、いくつかやり方がある。 あるプロジェクトでは、指1本で1NUTs、2本なら2NUTs、3本だとストーリーが大きすぎるので要分割、としていた。 またあるチームでは、指を立てられるのは1〜4NUTsまでで、指5本では大きすぎる、としていた。 いずれにせよ、ストーリーに難題があって見積り不可能だと言えるような"取り決め"を必ず設けておいて欲しい——ほとんどの場合はストーリーが大きすぎることによるものだが、なかにはテストできないからというの場合もあるだろうし、もっと他の問題が原因の場合だってあるだろう。

この方法を採用しているチームは、ストーリーの見積りを非常に早いスピードで行っているとのレポートが出ている。 素直に見積りの出来るストーリーには時間を割かず、 問題のありそうなストーリーに集中して議論を行っているのだそうだ。 この方法だと、全員を見積りプロセスに関わらせることが出来る。それに、なんといっても楽しい。

You can’t perform that action at this time.