誰がスクラムのタスクを定義、割り当て、実装、および実行する必要がありますか?


10

スクラムでの役割は、プロダクトオーナー、スクラムマスター、およびスクラムチームです。ユーザーストーリーは、タスクと呼ばれる小さな部分に分解する必要もあります。タスクには、定義、割り当て、実装、フォローという4つのフェーズがあるようです。

タスクについてスクラムで誰が何をすべきか?タスクの残り時間を更新するのはスクラムマスターの責任ですか、それとも開発者(スクラムチーム)の責任ですか?開発者は自分にタスクを割り当てる必要がありますか、それとも製品の所有者が伴うスクラムマスターの責任ですか?

回答:


12

アジャイルはいくつかの原則に従います。その1つは、人々に力を与えることです。そのため、タスクはチームが定義し、タスクはチームメンバーが選択する必要があります。タスクをチームメンバーに割り当てないでください。チームは自己組織型である必要があり、そのため、難しい/簡単/興味深い/退屈なタスクの配分は均等になるはずです。

スクラムマスターは、チームがスクラムの原則に従っていることを確認する必要があります。彼はプロジェクトマネージャーではありません。

これは理論であり、成熟したチームで機能します。スクラムの初心者にとっては難しいこともありますが、少なくともチームメンバーがタスクを割り当てるのではなく、自分でタスクを選択するように主張する必要があります。

タスクの残り時間を更新する

私の意見では、タスクの見積もりと残り時間の維持は無駄です。ユーザーストーリーのセットにコミットしたので、各タスクにどれくらい時間がかかるかは問題ではありません。唯一重要なのは、ユーザーストーリーが完成するかどうかです。


3
タスクを見積もり、残り時間を維持することは無駄です。「残り時間」は、予期せぬ事態が発生したときに取得できる最も早い早期警告サインであることがわかりました。正確である必要はありませんが、スクラムマスターは、見積もりがA)変化していないか、B)増加しているかを認識する必要があります。これは、(開発者にさえ)隠れた障害がある場合によく発生します。新しいスクラムチームでは、これは透明性にも役立ち、「昨日xをやりました、今日はもっとxをやる」というスタンドアップを防ぐのに役立ちます。
ブルック

@ブルック:スクラムがバーンダウンチャートを使用するのはそのためです。バーンダウンチャートを使用して、完了したユーザーストーリー(ストーリーポイントによって定義される複雑さ)を表示する場合でも、そのようなフィードバックがあります。私の経験では、10時間の未完了の作業で終了することはないため(例)、1時間ごとに10件のユーザーストーリーが失われるため、フィードバックはさらに改善されます。
Ladislav Mrnka、2011

できれば、この答えを+10あげます。見つけて、絶対に正しい。
wolfgangsz 2011

@Ladislav Mrnka:バーンダウンから同様のデータを取得しますが、作業が残っていると、より詳細に表示され、より早く警告することができます。すべてのタスクに1日未満かかる場合は問題となりますが、タスクに1日以上かかる場合もあるので、残りの作業は、心配する必要があるかどうかをすばやく示すことができます。私は通常、人々にそれについての多くの考えを与えるように頼みません、彼らの腸の感覚が何であれ、ちょうどそれは追加するメトリックのそれほど面倒ではありません。
ブルック

より早く?スプリントは「短く」する必要があります。警告する必要があるのはどのくらい前ですか。私は非常に単純なルールを使用しました。スプリントの半分でユーザーストーリー(ストーリーポイント)の少なくとも1/3が完了していない場合、おそらくコミットしたすべてを提供することはできません。それはかなりうまくいき、私たちは何も見積もる必要がありませんでした。2〜3週間かかるスプリントでは、これ以上必要ありません。
Ladislav Mrnka、2011

6

開発者は自分にタスクを割り当てる必要がありますか、それとも製品の所有者が伴うスクラムマスターの責任ですか?

私が作業した場所は、私たちが両方とも行ったスクラムに従っていますが、理想的には開発者は自分のタスクを選択する必要があります。最終的には、すべてのタスクが完了していれば問題ありません。

それぞれのアプローチには長所と短所があります。

チームに自分で選択させる:

  • 長所-チームはタスクの所有権を感じ、彼らは彼らが良い仕事をすることができると思うものを選びます。所有権は、多くの人々が見落としている開発の重要な側面です。
  • 短所-一部のタスクは、最初に実行したほうがよい最後まで残ります。

タスクが割り当てられています:

  • 長所-すべてのタスクは平等と見なされ、除外されない可能性があります。
  • 短所-チームメンバーは、タスクの所有権を必ずしも感じるとは限りません。

実際には、実用的なアプローチをとる必要があります。タスクを割り当てる必要がある場合もありますが、これらは数が少ないはずです。


+1-最終発言権を持つ人のため。誰かが担当する必要があります。
JeffO 2011

2
特定の実用主義は有用なものですが、開発者にタスクを割り当てることは、スクラムのやり方ではありません
wolfgangsz 2011

@ChrisF:スクラムのどこにスクラムマスターが支配権を持ち、他の人が開発者にタスクを割り当てることが許可されていると言っているのか明確にできますか?
マーティンウィックマン

@Martin-いいえ、できません。主に私がスクラムで働いてからしばらく経っていたからです。しかし、私の中で現実主義は、と述べているいくつかの点で誰かが決断を下す必要があります。
ChrisF

ゲームの少し遅いですが、私の2¢-最初に実行する必要があるタスクが最後まで残っている場合、それは、スクラムマスター(およびプロダクトオーナー)がそれらのタスクを十分に重視していないことを意味します。
ウェインヴェルナー

2

スクラムプロセスでは、次のことを行います。

タスクは、ユーザーストーリーを実装する可能性が最も高い開発者のグループによって定義されます。

少なくとも2人の開発者がユーザーストーリーの実装を担当しているため、タスクに自動的に割り当てられます(並行して作業できる場合は、知識と個人の好みに応じて最適なタスクを実行します。それ以外の場合は、プログラムをペアリングします)。


2

タスクの残り時間を更新するのは誰ですか?

残りの作業量を知ることができるのは開発者だけなので、情報を提供します。正確に誰が時間を更新するかは重要ではありません。

開発者は自分にタスクを割り当てる必要がありますか?

はい。自分のためにタスクを選択することは、他の誰かがあなたに割り当てた場合には不可能な方法でタスクを完了することを強く約束するため、強力です。


2

スクラムガイド

タスクに関するすべてのことは、スクラムのチームの責任です。チームは通常、スプリント計画会議の後半でストーリーをタスクに分解しますが、新しい情報を導入したり、スプリント中にタスクをいつでも削除したりできます。私の意見では、この毎日のフィードバックループはスクラムの重要な部分です。

スクラムマスターはチームリーダーでもそのマネージャーでもありません。スクラムマスターの役割は、スクラムプロセスを促進し、障害を取り除くことです。スクラムマスターは開発者にタスクを割り当てません。製品所有者は開発者にタスクを割り当てません。チームは、ユーザーストーリーを実装することにより、製品所有者(および顧客を拡張すること)に価値を提供します。

チームはすべての見積もりを担当します。したがって、ボード上のタスク(およびストーリー)の見積もりを所有します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.