スプリントでポーカーを計画する目的は何ですか？

私たちのビジネスアナリストとプロジェクトリーダーは、ストーリーとしてのクライアントの要件を教えてくれます。すべてのスプリントプランニングでは、開発者はプランニングポーカーをプレイするよう求められます。

彼らは私たち全員に、「努力」ではなく「複雑さ」を考慮するように頼みました。私たちは本当に混乱しており、会議に時間を浪費しています。ある開発者は、「何を本当に検討したいのですか？この要件（時間の見積もり）で行う必要があるコード/ DDLの変更に関するものですか、それとも要件を理解したかどうかに関するものですか？

しかし、彼ら（ビジネスアナリストとプロジェクトリーダー）は、「要件を理解する」と「カードを調達する」とはどういう意味ですか？

さらに、個々のスクラムチーム用のスライス会議があり、各開発者が各スクラムチームの特定のタスクの時間を見積もります。それで、彼らはPlanning Pokerで本当にどんなことを話しているのでしょうか？

例を使用してこれを説明できる人はいますか？彼らが「複雑さ」と「努力」と言うとき、彼らが本当に話していることを区別するようにしてください。

プロジェクトマネージャーの視点を検討する

複雑さを求めることで、チームとしてのベロシティを見つけるために次のスプリントと比較できる数値が必要になります。また、結果を他のチームからの推定値と加算して、すべてのストーリーがいつ終了するかについての全体的な推定値を提供するために使用することもあります。

プロジェクトマネージャーは、プロジェクトがいつ終了するか、時間関数コストトライアングルの反対側で柔軟な場合、残りの時間に合うように他の離脱者を引くことができるものの推定値を探しています。これは不合理ではありません。この見積もりに基づいてビジネス上の決定を下す必要があります。問題は、ソフトウェアでこれを推定するのが本当に難しいことです。ポーカーの計画は、この問題を解決する方法の1つです。ストーリーポイントの数を単純に加算するのではなく、できる限り推定し、作業を行い、それがかかった時間を測定し、反復し、外挿するより複雑な機能と考えてください。

議論は数よりも重要です

ストーリーポインティングミーティングの最も重要な部分は、議論が行われることです。チーム内の誰かが数字の提案に自信がない場合、おそらく彼らは物語を完全に理解していないので、さらに議論する必要があります。アジャイル宣言から「契約交渉に関する顧客のコラボレーション」。ユーザーストーリーとして書かれた契約を指定して、チームがあなたが望むことを正確にやらないとチームが失敗したと言うよりも、理解するまで顧客が本当に望んでいることについて話す方が常に良いです。

複雑さ対努力

複雑さ対努力に関するあなたの特定の質問に対処するために、誰もがこれについて異なる意見を持っているようです。Mountain Goatは、裏にヤギがいるプランニングポーカーカードを作成し、所有者のMike Cohnはアジャイル/スクラムの世界で大きな存在であり、複雑さではなく努力であるべきだと言います。

人々は時間を見積もるのが苦手なので、通常は時間の尺度とはみなされません（カウンターの例については下の例を参照）。たとえば、より多くの機能に適合できるように数値を低く保つ圧力で、あなたが問題に出くわした場合に自分自身にいくらかの部屋を与えるためにより高い数を与えるように圧力をかけます。ソフトウェアの構築は困難です。100番目の家を建てるとき、それまでに99個の家を建てたので、どれくらいかかるかを見積もることができます。構築しているソフトウェアが以前に構築したプログラムと同じである場合、コピーアンドペーストすることができますが、ソフトウェアプロジェクトは異なるため、最初は予測していなかった問題が発生します。

隠れた圧力を含む時間の見積もりと同様に、労力の測定にも問題があります。若手開発者が高い複雑さを見積もる場合、彼らは、より低い見積もりを与える他の人からは十分ではないとして、攻撃に対して自分自身をオープンにしておくと感じるかもしれません。これはあなたの見積もりだけでなく、チームのメンバーにとっても有害です。

プランニングポーカーの数は、「日数」やその他の時間の尺度ではなく、2つのユーザーストーリーを比較できる相対的な尺度です。新しいチームで最初に行う必要があるのは、ベースラインを確立することです。複雑さの範囲の中央にあるユーザーストーリーを1つ選択し、割り当てたい範囲の中央の数字をチームとして同意します。これで、他のすべてのユーザーストーリーに、これに関連して番号を付けることができます。これにより、はるかに簡単になることがわかりました。

見積もりできない理由

