2

アジャイル見積もりでは、1/2 から 1.5 日のような間隔のみを選択すると言う人がいるのは本当ですか?

4

9 に答える 9

8

経験則として (アジャイルであろうとなかろうと)、タスクを最大で 1 ~ 2 日単位に分割するのが一般的です。

それよりも大きなチャンクがある場合、タスクを十分に分割していないため、見積もりを逃して、分割したよりも長い時間見逃す可能性が高くなります。多くの場合、それを分解すると、最初の見積もりが外れていることがわかります。タスクをより具体的なタスクに分解したため、見積もりがより正確になり、追跡可能で意味のあるものになりました。

やることリストにすぐに出てくるタスクについては、これに注意を払う必要がありますが、機能の詳細を必ずしも考えていない長期的な計画については、より大きな見積もり/機能の分割されていないタスクは問題ないと思います.

Joel Spolsky がこれについて話しているリンクがあります。ページの半分ほど下にあるアイテム #5 を見てください。

http://www.joelonsoftware.com/articles/fog0000000245.html

于 2009-08-27T16:44:55.187 に答える
4

私の経験では、2 日を超える見積もりは、さらに分解する必要がある深刻な作業を隠している可能性があります。このような見積もりは、非常に高い確率で上回ります。個々のチャンクのコストが 1 ~ 2 日を超えないように、すべてを小さなチャンクに分割するようにしてください。

于 2009-08-27T16:44:48.413 に答える
3

見積もりを短くすることには利点があります。大きなタスクを、迅速に測定および議論できる小さな個別のタスクに分割することを強制するため、アジャイル開発プロセス全体を促進するのに役立ちます。

そうは言っても、私はこのようなもので厳格なルールとして「ルール」を維持することはほとんどありません. ただし、これは良いガイドラインだと思います。

于 2009-08-27T16:41:32.587 に答える
1

私のチームはジュニアプログラマー(大学生)で構成されており、大きなタスクをすべて小さなタスクに分割すると、一般的に簡単であることがわかりました。それにはより前向きな考え方が含まれますが、最終的には生産性が向上し、進捗状況をより簡単に評価できるようになります。また、一日の終わりに何かを完了したときに達成感をもたらします。

于 2009-08-27T17:03:54.303 に答える
1

私はそのガイドラインに同意します。私がこれまでに 5 日間のタスクを引き受けたことがあるときはいつでも、それは 3 週間の悪夢に変わりました。見積もりが大きいということは、その問題について事前に十分に学んでおらず、何が関係しているかを把握できていなかったことを示しています。

于 2009-08-27T17:06:43.317 に答える
0

同意しません。チームのイテレーションが 2 週間の場合、10 日ということは、イテレーション クローズ (ショー & テル)、イテレーション プランニング、およびタスキングまたはプランニング ポーカーに 1 日が費やされることを意味します。

プランニング ポーカーをプレイする場合、チームは見積もりの​​ために幾何学的またはフィボナッチ プログレッションを使用します。たとえば、カードには 1、2、4、8、16 または 1、2、3、5、8、13 などの値が含まれます。各数字は、2 人のプログラマーの開発日数を反映しています。

各カードについて、議論が行われると、各メンバーは見積もりを反映したカードを同時にプレイします。チームの大多数が同じ見積もりに収束した場合、その見積もりは受け入れられます。見積もりに大きなばらつきがある場合は、さらなる議論が行われ (メンバーは見積もりの​​理由を説明します)、別の投票が行われます。これは、コンセンサスに達するまで発生します。

8 より大きい数字が選択された場合、そのカードは大きすぎると見なされ、そのカードは少なくとも 2 枚の小さいカードにリファクタリングされます。その理由は、そのような大きな見積もりは、カードが大きすぎて 1 回の反復で完了することができず、見積もりが不正確である可能性が非常に高いことを示しているからです。

このような方法を使用すると、チーム メンバーは約束したことをすべて実行するというコミットメントを得ることができ、新しいチームの見積もりは非常に正確になるため、カードの持ち越しはすぐにリスクが低くなります。

于 2009-08-28T11:48:23.220 に答える
0

agile42 のブログにある、アジャイルの見積もりと計画に関する非常に優れた記事:ジャスト イン タイム、ジャスト イン タイム

于 2009-08-28T15:50:44.490 に答える
0

このスレッドでは、情報が少し混ざり合っていて重複していると感じています...私の主張をさせてください:-)

1) フィボナッチ数列は、Mike Cohn のプランニング ポーカー テクニックで非常によく使われていますが、ユーザー ストーリーの「複雑さ」を見積もることに関するものです。ユーザー ストーリーは、Cam が言ったように、通常はカードに書かれ、複数のタスクを伴います。少なくとも、ストーリーを出荷可能にするために必要なすべてのもの (Ken Schwaber、Alistar Cockburn、Mike Cohn...)

2) ストーリーを完了するために含まれるタスクは、通常、理想的な時間またはポモドーリ (Francesco Cirillo、「ポモドーロ テクニック」) で見積もられます。通常、理想的な時間数を見積もる場合、経験則では、半日 (理想的な 3 時間) から 2 日 (理想的な 12 時間) の作業時間に保つことです。これは、少なくとも 2 日ごとにチーム メンバーがタスクを完了したと報告することで、チームがより定性的なステータス情報を得ることができるためです。これは、60% の完了よりもはるかに「価値がある」ものです。Pomodori を使用すると、暗黙的に 25 分に「タイムボックス化」されます。各

タスクを小さくする理由は、基本的に「経験的プロセス制御理論」に由来します。この理論では、透明性と定期的な検査と適応により、作業の進捗状況を数値化することでよりよく確認できます。より小さなタスクを持つことの目標は、「未来」を予測しなければならないことから生じる自然な不確実性に与えられた「推測」をあまり加えずに、実際に行われることを詳細に明確に記述し、想像できるようにすることです。さらに、結果を定義し、タイムボックスを短くすることで、人々は十分な「切迫感」を持って集中し続けることができ、やりがいがあり、やる気を起こさせる経験になります。

また、Chris からの「動機」と「エゴ」の要点に追いつきたいと思いますが、人々に献身的でやる気を起こさせる良い方法は、タスクの期待される結果を定義し、結果を測定できるようにすることであると付け加えます。完了したら、成功を祝います。このアイデアはポモドーロ テクニックに要約されていますが、推定に理想的な時間を使用することでも実現できます。ポモドーロ テクニックのもう 1 つの興味深い点は、「休憩」は「ファースト クラスの市民」と見なされ、定期的に計画されることです。これは、特に創造的で脳を集中的に使用する活動において非常に重要です :-)

どう思いますか?
ベスト
アンドレアト

于 2009-08-29T09:55:46.390 に答える