agile - スクラム バーンダウンの問題

Question

約 9 か月間スクラムを使用しており、おおむね成功しています。ただし、当社のバーンダウン チャートが「モデル」チャートのように見えることはめったにありません。代わりに、上り下りを誘発する吐き気のある恐ろしいジェットコースターに似ています。

これに対抗するために、スプリントのプロトタイピングと設計の前により多くの時間を費やしていますが、それでもスプリント中に最初に考えていたよりもはるかに多くの作業を発見しているようです. 注: これは、バックログの新しい項目を特定したというよりも、バックログを満たすために必要な作業が最初に考えられていたよりも複雑であることを意味します。

これはスクラムの一般的な問題ですか?スムーズに進めるためのヒントはありますか?

私たちの開発作業のほとんどはグリーンフィールドではないため、既存の大規模で複雑なアプリケーションの機能を維持していることを指摘しておく必要があります。既存のコードがどのような問題を引き起こすかわからないという理由だけで、スクラムはこの種の開発にはあまり適していませんか?

スプリントが開発の詳細を検討し始めるまでに、どれくらいの時間を費やす必要がありますか?

更新: 現在、より多くの成功とよりスムーズな乗り心地を実現しています。これは主に、見積もり時に悲観的な見方をしているため、計画どおりにいかない場合に対処するための余裕ができたためです。そのおかげで、私たちはより「アジャイル」になることができたと言えます。また、バーンダウン チャートはスコープ v リソースを示すものではなく、ある種のスケジュールであるという認識を変えようとしています。

Answer 1

物事をスムーズにするためのいくつかのヒント。

1）他の人が言っているように、タスクを小さなチャンクに分割してみてください。これを行うためのより明白な方法は、技術的なタスクをより詳細に分析することです。可能であれば、プロダクトオーナーに相談して、代わりに範囲を縮小したり、ストーリーを「薄く」したりできるかどうかを確認することをお勧めします。後者の方が効果的だと思います。チームと製品所有者の両方が議論されていることを理解していれば、優先順位と見積もりを調整するのは簡単です。

私の一般的な経験則は、理想的な日の半分よりも大きい見積もりはおそらく間違っているということです:-)

2）短いスプリントを試してみてください。1か月のスプリントを行う場合は、2週間試してください。2週間やっている場合は、1週間試してみてください。

• ストーリーサイズの制限として機能します-プロダクトオーナーとチームが、正確に見積もることが容易な小さなストーリーに取り組むことを奨励します
• あなたはあなたの見積もりについてより頻繁にフィードバックを受け取ります-そしてスプリントの開始時にあなたが下した決定と実際に起こったこととの間の関係をより簡単に見ることができます
• 練習すればすべてが良くなります:-)

3）スタンドアップと回顧展を使用して、浮き沈みの理由をもう少し調べます。コードベースの特定の領域で時間を過ごすときですか？それは、製品の所有者を誤解している人々が原因ですか？チームから開発時間を奪うランダムな緊急事態？浮き沈みがどこから来ているのかを理解すれば、それらの問題に具体的に取り組むことができます。繰り返しますが、スプリントを短くすると、これがより明確になります。

4）あなたの歴史を信じなさい。あなたはおそらくこれを知っているでしょう...しかしとにかくそれを言います:-)その恐ろしいレガシーFooパッケージをいじるのにあなたが最後のスプリントであると思ったよりも3倍長くかかったなら-それはあなたが思うよりも3倍長くかかるでしょう次のスプリント。今回はどれだけ効果的だと思いますか;-)歴史を信頼し、昨日の天気などを使って次の春の見積もりを導きましょう。

お役に立てれば！

Answer 2

私の経験では、スクラムは間違いなく、メンテナンスよりも新しい開発を対象としています。新しい開発は、古い大規模なコードベースを維持するよりもはるかに予測可能です。

そうは言っても、考えられる問題の1つは、タスクを十分に小さいチャンクに分割していないことです。一般的なソフトウェア計画でよくある問題は、そのタスクを実行するために何が行われるかを実際に考えずに、「ああ、このタスクには2日かかるはずだ」と考えることです。多くの場合、座って考えてみると、そのタスクはA、B、C、およびDを実行することで構成されており、2日以上の作業になってしまうことがよくあります。

Answer 3

他の人が言っているように、私はバーンダウンが上下することを期待します。何かが起こります！ふりかえりの飼料として「上下」ビットを使用する必要があります。

「行われている」とはどういう意味かを全員が明確にし、その共同理解を利用して計画セッションを推進します。多くの場合、実行可能となるもののリストを用意しておくと、（a）忘れてしまう可能性のあることを思い出すのに役立ち、（b）後で明らかになるタスクのアイデアが増える可能性があります。

もう1つ考えておくべき点は、予測できないコードベースで月ごとに作業している場合でも、速度が適度に安定した速度に正常化することを期待しています。計画した作業に対して成功を追跡し、計画時に完成したアイテムのみを最大限に使用します。次に、計画外のタスクに焦点を当て、計画された作業にそれらのことを含めるために別の方法で実行できることがあることを示唆するパターンがあるかどうかを確認します。

