スクラムでのアジャイル推定？ストーリーポイントとプランニングポーカー

実際、労働時間は「絶対的に正確」と推定することはできませんが、「比較的客観的」と推定する方法はいくつかあります。労働時間と要件の複雑さのために、多くの場合、正の相関関係があります。したがって、この記事では、最初に要件の複雑さに対応する一般的な問題を説明し、提案されたソリューションを提案し、ソリューション内の多くの設計の目的を説明します。

問題

開発者の鉱山

「とても簡単です。作るのにそれほど時間はかからないのですか？」
首相は今日あなたに言った：「私は明日までにそれを引き渡さなければなりません。「品質を求める前にそれを成し遂げる」
明後日、首相はあなたにこう言いました。「なぜプログラムの質が悪いのですか？」
それが遅れたとき、他の同僚は次のように述べています。これには、参照用の既製のコードがあります。これは、使用するのに適した最下層を持っています。どうして私に聞かなかったの？」
他の同僚：「私は1日しか必要ありません、なぜあなたはそんなに多くの日を過ごしたのですか？」
「これは常識です！要件について言及しない場合は、何をすべきかを知っておく必要があります。」

PM / POの鉱山

「なぜそんなに簡単なのですか？とても時間がかかりますか？」
「Facebookにアクセスしているのに、アクセスする時間がないのはなぜですか？」
「なぜそんなに悪くなったものの品質なのか？」
「なぜ彼は最後にそれを作ったのですか、あなたは何日しなければなりませんか？」
仕様や要件が明確に書かれていないため、開発者は要件の変更として説明されます。

結果

役割の敵意：デマンドユニットと開発ユニットは、ユーザーに利益をもたらすことができる製品を提供するのではなく、追加の責任を負わなくても済むように、それぞれの目的でお互いを攻撃します。したがって、需要ユニットと開発ユニットがまったく単一のチームではないという状況。
責任：チームは、ユーザーのニーズを優先するのではなく、「私は間違っていないので、遅延は私の責任ではない」と考えています。
需要の凍結：開発者は期限のプレッシャーのために要件を変更することを余儀なくされます。そうしないと、開発者は遅れ、責任は開発者に委ねられます。その結果、多くのバグを隠す何かを作成するために残業するか、ユーザーのニーズを満たさないある種の機能を作成する必要がありました。どちらもユーザーの満足度を低下させます。
低品質：PMのステータスは、多くの場合、開発者のステータスよりも高くなります。したがって、契約の締め切りに間に合わせるため、またはペナルティなどを回避するために、チームは「最初に完了し、次に改善を求める」ように求められますが、最後に「最初に、良いことを求める時間がない」ことがよくあります。。」技術的負債の蓄積が増加しており、その結果、実際の責任の連鎖モデルが作成されます。これは、連鎖の最後で最大の責任とコストを伴います。つまり、チームはスタックポップのようなものであり、開発者は1つずつ維持できません。これが、プロジェクト会社のエンジニアが離職率を高くすることが多い要因の1つです。
コードの重みを上げる：効率を最適化するために、最も精通している人の位置が常に労働時間を推定するために使用されるため、モジュールとプロセスに最も精通している人は常に関連する要件に関心があります。結局、自分のコードを維持できるのはそれらの人々だけです。それはパンドラの箱のようなもので、開いた後にどの牛や幽霊がなくなるかはわかりません。ブラックボックスは汚いことが多いのですが、会社はこの問題を解決する方法を知りませんでした。また、彼が去らないことを望んでいます。そうしないと、コードの一部が理解されません。

ソリューション

ここで提案するソリューションは、スクラムの要件の複雑さを見積もる一般的な方法ですが、スクラムチームでなくても、原則と設計目標に基づいてチームを見積もる最良の方法を読者が特定できるようにすることをお勧めします。。

特効薬がなければ、他の誰かのベストプラクティスが必ずしもあなたのチームに当てはまるとは限らないことに注意してください。最初にあなたのチームが現在経験している問題を理解し、次に他の誰かの実践から問題を解決するためにあなたにとって何が正しいかを見つけてください。、それが新しい問題を引き起こさない限り、または新しい問題のコストリスクが許容できる限り。

要件の複雑さを見積もるためにここで使用される単位は、稼働時間（絶対単位）ではなく、ストーリーポイント（相対単位）です。

ここで需要の複雑さを推定するために使用される単位は、作業時間（絶対単位）ではなく、ストーリーポイント（相対単位）です。これを行う理由はいくつかあります。

