Always All Ways

Apologies, Glances and Messed Up Chances

"An Introduction to Planning Poker" by Bob Hartman

Agile

[From the Archive: Originally posted at my old blog: Always All Ways: [Translation] "An Introduction to Planning Poker" by Bob Hartman Feb. 27, 2010]
[これは以前の私自身の旧ブログの記事（2010年2月27日）からの転載記事です]

This is a translation of the article "An Introduction to Planning Poker" by AgileForAll (Bob Hartman) published on Agile Zone.
Source URL: http://agile.dzone.com/articles/introduction-planning-poker
Please see also Bob's blog: http://www.agileforall.com/blog/

これは、Agile Zoneのサイトに掲載されたBob Hartman氏による「An Introduction to Planning Poker」という記事を氏の許可を得て翻訳したものです。
元の記事のURL: http://agile.dzone.com/articles/introduction-planning-poker
原文公開日：2009/11/11
合わせてBobのブログもどうぞ：http://www.agileforall.com/blog/

An Introduction to Planning Poker

プランニングポーカーはアジャイル開発で使われる見積り手法であり、近年とてもポピュラーになってきています。これは、ランド研究所（Rand Corporation）によって1940年あるいは1968年（どの情報源を信用するかによる）に考案されたワイドバンドデルファイ（Wideband Delphi）として知られる見積り手法をベースとしています。この手法は2002年にJames Grenning氏によってさらに洗練されました。そしてMike Cohn氏の"Agile Estimating and Planning"（日本語版タイトル：「アジャイルな見積りと計画づくり〜価値あるソフトウェアを育てる概念と技法〜」）で紹介されると、さらに広く知られるようになりました。この手法は何年も前から存在していましたが、Grenning氏が洗練することによってアジャイル開発のチームが利用できるようになり、彼らはフルにその恩恵を受けてきました。

プランニングポーカーのやり方はとてもシンプルで、しかもアジャイルな見積りに使うのに十分な正確さを持っています。基本的なルールは以下の通りです。

  1. 参加者はそれぞれ、数列を表す数字の書かれた見積りカードのデッキを持ちます。使われる数列としては、倍々になっていくもの（0, 1/2, 1, 2, 4, 8, 16, …）やフィボナッチ数列（1, 2, 3, 5, 8, 13, 21, …）がありますが、フィボナッチ数列の方がより一般的です。
  2. 進行役（モデレータ）がチームにユーザーストーリーを一つずつ提示します。
  3. プロダクトオーナー（もしくはそれに相当する役割の人）がそのストーリーに対するチームからの質問に回答します。
  4. 参加者は、ユーザーストーリーの規模のそれぞれの規模見積りを示すカードを他人に見せないようにして選びます。通常、その見積りは時間やリスク、複雑さなどの要素を考慮した値となります。
  5. 全員がそれぞれの見積りの用意ができたら、そのカードを同時に見せ合います。
  6. もし数字が一致していれば、その規模を記録して、次のユーザーストーリーに進みます。
  7. 見積りに差がある場合（そうなることの方が多いのですが）には、最も高い見積りをした人と最も低い見積りをした人がチームの他のメンバーに対して、その正当性を説明します。
  8. グループで短い議論を行います。
  9. そしてもう一度見積もりを行います。（上のステップ４と５を繰り返します。）
  10. コンセンサスが得られるまでこれを続け、進行役が見積りを記録します。
  11. これを全てのユーザーストーリーに対して行います。

プランニングポーカーの使用を推進している人々は、なぜそれが成功するかの主な理由を理解しています。Mike Cohnのような人たちはプランニングポーカーの普及に大変貢献していますし、分散したチームでもプランニングポーカーができるように http://www.planningpoker.com のようなサイトも立ち上げています。多くのアジャイルトレーナーやコーチ（私自身も含む）がなぜその利用を推進するのか、しっかりとした理由があるのです。

私が個人的に考えるプランニングポーカーが素晴らしい理由のトップ３は以下の通りです。（これらは、チームがプランニングポーカーを適切に使えば、という前提付きですが。）

  1. チーム全員で取り組むことでコラボレーションが促進される
  2. 一個人が見積りを仕切るのではなく、合意に基づく見積りができる
  3. ひとつひとつのユーザーストーリーを早い段階で議論することで問題が明らかになる

これらは全てプランニングポーカーを使う強力な理由となります。しかし、それをもっとうまくやるためのいくつかの方法もあります。上に挙げた３点は全てプランニングポーカーを使うチームが成功するのを見ていたらすぐにわかるものです。しかし、プロセスを改善するためにできる小さなことで、ほとんどの人々が忘れていることがあります。それを知ることによって、成功するコーチがチームをよりよくすることに役立ちます。それのよいところはあなたがチームの改善を助けるためにあなた自身が必ずしもコーチである必要がなく、ただチームが信頼を寄せる存在であればよいということです。ここからその黄金の知恵を見ていきましょう。

実際に仕事をすることができる人が投票する人です。アジャイルチームではしばしばそのユーザーストーリーに含まれる仕事に関する知識がない場合でも全員に投票させてしまっています。

