15

最近スクラムを実装していますが、よく疑問に思うことの 1 つは、ストーリー内のタスクの粒度です。

社内の何人かは、理想的には、これらのタスクは非常に細かく設定する必要があると述べています。彼らは、これにより、現在のスプリントでのパフォーマンスを追跡できるようになると主張しています。

これにより、コンポーネント X がデータベースに保持されるように DAO を作成するなど、実行する必要がある多くの技術的側面と小さなアクションを詳述する多数のタスクが発生します。また、Ken Schwaber と Mike Beedle の著書『Agile Software Development with Scrum』を読んでいて、タスクにはこの種の細分性が必要だということを理解しました。章の 1 つで、タスクが完了するまでに 4 ～ 16 時間かかる必要があると述べています。

しかし、私が気付いたのは、このような小さなタスクでは、物事を過剰に指定する傾向があり、計画会議で以前に確立したものとソリューションが異なる場合、多くの新しいタスクを作成するか、古いタスクを置き換える必要があるということです. また、チーム メンバーは、スプリント内で行っているすべてのことを追跡して新しいタスクを作成する必要もありません。これは、バーンダウン チャートで合計タスクを増やす必要があるが、必ずしも価値を集約するタスクを追加する必要がないことを意味するためです。

では、理想的には、タスクは各ストーリー内でどの程度の粒度である必要がありますか?

4

6 に答える 6

9

Schwaber と Beedle は、「およそ4 時間から 16 時間」と言います。

上限は便利です。チームに計画を強制し、進捗状況を毎日可視化するのに役立ちます。

下限は、過大な仕様の脆弱性とコストを回避するために、ほとんどのタスクにとって有用なターゲットです。ただし、チームが計画に役立つ短いタスクを見つける場合があり、それらを自由に含めることができます。義務付けられた下限があってはなりません。

たとえば、現在のストーリーの 1 つに、別のチームに何かを送信するタスクが含まれています。このタスクは 0 時間かかりますが、忘れずに終わらせたいタスクです。

バーンダウン チャートのタスク数は関係ありません。大事なのは残り時間。Schwaber と Beedle が指摘しているように、チームはスプリント中に自由にタスクを変更する必要があります。

于 2010-11-16T18:13:03.620 に答える
4

私の最後の割り当てでは、タスクごとに 4 時間から 32 時間かかりました。タスクを 32 時間以上と見積もったのは、見積時にタスクの内容と方法を理解していなかったためであることがわかりました。

その結果、これらのタスクの実際の実装時間は、小さなタスクよりも大幅に異なりました。また、これらのタスクで「立ち往生」したり、間違ったパスを選択したり、要件を誤解したりすることもよくありました.

後で、タスクがそれほど長く見積もられた場合、それはそれをさらに分解しようとする合図であることがわかりました. それが不可能な場合は、タスクを却下し、さらなる調査のために送り返しました。

編集
また、少なくとも週に 2 回はタスクを完了すると、気分が良くなります。
何かが計画どおりに進まない場合にも、かなり迅速なフィードバックを提供します。誰かが 2 日間で 8 時間のタスクを完了できなかった場合、その人がどこかで行き詰まっていないか、他の誰かがどのように進めるかについてアイデアを持っているかどうか、または見積もりが最初から間違っていたかどうかについて話し合いました。

于 2010-11-16T13:55:55.270 に答える
4

タスクにはおそらく半日から 1 日、場合によっては 2 日ほどかかるはずです。

このように考えてみてください。よりマクロなレベルでは、短いイテレーションは、少量の価値を迅速に生み出し、ビジネス ニーズの変化に応じて計画を変更できるようにすることで、アジリティを促進します。よりミクロなレベルでは、同じことがタスクにも当てはまります。1 回の反復に 3 か月を費やしたくないのと同じように、1 つのタスクに 1 週​​間も費やしたくありません。

毎日のスタンドアップ ミーティングで、タスクのサイズが大きすぎるという手がかりを得ることができます。チームメンバーが「昨日何をしましたか?」と頻繁に答える場合 と「今日は何をしますか？」彼らが前日に与えたのと同じ答えで、あなたのタスクはおそらく十分に小さくありません.

その例として、チーム メンバーが定期的に「今日は BigComplexFeatureObject に取り組み、明日も取り組む予定です」と 1 日以上続けて回答する場合、それはタスクが大きすぎる可能性があるという手がかりになります。うまくいけば、チーム メンバーが 1 つのタスクを完了したと報告し、別のタスクを開始しようとしている日が大半になることを願っています。

他の人が言うように 4 ～ 16 時間の短いタスクは、プロジェクトの進捗状況について PO とチームに良いフィードバックを与えます。また、チーム メンバーが「うさぎの道」をたどり、ビジネスが変化を望んでいる場合に必要とされない可能性のある作業に多くの労力を費やすことを防ぎます。

より小さなタスクを多数持つことの良い点は、PO がタスクの優先順位をより適切に設定し、提供される価値を最適化する余地を与える可能性があることです。大きなタスクの「重要な」部分が、それ自体が小さなタスクである場合、どれだけ延期または削除できるかに驚かれることでしょう。

于 2010-11-29T16:29:23.017 に答える
3

一般的に、適切な基準は、タスクが特定の日に行うことであるということです。これは理想的です。つまり、まれです。しかし、それはあなたが与えたその4-16時間の見積もり（半日かかるものもあれば、2日かかるものもあるなど）にうまく適合します。確かに、1つのタスクに中断のない1日を費やしたことはないと思います。少なくとも、スクラムミーティングのために休憩する必要があります。（前の仕事では、1日のコーディングはオーバーヘッドを考慮して6時間と見なされていました。）

私は、すべての詳細を計画したいという経営陣の誘惑を理解することができます。そうすれば、彼らはそれのあらゆる側面を細かく管理することができます。しかし実際には、それはうまくいきません。また、タスクの説明を使用して、ソフトウェアに関する詳細なドキュメントを生成し、実際のタスク自体としてそれを本質的にスキップできると考える場合もあります。繰り返しますが、実際には機能しません。

アジャイル開発は小さな作業項目を必要としますが、それをやりすぎると目的が完全に失われます。事前の計画が多すぎて、何かが変わったときはいつでも大量の追加の再計画をしなければならないという問題になってしまいます。その時点で、それはもはや機敏ではなく、単なる一連の小さな滝です。

于 2010-11-16T13:50:27.253 に答える
1

この質問に対する普遍的な答えがあらゆる状況に当てはまるとは思いません。同僚が提案していることを試してみて、最初の1、2回のスプリントの後、すべての人のニーズと希望に対応するためにプロセスを微調整する必要があるかどうかを評価して確認する必要があると思います。

于 2010-11-16T13:48:28.057 に答える
1

この 4 時間という数字は、私にとっては適切な最小値のように思えます。私は目に見える結果の観点から考えるのが好きです。コードの行ごと、画面上のラベル、またはリファクタリングされたユーティリティ メソッドごとにタスクはありませんか? しかし、他の誰かが使用するパブリック クラスや、画面上の一連のフィールドなど、他の誰かが使用できるものに到達すると、これは追跡可能なタスクのように思えます。

私にとって重要な質問は、「完了したことを知っていますか?」ということです。個々のヘルパー関数を使用すると、リファクタリングと変更の可能性がかなり高くなりますが、同僚に「これを使用してください」と言うと、機能するか機能しないかのどちらかです。タスクの完成度を評価できます。

于 2010-11-16T13:51:59.703 に答える