Answer 4

同様の問題がありました。私の以前のチーム (1 年以上) は大規模で、一連の初期製品のリリースのために、急速に変化する非常に大規模なコードベースを維持していました。私たちのバーンダウンは恥ずかしそうに見えましたが、これまでで最高のものでした。

（グラフの見栄えを良くするために）役立つかもしれないことの1つは、一定にコミットされた時間/ポイントの数に固執することです. タスクを過小評価していて、2 倍の時間を費やさなければならない場合は、スプリントから何かを引き出します。新しいタスクを引き込む場合、それはチームがコミットしたものよりも明らかに優先度が高いため、他のタスクを引き抜きます。

計画の段階とその前に、タスクを多くのタスクに分割しようとしましたが、それは役に立ちませんでした。実際、スプリント中に追跡するチケットが増えただけです。要件はチケットへの移行を開始し、(当然のことながら) すべてのシャッフルで迷子になりました。

私の新しいチームでは、かなり急進的なアプローチを取り、「ProjectX に v1.2 の機能を実装する」などの大きなチケット (1 週間以上かかるものもあります) を作成し始めました。ProjectX (バージョン 1.2 を含む) の要件/機能リストは wiki に保存されているため、チケットは非常にクリーンで、実行された作業のみを追跡します。これは私たちを大いに助けてくれました -他のチームを助けたり火を消したりするためにスプリントタスクを引き離し続けているにもかかわらず、追跡するチケットがはるかに少なくなり、すべてのスプリントを完了することができました.

新しいアイテムを持ち込むことを (男性によって) 強制された場合 (およびその場合にのみ)、スプリントからアイテムを押し出し続けます。

役に立ったもう 1 つの簡単なヒントは、「スプリントの合計時間」をバーンダウンに追加することです。これは、すべての見積もりの​​合計になります。このラインをフラットに保つように取り組むと、チームが直面している可能性のある問題の可視性が向上する可能性があります (降格しないと仮定して...)

-ab

Answer 5

バーンダウンでも同様の問題がありました。バーンダウンに含まれていたものを改良することで「修正」しました。

SiKeep は次のようにコメントしています。

そのスプリントに対して選択されたバックログに対する進捗状況。これは、リリースになる場合とならない場合があります。

あなたはスプリントのために特定のものを選択し、それがバーンダウンにあるので、すべての「新しい作業」がバーンダウンに表示されるかどうかはわかりません。現在のスプリントに移動するのに十分なほど重要でない限り (バーンダウンに影響を与えずに) バックログに移行することがわかります (その後、バーンダウンの上昇傾向として表示されます)。

とはいえ、トレンドラインが基本的に予想される速度に従っている場合、マイナーなアップとダウンは正常です。あなたが言及しているジェットコースターの傾向が気になります。ただし、現在のスプリントに優先度の高い項目のみを追加してバーンダウンを分離するという考え方は、バーンダウンのこれらの浮き沈みを抑えるのに役立つ場合があります。

他の人が言っているように、スプリント開始前の計画は短くする必要があります... ( 4 時間以内)。

Answer 6

計画外のタスクには「タイムボックス」タスクを使用しています。優先度の高い作業が発生したり、突然バグが発生したりするときはいつでも、タイムボックスの時間を使用できます (ただし、ゼロ未満になることはありません)。この方法には、どのタスクが予期せぬものであったかを簡単に追跡できるという追加の利点があり、次のスプリント計画でそれらのことを考慮に入れることができます。

Answer 7

スプリントの開始日に新しい作業を統合して、見栄えの良いバーンダウン チャートを作成できます。

追加の作業に特定のマーカーを付けてタグ付けし、スプリントの最後に、以前にそれらのタスクを特定できなかった理由を評価できます。

Answer 8

記事あなたのバーンダウンチャートですか？バーンダウン チャートの特定のステータスが何を意味するかを説明します。また、それをどうするかについての提案も提供します。

この記事で説明されているいくつかの例:

Answer 9

現在、バーンアップチャートを使用しています。残っている作業量をグラフ化するだけでなく、完了した作業量と合計作業量 (つまり、完了 + 未処理) の 2 つをグラフ化します。

これにより、すべての作業が完了したときに交わるはずの 2 本の線がグラフに表示されます。また、作業が追加されて進捗が遅れていることが明確にわかるという大きな利点もあります。

必要に応じて、PO が 1 つの行 (作業全体) を「所有」し、開発者/テスターが他の行 (完了した作業) を「所有」します。

PO の行は、作業の追加/削除に応じて上下します。

dev/tester ラインは、作業が完了したときにのみ上がります。

Answer 10

これはあるべき姿です。バーンダウン チャートがモデル チャートのように見える場合は、問題があります。チャートは、あなたがコミットメントを行い、すべてのストーリーを完了することができるかどうかを確認するのに役立ちます.

スプリント中にストーリーを発見することは常に起こります。理想的には、事前にタスクを設計して見つけ出すことができますが、それらが機能する場合、事前に大規模な設計が機能しないのはなぜでしょうか? 最後の質問に答えると、スプリント計画には最大で 4 時間かかります。