1

私は、ソフトウェア製品のリリースに取り組んでいるアジャイル スクラム チームの一員です。スプリント期間は 2 週間 (~10 日) です。

ここでは、「スプリント中の受け入れ」と呼ばれる独特の指標が使用されています。基本的に、スクラム チームがスプリントでコミットおよび計画したユーザー ストーリー ポイントの半分は、そのスプリントの途中までに完了する必要があると予想されます。これは、スプリントが順調に進んでいることの強力な指標であるポイントの線形バーンダウンにつながると彼らは言います。

チームとして、私たちのスプリント中盤の承認は通常悪いものですが、スプリントの終わりまでにすべてのコミットされたユーザー ストーリー ポイントを完了することが知られています。

次の質問があります。

1) スプリント中の受け入れは有効なアジャイル/スクラムのプラクティスですか? 他の場所で使用されていますか？

2) 作業の半分が半分の時間で完了することを期待することは、作業の性質と複雑さが完全に決定論的である「工場フロア」の仕事として扱うことに似ています。ソフトウェア開発は「創造的な」プロセスであるため、アジャイルなどの非常に柔軟な方法論におけるそのような厳格な指標は関係ありません。どう思いますか？

3) スクラム チームはスプリントに間に合うようにすべてのコミットメントを完了しますが、スプリント中の受け入れ指標が悪いことについて質問されています。他の場所のスクラム チームでは、スプリントの終わりに向けてのみコミットメントを果たすことは完全に普通のことですか?

よろしくお願いします。

4

6 に答える 6

5

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

スプリントの途中で受け入れられるという話は聞いたことがありません。それが有効なアジャイル/スクラムのプラクティスだとは思えません。このサイトは、「チームが作業にコミットすると、プロダクト オーナーは作業を追加したり、スプリントの途中でコースを変更したり、細かな管理を行ったりすることはできない」と同意しているように見えます。

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

あなたが言及した理由から、厳格なメトリックは一般的に開発者と一緒に使用することはお勧めできません。また、おそらく開発者は、高品質の製品を作成することよりも、測定されているもので合格点を取得することに関心を持つでしょう. これは Joel Spolsky のバグ ベアの1つです。

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

成功するスクラム チームは、スプリントの終わりまでに約束したことをすべて完了する必要があります。バーンダウン チャートは、この目標に向けた進捗をガイドするために表示される必要があり、スプリントの後半には、スプリントが成功する可能性があるかどうかが確実に示されます。私が関わってきた成功したスプリントでは、ユーザー ストーリーの完了に向けて着実に進歩するのが普通ですが、これはユーザー ストーリーの半分を半分の時間で完了することには反映されません。

于 2012-03-12T06:30:03.967 に答える
1

これはスクラムのプラクティスではありません。これはメトリックとして解釈できますが、悪いものです。あなたの疑問に関しては、あなたは正しいです。

スクラムには、進行状況を追跡するための完璧なツールがあります。バーンダウン チャートです。任意のマイルストーンを追加する必要はありません。

あなたの経営陣はスプリントの基本概念を理解していないようです。彼らはカウンセリングを受けるか、基本的なトレーニングを受ける必要があります。1 週間以内に何をしたかが経営陣にとって依然として重要である場合は、代わりにスプリントの長さを半分に短縮することを提案してみてください。

于 2012-04-04T12:27:34.983 に答える
0 
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

はい、そうです。

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

タスクを非常に小さなタスクに分割すると、作業の進化の優れた指標を達成できます。したがって、タスクが 1 日で完了するように設計すると、バーンダウン メトリックを適切に使用できます。あなたが言ったように、予測不可能な長さの長いタスクがある場合、バーンダウンの指標は無関係です。

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

問題はチームではなく、タスクの設計です。この問題は、タスクの粒度に関するものです。あなたのチームはスプリント タイム メトリクスでジョブを完了できますが、スプリント タイム メトリクスでタスクの 50% を完了するようにタスクを調整する必要があります。タスクをより小さなタスクに分割すると、目的の (線形) バーンダウン チャートを実現できます。

于 2012-03-09T20:29:24.213 に答える
0

これは標準外の用語ですが、あなたのマネージャーが言っていることには何かがあります.

バーンダウン チャートの最後が重い (つまり、チャートの大部分で高いままで、最後に急激に減少する) バーンダウン チャートは、タスクが粗粒化されていることを示しています。スプリント全体を完了し、個々の開発者によって達成されます。このパターンでは、スプリントの終了直前まで、すべてのタスクが未完了のままになります。

これは本来の動作方法ではありません。バックログが優先順位に従っている場合、優先順位が最も高くない問題が処理されているのはなぜでしょうか? さらに、これにより、各タスクの「バス番号」が非常に低く設定され、スプリントの終わりまでにタスクが未完了のままになるリスクが大幅に増加する可能性があります。

これを修正するには、タスクをより小さなチャンクに分割する必要があります。プランニング ポーカーを行っていて、タスクが 8 ポイント以上と見積もられている場合、そのタスクは指定されていない可能性があります。分解する必要があります。可能であれば、2 秒と 3 秒 (またはそれ以下!) に抑えるようにしてください。このようにして、複数の開発者が同じ全体的な目標に向けて独立して作業することができ、同じ作業が行われている場合でも、バーンダウン チャートがよりスムーズになり、リスクが少なくなります。

于 2014-11-05T09:17:57.080 に答える
0

ミッド スプリントの受け入れは、アジャイルの実践ではないか、実際には機能しません。各ユーザー ストーリーとタスク (Rally など) の見積もりが正しい場合、バーンダウン チャートは、スプリント作業が計画に沿っており、時間内に完了できるかどうかを明確に示します。受け入れは、タスクではなく、ユーザー ストーリーの開発とテストの最後にのみ行われます。

于 2016-08-23T10:12:09.733 に答える