おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

アジャイルサムライ読書会 at 大阪道場 第5回 の個人的ふりかえり

きのう、アジャイルサムライ読書会 at 大阪道場 第5回 に行ってきました。今回で4回目の参戦になります。

1チーム6人ごとの2チームに分かれて、ワークショップ&ディスカッションしました。

プランニングポーカーのワークショップ

うちの「インセプションデッキをつくる」を見積り対象として設定して、見積りました。
もう一つのチームは「居酒屋を開業する」だったようです。

インセプションデッキは10個の手ごわい質問と課題から構成されています。
それぞれ完成させるのにどれくらいかかるかをプランニングポーカーで見積もっていきました。

基準となる小さめの課題を決めて、あとは相対的に見積もります。
ブレがいちばん少なそうな「『ご近所さん』を探せ」を今回は基準の 2pt として進めました。

最初は基準を「エレベーターピッチ」に設定していましたが、それぞれが想定している作業内容に大きな差異があることが判明しました。そのため、途中で基準を変更しました。(柔軟な方向修正は歓迎ですね)

時間が来てしまい、40分くらいで10個のうち5個しか見積りできませんでした。見積り結果は次のとおり。残り5個もやり遂げたかったというのが正直な思い。

 8pt 「我われはなぜここにいるのか?」
 5pt 「エレベーターピッチ」
 5pt 「パッケージデザイン」
 3pt 「やらないことリスト」
 2pt 「『ご近所さん』を探せ」

実は、インセプションデッキの勉強

各人が想定しているインセプションデッキ各作業のイメージ、作る際のプロジェクト背景・対象システムなど、バックボーンや前提が実は異なっているため、ポーカーの見積り差異が大きくなることが多々ありました。

・プロジェクトやシステムの目的を知っていること前提か?/まったく知らない前提か?
・プロジェクトメンバー全員が意識が高いとは限らない(プログラミングだけしか考えない人もいるかも)
・作るのはすぐだけれど、それまでに悩む・議論する時間をどれくらいに考えているか?
・Done の定義をどこまでで設定しているか?例えば、パッケージデザインは内部認識レベルで留めるなら作業量は少ない

そういう意味で、プランニングポーカーをしながらインセプションデッキの勉強ができました。
インセプションデッキをつくる」のプランニングポーカーはワークショップとしておもしろいです。議論発散には注意ですが。

ワークショップのあとは、プランニングポーカー・見積りについてのディスカッションとなりました。
以下、心に残ったトピックをまとめます。

三角測量をすべきか

アジャイルサムライ』には次のようにあります。

三角測量(Triangulation)は、代表的なストーリーをいくつか基準として選出して、残りのストーリーを、基準になるストーリーとの相対サイズで見積もるやり方だ。

例として、小・中・大の基準となるストーリーを設定して、分類していくやり方が紹介されています。最初にいくつかストーリーをピックアップする必要があります。

一方で、基準となる比較的小さめのストーリーをひとつ設定して、それとの相対サイズで見積もっていく方法があります。今回はこちらの方法を選択して進めました。

ふりかえってみて、最初から三角測量をすることは必須ではないと感じました。最初に基準としてひとつだけを選択したとしても、途中で見積済みのストーリーが複数存在する状態になります。つまり途中から「これよりも大きいが、あれよりも小さい」的な見積り思考になります。これって三角測量ですよねということです。

最初の段階で一気に3つも見積もるのはしんどいので、途中から三角測量になるのでよいと思います。

目的は見積りだけではない

プランニングポーカーの効果としてよく挙げられますが、全員で見積りができるだけではなく、ストーリーや背景の共有、リスクの顕在化ができることも大きいです。プランニングポーカーを通して、ディスカッションができます。経験の浅いメンバーの教育にもなるという意見もでました。

今回もインセプションデッキのディスカッションができました。

作業を見積るという意識になると、仕様理解やリスク分析の真剣度が増すような気がします。アウトプットとして、数値を出さないといけないとなるとシビアになりますよね。
作業依頼をするときなど、仕様説明をすると思います。そういったときに、単純に「ストーリーの理解をしよう」という持っていき方より、「これからやってもらうストーリーをお互いに見積ってみましょう」という方がいいかもしれません。

メンバーの意見を引き出すために

プランニングポーカーで見積もった際、見積り結果に食い違いがあった場合の進め方です。よく言われるのが、最も大きく見積もったメンバーと最も小さく見積もったメンバーにその理由を話してもらうというやり方です。

今回も大筋はその形式を取りましたが、最大・最小の意見を聞いた後はフリーで話をしていました。特出した立場の意見から話しだせば、ディスカッションの口火が切りやすく、そういうやり方でいいのではと思っていました。

チーム間でのワークショップ・ディスカッションの共有の際に「最大・最小の意見を聞いた後はフリーで話をする」に対して反論の意見があり、とても感心させられました。

その内容は、結局好きに話をしてしまうと超えの大きい人の意見に流されてしまうということです。あーなるほど。これ、今回のいちばんの収穫です。

最大見積りをした人は悲観的に考えていて、最小見積りをした人は楽観的に考えている。その意見や考えを引き出すこと、活用することが重要。対立点がはっきりして、身のある議論ができるということです。

私も経験がありますが、結局年長者やスキルの高いメンバーの意見に流されることが多いです。「◯◯さんがそういうなら、ぼくも少なめの見積りでいいです」をよく聞きます…

今度チーム内で見積りをする際はこのやり方を採用したいと思います。

ストーリーポイントを金額にどうやって換算するか

プランニングポーカーで見積もったストーリーポイントは相対的なサイズになります。時間や人日ではありません。
かといって、上司や顧客には見積金額、規模、期間を要求されます。どうやって換算するのがいいんでしょうか。

見積もった時点では、ストーリーポイントと実際の時間とのマッチングはできないというのが正答で、もし換算できるとすれば数回イテレーションを回した後でベロシティが安定してきたころになります。

ところが、契約上・組織ルール上、最初の見積もり時点で金額や絶対的数値での規模が要求されるのが常です。概算見積りレベルであれば提示できますが、そのブレ幅は4倍〜0.25倍(不確実性コーン)といった具合でその要求を満たすのに十分な信頼度はありません。

今回もこの点について、悩んでいる人が多かったです。また、別途考えたいと思っています。

その他の意見やメモ

とりあえず、備忘録的にざっと。

・個々の見積りを積み上げて合計値を見てみると、大きくなりすぎたと思ってしまって少なめにする調整をしてしまう
・政治的なこと(決定済みの予算など)とは切り離して、見積りはすべき。強気見積り。
・顧客提示する見積り・金額と本当の見積りは別で持っておく
・プランニングポーカーでは、それぞれのストーリーにバッファはつまない。
・ストーリーレベルでは作業者を特定しない、ボリューム感を見積もる。ざっくり
・タスクレベルでは作業者を特定して見積もるのはあり。
・基準となる開発者(メンバーの◯◯さん)やスキルセットを決めておけば、見積りしやすい?
・いやいや、自分が担当するとしたらでいいのでは。
・プランニングポーカーの進行テンポを重視する。見積り結果の食い違い時のディスカッションは3回までとか決めておく。