「ミッドスプリント」受け入れはAgile/SCRUMの有効なコンセプトですか？

Question

私はソフトウェア製品のリリースに取り組んでいるアジャイルスクラムチームの一員です。スプリントの所要時間は2週間（〜10日）です。

「ミッドスプリント受諾」と呼ばれる固有のメトリックがここに使用されています。本質的には、スプリントの中でスクラムチームがコミットし計画したユーザーストーリーポイントの半分が、そのスプリントの途中で完了する必要があるということです。これは、スプリントが順調に進んでいることを示す強力な指標である点の直線的な打ち切りとなります。

チームとして、私たちのミッドスプリントの受け入れは通常悪いですが、スプリントの終わりまでにすべてのコミットされたユーザーストーリーポイントを完了することがわかっています。

私は、次の質問があります。

1）は、有効なアジャイル/スクラムの練習半ばスプリント受け入れますか？他の場所で使われていますか？

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

3）私のスクラムチームはスプリントのためにすべてのコミットメントを完了しましたが、私たちは悪いミッドスプリントの受け入れメトリクスについて質問されています。それ以外のスクラムチームでは、スプリントの終わりに向かってコミットメントを満たすのは完全に正常ですか？

事前に感謝します。

Answer 1

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

私は前に半ばスプリント受諾の聞いたことがありません。私はそれが有効なAgile/Scrumの練習だとは思わない。 This siteは「チームが作業にコミットすると、プロダクトオーナーはコースミッドスプリントを変更したり、マイクロマニーを変更することはできません。

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?

任意の剛性指標は、一般的に、あなたが言及の理由で、開発者と一緒に使用するのは良いアイデアではありません。確かに、開発者は、測定されているものであれ、品質の良い製品を生産していなくても、合格マークを取得することにもっと興味があります。here、hereとhere

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?

成功スクラムチームは、彼らがスプリントの終わりで行うことを約束していることすべてを完了しなければならない - これは、ジョエルSpolskysバグ熊の一つです。バーンダウンチャートは、この目標に向けて進捗を導くために見えるはずであり、確かにスプリントの後半では、スプリントが成功する可能性があるかどうかを示します。成功したスプリントでは、ユーザーストーリーの完成に向けて着実に進歩していますが、半分のユーザーストーリーの半分にこれを反映させることはできません。

Answer 2

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％を完了する必要があります。タスクをより小さなタスクに分割し、希望の（線形）打ち切りチャートを達成することができます。

Answer 3

進行中の作業量を制限しようとしましたか？すべてのチームに2つのストーリーに焦点を当て、それらのストーリーが終了するまで移動しないと、あなたのバーンドダウンはより線形になるはずです。

ストーリーのサイズを調べる価値があるかもしれません。私は個人的には、開始から終了までに2、3日以上かかるストーリーを見るのが好きではありません。

Answer 4

これはスクラムの練習ではありません。それはメトリックとして解釈されるかもしれませんが、悪いものです。あなたの疑問について、あなたは正しいです。

スクラムには、プログレスに従うのに最適なツールがあります - バーンダウンチャート。任意のマイルストーンを追加する必要はありません。

あなたの経営陣はスプリントの基本コンセプトを理解していないようですので、カウンセリングを受けるか、基本的なトレーニングに従ってください。あなたの経営幹部にとって1週間以内に何が行われたのかが依然として重要な場合は、代わりにスプリントの長さを半分にすることをお勧めします。

Answer 5

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

最終的に重い（つまり、チャートの大部分が高くなり、最後に突然テールオフした）テイクダウンチャートは、タスクが粗粒であるということを示しています。つまり、タスクは完了するためにスプリント全体を取る可能性が高く、個々の開発者が達成する可能性があります。このパターンでは、すべてのタスクはスプリントの終了直前まで不完全なままです。

これは本当に動作する方法ではありません。バックログの優先順位が高い場合、最も重視されていない問題はなぜ発生していますか？さらに、これは各タスクの「バス番号」を非常に低く設定するため、スプリントの終了時にタスクが不完全になるリスクが大幅に増加する可能性があります。

この問題を解決するには、タスクをはるかに小さなチャンクに分割する必要があります。あなたが計画ポーカーをしていて、8ポイント以上の仕事があると見積もられている場合、その仕事は不十分である可能性があります。それは分解されなければならない。可能であれば、2秒と3秒（またはそれ以下）にしてください。このようにして、複数の開発者が同じ全体目標で独立して作業できるようにすることができます。同じ作業が完了していても、バーンダウンチャートはよりスムーズになり、危険性は低くなります。

Answer 6

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