スクラム バーンダウンの問題 [終了]
https://stackoverflow.com/questions/91257
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私たちはスクラムを約 9 か月間使用してきましたが、ほぼ成功しています。ただし、バーンダウン チャートが「モデル」チャートのように見えることはほとんどなく、嘔吐を伴う上昇と落下を伴う恐ろしいジェット コースターに似ています。
これに対処するために、スプリントの前にプロトタイピングと設計に多くの時間を費やしていますが、それでもスプリント中に当初考えていたよりもはるかに多くの作業が発見されているようです。注記：これは、バックログの新しい項目を特定したというよりも、バックログを満たすために必要な作業が当初の考えよりも複雑であることを意味します。
これはスクラムによくある問題ですか?スムーズに進めるためのヒントを持っている人はいますか?
私たちの開発作業のほとんどはグリーンフィールドではないため、既存の大規模で複雑なアプリケーションの機能を維持していることを指摘しておきます。既存のコードがどのような問題を引き起こすかわからないという理由だけで、スクラムがこの種の開発にはあまり適していないのでしょうか?
スプリントで開発の詳細を詰め始めるまでに、どれくらいの時間を費やす必要があるでしょうか?
アップデート：私たちは今、より多くの成功を収めており、よりスムーズに進んでいます。これは主に、私たちが見積もりの際に悲観的な見方をするようになり、計画通りに進まない場合に対処するための余裕ができたためです。これにより、より「機敏」になることができると言えるでしょう。また、バーンダウン チャートはスコープとリソースを示すものではなく、ある種のスケジュールであるという認識を変えようとしています。
解決
物事をスムーズに進めるためのヒント。
1) 他の人が言ったように、タスクを小さな塊に分割してみてください。これを行うためのより明白な方法は、技術的なタスクをより詳細に分解してみることです。可能であれば、製品所有者に相談して、代わりに範囲を減らすか、ストーリーを「薄く」できるかどうかを確認することをお勧めします。私は後者の方が効果的だと思います。チームと製品所有者の両方が議論の内容を理解していれば、優先順位と見積もりの調整が容易になります。
私の一般的な経験則では、理想的な 1 日の半分を超える見積もりはおそらく間違っているということです :-)
2) 短いスプリントを試してください。1 か月のスプリントを行う場合は、2 週間試してみてください。2 週間続けている場合は、1 週間試してみてください。
- ストーリーのサイズを制限する役割を果たし、製品所有者とチームが正確に見積もりやすい小さなストーリーに取り組むことを奨励します。
- 見積もりに関するフィードバックをより頻繁に受け取ることができ、スプリントの開始時に行った決定と実際に起こったこととの関連性を確認しやすくなります。
- 練習すればすべてがうまくなります:-)
3) スタンドアップと振り返りを使用して、浮き沈みの理由をもう少し詳しく調べます。コードベースの特定の領域に時間を費やしているときですか?それは人々が製品所有者を誤解していることが原因でしょうか?チームの開発時間を奪うランダムな緊急事態はありませんか?浮き沈みがどこから来ているかをより深く理解すると、多くの場合、それらの問題に具体的に対処できるようになります。繰り返しになりますが、スプリントを短くすると、これがより明確になります。
4) 自分の歴史を信じましょう。おそらくこれはご存知でしょう...しかし、とにかく言います :-) もし、その恐ろしいレガシー Foo パッケージをいじるのに、スプリントが続くと考えている時間の 3 倍の時間がかかったとしたら、次のスプリントにも、あなたが考えている時間の 3 倍かかります。今回はどれだけ効果的だと思っていても ;-) 過去の履歴を信頼し、昨日の天気などを利用して、来春の予測を立ててください。
お役に立てれば！
他のヒント
スクラムがほぼ成功していると聞いてうれしく思います。スプリント バーンダウン チャートが理想的に見えることよりもそれが重要です。スプリント バーンダウンは、チームがスプリントの目標に向かって順調に進んでいるかどうかを知るのに役立つツールにすぎません。チームがスプリントの目標を達成しているのであれば、グラフがジェット コースターのように見えてもあまり心配する必要はありません。いくつかの提案
- スプリントの振り返り中に、追加の作業がどこから来るのかをチームに尋ねます。
- スプリントの早い段階で良好な受け入れテストが行われないと、余分な作業が発生する可能性があります
- バックログがきちんと整理されていないと、余分な作業が発生する可能性があります。経験則としては、チームの時間の少なくとも 5% を、次のスプリントのストーリーについて事前に考えることに費やすことです。
- 進行中の作業を監視します - チームは並行してやりすぎていませんか?
- スプリント計画中、チームはストーリーを構成するタスクの内訳についてどのように感じていますか?
スプリント目標を達成できていない場合は、確立されたチームのベロシティを利用して、次のスプリントでは負担を軽減します。走る前に、歩くことが上手になる必要があります。
私の経験から言えば、スクラムはメンテナンスよりも新しい開発を重視しているのは間違いありません。新しい開発は、古い大規模なコード ベースを維持するよりもはるかに予測可能です。
そうは言っても、考えられる問題の 1 つは、タスクを十分に小さなチャンクに分割していないことです。一般に、ソフトウェア計画に関して人々が抱えるよくある問題は、そのタスクを実行するために何が必要かをよく考えずに、「ああ、このタスクには 2 日かかるはずだ」と考えてしまうということです。座ってよく考えてみると、そのタスクは A、B、C、D の実行で構成されており、最終的には 2 日以上の作業になることがよくあります。
他の人が言ったように、バーンダウンは上下にあると予想されます。何かが起こる！「上向きと下向き」の部分は、振り返りの材料として使用する必要があります。
「完了」が何を意味するのかを全員が明確に理解していることを確認し、その共通理解を利用して計画セッションを推進してください。多くの場合、何を完了したかのリストを用意しておくと、(a) 忘れそうなことを思い出すのに役立ち、(b) そうでなければ後から浮かび上がってくるタスクについてのアイデアがさらに増える可能性があります。
考慮すべきもう 1 つの点は、予測不可能なコードベースで毎月作業している場合でも、速度がかなり安定した速度に正規化されることを期待することです。計画した作業に対して成功を追跡し、計画時には完了した項目のみを最大値として使用してください。次に、計画外のタスクに焦点を当て、それらのタスクを計画済みの作業に組み込むために別の方法で実行できることを示唆するパターンがないかどうかを確認します。
私も同様の問題を抱えていました。私の以前のチーム (1 年以上在籍) は大規模で、一連の初期製品の発売に向けて、非常に大規模で急速に変化するコードベースを維持していました。私たちのバーンダウンは恥ずべきものでしたが、それが私たちにできる最善のことでした。
グラフの見栄えを良くするために役立つことの 1 つは、コミットされた時間数/ポイント数を一定に保つことです。タスクを過小評価し、2 時間必要になった場合は、スプリントから何かを取り出してください。新しいタスクを取り込んだ場合、それはチームがコミットしたものよりも明らかに優先度が高いため、他のタスクを取り除きます。
私たちは計画を立てる前に、タスクを多くのタスクに分割しようと試みましたが、それは決して役に立ちませんでした。実際、スプリント中に追跡するためのチケットがさらに増えただけです。要件がチケットに移行し始め、(当然のことですが) すべてのシャッフルの中で失われてしまいました。
私の新しいチームでは、かなり急進的なアプローチを取り、「ProjecxにV1.2機能を実装する」などの大きなチケット（1週間以上）を作成し始めました。 Projecx（バージョン1.2を含む）の要件/機能リストはWikiに保持されるため、チケットは非常にきれいで、実行された作業のみを追跡します。これは私たちにとって非常に役に立ちました。 方法 追跡するチケットが減り、他のチームを支援したり消火活動をするためにスプリント タスクから外され続けているにもかかわらず、すべてのスプリントを完了することができました。
新しいアイテムを導入するよう（男性によって）強制された場合に限り、アイテムをスプリントから押し出し続けます。
役に立ったもう 1 つの簡単なヒント:「スプリントの合計時間」をバーンダウンに追加します。これはすべての推定値の合計になります。この境界線をフラットに保つよう努めることは助けになる可能性があり、チームが直面している可能性のある問題の可視性を高めます (それで降格されないことを前提としています...)
-ab
私もバーンダウン時に同様の問題を抱えていました。バーンダウンに含まれていたものを改良することで、それを「修正」しました。
SiKeep は次のようにコメントしました。
そのスプリントのために選択されたバックログに対するその進捗は、リリースとして終わる場合とそうでない場合があります。
スプリント用に特定のものを選択し、それがバーンダウンに含まれるため、すべての「新しい作業」がバーンダウンに表示されるかどうかはわかりません。現在のスプリントに移行するほど重要でない限り（バーンダウンに影響を与えず）バックログに進むと思います（その後、バーンダウンの上昇傾向として表示されます）。
そうは言っても、 多少の上り下りは正常です, トレンドラインが基本的に予想速度に従っている場合。私はあなたが言及しているジェットコースターの傾向を懸念しています。ただし、優先度の高い項目のみを現在のスプリントに追加してバーンダウンを分離するというアイデアは、バーンダウンの上下を緩和するのに役立つ可能性があります。
他の人が言ったように、スプリントを開始する前の計画は短くする必要があります...(4時間以内).
計画外のタスクには「タイムボックス」タスクを使用しています。優先度の高い仕事が迫っているときや、突然バグが発生したときは、タイムボックスの時間を利用できます (ただし、ゼロを下回ることはできません)。この方法には、どのタスクが予期せぬものであったかを簡単に追跡でき、次のスプリント計画時にそれらのことを考慮に入れることができるという追加の利点もあります。
スプリントの開始日に新しい作業を統合して、見栄えの良いバーンダウン チャートを作成できます。
追加の作業に特定のマーカーを付けて、スプリントの終了時に、これまでそれらのタスクを識別できなかった理由を評価できます。
現在、バーンアップ チャートを使用しています。単に残りの作業量をグラフ化する代わりに、次の 2 つのことをグラフ化します。完了した作業量と総作業量 (すなわち、完了 + 未処理)。
これにより、すべての作業が完了したときに交わるはずの 2 つの線がグラフ上に表示されます。また、作業が増えて進捗が遅れていることが明確に分かるという点でも大きなメリットがあります。
必要に応じて、PO が 1 つのライン (合計作業) を「所有」し、開発者/テスターがもう 1 つのライン (完了した作業) を「所有」します。
発注書のラインは、作業を追加/削除すると上下します。
開発者/テスターのラインは、作業が完了した場合にのみ上がります。
記事 それはあなたのバーンダウンチャートですか？ バーンダウン チャートの特定のステータスが何を意味するかを説明します。また、それに対して何をすべきかについての提案も提供します。
記事で説明されている例は次のとおりです。
これは当然のことです。バーンダウン チャートがモデル チャートのように見える場合は、問題があります。このチャートは、あなたが約束を果たし、すべてのストーリーを完了できるかどうかを確認するのに役立ちます。
スプリント中にストーリーを発見することは常に起こります。理想的には、事前にタスクを設計して見つけることができますが、それらが機能するのであれば、なぜ大規模な事前設計が機能しないのでしょうか?最後の質問に答えると、スプリント計画には次の時間がかかります。 長くても4時間.
