web-dev-qa-db-ja.com

ストーリーのサイズを2〜3日にすることが推奨されるのはなぜですか?

スプリントが平均10日間である場合、なぜストーリーが2〜3日間のサイズであることが推奨されるのはなぜですか?

関連質問:1つのスプリントよりも長いバックログ項目を処理するには?

6
blunders

推定する場合、タスクが長いほど変動の余地が大きくなります。変動性は多くのことを意味します-誰かが病気になって休みをとる、誰かが会議に引き込まれる、誰かが別のプロジェクトをサポートしなければならない、リソースを他の人やチームとタイムシェアする必要がある...リストは続きます。特定のタスクの時間枠を短縮することで、作業を行っている人が離れたり、見積もっている作業をブロックされたりする可能性がある時間を短縮しようとしています。

このアイデアは、スクラム(または任意のアジャイルメソッド)にも固有のものではありません。これは、エンジニアリングプロジェクトに適した見積もり手法の一部です。タスクをより細かくすると、より正確な見積もりが得られる傾向にあり、この精度は急激に高まります。

9
Thomas Owens

「提案されることが多い記事は平均して2日間のサイズにする」についての言及はありますか?

一部の人が、タスクが完了するまでに最大で1日かかると提案しているのを見てきました。重要な点は、見積りが得意ではなく、タスクを完了するのにかかる時間が長いほど、間違いを犯す可能性が高くなることです。

あなたはより多くを見つけることができます:

http://www.xqa.com.ar/visualmanagement/2009/02/one-day-tasks

そして

http://www.Amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

4
José Ricardo

ストーリーが2〜3日のサイズであることがしばしば提案されるのはなぜですか?

それが間違っているので、あなたはこの提案をどこで得たのだろうと本当に思います。この提案には一般に2つの問題があります。

  • 見積もりは日単位で行われます。
  • 提案は、あなたの平均的なストーリーがどれだけ取るべきかを決定します。

これらの問題は両方とも、アジャイル手法で使用される単純な推定の原則に違反しています。ストーリーを完了するために必要な時間を事前に把握していない。バックログ内のストーリーのサイズ(複雑さ)を比較することだけを試みており、ミーティングの計画中に、スプリント中に完了すると思われるいくつかの最も優先度の高いストーリーにコミットします。スプリントの完了後、完了したユーザーストーリーの数を確認し、他のストーリーを完了するのに必要な時間について仮定を立てることができます。より多くのスプリントを実行するほど、仮定はより正確になります。ストーリーを完成させるために必要なリアルタイムについてのあなたの仮定が向上するにつれて、あなたのコミットメントも向上します。

そのため、人々は相対的な尺度を使用して、ストーリーポイントやTシャツのサイズなどのストーリーを推定し、ストーリーポイントや他のユニットを提供するために必要な平均時間を計算します。一貫した見積もりを使用して、ストーリーポイントを配信する平均時間を3〜4回のスプリント内で安定させる必要があります。

単位は相対的なので、すべてのプロジェクトで同じスケールを使用する必要はありません。あなたは通常、あなたがそのコンテンツについて最も確信している単一のユーザーストーリーから始めて、ある程度の大きさのエタロンとしてそれを取ります。次に、エタロンと比較して他のストーリーを推定し、予想されるサイズを選択するためにすでに推定された他のストーリーを推定します。ストーリーポイントの場合、通常、フィボナッチのような予想されるサイズのシーケンスを使用します。これは、ストーリーが複雑になるにつれて、推定が難しくなり、はるかに不確実性が高まるためです。リンクされた質問で説明されているように、大きな物語は分解されるべきです。

2
Ladislav Mrnka

ストーリーが大きければ大きいほど、推定値の精度が低くなる可能性があります。

個人的には、それよりもさらに小さく分解します。

0
sevenseacat