私は、Joel Spolsky が提案した方法で時間の見積もりについて考えることに慣れています。スケジュールされた項目に 16 時間以上かかる場合は、より小さなタスクに分割する必要があります。現在、私はチームにスクラムを導入し、ストーリー ポイントに基づく見積もりを取り入れています。ストーリー ポイントの適切な単位は、工数ではなく工数であることが理想的だと思います。日を使用した場合、ほとんどの問題の見積もりは 1/2 または 1 になります。
理想的な工数の使用がスクラムの文献で最も頻繁に言及されている理由について何か考えがありますか?
ストーリー ポイントの適切な単位は、工数ではなく工数であることが理想的だと思います。
このフレーズは本当に奇妙に聞こえますが、真実ではありません。ストーリー ポイントと理想的な工数の間に相関関係があることをどこで知りましたか? 理想的な工数は、スクラムの初期に使用された可能性がありますが、私にとって、ストーリー ポイント (SP) は別のものです...
ストーリー ポイントは、複数のタスクで構成される特定のプロダクト バックログ アイテム (PBI) に関連する相対的な労力を定量化する方法です。PBI の「サイズ」を推定するために数値サイズ (つまり、1 から 10 のスケール) を使用するチームもあれば、T シャツのサイズ (XS、S、M、L、XL、XXL、XXXL) を使用するチームもあれば、フィボナッチを使用するチームもあります。シーケンス (1、2、3、5、8、13、21、34 など)。ところで、SPには単位がないことに気づきましたか？
日を使用した場合、ほとんどの問題の見積もりは 1/2 または 1 になります。
だから何？これは、PBI が小さいことを意味しますが、これは悪いことではありません (少なくとも、最も重要な PBI にとってはそうではありません)。しかし、スクラムには理論的に 2 つの見積もりレベルがあることを忘れないでください。製品バックログ レベル (ポイント単位) とスプリント バックログ レベル (時間単位) です。前の段落で述べたように、PBI はタスクで構成されており、スプリント計画ミーティングの第 2 部でタスクに分割する必要があります。タスクは時間単位で見積もられ、ここでは 16 時間ルールが適用されます。つまり、タスクは 16 時間を超えてはなりません。もしそうなら、それは大きすぎるので、小さなタスクに分割する必要があります (大きなものを見積もるのが下手なので)。
理想的な工数の使用がスクラムの文献で最も頻繁に言及されている理由について何か考えがありますか?
これはとにかく時代遅れです。将来的には状況が変わる可能性がありますが、現在のコンセンサスは、単位のないポイントで見積もることです。ポイントは時間単位から完全に切り離されており、これは実際の単位とのマッピングを避けるために意図的に行われています。作業能力は速度 (チームが 1 回の反復で達成できるポイントの量) で測定する必要があります。
時間レベルでの見積もりは、きめ細かくなりすぎます。また、アジャイルの原則とは多少正反対のマイクロマネジメントを過剰に実行する傾向があります。
私が4つのタスクを持っていて、それぞれが半日と見積もられている場合、2日でそれらをうまく処理できると比較的確信できます。
しかし、16の1時間のタスク？タスクのいずれかが非常に多くの変動の影響を受けるため、同じ期間に行われるものに対する自信ははるかに低くなります。
ストーリー ポイントと見積もりゲームの目的は、一般的に、複数のスプリントでベロシティを効果的に判断することです。
したがって、チームの全員が同じ方法で見積もり、各見積もりセッションで同じ単位が使用される限り、見積もりに使用される単位は実際には問題ではありません。
また、異なるチームがそれぞれのストーリー ポイントを関連付けようとしないようにすることも非常に重要です。私がストーリー ポイントとして考えていることは、必ずしもあなたのものであるとは限りません。
ですから、「適切と思われるものを使用してください」以外の答えはありません。
「スクラムの理想的な工数」のグーグル検索では 6500 の結果が得られ、「スクラムの理想的な工数」では 10000 の結果が得られます。それほど大きな違いではありません。私は文献のどちらかへの偏見に気づいていません。
本当に価値のあるものは、半日 (最小タスク期間) または 1 週間 (最小スプリント期間) 未満で完了することはめったにありません。
時間単位で見積もると、誤った正確さを感じる可能性があります。5 理想工数は正確ですが、おそらく 0.5 理想工数よりも正確ではありません。
理想的な人間の単位は、時間や日などの現実世界の同様の単位へのマッピングの概念も伝えます。マッピングが単純になることはめったにありません。そのため、多くのアジリストは、タスク サイズの尺度として単位のないストーリー ポイントを好みます。次に、チーム ベロシティ メトリックは、抽象的なサイズの見積もりから実際の時間へのマッピングを行います。
わかりませんが、これは「標準的な」スクラムの長さが 30 日であるためだと推測する準備はできています。30 日のブロックで作業を行うことを計画している場合は、スプリントの長さが 1 週間または 2 週間の場合よりも粗い測定単位が必要になります。
私が見たスクラムの実装のほとんどは、1 週間または 2 週間のスプリング期間を持っています。そのため、相対的なタスク サイズが小さいため、「理想的な時間」を数えた方が便利です。
労力の相対的な測定に関する限り、スクラムを使用してソフトウェアを開発していると仮定すると、各タスクをきれいに開発した場合に作成できる個別のソースコードコミットの数を数え、それを測定値として使用します.
適切なアジャイル プラクティスに従っており、単体テストを完全にカバーし、赤緑のリファクタリング サイクルを使用している場合、半日もかからない非常に少数の意味のあるタスクがあります。また、日数を使用すると、開発者がタスクに必要な時間を過小評価する傾向が抑えられます。そしてもちろん、過小評価して過小に配信するよりも、時間を過大に見積もって過大配信するほうがよいでしょう。