プロジェクトマネージャーがプロジェクトの完了時期を尋ねるとき、彼らは彼らが尋ねている質問の複雑さを理解する必要があります。プログラマーは工場労働者ではありません。生産性は、入力する速さと作業時間を掛けることで測定できます。彼らは問題への答えを考え出しているが、それは難しい。プランニングポーカーをプレイすることで、まずチームの誰がどの番号を割り当てるかという質問に答えられないと感じているかを特定し、次にその質問に答えられない理由を掘り下げます。少なくとも4つの理由があると思います。

1. ストーリーが大きすぎます。小さく、より具体的なユーザーストーリーに分けます。各ユーザーストーリーはユーザーに1つの価値を提供するものであることを忘れないでください。入力-プロセス-出力=値。
2. 彼らは問題のドメインを十分に理解していないため、どれだけ時間がかかるかを言うことができず、すべての質問を適切に尋ねることさえできません。利害関係者のドメイン/その種のアプリケーションのプログラミングについて詳しく知っている人と話してください。それが不可能な場合、またはそこまで到達できない場合は、デザインスパイクを使用できます。移動して、ソリューションをプロトタイプだけのために制限さと指定された時間の量。プロトタイピングフェーズがどれだけ長く続くかを定義します。長すぎずに、再度会って、新しい理解を共有します。
3. あなたの利害関係者は十分に具体的ではありません。「クラウドを構築する」は、受け入れられるユーザーストーリーではありません。「必要に応じてVMをスピンアップできるシステムを構築してください」はさらに細分化されていますが、100の隠された状態になるまでにかかる時間を正確に見積もることができるレベルではありません。その声明の中で、利害関係者が持っているという仮定は、何かを示すまでわからないということです。
4. 最後に、たとえあなたが見積もりを与えることができたとしても、それはおそらく最初は間違っているでしょう。見積もりは難しい問題であり、難しい問題を解決するために知っている最善の方法は、科学的な方法を使用することです。各チームメンバーが推定する数値に関するデータを収集し、それが実際にかかった時間、またはそれが実際にはどれだけ「複雑」だったかについてデータを収集します。最終的に、誰が過大評価し、誰が過小評価しているかの感覚をつかむことができます。それをチームと共有する必要があります。人々は、お互いの評価を向上させることができます。これらの数値を追跡ツールにフィードバックして、ストーリーにかかる時間をより正確に予測することもできます。

結論

ポイントは本当に議論すべきだと思いますが、本当に誰かに番号を付ける必要がある場合は、どのチームメンバーがそれに取り組んでおり、ストーリーがどの順序で取り組んでいるかとは無関係の番号にするようにしてください。重要なのは、優先順位が設定されたバックログを取得することです。したがって、プロジェクトマネージャーは、締め切り前にどれだけ多くの作業を行えるかを見ることができるように、適切な順序とサイズで作業します。反復の最後で停止し、開始されたすべての機能が完了した状態で出荷できるはずです。

警告

チーム内でタスクを完了する時間は、数字を自分で管理している限り、必要なだけ見積もることができます。任意の番号をチームから脱出し、他の人に見られるようにすると、彼らはあなたが意図しなかったその番号で何かをします。彼らは、タスクを完了するための日数としてそれを使用しようとします。彼らはあなたを相対的な複雑さの格付けに保持しようとし、同じポイント数で別のユーザーストーリーよりもあるユーザーストーリーを完了するのになぜ時間がかかったのかを尋ねます。彼らはあなたの数字を一緒に追加し、他のチームの数字と比較し、他のチームが一定の期間内により多くのストーリーポイントを完了するのになぜ他のチームが「もっと仕事をする」のかを尋ねます。あなたはできる'

さておき

番号の計画ポーカーセットは、通常、番号間のギャップが大きくなり続けるように配布されます。これは、ユーザーストーリーが16であるか17であるかを議論することを思いとどまらせるためのものだと思います。

例

私は、ポーカーのプランニングに数字1、2、3、4のみを使用するチームを少なくとも1つ知っています。慣例に反して、上記の議論に反して、これらをプログラミング日（実際にはペアのプログラミング日、つまり2人のプログラマーが同じマシンで一緒に作業してユーザーストーリーを完了するのにかかる日数）として定義します。ユーザーストーリーを完成させるのに4日以上かかるとチームが考えている場合、ストーリーは指摘されずに残され、プロダクトオーナーはチームと協力してストーリーをさらに分解するか、より正確に指定して、将来の計画会議のためにこの範囲内に持ち込まれます。しかし、これは高度なアジャイルであり、おそらく他のテクニックを使用した経験のある人のみが使用すべきです。

