8

ストーリー ポイントがサブ タスクにどのように割り当てられ、ストーリー ポイントが Jira でどのように管理されるかを理解しようとしています。

25 ポイントと見積もったユーザー ストーリーがあります。開発者は、このユーザー ストーリーをいくつかのタスクに分割します。

各タスクに (25 個の) ストーリー ポイントの数を割り当てる必要がありますか? 全体として、すべてのタスクを合計すると 25 ポイントになるのでしょうか? また、ユーザーが 10 ストーリー ポイントのタスクを終了した場合、Jira は 25 ポイントのメイン ユーザー ストーリーから 10 ストーリー ポイントが焼失したことを認識しますか?

また、スプリントの最後にユーザー ストーリーが完了していない場合 (たとえば、20 ポイントしか完了していない場合)、次のスプリントで 5 ポイントの新しいユーザー ストーリーを作成しますか?

4

4 に答える 4

7

しばらくの間、Jira が問題ではないことにしましょう。

まず、タスクはポイントではなく時間で見積もる必要があります。

第 2 に、ストーリーは、完了したときにのみバーンダウンにカウントする必要があります。( https://www.scruminc.com/sprint-burndown-by-hours-or-by-story/ )

第三に、タスクから得られる価値を考えてください。タスクを実行したチームでは、タスクを作成する作業が、ストーリーが十分に定義されているかどうかの優れた検証ツールであることがわかりました。タスクをマークすることは、私のチームにとってあまり役に立ちません。

第 4 に、スプリントの最後にストーリーが完了していない場合、プロダクト マネージャーが優先順位を付け直すためにバックログに戻す必要があります。もはや優先事項ではない可能性があります (特に、予想よりもはるかに長い時間がかかっている場合)。 https://pm.stackexchange.com/questions/3990/unfinished-stories-in-a-sprintスクラムガイド から- 「すべて不完全

プロダクト バックログ アイテムは再見積もりされ、プロダクト バックログに戻されます。」

個人的には、いくらかの努力が「失われる」ため、再見積もりは好きではありません。再見積もりしないと、個々のスプリント速度が上下に跳ね返っても、速度は時間の経過とともにバランスが取れます。

場合によっては、ストーリーが大きくなりがちで、4 日または 5 日以上かかると見積もられると、スプリント内の進捗状況を簡単に把握できなくなることがあります。これは、スプリントの長さが 2 週間の場合に特に当てはまります。

私が一緒に働いたチームは、タスクから離れて、より小さなストーリーを好むようになりました。(現在、13 ストーリー ポイントを超える場合は、おそらく大きすぎるため、分割する必要があるというルールを使用しています)。

これらすべてを考慮すると、Jira はかなりうまく機能するはずです。

于 2014-01-19T15:20:20.273 に答える
6

サブタスクは、JIRA でアジャイルと組み合わせて使用​​するのが最も難しい機能だと思います。それは常に次の 2 つのシナリオのいずれかになります。最初からサブタスクを使用しないようにする理由を思い出してください。

  1. 各サブタスクは実際にはストーリーであり、最初のストーリーは広すぎました。私がこのような状況に陥るたびに、元のストーリーは 1 スプリントを超えます (開発者が急いだり、怠けたり、ストレスを感じたりする原因となります)。
  2. または、サブタスク自体が詳細すぎて、独自の問題として JIRA に入れる価値がありません。代わりに、元の問題/ストーリーの進行状況や反芻を説明するコメントを追加して、JIRA のオーバーヘッドを回避する必要があります。

編集：@DaveHillierへの応答

JIRA の腕立て伏せに近いので、サブタスクを作成するのは好きではありません。サブタスクの魅力は、JIRA の使用がより構造化されているように見えることにあると思いますが、JIRA をうまく使用する上で重要な部分は、課題数をできる限り少なく保ちながら、チームにとって効果的であることだと思います。「JIRA では少ないほどよい」と言う以外に、このスレッドで課題数を少なくすべきだと思う理由を正当化することはできません。

次の要件を満たす私がしていることをお見せしましょう。

  • 問題の透過的な進行状況 (必要に応じて他のユーザーに通知できます)
  • 自分の考えを整理させてくれる
  • 問題に沿ったままで、誰かが私の 1 つのストーリーを見て、私がどこにいるのかをすぐに理解できるようにします

次のように JIRA マークアップを使用して、メイン ストーリーの説明にリストを作成します。

Build the thing. Lots of words blah blah.

h3. Progress
* code it
* test it
* deploy it

次に、JIRA マークアップを使用し(/)て、各箇条書きの横に小さな緑色のチェックマークを追加して、バグの「リスナー」が進行状況を把握できるようにします。

Build the thing. Lots of words blah blah.

h3. Progress
* (/) code it
* (/) test it
* deploy it
于 2014-01-19T03:43:33.070 に答える
5

各タスクに (25 個の) ストーリー ポイントの数を割り当てる必要がありますか? 全体として、すべてのタスクを合計すると 25 ポイントになりますか?

いいえ、ストーリーのタスクにはポイントが割り当てられません。これは、1 つのタスクが完了してもクライアント/エンドユーザーに大きな価値をもたらさないためです。すべてのタスクを組み合わせると、エンドユーザーにとって何らかの価値のある作業コードが提供されます。本質的に、すべてのタスクが完了するまでストーリーは完成しません。覚えておいてください:作業中のソフトウェアは、進行状況の主要な尺度です。

ユーザーが 10 ストーリー ポイントのタスクを終了した場合、Jira は 25 ポイントのメイン ユーザー ストーリーから 10 ストーリー ポイントが焼失したことを認識しますか?

(前述のように) タスクにはポイントがないため、これは廃止されます。

スプリントの最後にユーザー ストーリーが完了していない場合 (たとえば、20 ポイントしか完了していない場合)、次のスプリントで 5 ポイントの新しいユーザー ストーリーを作成する必要がありますか?

スプリントの終わりにストーリーが未完成のままである場合、2 つの選択肢があります。ストーリー全体を製品バックログに戻すか、未完成のストーリーの一部を回収してソフトウェアの作業部分として扱うことができる場合は、ストーリーを分割します。 2つに。作業部分は現在のスプリントで完了したと見なされ、非作業部分はプロダクト バックログの一部になります。この部分は新規ストーリーとして扱い、別のストーリーとして見積もる必要があります。作業部分と非作業部分の間でストーリー ポイントを分割することはできません。

于 2014-01-20T11:32:03.713 に答える
1

サブタスクは、Jira Agile ではうまく機能しません。

私の現在のチームでは、それらを使用していません。

サブタスクを使用する理由がないということで、私は sethcall に同意しません。

現時点では簡単に追跡できないことを追跡したい：

  • 完了の定義の各ポイントを完了するためのタスク
  • 受け入れテストに合格するためのタスク

受け入れテストをサポートするプラグイン ( Behave for JIRA など) がありますが、私はそれらの経験がありません。

完了 (および受け入れテスト) の定義にカスタム フィールドを使用することを提案する人もいますが、リストには例外が多すぎるため、私はその考えに熱心ではありません。これは、受け入れテストにチェックリストを使用することを提案する記事です。試してみる価値があるかもしれません。

于 2014-01-19T12:29:48.900 に答える