アジャイルの全体見積りとリリースロードマップ作成ポイント

アジャイルのメジャーな見積りプラクティスにプラニングポーカーがある。
その名の通り、ゲーム感覚で楽しんで見積る方法だ。
開発者にとって、作業見積りはストレスを感じることだから、少しでも負担を減らして楽しみながらできる仕組みだ。

進め方はこうだ。
開発者は全員同じ数字のカードセットを持つ。
大抵、1，2、3，5，8，13の6種類。これを使って見積る。

1．最初に小さな（小さそうな）バックログを選ぶ。
2．プロダクトオーナーがバックログの内容を説明する。
3．開発チームとの質疑応答。
4．開発者は各自で見積り、カードを伏せてテーブルの上に置く。
5．一斉に表に向ける。
6．1番大きな数字を出した人、および1番小さな数字を出した人が、根拠を説明。
7．再び、見積りして、一斉にカードを見せる。
8．繰り返す。まとまってきたら平均の数字、または一番大きい数字をチームの見積りとする。
9．チームで合意したバックログを、ベースライン・バックログとする。
10．以降の見積りは、ベースライン・バックログと比較し、2倍とか、半分と決めていく。

ベースライン・バックログを決めた後、2~3個、他のバックログを連続して見積る。
そうすると、チーム全体で見積り2と3の幅、3の5の幅がわかってくる。連続して2つめ、3つめと見積ることで、見積り間隔が明確になる。

数字は時間ではない。抽象化した規模だ。
2は2時間ということではなく、単純に2という大きさを表わす。あえて抽象化しているのは、その方がスピーディーに決められるから。

プラニングポーカーもタイムボックス・イベントである。
あらかじめ時間を決めて、さくさく見積っていく。だらだらやらない。

これから取りかかるプロダクト開発の初期段階で、精緻な見積りを出すことは不可能である。
プロジェクトと同じで、最初は情報が一番少ないのだ。
ユーザーの要求も全部揃わないし、仕様だってどんどん変わっていく。

不確実性のコーンをご存じだろうか。
プロジェクト初期の見積りは、実際の4倍から1/4倍までばらつきがある。
だから、最大で16倍の誤差がある。

進めて行くにつれて、情報が蓄積され、状況が安定し、徐々に見積りの精度が増す。

だから、初期段階で、実時間で実装にかかる時間をうんうんうなって見積っても意味がないのだ。変わる前提の見積りだから、ゲーム感覚で、スピーディーに進めるのがいい。ばば抜きやブラックジャックをしている要領でテキパキと見積っていく。

ここまで読んで気がついた人もいると思うが、見積る単位は数字じゃなくてもいい。時間じゃないのだから、動物の大きさとか、フルーツの大きさとか、相対的にサイジングできる物であればなんでもいい。

一般的なのはフィボナッチ数列だが、他にもいろいろある。

ドッグポイント
ズーポイント
フルーツポイント

開発チーム毎に、好きな尺度で決めればいい。メンバー全員が感覚的にイメージしやすく、楽しめるものがいい。

プラニングポーカーをする上で、重要なポイントはスピード、そして、全員一斉に見積ることである。

なぜ一斉なのか？
バンドワゴン効果とハロー効果を排除するためだ。

バンドワゴン効果は、大多数の人が同一意見である時、一人だけ異なる意見を言うことをためらってしまうことだ。

レストランで注文するとき、皆が「日替わり」を頼んでいるときに、自分だけアラカルトから選ぶのは気が引けるものだ。
仕事でも自分は「選択肢A」だと思っても、前の6人全員が「選択肢B」だと結論づけた後、自分だけ違う意見を言うのはなかなか度胸がいる。協調性を重視する日本人ならなおさらだろう。
ありのままの自分を表現するには一斉でないといけない。

ハロー効果は、ある一つのことについての特徴が、他のことの評価に影響を与えることである。
あることが優れている人を、全く無関係な別のことにおいても優れていると判断しがちなことだ。

例えば、算数がクラストップの友人がいるとする。国語については、無関係なのに、きっと国語もできるんだろうと勝手に決めつけてしまう。
仮に自分の尊敬する先輩が同じチームであったとすると、その人の見積りに過度に影響を受けてしまうのが典型例だ。
だから、ここでも自分の考えをありのままに表現するには、一斉でないといけない。

プライングポーカーは市販のトランプを使ってもできる。
ズーポイントなら、好きな動物の絵を描いて手作り感満載のカードを作ってもい。
フルーツポイントなら、マグネットシートにフルーツを描いて、カード状に切り、見積り時にホワイトボードに貼り出してもいい。
一つのストロベリー、二つのストロベリー、三つのストロベリーなんかおいしそうだ。
もちろん、バラエティー重視で、ストロベリー、キューイフルーツ、ミカン、リンゴ、メロン、スイカでもいい。

開発者は堅苦しいのが苦手だ。ドーナツ食べながら、リラックスして、ポーカーしながら見積っていく。

ざっくり全体見積りができたら、イテレーションの度に見直していく。数回イテレーションを回したらチームのベロシティが見えてくるから、それを踏まえて全体見積りを洗練していく。
不確実性のコーンも時間と共に誤差が減っていくから、見積り精度はどんどん高くなってゆく。

全体見積りを最初から実際の時間でするのは無駄だ。
特に、新しいチームではバックグランドも経験値も違う。あるストーリーをベースライン化して、それを軸に見積っていくのがいい。

相対見積りの理由はこちら。