フランクとエンカイタの答えはほぼカバーしていると思いますが、考慮すべき追加事項がいくつかあります。

ストーリーポイントを使用する理由

ストーリーポイントで推定する目的は、アプリケーションの機能開発の相対的な複雑さを示すことです。それについて考える簡単な方法は、たとえばURLの変更など、今後のスプリントでのストーリーを取り上げることです。これは複雑さの点で単純であり、受け入れ基準が明確に定義されているため、テストでも1（Fiboスケールを使用）であることにチーム全体が同意しています。

推定される次のストーリーは、一連のユーザーデータを集約し、フロントエンドで視覚化することです。開発者としてすぐにわかるように、これはURLを変更するよりもはるかに複雑です。ストーリーと受け入れ基準について話し合い、多くの質問があり、これを行うためのいくつかの潜在的な解決策を見ることができます。他の開発者とQAも、非常に複雑であることを認めています。それで、あなたはそれが34ポイントの物語であることに同意します。Fiboスケールでは、シミュレーションにどれだけ自信があるかを示すこともできます。数値間のギャップが大きいほど、見積もりに自信がないことを示します。

この時点で、スクラムマスターはジャンプして、これを単一のストーリーとしては大きすぎ、複雑さの少ない小さなストーリーに分割する必要があると言う必要があります。スパイクとして知られていることを行うことでこれにアプローチできます-これは何かを調査するために取っておく時間です。したがって、この例では、あなたと他の開発者は、4時間で技術的な解決策について話し合い、調査することに同意します。

長い話を短くするには、その大きな話を5、8、8、13ポイントの4つの別の話に分けます。これらの見積もりはすべて相対的な複雑さに関するものであることを忘れないでください。元の見積もりと足し合わせる必要はありません。さらに、より正確な見積もりを行うためにより多くの情報が得られます。

その後、チームとして、このスプリントでは、13ポイントのストーリー、1つの8ポイントのストーリー、および既に特定した1ポイントのURLの変更を行うことに同意します。合計22ポイントです。次のスプリントでは27ポイント、次のスプリントでは18ポイントが完了します。3回のスプリントの後、速度にある程度自信を持ち始めることができます（速度とは、チームが1回のスプリントで達成できる作業量です）。速度を取得するには、前のスプリントの平均を取ります。したがって、この例では、平均は（22 + 27 + 18）/ 3 = 22.3であるため、Fiboスケールで最も近い21に丸めます。

次のスプリントでは、21ポイントを獲得することを目指します。

ストーリーポイントを正確に見積もるのに夢中にならないでください-それは正確な科学ではありません。URLの変更は、データを集約するよりもはるかに簡単なので、それに応じてスコアリングするだけです。

加えて、これらのことをチームとして議論することは良いことです。スプリントのレビュー中に見積もりを振り返り、それらに満足しているかどうかを話し合い、次のスプリント計画セッションにフィードします。

チーム全体の見積もり

チーム全体が各ストーリーの単一の見積もりに同意する必要があります。生産準備が整うまで、機能は実行されません。コードを作成するだけではありません。私の経験では、スクラムチームはチームとして働くときの方がはるかに効果的でした。私が今取り組んでいるチームの例を挙げてください。私が参加したとき、彼らはすべてのスプリント会議とポーカーのプランニングをしていましたが、スプリント中のプロセスは1でした。コード3.開発者は、QAがテスト4。

ここに何が欠けていますか？前もって十分な議論が行われておらず、各チームメンバーは自分のタスクだけを見ました。これで、BA / PO、開発者、およびQAは、要件を詳細に議論し、事前に質問をするコードを書く前に集まって、スプリント全体で議論を続けます。これははるかに効率的で、より良い品質のソリューションにつながります。

ポーカーを計画することは、チームが機能について話し合い、チームとしてその機能の配信がどれほど複雑であるかに同意することを強制するため、このプロセスに役立ちます。従来のソフトウェア開発では、プロジェクトマネージャーがプロジェクトの配信を担当していましたが、そのアプローチの経験がある人は誰もが動作しないことを知っています。アジャイルでは、プロジェクトマネージャーは必要ありません。これは、チームが全体としてアプリケーションの配信を担当するためです。

タスクの時間見積り

私の見解では、タスクの時間を見積もるチームや、ストーリーポイントの推定のみを行うチームと時間を見積もるのは時間の見積もりをしないでください！実際には時間の無駄です。彼らはチームではなく個人に固有であるため、ストーリーポイントほど正確ではありません。また、各個人は、時間の見積もり（炎上）について異なる考えを持っています。