マネージャーは投票しません。マネージャーは普通その仕事をより短い時間で終わらる方向に動機づけられています。したがって彼らは見積りを必要以上に低く歪めてしまいます。一方で、マネージャーは通常平均的なチームメンバーよりは多くの経験を持っていますので、チームが合意したものに対する拒否権を認めています。ただし、ある特別な状況下においてのみです。すなわち、彼らは見積り規模を大きくさせるかもしれない要因を考慮したかどうかチームに尋ねることができるのです。マネージャーがチームに見積り規模を小さくさせることを決して許してはいけません。マネージャーの意見はとても重みがあり、規模に対してアンカーになってしまいます。そして彼らが自分のポジションを熱心に守ろうとすればするほど見積りは低く抑えられてしまいます。

２つの連続したサイズの間で票が割れたときは、大きい方を採用して次に進みましょう。見積りにフィボナッチ数列（1, 2, 3, 5, 8, 13）を使っている場合、連続したサイズとは例えば5と8になります。大きい方の数字を採用することに誰もまあ文句を言わないでしょうし、票が２つに割れた時は決着がつくまでに長い時間がかかります。そして少なくとも私の経験ではだいたい大きい方に落ち着くのです。ですから、そういう事実を有効に使ってどんどん進めましょう。

実装に関する議論は深入りする前に止めましょう。チームがユーザーストーリーを議論するときに技術的な詳細に突っ込んでいくというのはよくあることです。ある程度までならそれもよいのですが、それには厳しく制限をかけるべきです。１分間までの議論にしましょう。規模見積りを行う人はできるだけ簡単な実装方法を頭に描き、そのシナリオに基づいて規模を見積もるべきです。議論をするほど規模見積りはより正確になるほうな気もします。しかし現実にはそれは正しくありません。そもそものものさしの粒度が揃っていないわけですから、精度に欠けるのは明白なのです。チームが最善の見積りができると思える程度に部分的に議論して、次に進みましょう。

「休憩しよう」カードを使いましょう。チームがプランニングポーカーに熱心になり、チームの誰かが休憩を必要としていることに気がつかないことがよくあります。そんな時に「休憩しよう」カードを持つことで、みんなの注意を引くことができます。

議論の時間を制限するために何らかのタイマーを使いましょう。これは説明するまでもないですね。私は議論を１分以内に制限するのが好きです。

３ラウンド回してみても完全合意に至らない場合には、出された中で最大の規模を採用して次に進めましょう。議論の２ラウンド目を過ぎると、もうそれ以上の議論はそれにつぎ込む時間の割には大した結果をもたらしません。最大の数字を選んでおけば、チームはそこから改善することもできるし、時間が足りなくなるという危険にさらされるっこともないでしょう。十分な時間がないというのはチームが避けたい主な問題の一つです。ですから、ショートカットをとることがその問題を生じさせることがあってはならなりません。

プランニングポーカーをやる前に、ユーザーストーリーを作る人にはQA（品質保証）や開発のリーダーたちに会ってもらい、チームが尋ねそうなすぐわかる質問の答えがユーザーストーリーから読み取れるようにしておきましょう。それによって、チームが情報の収集に時間を使わず、規模の見積りに専念することが可能になります。

ベースラインを忘れないようにしましょう。チームがベースラインとして選んだものはイテレーションが進んでも首尾一貫している必要があります。もし理想日を規模１としたら全てのイテレーションでその参照ポイントを使わなければなりません。あるユーザーストーリーが規模１とか規模３とかであれば、それはどのイテレーションにおいても同じであるべきです。そのためには、いくつかのユーザーストーリーの規模見積りをした後にベースラインを持ち出してチームにその見積りとベースラインとの相対がきちんとしているかどうか尋ねてみることが役に立ちます。それをやらないと、時間が経つにつれて、私の言う「サイズ・クリープ」という現象が現れます。言い換えれば、チームが次第に心の中で本当よりもベースラインを大きくあるいは小さく変えてしまうのです。これは結果として、全て同じように見えるのにチームがいくつかのイテレーションにわたるコミットメントを果たせないという形で現れることになります。

楽しくやりましょう！プランニングポーカーは楽しく恊働的な活動であるべきです。あまりにも多くのチームが１時間も２時間もがむしゃらにプランニングポーカーをやって、仕事を楽しむことを忘れています。プロセスの中に楽しさを注入する方法はたくさんあります。その中でも私のお気に入りの一つは見積り規模で本当のポーカーをすることです。規模見積りをしたユーザーストーリーをポーカーのカードに見立てて、ユーザーストーリー５つがポーカーの手札になります。始める前に、全員がどの手札がもっとも良いポーカーの手になるか選びます（例：　手札１、手札２、手札３、など）。これによって、どの５枚セットがストレートやフォーカードになるか当てるために事前にユーザーストーリーをチームが見ることになります。勝者はちょっとした賞品ももらえます。

これらのヒントとともにプランニングポーカーをやってみて、それがあなたのチームの役に立つかみてみてください。

あわせて読みたい


Agile Estimating and Planning (Robert C. Martin Series)

Agile Estimating and Planning (Robert C. Martin Series)

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~