1.比較は人によって異なりません。要件の複雑さは人によって異なることが多く、練習に必要な時間は人によって異なります。

2.「相対的」は「絶対的」よりも評価が容易です。労働時間を見ると、絶対数を見積もる必要があり、見積りプロセスで実装の詳細を考慮する必要があります。ストーリーポイントを使用して複雑さを見積もるには、サイズを他の要件と比較するだけで済みます。

たとえば、「塔の高さは数メートル」とは言い難いですが、「この塔はその建物の約2倍の高さ」と指摘しやすいです。

3.ユーザーストーリーのストーリーポイントを見積もるプレッシャーは、作業時間の見積もりよりも小さくなります。要件自体に焦点を合わせ、自身のリソースやプロジェクトリソースを気にせずに、要件の複雑さを評価するだけです。見積もりプロセス中、チームメンバーはストレスが少なく、ゲームのようにソフトウェア開発の一部を果たします。

需要の複雑さは労働時間と正の関係にあることがよくありますが、実装条件が異なるため、ストーリーポイントの高い機能を使用することは可能であり、労働時間の需要はストーリーポイントよりも低くなります。しかし、スクラムでは、反復スプリントを使用して、各スプリントチームが消化できる複雑さを評価できます。PO / PMの場合、失敗した時間経過を見積もる代わりに、プロジェクトの予想される時間経過からどれだけ離れているかを最初に理解できるように、より正確で客観的な時間経過を見積もる方がよいでしょう。リソースが限られている場合、要件に優先順位を付ける方法、または他のサポートを求める方法。

次に、ソリューションのさまざまな側面について説明します。

いつ

誰がそれを行う必要があるかを決定する前に評価を実施します。そうすることの利点は、開発者の個人的な要因を最小限に抑えることです。誰がそれを行うのかわからないので、自分のタスクや期限のためにバッファを追加するために過大評価する必要はありません。

WHO

一緒に評価することをする人だけ：2つの重要なポイント：

物事を行う人だけが推定できます。要件ユニットによって見積もられる時間や複雑さは客観的ではありません。なぜなら、彼らは実際に作業を行う人ではなく、作業能力の評価に基づいて開発チームの見積りに影響を与える力がないからです。これにより、期限からの要件の複雑さの評価を回避することも容易になります。
一緒に物事を行う人は見積もります。誰がやろうとしているのかわからないので、一人一人が一緒に見積もった数字は、話し合いと再見積りの後で合意に達するのは簡単です。誰もが参加し、参加感があり、誰もが参加しているので、見積もり結果は全員が決めるので、将来誰がやるのか不満はありません。

何

プランニングポーカーを使用して、ストーリーポイントを見積もります。

ポーカーカードとフィボナッチ数列

フィッシャーシリーズには興味深い機能があり、各番号は最初に追加された2つの番号です。一方、数字と次の数字の差が大きいほど、差は大きくなります。

上に示したように、8と13の間のギャップは5であり、13と20の間の差は7です。しかし、これは需要の複雑さの推定とどのように関連していますか？私たちは数学の授業ではありません。

フィボナッチ数列に関連する推定の特徴

見積もりには特性もあります。つまり、精度が高いほど、需要またはタスクがより細かい粒度にカットされるほど、より正確であると見積もられることがよくあります。大きな不規則な石がカップに取り付けられているのと同じように、中央に隙間ができます。これは、位置がずれているか無駄になっている部分です。より細かいサイズで同じ凹凸のある石を取り付けると、隙間が比較的小さくなり、調整が容易になり、隙間を埋めやすくなります。

前の数字との差が比較的小さくても、数が少ないので問題ありません。つまり、動きが柔軟でリスクが低いということです。特定の要因により時間の見積もりが不正確な場合、前の少数のタスクは約20分の残業です。2〜5日間残業する代わりに。

大きなデジタルギャップが大きいため（Fermiシリーズの前後2つの値の差の比率は1.618に近い）、「この複雑さが20か21か」の推定を回避することができます。「13が必要な場合は20が必要であり、40が必要な場合。

そのようなギャップは、ほとんどすべてが1.5倍以上悪いため、同じ要件の見積もりの違いを浮き彫りにすることができます。この比率は、人間が相対的なサイズを判断するのが非常に簡単であるため、多くのニュアンスと不要な再見積もりプロセスのコストを削減できます。

ポーカーカードの特別番号