ストーリーポイントは要件、つまり要件が常に変化することを受け入れているため、チームがスプリントで何を完了することができるかを示すインジケーターが本当に必要です。

速度を理解したら、各スプリントで何ができるかを知っているので、成果物を適時に測定できます。たとえば、2週間ごとにどの機能を提供できるかがわかります。スクラムマスターとプロダクトオーナーは、今後のスプリントを先取りするための見積もりセッションを行う必要があります。これにより、今後数か月でどれだけの作業が完了するかを示すインジケータを取得できます。これにより、製品所有者は最終アプリケーションに含める機能について優先順位を決定できます。

開発者に計画を立てるためにタスクの時間を見積もるように頼みましたが、実際にはこのアプローチには同意しません（実際、このアプローチには同意しません）。 1人の開発者がタスク自体の時間だけを含めることもあれば、他の誰かがお茶を飲む時間を追加することもあります。

時間の見積もりは、レポートの目的で常に他の人に渡され、機能を提供する個々の要素とチーム全体の労力を強調しすぎます。

推定は最大の問題ではありません

余談ですが、見積もりを理解することは、チームが解決しなければならない最大の問題ではありません。最も重要なことは、チームとして協力してスプリント全体を通して物事を成し遂げることであり、最終日にテストのためにすべてを引き渡すことはありません。2週間のスプリントを通して、安定した機能のトリクルを確認したい場合。上で説明したチームダイナミクスは、これの大部分です。ストーリーポイントの見積もりは、これを計画するのに役立ちます。これは、定期的にテストに配信できる小さなストーリーに分解する必要がある大きなストーリーを確認できるためです。

ウィキペディアはポーカーのプランニングについて非常によく説明しています。あなたのケースに焦点を当てて、そこにある状態のいくつかを要約しましょう：

ポーカーを計画する理由

まず第一に、「通常の」見積もりとは対照的に、なぜあなたがプランニングポーカーをしているのかについて全員が参加している必要があります。理由は実際には非常に単純です。タスクの時間を見積もるとき、私たち全員が大きな時間を費やします。ほぼすべての研究が明らかにしたように、人間の脳は、合理的な時間を要するタスクを単純に推定することはできません。（また、理由で、見積りで2〜3日を超えるチケットが見積りに関してほとんど価値がない理由です。）

努力ではなく複雑なのはなぜですか？

これは上記と密接に関係しています。努力とは、通常、時間を意味します。その代わり、複雑さを客観的に定量化することは困難であり、これはこの場合には良いことです。この物語が複雑になることを告げるのはあなたの腸です。他の誰かにとっては、それほど複雑ではないかもしれません。しかし、実際の複雑さを正確に定量化する必要はありません。X時間のかかる努力とは対照的に、この数の複雑さを取得する必要はありませんX。

なぜカードを隠すのですか？

あなたの複雑さをゲストに持つカードは隠されてプレイされ、その後一度に公開されます。これは、最初の見積もりを行う前に、他の人の意見に影響されないようにするために行われます。誰もが複雑さの点でほぼ同じ直感を持っているのであれば、それで終わりです。大幅に異なる数値が発生している場合は、そこに隠された議論すべきことがあることがわかります。このようにして、必要な複雑さ/労力について誰もが同じ考えを持つストーリーを非常に迅速に処理できます。

なぜフィボナッチ数ですか？

カードの数字は通常、フィボナッチ数または数字に多くのギャップがある他の種類の数字です。これはあなたの腸の感覚を完全に信頼するように強制することです。8から13の間で選択する必要がある場合、9または10に行くよりもはるかに多くのステートメントです。また、上記のように、大きな違いは隠れた問題がある場所であるため、ギャップを拡大することで、これらの問題をよりよく検出します。

なぜこれがまったく機能するのですか？

興味深いことに、プランニングポーカーを最初の数回行うと機能しません。それはそれと同じくらい簡単です。「3」または「5」とはどういう意味ですか？各番号の意味（意図的！）の定義はありません。これらの各番号の背後にある実際の意味を発見するのはチーム全体です。これらの数字でストーリーを推定することを受け入れた後、そしてこれらのいくつかを理解した後にのみ、5を上げるべき時期と8である時期をよりよく理解できます。

これを速度の概念と組み合わせて、これらのストーリーポイントを介してスプリントの進行を測定すると、従来の時間推定とはほぼ独立したまったく新しい効率のスケールが得られます。

