スプリントでポーカーを計画する目的は何ですか？
当社のビジネスアナリストとプロジェクトリーダーは、ストーリーとしてクライアントの要件を教えてくれます。すべてのスプリント計画では、私たち（開発者）が計画ポーカーをプレイするように求められます。
彼らは私たち全員に「努力」ではなく「複雑さ」を考慮するように求めました。私たちは本当に混乱していて、会議で時間を無駄にしています。ある開発者は、「何を本当に検討したいですか？」この要件（時間の見積もり）で行う必要があるのは、コード/ DDLの変更に関するものですか、それとも要件を理解したかどうかに関するものですか？」
しかし、彼ら（ビジネスアナリストとプロジェクトリーダー）は、「要件を理解して」「カードを上げる」とはどういう意味ですか？
さらに、個々のスクラムチーム用のスライシングミーティングがあり、各開発者が各スクラムチームの特定のタスクの時間を見積もります。それで、彼らはPlanning Pokerで本当にどんなことを話しているのですか？
誰でも例を使用してこれを説明できますか？彼らが「複雑さ」と「努力」を言うとき、彼らが本当に話していることを区別するようにしてください。
プロジェクトマネージャーの視点を検討してください
複雑さを求めることで、チームとしてのベロシティを見つけるために、次のスプリントと比較できる数値が求められます。彼らはまた、すべてのストーリーがいつ完了するかについての全体的な見積もりを提供するために、他のチームからの見積もりと結果を加算するためにそれを使用しようとしている可能性があります。
プロジェクトマネージャーは、プロジェクトがいつ終了するか、または時間と機能とコストの三角形の反対側で柔軟である場合に、残りの時間に収まるように他のリーダーを引き出すことができるかどうかの見積もりを求めています。これは不合理ではありません。この見積もりに基づいて、ビジネス上の決定を行う必要があります。問題は、ソフトウェアでこれを見積もることが本当に難しいことです。ポーカーの計画はこの問題を解決する方法の1つです。ストーリーポイントの数を単純に足し合わせるのではなく、作業を実行し、作業にかかった時間を測定し、反復し、外挿することで、できるだけ複雑な関数として考えてください。
議論は数字よりも重要です
ストーリーポインティングミーティングの最も重要な部分は、出てくる議論です。チームの誰かが自信を持って数字を提案していない場合、彼らはおそらくその話を完全に理解していないので、もっと議論する必要があります。アジャイルマニフェスト「契約交渉をめぐる顧客コラボレーション」より。ユーザーストーリーとして書かれた契約を指定して、チームが希望どおりに実行しないとチームが失敗したと言うのではなく、理解するまで顧客が本当に望んでいることについて話し合うのが常に良い方法です。
複雑さ対労力
複雑さと努力についてのあなたの特定の質問に取り組むために、誰もがこれについて異なる意見を持っているようです。 Mountain Goat 、裏側に山羊がいるポーカーカードを計画している人で、所有者のマイクコーンはアジャイル/スクラムの世界で大きな存在であり、努力ではなく、複雑。
人々は時間を推定するのが苦手であり、他の要因が彼らが与える数に影響を与えるため、通常は時間の測定値とは見なされません（カウンターの例については以下の例を参照）。より多くの機能を組み込むことができるように数を低く保つ圧力、問題が発生した場合にいくらか余裕を持たせるために高い数を与える圧力ソフトウェアの構築は難しい。 100戸目の家を建てるとき、それまでに99戸の家を建てたときの所要時間を見積もることができます。作成しているソフトウェアが以前に作成したプログラムと同じである場合は、コピーして貼り付けることができます。ソフトウェアプロジェクトが異なる間は価値があるため、最初は予測できなかった問題が発生します。
隠れた圧力を含む時間の見積もりと同様に、努力の測定にも問題があります。ジュニア開発者が非常に複雑であると推定した場合、より低い推定値を与える他の人からは十分ではないため、攻撃にさらされていると感じるかもしれません。これは、見積もりだけでなく、チームの人々にとっても有害です。
計画ポーカー数は「日数」やその他の時間の尺度ではなく、2つのユーザーストーリーを比較できる相対的な尺度です。新しいチームで最初に行う必要があるのは、ベースラインを確立することです。複雑度の範囲の中央にある1つのユーザーストーリーを選択し、割り当てたい範囲の中央にある番号をチームとして同意します。これで、他のすべてのユーザーストーリーに、これに関連して番号を付けることができます。これにより、はるかに簡単になります。
見積もりができない理由
プロジェクトマネージャーがプロジェクトの完了時期を尋ねるとき、彼らが求めている質問の複雑さを理解する必要があります。プログラマーは工場労働者ではありません。生産性は、タイピングの速度と作業時間を掛け合わせることで測定できます。彼らは問題への答えを見つけ出しており、それは難しいです。プランニングポーカーをプレイすることで、まずチーム内の誰がどの番号を割り当てるべきかという質問に答えることができないと感じている人を特定し、次に彼らがその質問に答えられない理由を調べます。少なくとも4つの理由があると思います。
- ストーリーが大きすぎます。より小さく、より具体的なユーザーストーリーに分解します。各ユーザーストーリーはユーザーに1つの価値を提供する必要があります。入力-プロセス-出力=値。
- 彼らは問題の領域を十分に理解していないので、どれだけ時間がかかるかを述べたり、すべての質問を適切にしたりすることさえできます。これまでに見たことのないものは何であれ、利害関係者のドメインやその種のアプリケーションのプログラミングについて詳しく知っている人と話をしてください。それが不可能な場合、またはそこまで到達できない場合は、設計スパイクを使用できます。 限られたと指定された時間だけのソリューションを試してみてください。プロトタイピングフェーズがどれくらい長く続くかを定義し、長すぎないようにします。その後、再度会って、新しい理解を共有します。
- あなたの利害関係者は十分に具体的ではありません。 「Build me a cloud」は許容できるユーザーストーリーではありません。 「オンデマンドでVMを起動できるシステムを構築する」は、さらに分解されるためより優れていますが、100が隠されているため、どれくらいの時間がかかるかを正確に見積もることができるレベルではありません。あなたの利害関係者があなたが彼らに何かを示すまであなたはそれらを知ることができないということをその声明の中で仮定します。
- 最後に、見積もりを出すことができたとしても、おそらく最初は間違っているでしょう。見積もりは難しい問題であり、私が知っている難しい問題を解決する最良の方法は、科学的方法を使用することです。各チームメンバーが推定する数値に関するデータを収集し、実際にかかった時間、または実際にはどれほど「複雑」であったかについてのデータを収集します。最終的には、誰が過大評価し、過小評価しているのかという感触を得て、それをチームと共有する必要があります。人々は、お互いをより良く推定するのを助けることができます。これらの数値を追跡ツールにフィードバックして、ストーリーの所要時間をより正確に予測することもできます。
結論
重要なのは議論であるべきだと思いますが、本当に誰かに番号を付ける必要がある場合は、どのチームメンバーがそれに取り組んでいるか、どのような順序でストーリーに取り組んでいるかに依存しない番号にしてください。重要なのは、優先順位が付けられたバックログを取得することです。これにより、正しい順序でサイズを調整して、プロジェクトマネージャーが締め切り前にさらにいくつ追加できるかを大まかに確認できます。イテレーションの最後で停止し、開始されていたすべての機能が完了した状態で出荷できるはずです。
警告
チーム内でタスクを完了する時間は、自分の数を守っていれば、好きなだけ見積もることができます。任意の番号がチームを脱出し、他の人に見られるようになると、彼らはあなたが意図していなかったその番号を使って行動します。彼らは、タスクを完了するための日数としてそれを使用しようとします。彼らはあなたを相対的な複雑さの評価に留めようとし、同じ数のポイントを持つ別のユーザーストーリーよりも1つのユーザーストーリーを完了するのに時間がかかった理由を尋ねます。彼らはあなたの数を一緒に追加し、それらを他のチームの数と比較し、他のチームが一定期間内により多くのストーリーポイントを完了するのに、なぜ他のチームが「より多くの仕事をしている」のかを尋ねます。これを止めることはできませんが、すべての利害関係者とのオープンなコミュニケーションラインを維持し、彼らの期待を現実の理解にできるだけ近づけることを試みることができます。
さておき
番号の計画ポーカーセットは通常、番号間のギャップが大きくなり続けるように配布されます。これは、ユーザーストーリーが16と17のどちらであるかを議論するのをやめさせるためのものであると考えています。
例
ポーカーの計画に1、2、3、4の数字のみを使用するチームが少なくとも1つあることを知っています。彼らは、慣習に反して、上記の議論に反して、これらをプログラミング日数と定義します（実際には、プログラミング日数をペアにします。つまり、2人のプログラマーが同じマシンで一緒に作業してユーザーストーリーを完了するのにかかる日数です）。ユーザーストーリーを完了するのに4日以上かかるとチームが考えている場合、ストーリーは指摘されずに残され、プロダクトオーナーはチームと協力してストーリーをさらに細かく分解するか、より正確に指定して、将来の計画会議のためにこの範囲内に持ってきてください。しかし、これは高度なアジャイルであり、おそらく他のテクニックを使用した経験のある人だけが使用すべきです。
私はフランクとエンカイタの答えがそれをほとんどカバーしていると思いますが、考慮すべきいくつかの追加事項があります：
ストーリーポイントを使用する理由
ストーリーポイントで推定する目的は、アプリケーションの機能開発の相対的な複雑さを与えることです。それについて考える簡単な方法は、あなたが次のスプリントで持っている物語をとることです。 URLの変更。これは複雑さの点で単純であり、受け入れ基準が明確に定義されているため、テストしても（フィボスケールを使用して）1であることにチーム全体が同意します。
推定される次のストーリーは、ユーザーデータのセットを集約し、それをフロントエンドで視覚化することです。開発者は、URLを変更するよりも複雑であることをすぐに理解できます。ストーリーと受け入れ基準について話し合い、多くの質問があり、これを行うためのいくつかの潜在的なソリューションを見ることができます。他の開発者とQAも、非常に複雑であることに同意しています。だから、あなたはそれが34ポイントの話であることに同意します。フィボスケールでは、シミュレーションに対する信頼度を示すこともできます。数値間のギャップが大きいほど、推定値に対する信頼度が低くなります。
この時点で、あなたのスクラムマスターはジャンプして、これは1つのストーリーとしては大きすぎるため、あまり複雑ではない小さなストーリーに分割する必要があると言ってください。 SPIKESとして知られていることを実行することで、これにアプローチできます。これは、何かを調査するために取っておかれた時間です。したがって、この例では、あなたと他の開発者は、考えられる技術的な解決策について4時間話し合い、調査することに同意します。
長いストーリーを短くするには、その大きなストーリーを5、8、8、13ポイントの4つのストーリーに分割します。これらの見積もりはすべて相対的な複雑さに関するものであることに注意してください。元の見積もりに追加する必要はありません。さらに正確な見積もりを行うために、より多くの情報を入手できます。
次に、チームとして、このスプリントでは13ポイントのストーリー、8ポイントのストーリーに加えて、すでに特定した1ポイントのURLの変更を達成することを目指すことに同意します。合計で22ポイントです。次のスプリントでは27ポイントが達成され、次のスプリントでは18ポイントが達成されます。 3つのスプリントの後、速度にある程度の自信を得ることができます（速度は、チームが1つのスプリントで実行できる作業量です）。速度を取得するには、以前のスプリントの平均を取ります。したがって、この例では、平均は（22 + 27 + 18）/ 3 = 22.3なので、Fiboスケールで最も近い21に丸めます。
次のスプリントでは、21ポイントを達成することを目指します。
ストーリーポイントの見積もりを正確に得ることに夢中にならないでください。これは正確な科学ではありません。 URLの変更はデータの集計ほど複雑ではないので、それに応じてスコアを付けてください。
さらに、これらのことをチームとして話し合うことは良いことです。スプリントのレビュー中に見積もりを振り返り、それらに満足しているかどうかを話し合い、それを次のスプリント計画セッションにフィードします。
チーム全体の見積もり
チーム全体が各ストーリーの1つの見積もりに同意する必要があります。機能は、本番環境で使用できるようになるまで行われません。コードを記述するだけでは決して完了しません。私の経験では、スクラムチームはチームで作業するときにはるかに効果的でした。今一緒に働いているチームの例を見てみましょう。私が参加したとき、彼らはすべてのスプリントミーティングとポーカーの計画を行っていましたが、スプリント中のプロセスは1でした。BA/プロダクトオーナーは、要件をストーリーとして受け入れ基準と受け入れテストで定義します。2。これらの要件を開発者に渡し、開発者はコード3.開発者は、QAをテストするために開発ブランチにコードをマージします。4。QAテストを開始すると、質問が出され、テストが失敗するため、開発に戻ります。
ここで何が欠けているのですか？前もって十分な議論はなく、各チームメンバーは自分のタスクのみを見ました。これで、BA/PO、開発者、QAが集まり、コードを記述して要件を詳細に議論し、前もって質問をしてから、スプリント全体で議論を続けます。これははるかに効率的で、より良い品質のソリューションにつながります。
ポーカーの計画は、チームが機能について話し合い、チームとして、その機能の提供がいかに複雑であるかに同意することを強制するため、このプロセスを支援します。従来のソフトウェア開発では、プロジェクトマネージャーがプロジェクトの提供を担当していましたが、そのアプローチの経験がある人なら誰でも、それが機能しないことを知っています。アジャイルでは、チームがアプリケーションの配信について全体として責任を負うため、プロジェクトマネージャーは必要ありません。
タスクの時間見積り
タスクの時間を見積もるチームやストーリーポイントの推定のみを行うチームと協力した私の考えは、時間を見積もらないことです！それらは実際には時間の無駄です。それらはチームではなく個人に固有であるため、ストーリーポイントほど正確ではありません。また、各個人は、時間の見積もりについて異なる考えを持っています（炎をもたらす）。
ストーリーポイントでは、要件、つまり要件が常に変化するため、チームがスプリントで何を完了できるかを示す指標が本当に必要です。
速度を理解したら、各スプリントで何ができるかがわかっているので、成果物を時間で測定できます。 2週間ごとに、どの機能を提供できるかがわかります。スクラムマスターと製品の所有者は、将来のスプリントを見据えて見積りセッションを行う必要があります。そうすれば、今後数か月でどの程度の作業が完了するかを示す指標を得ることができます。これにより、製品の所有者は、最終的なアプリケーションに含める機能について、優先順位を決定できます。
私は開発者に計画するためにタスクの時間を見積もるように依頼しましたが、私は実際にはこのアプローチに同意しません（実際、私はこのアプローチに強く同意しません）。これが私に4時間かかるとはどういう意味ですか。1人の開発者がタスク自体の時間のみを含み、他の誰かがお茶を作る時間を追加する可能性があります。
時間の見積もりは常にレポート作成のために他の人に渡され、チーム全体の作業ではなく機能を提供する個々の要素を強調しすぎます。
見積もりは最大の問題ではありません
余談ですが、見積もりを把握することは、チームが解決しなければならない最大の問題ではないと思います。最も重要なことは、チームとして協力してスプリント全体で物事を成し遂げることで、最終日のテストのためにすべてを引き渡さないようにします。 2週間のスプリント全体にわたって、機能の着実なトリクルを確認する必要があります。上で説明したチームのダイナミックさは、その大部分を占めています。ストーリーポイントの推定は、定期的にテストに配信できる小さなストーリーに分解する必要のある大きなストーリーがどれであるかがわかるので、これを計画するのに役立ちます。
ウィキペディアは ポーカーの計画 について十分に説明しています。あなたのケースに焦点を当てて、そこにある状態のいくつかを要約しましょう：
なぜポーカーを計画するのですか？
まず最初に、「通常の」見積もりとは対照的に、なぜポーカーを計画しているのかについて全員が参加している必要があります。その理由は実際には非常に単純です。タスクのtimeを見積もる場合、私たち全員が大きな時間を費やすことになります。ほぼすべての研究で、人間の脳は、かなりの時間を要するタスクを推定することができないことが明らかになっています。 （また、理由として、見積もりで2〜3日を超えるチケットは、見積もりの点でほとんど価値がないのです。）
なぜ努力よりも複雑なのか？
これは上記と関連しています。努力は通常timeを意味し、私たちはそれを吸います。 複雑さ代わりに客観的に定量化することは困難であり、これはこの場合には良いことです。この話が複雑になることを告げるのはあなたの直感です。他の誰かにとっては、それほど複雑ではないかもしれません。しかし、それが実際にどれほど複雑であるかを正確に定量化する必要はありません。この数Xの複雑さを取得する必要はありません。時間のかかる作業とは対照的に、最終的にX日程度かかることに同意する必要があります。
なぜカードを非表示にするのですか？
複雑なゲスト味のあるカードは隠されてプレイされ、その後一度に公開されます。これは、最初の見積もりを行う前に、他の人の意見に影響されないようにするためです。誰もが複雑さの点でほぼ同じ直感を持っている場合は、完了です。非常に異なる数の数字が発生している場合は、そこに隠された議論の対象があることがわかります。このようにして、必要な複雑さ/労力について誰もが同じ考えを持つストーリーに非常に迅速に対処できます。
なぜフィボナッチ数？
カードの番号は、通常、フィボナッチ数列または数のギャップが多い他の種類のシーケンスです。これは、あなたの直感を完全に信頼することをあなたに強制することです。 8と13の間で選択する必要がある場合、それは9や10に行くよりもはるかに多くのステートメントです。また、上記のように、大きな違いは隠れた問題がどこにあるかなので、ギャップを拡大することにより、これらの問題をよりよく検出します。
なぜこれがまったく機能するのですか？
興味深いことに、最初の数回はポーカーを計画することはできません。それはそれと同じくらい簡単です。 「3」または「5」はどういう意味ですか？各数値の意味は（意図的に！）定義されておらず、各数値の背後にある実際の意味を発見するのはチーム全体です。これらの数字でストーリーを見積もることを受け入れた後、そしてこれらのいくつかを実現した後でのみ、いつ5をレイズすべきか、むしろ8であるかについて、より良いアイデアを得られます。
これを速度の概念と組み合わせ、これらのストーリーポイントを介してスプリントの進行状況を測定すると、従来の時間推定とはほぼ独立したまったく新しい効率のスケールが得られます。
それにもかかわらず、私個人にとって、ポーカーを計画する上で最も有益な点は、時間の見積もりではなくフィボナッチ数を使用することで、不確実性を検出する時間がはるかに簡単になるということです。古典的な時間の見積もりでは、そのような「極端な」決定（数値のギャップのため）を強いられることはありません。したがって、見積もりはかなり接近しており、チームはストーリーを十分に理解していると誤って信じる場合があります。
例
通常起こることの簡単な例は、ストーリーが提示され、次にAの人が異議を唱えることです。これは、「この機能がXに影響することを忘れないでください。これは、これまで考えていたものよりもコストがかかることを意味します」です。主な問題は、常にこの人物Aがテーブルにいることです。誰かが常に心配していることがあります。率直なオープンディスカッションを行っている場合、このXがどれほど大きな心配をしているのか本当にわかりません。
時間に基づいて非表示の見積もりを行うと、少し良くなります。しかし、それでも、有効な異論を持つ人物Aは、まだ彼女の推定値の明確な外れ値ではない可能性があります。一方、ポーカーを計画する場合、人Aは実際の問題Xがどれだけあるかについてもっと考えなければなりません。 2つの異なる問題について、上記の「異論の音声テキスト」ではそれらの重要性を適切に区別できません。時間を見積もっても、どちらがより問題であるかを確認するのはかなり困難です。ここでプランニングポーカーを使用することの希望は、1つの異議が他の見積もりとわずか2〜3ポイント異なるだけで終わることですが、中央値から5または8ポイント離れた他の異議はtheスプリント計画の最も重要な不確実性。
私のチームで何十回も繰り返した結果、ストーリーポイントは主に中期プロジェクトのステアリングに関するものであることがわかりました。これにより、製品の所有者は自分で2つまたは3つのスプリントを予測し、平均的な速度に基づいて、リリースに関するビジネスとスコープの決定を本質的に行うことができます。
2つのスプリントが類似しておらず、実行される作業量を予測することが不可能であるため、スプリントレベルではストーリーポイントはそれほど有用ではないことがわかりました。その結果、私たちは見積もりの部分に夢中になるべきではなく、ポーカーセッションの計画を機能についての会話の口実としてとるべきだと判断しました。
これはMike Cohn here の指摘と一致します。
補足として、これは特定のチームに当てはまりますが、ストーリーポイントがどのように役立つかについての規則はありません。最初に 方法論 を使用することをお勧めしますが、それらがどのように役立つか、そしてどのように役立つかを自分ですばやく見つけてみてください。ふりかえりは、あなたがそれに反省するのに役立ちます。
ここでの根本的な問題は、それが壊れていることです。 PMは、計画のポーカーを使用して、各ストーリーの複雑さを把握したいと考えています。スプリントに組み込むことができるストーリーの数（チームの速度）を大まかに把握することを目的としています。
その結果、「時間に基づく」「時間に基づく」ではありません。誰もが混乱するのも不思議ではありません。
これを機能させる方法はいくつかあります。まず努力を忘れ、複雑さに焦点を当てます。それぞれのストーリーが影響を与える領域に焦点を当てる代わりに、開発と集中にかかる時間についてはすべて忘れてください。 DB、サーバーコード、クライアントコード、およびクライアントドキュメントを更新するストーリーがある場合、それは4ポイントのストーリーであると言えます。 DB sqlの変更のみの場合は、1ポイントの話です。これにより、ストーリー間の相対的な複雑さを理解するためのより理解しやすい方法が得られます。 （状況に応じて、テスト範囲の要件やUIの複雑さなど、いくつかのメトリックを考え出す必要があります）
私の意見は、一般に、まるでミニウォーターフォールプロジェクトであるかのように、スプリントの計画を促進するだけの時間の無駄です。スプリントに含めることができるストーリーポイントの数を本当に気にしているのは誰ですか？スプリントの最後に残りのストーリーがある場合は、次のストーリーでそれらを実行します。それを考えると、バックログをあなたが持っているすべての傑出したストーリーのサイズにして、徐々に時間をかけてそれらすべてを徐々に削ることもできます。納品には時間がかかります（ただし、バックログやスプリントの計画会議で時間の20％を浪費していなければ、より早くなります）。プロジェクトの終わりには、ストーリーポイントがいくつ配信されたかは誰も気にしません。人々が気にするのは、提供されたプロジェクトです。
また、ユーザーストーリーポインティングにより、再ネゴシエーションが必要かどうかという点で、ビジネスは有利になります。あなたが100点をとったいくつかの仕事を完了する月があるなら、あなたは困っているかもしれません。また、叙事詩の物語を、まだ価値があり、スプリントで完了することができる小さいものに分解する機会も与えられます。