さらに、上の写真は、0、無限大、疑問符などのいくつかの特別な数字で見ることができます。

0は、この要件をまったく実行する必要がないか、すでに完了していることを意味する場合があります。
無限大とは、需要が明確であることを意味しますが、最大数を超えるものは、需要を複数のより小さなサイズの要件に細分化する必要があることを示します。
疑問符は、需要が明確ではなく、説明または明確化するためにPO / PMが必要であることを示します。

どのように

1.最初に、単一テーブルの包括的なクエリの関数など、複雑さの単位1を定義します。見積もりプロセスは相対的なサイズに基づいているため、最初に比較の単位ベンチマークを定義し、チームが見積もりを行った後に比較の基礎があります。

2.ホストは要件（ユーザーストーリーカードなど）を声に出して話し、全員が要件を理解し、各人が独自の推定複雑さを提示するようにします。プランニングポーカーを使用する理由は、評価した数字をローテーションする代わりに、評価した数字を同時に表示できるためです。数字を見つけて、背後にいる人々の結果が前の数字の影響を受けるのは簡単です。

3.チーム内に異なる見積もりがある場合、2つは最小と最大であると推定され、それらが複雑または単純である理由を評価します。上記の例では、推定プロセスで、ある人がストーリーポイントを13と推定すると、ほとんどの人が20を推定し、別の人が40を推定します。13と40はほぼ3倍悪いので、基本的に、同期されていません。

たとえば、13を見積もる人は、この需要は過去の要件とほぼ同じであり、この要件は想像したほど複雑ではないと考えています。40と見積もる人は、この要件やプロセスに精通していないため、比較的複雑に感じるかもしれません。

4.最小値と最大値は、評価の理由が完了し、さらに投票が行われます。それでも投票数が異なり、大多数の人がコンセンサスを持っていて、推定される複雑さがコンセンサスの複雑さから1レベルだけ離れているというコンセンサスがない場合は、異なる数を推定するメンバーに、あなたが評価した数字を受け入れることができます。

5.番号にまだレベルを超えるギャップがある場合、またはコンセンサスが得られない場合は、コンセンサスに達するまで手順3〜5を繰り返します。

繰り返しになりますが、実際にタスクを実行するか、要件を完了する人だけが投票プロセスに参加でき、PO / PMは干渉できません。

どうして

この見積もり方法にはいくつかの利点があります。

一緒に仕事をしている人は、合理的で客観的な見積もり結果を決定し、参加感があり、不満はありません。
決定の結果は、POとチームの間のコンセンサスであり、将来のしっぺ返しの状況の発生を減らすでしょう。
誰もが要件を理解できます。将来的には、誰もが要件を満たす人として行動することができます。サポートの要件が必要な場合、人々は互いに助け合ったりサポートしたりすることもできます。
そうする前に、要件の明確でない部分と疑問がある部分を明確にすることができます。
あなたがそれをすることができる前に、あなたはチームで働くための最良で最も効率的な方法を見つけることができます。
チーム全体が信頼できない人物でない限り、この数値は見積もりがチームによって共有されているという事実を反映しており、POは需要と評価のギャップを理解できます。
要件間の複雑さの相対的なサイズを比較することにより、将来のPOは、反復で実行できる作業量を約束でき、比較の基礎があります。

結論

上記の見積もりプロセスを通じて、そのような決定はオープンで、透明で、客観的で、合意に基づいています。2つの役割の場合：

PO / PMの場合：

特定のメンバーがバッファのタスクを過大評価することを心配する必要はありません。
評価プロセスで要件またはタスクを実装することの根本的な難しさを理解する。
明確に述べる必要がある、または誤解する必要のある要件の部分があるかどうかを理解します。

チームの場合：

もはや物事を行っていない人々は、期限に従って不当な制限時間を与えられます。
開発者がタスクに取り掛かる前に、開発者間で知識を交換します。見積もり数が増減するかどうかに関係なく、需要はより明確になり、見積もりはより客観的になります。
誰がこのタスクを要求しているかがまだわからないため、見積もりプロセスを客観的にチームのコンセンサスで達成できるため、プロセスを通じて誰がこのタスクに精通しているかがわかります。実際にそれを行うときは、プログラミングをペアにするか、誰に助けを求めるかを知ることができます。

このホワイトペーパーで提案するソリューションは、一般的なソリューションです。焦点はフォームではなく、どのような問題を解決するために、アジャイル推定プロセスの各リンクの設計目的にあります。

問題