それでも、個人的には、ポーカーを計画する最も有益な点は、時間の見積もりの​​代わりにフィボナッチ数を使用することで、不確実性を検出する時間がはるかに簡単になることです。古典的な時間の見積もりでは、そのような「極端な」（数のギャップによる）決定を強制されることはありません。したがって、見積もりはかなり密接であり、チームはストーリーを十分に理解していると誤って信じることがあります

例

通常起こることの簡単な例は、物語が提示され、その後、人Aが異議を唱えることです。これは「この機能がXに影響することを忘れないでください。これは、これまで考えていたよりもコストが高いことを意味する可能性があります」。主な問題は、この人物Aが常にテーブルにいることです。誰かが心配しているものが常にあります。率直な議論をしているのなら、このXがどれほど大きな心配なのか、まったくわからないでしょう。

時間に基づいて隠れた推定を行うと、少し良くなります。しかし、それでも、有効な異議を唱えている人Aは、彼女の推定ではまだ明確な外れ値ではないかもしれません。一方、ポーカーを計画する場合、人Aは実際の問題Xがどれくらいあるかについてさらに考える必要があります。2つの異なる問題については、上記の「異議申し立てテキスト」によってそれらの重要性を適切に区別することはできません。時間を見積もっても、どちらが問題なのかを判断するのはかなり困難です。ここでプランニングポーカーを使用することの希望は、1つの異論が他の予測とはわずかに2〜3ポイント異なることですが、中央値から5または8ポイント離れた他の異論は、最も重要な不確実性である可能性がありますスプリント計画の。

私のチームで何十回も繰​​り返した後、ストーリーポイントは主に中期のプロジェクトステアリングに関するものであることがわかりました。これにより、製品所有者は自分自身で2つまたは3つのスプリントを先読みし、基本的に平均速度に基づいてリリースに関するビジネスおよびスコープの決定を下すことができます。

2つのスプリントは類似しておらず、どの程度の作業が行われるかを予測することは不可能であるため、ストーリーポイントはスプリントレベルではそれほど有用ではないことがわかりました。その結果、見積り部分に夢中になるべきではなく、機能に関する会話の口実としてポーカーセッションを計画するだけでよいと判断しました。

これはマイクコーンがここで指摘した点と一致します。

補足として、これは特定のチームに当てはまりますが、ストーリーポイントがどのように役立つかについてのルールはありません。最初に方法論に固執することをお勧めしますが、それらが有用であるかどうか、どのように有用であるかを自分ですぐに見つけてみてください。回顧は、あなたがそれについて考えるのに役立ちます。

ここでの基本的な問題は、破損していることです。PMは、プランニングポーカーを使用して、各ストーリーの複雑さを把握し、スプリントに組み込むことができるストーリーの数（チームの速度）を大まかに把握することを望んでいます。

結果として、その「時間に基づいていない」「時間に基づいていない」。誰もが混乱するのも不思議ではありません。

あなたのためにこれを機能させる方法があります。最初に努力を忘れ、複雑さに焦点を合わせます。代わりに、各ストーリーが影響する領域を開発して集中するのにかかる時間を忘れてください。DB、サーバーコード、クライアントコード、およびクライアントドキュメントを更新するストーリーがある場合、それは4ポイントのストーリーであると言えます。DB SQLの変更のみの場合は、1ポイントのストーリーです。これにより、ストーリー間の相対的な複雑さを把握するより理解しやすい方法が提供されます。（状況に合ったいくつかのメトリックスを考え出す必要があります。テストのカバレッジ要件やUIの複雑さかもしれません）

私の意見は一般的に、それはあたかもそれらがミニウォーターフォールプロジェクトであるかのようにスプリント計画を単に促進する無意味な時間の浪費であるということです。スプリントに収めることができるストーリーポイントの数を誰が本当に気にしますか？スプリントの最後に残ったストーリーがある場合は、次のストーリーでそれらを行います。それを考えると、あなたのバックログをあなたが持っているすべての傑出した物語のサイズにし、徐々にそれらを徐々に削っていくかもしれません。納期はかかる限りかかります（ただし、バックログおよびスプリント計画ミーティングで時間の20％を無駄にしないと、より迅速になります）。プロジェクトの終了時には、ストーリーポイントがいくつ配信されたかは誰も気にしません。人々が関心を持っているのは、提供されたプロジェクトです。

また、ユーザーストーリーのポインティングは、再交渉が必要な場合にビジネスに注目を集めます。あなたが100点を獲得した仕事を完了するための月があるなら、あなたは問題を抱えているかもしれません。また、壮大なストーリーを、価値がありスプリントで完了することができる小さなものに分解する機会も与えます。