「Planning Poker」についてどう思いますか？
まとめ、wikiの記事を読みたくない場合：
- 今後のイテレーションで実行したいタスクのリストを取得します
- 各タスクについて：
2.1グループに必要なものについて話し合う
2.2全員が、タスクに必要な労力の見積もりを書き留める/選択する
2.3全員が推定を明らかにする
2.4最高および最低の外れ値はその理由を説明します
2.5コンセンサスに達するまで繰り返します
通常、0、½、1、2、3、5、8、13、20、40、100のようなフィボナッチシーケンスの数値に似たものは許可された値なので、23や27。
さらに、数値は単位のない労力の値を表します。その値は、全員が1に一致するベースラインタスクによって決定され、それ以外はすべてそれに比例します。
最終的に、目標は、特定のチームの「速度」、つまり特定の反復で完了することができるこれらのポイントの数を適切に把握することです。これにより、特定の機能にかかる時間をかなり正確に見積もることができます。
これは、私が働いていたある会社での反復計画会議でこれを行い、それはその特定の会社の数少ない良い点の1つだと思いました。だから、私が疑問に思っていることは、誰かがこれを使用したことはありますか？推定に役立つツールだと思いますか？すべての状況で機能しますか、それとも特定のチーム、プロジェクトなどに適していますか？
私が関わっているプロジェクトのために会社でそれを使用しています。ポーカーの計画についてのいくつかのメモは 私の最近のブログ投稿 で表されています。
同意する人々はいかなる結果も強制されない。代わりに、彼らは彼ら自身の見積もりをすることを強いられます！必要に応じて、自分の見積もりを守るための時間も割り当てられます。
それはみんなを忙しくします。会議に参加していることを示しながら、会議中にたるむことはできません。また、手を動かす必要性は、あなたが眠らないようにするための良い運動です。
ただし、これの欠点は、他のことをする必要がある場合があることです（たとえば、メモを取り、到達したばかりの契約の詳細を書き留めます）。
それは会議をより速く保ちます。すべてのペースを維持するために、会議のリーダーが常に関与する必要はありません。明確なルールのあるゲームの方がはるかに優れています。はい、あなたはカードを置く、それらを明らかにするなどのためにいくつかの追加の動きをする必要がありますが、これらは彼らの道を歩みます。
多くの人がカードをプレイしたい、特にポーカー:-)これはモチベーションを高めます。
そのようなカードのデッキを販売する会社は彼らのサイトに Planning Pokerに関する記事 を伴っていましたが、これも読む価値があります。
幅広く使用しています。私はそれが伝統的な方法に比べていくつかの利点を持っていることがわかります
- チームは見積もりのより多くの所有権を取得します
- 多くの場合、プログラマーのアーキタイプは内向的な人を支持します-この方法は、そうでなければ外向的な人格に委ねる可能性がある場所に貢献することを奨励します
- 機能に推定値の幅広い分布がある場合、それはリスクの良い指標です
- 見積もりを行うだけで、タスクの詳細がわかります
- 部屋に効果的にコミュニケーションする人々を置くことに勝るものはありません
Pavelの指摘に同意します。価値のあるもう1つのこともあります。議論の場を平準化します。多くの場合、静かな人々は、グループディスカッションでより口頭の人々に溺れてしまいます。ポーカーを計画することは、活発な議論が始まる前に誰もが彼らの決定をする機会を与えます。そして、それが「外れ値」の意見を提供する静かな人なら、彼らは彼らのケースを提示するための完全なステージを持っています。したがって、この手法は、より静かな貢献者に力を与え、完全なチーム参加を保証します。
いくつかのスプリントにポーカーの計画を使用した後、経営陣は最終的に私たちすべての開発者が数か月間知っていたことを理解しました。
ポーカーの計画、またはより正確には、ストーリーポイントベースの見積もりは、機能セット全体の複雑さを組み合わせる簡単な方法とチームの実際のキャパシティの実際の測定値を簡単に組み合わせることができるため、従来の見積もり手法よりもはるかに正確です。
ここにはすでに多くの良い答えがあります-私は他の機能を指摘したかっただけです。
プランニングポーカーを使用すると、仕事のサイズに関する大きな不一致がすぐにわかります。 2だと思って、3だと思ったら、3と呼んで次に進んでください。しかし、私が1だと思っていて、5だと思ったら、話し合ったほうがいいでしょう。
それは誰もが話し、何が行われているかについて考えさせます。取り組まなくても、見積もりには気を付けないといけない。これは、2か月後にその領域に触れるものに取り組む必要があるときに役立ちます。
把握も簡単です。仕事の分解構造を人々に見せ、目を凝視させ、彼らは睡眠中によだれをだし始めます。次の2週間から4週間のタスクのリストを表示すると、彼らはそれを理解できます。
もう1つの良い点：タスクXが「3」か「8」かについての議論は、チームがスコープを正確に特定するのに役立ちます-したがって、後で、タスクXに伴うものについて不一致はありません。
私が現在のチームでそれを嫌いなのは、主に私たちが根本的にそれに賛成しない人々がいるからです。グルーミングセッションのかなりの部分を費やして、ポイントが価値があるかどうかを議論します。また、製品の所有者がエピックを分解することはないため、通常は、キルターの見積もりや、ポイントが分解する必要があることを示すストーリーが乱暴になります。 。
1つのスプリントに40と2の20がいるのと同じです
私はPavelのポイントが気に入っています。これは、ジュニア開発者や初心者がより速く学ぶのに本当に役立つことを付け加えたいと思います。彼らはただ腰を下ろして上級開発者に支配を任せることはできません。彼らの投票も同様に重要であり、彼らが彼らの推定を正確にすることに本当に焦点を合わせるならば、彼らは上級開発者から多くを学ぶでしょう。