私は最近、ポイントを使用してタスクの見積もりが行われる環境で働き始めました。このプロセスの利点を強調するリソースを見つけることができなかったので、SO コミュニティに頼って、それらが何であるかを理解する必要があります。ポイントを使用してタスクを見積もるスクラム環境で働いたことがある人がいる場合、時間を使用することよりも主な利点は何ですか?
4 に答える
tl; dr命名の違いは意味論的であり、見積もりについて異なる方法で/適切に考えるのに役立ちます。
私がスクラムチームで働いていたとき、スクラムマスターは私に、ポイントのポイント(しゃれを意図した)は問題の規模の指標であると考えられていると説明しました。時間の観点から見積もりを行う場合、(技術者以外の人、特にPHBの)人々はあなたの見積もりを締め切りと考え始めます。管理ページが32時間と見積もられている場合、そのような人々は週末までにそのページを「ちょうど」欲しがるでしょう...それは100時間かかるかもしれない他の舞台裏のものに依存しているという事実にもかかわらず別のタスクやストーリーの一部である可能性もあります。また、あなたは間違っている可能性があります(そしておそらくそうです)ので、これらはどれくらいの時間がかかるかではなく、スケール指標であると考えることが重要です。
スクラムでの見積もりは、理解して効果的に行うための重要な側面です。エンジニア (特に) が、時間に基づく従来の見積もり方法から来ていることは非常に一般的です。そして、私たちは皆、歴史的にこれらがいかにエラーを起こしやすいかを知っています。
ポイントの背後にある前提は、それらが別のストーリーと比較したあるストーリーの相対的な重み (基本的には労力) の推定値であるということです。したがって、特定のストーリーの重み付けが「2」で、別のストーリーの重み付けが「5」だとすると、実際には、ストーリー #2 はストーリー #1 のサイズの約 2 倍であると言えます。人間は、「これはあれよりも大きい」、「これはあれよりもはるかに大きい」など、アイテムを互いに比較することに非常によく適応していることが判明しました。大きさ3立方メートル」。したがって、作業項目に任意の時間数を割り当てると、通常、プラクティスで非常に悪い結果が得られるのはなぜですか。
ポイントが作用するのは、スプリントの速度です。これは、特定の期間 (通常は 2 週間から 4 週間) に、グループの人々が通常何ポイントを完了したかを示す単純な尺度です。短時間のスプリントの後、チーム メンバーが一緒にいると仮定すると、チームが取り組んでいるストーリーの種類に関係なく、ベロシティは安定する傾向があります。ただし、スクラム マスター、マネージャー、または他の非チーム メンバーではなく、チーム メンバー自身がポイント見積もりを作成することが重要です。そうしないと、プロセス全体が崩壊し、スプリントが失敗する可能性があります。
ポイントは、ストーリーの複雑さを反映するものでもあります。20 点、40 点など、ポイント スペクトルを上に移動するほど、そのチームにとってそのストーリーはより危険で複雑になります。したがって、サイズ 20 のストーリーは 5 ポイントのストーリーの約 4 倍のサイズであると言えますが、実際には 20 ポイントのストーリーが実際には 25 または 30 ポイントのサイズである可能性もあります。ストーリーの複雑さと範囲により、推定の信頼性が低下する可能性があります。したがって、通常、チームはプロダクト オーナーと協力して、可能な場合は 2 ~ 5 ポイントのサイズでストーリーのサイズを調整します。大きすぎず、小さすぎず。
最後に、チームがスクラムに習熟するにつれて、通常エピックと呼ばれる一連のストーリーがいつ完成するかについて、将来の予測を実行し始めることができます。これにより、製品または機能の目標期日を設定できます。一連のストーリーがチームによってポイントで見積もられ、そのチームのベロシティが安定している場合、バックログにそれ以上の変更がないと仮定して、作業を完了するのに必要と思われるスプリントの数を予測できます。新製品からメンテナンス リリースまで、いくつかのプロジェクトでチームと一緒にこれを行っていますが、非常に正確であり、スクラム以前の時代に時間に頼っていたときよりもはるかに正確です。
時間からポイントに移行する利点は、次のように要約できます。
- ポイントで見積もる方が高速です。
- ポイントで見積もったほうが正確です。
- ポイントで見積もる方が簡単です。
アジャイルの信条の 1 つはフィードバックです。つまり、測定と適応です。1 時間ごとにポイントを使用する利点は、「チームがそのタスクを完了するのにどれくらいの時間がかかるか」ではなく、「このタスクは他のタスクの 2 倍の大きさか」という質問に答えるのがはるかに簡単になることです。事業。プロジェクトが進行するにつれて、単位時間あたりに出荷されるポイント数を観察し、特定の時間枠内でタスクを実行できるかどうかを簡単に判断できます。本質的に、これはその時点で時間を見積もることと同じですが、見積もりは、見積もりを困難にするすべての無形の要因を含む、チームの観察された過去に基づいています (人々はうまく協力しているか、時間を浪費する非コーディング活動) -そして、あなたは「時間の交渉」を避けます。
スクラムは、スプリント計画の残りの作業をどのように見積もるかを指定しません。タスクを使用して計画を作成しているようです。私が参加した一部のチームでは、残りの作業の合計としてタスクの数をうまく使用しました。一部使用時間あり。一部のチームは、プロダクト バックログ アイテムのストーリー ポイントの残りの数を、残りの尺度として単純に使用します。
私は、タスクとストーリー (PBI) をポイントで見積もるチームと仕事をしたことはありませんが、彼らが経済の違いを理解するようになったなら、それは彼らのために働くことができると思います.