スプリントが重なる場合のバーンダウンチャートによる進行状況の追跡
私たちのチームは、ソフトウェアを開発してクライアントに提供するために、いくつかのアジャイルプラクティスを採用しています。アジャイルキャンプに大規模に飛び込むのではなく、必要に応じて（問題/課題が特定されたときに）プラクティスを採用します。私たちにとって重要なのは、製品とスプリントのバックログを維持し、約1か月のスプリントで新しいバージョンを開発して提供することです。スプリント内で何を提供できるかを推測するために、スプリントバックログのアイテムを見積もります。しかし、進捗状況をうまく追跡していないため、目標を達成しているかどうかを知ることは困難です。
私たちの進化における次のステップは、進捗追跡能力を向上させることであるように思われます。 チャートのバーンダウン を使用して支援することを検討しています。ただし、ソフトウェアプロモーションスケジュールの確立と手順により、スプリントは大幅に重複しています。以下の確立されたイベントがあります。
- 開発はスプリント1で始まりそしてコードフリーズ。つまり、開発グループとテストグループを使用して、このフェーズ全体でソフトウェアをテストします。
- コードフリーズはSprint 1機能で開発を停止します。次のイベント受け入れプロモーション1の前に問題を終了または修正するための小さなウィンドウ。さらに、スプリント2で開発が開始されます。
- 受け入れ促進1は、アプリケーションをクライアントの受け入れ環境に促進し、そこでテストグループによってテストされます。テストで特定された問題は、承認プロモーション2の前の小さなウィンドウで修正される場合があります。一方、Sprint 2開発は継続されます。
- Acceptance Promotion 2は、アプリケーションを最後にもう一度クライアントの受け入れ環境にプロモートして、受け入れプロモーション1。 スプリント2開発は継続されます。
- 本番プロモーションは、アプリケーションを本番環境にプロモートし、テストグループとSprint 1が正式に完了しました。これが本当に完了したときです。
これを視覚的に表したものを以下に示します。 開発開始からコード凍結までの平均カレンダー時間は4週間です。 コードフリーズと本番プロモーションの間の平均時間は2週間です。
このイベントのスケジュールは、私たちの管理下にはありません。クライアントポリシーは、アプリケーションソフトウェアがテストから受け入れ、本番に昇格する時期を指示します。 2番目の修正ウィンドウを超えてアプリケーションコードを変更することはできません。プロモーションは行っておりません。これも、ポリシーにより、クライアントのサイトの「サードパーティ」によって実現されます。
さらに、データの更新などの一部のタスクは、このスケジュール外で発生する可能性があります。特定のデータ更新はコードに従いますが（たとえば、スキーマの依存関係がある場合）、データのバグや新しいデータなどの他の更新は、このスケジュール外で発生する可能性があります。これは、クライアント環境で何をいつ変更できるかに関する制限が少ないためです。アプリケーションコードのみがこれらの特定のマイルストーンに制限されています。データと構成は免除され、技術的には必要に応じて変更される場合があります。データの更新がコードと同じスケジュールに従うように、これを強化することを検討しています。
このシナリオ、重複するスプリントを考えると、いくつか質問がありますか？
前のスプリントから開発、テスト、およびデータ時間を燃焼し、次のスプリントに向けて作業するときに、バーンダウンチャートを作成/処理する適切な方法は何ですか？
スプリントごとに2つの同時バーンダウンチャートがあると思います。
最大で2つのバーンダウンチャートがあると仮定すると、スプリントがオーバーラップしたときに累積バーンダウンを表示して、それぞれの実際のワークロードの進行状況を理解し、成功に向けて最適に設定するにはどうすればよいでしょうか。
コードフリーズ後にSprint1でSprint2で対処する必要のあるアイテムが見つかった場合、Sprint 2のバックログとバーンダウンはどのように行われますか？
重要なアイテムについては、不完全なSprint 1アイテム用のスペースを確保するために、重要度の低いSprint2アイテムをバンプアウトする必要があると思います。重要でないアイテムは、Sprint3以降にバンプされます。
バーンダウンチャートの適切な開始日と終了日はいつですか？
現実を反映するのが最善の選択肢のようです。スプリント1は、本番プロモーションとその最終テストまで、実際には実行されません（テストとデータ更新を含む）。したがって、開始日は開発開始になり、終了日は生産促進になります。 ）重複があるにもかかわらず。
他に何が欠けていますか？他に何が私たちを噛むことができるか、または噛むでしょう？
開発のセットアップをどのように行うかは良い考えではないと思います。スプリントが制限され、重複しない理由の1つは、発生したばかりの問題です。バーンダウンチャートの作成方法を気にするよりも、スプリントサイクルの簡素化に重点を置くことをお勧めします。
最初の4週間は、推奨されるスプリントの長さの境界にあり、2週間の「テスト」とともに、基本的に春全体が6週間になります。これは、アジャイルプラクティスでは間違いなく正常ではありません。
通常、顧客のテストはスプリント中に行われ、このテストに基づくエラー/提案は、次に利用可能なスプリントで考慮されます。スプリントが短い正確な理由は、そのような複雑な開発/テストプロセスを必要とせずに、顧客がプロジェクトで抱える可能性のある問題に迅速に対応するためです。
また、顧客のテスト環境への自動展開を使用して、自動受け入れテストを実装することを検討する必要があります。それらがあれば、スプリント間の短い時間の間に簡単に実行できます。これにはおそらく、アジャイルプラクティスの基本の1つである、顧客とのより緊密なコラボレーションが必要になります。
コードを実線でフリーズさせ、テスト済みのコードのみを宣伝することで、スプリントが重複する2週間の時間枠のあいまいさを排除できます。ただし、これにはテストをより早く実行する必要があり、自動テストによりバグを修正し、修正されたままであることを確認できます。
おそらく、開発のマスターブランチを常に本番環境にプッシュする準備ができており、このマスターブランチにコードをコミットする前にすべてのテストを実行するというポリシーを採用しています。機能が時間内に実行されたり、スコープが単純な場合は、それらをマスターブランチにプッシュしないでください。
スプリントに必要な機能とタスクのリストがあれば、バーンダウンチャートの実装は簡単です。コードがフリーズした場合-1週間で、3/5の機能がマスターにプッシュされ、自分がどこに立っているかが明確にわかります。よりきめ細かい制御ブレークダウン機能を使用して、マスターバーンダウンに集約されるバーンダウンにしたい場合。
別の見方をすれば、4週間のスプリントはダイアグラムの2週間で始まり、最初の2週間の開発と、さらに2週間のコードフリーズなどがあります。最後の2週間のアイドル時間は、次のスプリント。しかし、そのスプリントは正式にダイアグラムの6週間後に始まります（前のスプリントを受け入れた後）。
これにより、より明確な優先順位が作成されるだけでなく（新しいことから始めるよりも受け入れを得ることが重要です）、完全に教科書のリリースを焼き切ることもできます。
最も簡単な方法は、スクラムがアジャイルであると考えるのをやめ、かんばんなどのわずかに異なる（そしてより良い-すべてがスクラムよりも優れている:)）方法を使用することです。
アジャイルであるためにバーンダウンチャートは必要ありません。また、「目標どおり」である必要もありません。バーンダウンは、実際には、以前のスプリントで完了した作業によって測定された、スプリントで達成できるはずの作業量を決定するのに役立つツールとしてのみ存在します。他の方法論はそのようなことを気にせず、完了するまで必要なことをすることを好みます-それはとにかくスクラムで行うことですが、燃え尽き症候群に駆り立てるバーンダウンチャートの圧力はありません。
バーンダウンチャートの使用を主張する場合、それらは前の作業に基づくツールであることを忘れないでください（そのため、一定の期間を割り当てる代わりに、タスクにTシャツのサイズ設定などの見積もりツールを使用します）。バーンダウンは他のすべてのバーンダウンと比較して異なります。したがって、1つのスプリントで行われる作業の量が重複する作業によって削減され、その後のスプリントにも重複する作業が含まれるため、6週間を含めるようにスプリントを設定するだけです（重複を無視します）。これは、すべてのバーンダウンが他のすべてのバーンダウンと一致するため、自己調整することを意味します。 3回のスプリントの後、速度は安定した数値に落ち着きます。 （通常のスクラムシステムでは、とにかく安定した速度を得るために3回程度のスプリントを実行する必要があることに注意してください！）
スプリントはスクラムから取った名前です。 Sprintの終了時に、ソフトウェアは「出荷可能」である必要があります。
スプリント中、チームは干渉を受けないようにする必要がありますが、スプリントの最後にソフトウェアを提供することを約束します。
あなたがしていることは、通常、スプリントとして説明されません。
4週間のイテレーションの間に、リリースブランチからのバグ修正に数日かかるようです。
多くのオプションがありますが、私の推奨する選択は、反復の長さを1週間に短縮することです。リリースブランチで作業する必要がある場合は、適切なスプリントバックログにそれを導入します。 UATで特定された問題は、反復/週5で修正する必要があります。無駄を避けるために、修正のために反復の開始をこのウィンドウに揃えようとします。受け入れテストは、他のバグ修正と比較して特別なものと見なされるべきではありません。彼らが発見したバグは、バックログに入れて、必要に応じて優先順位を付ける必要があります。
あるいは、それが比較的一定の作業量であるかのように、つまり、常に特定の日数がかかる場合は、バグ修正のアクティビティをタイムボックス化し、バーンダウンの一部とは見なしません。これらの問題について、所要時間とポイント/見積もりが追跡されていることを確認する必要があります。
もう1つのオプションは、受け入れテストの結果である可能性が高い作業のプレースホルダーストーリーをいくつか挿入することです。彼らが歴史的に取った努力の量を使用することによって、あなたはそれらを割り当てるためにポイントを計算することができます。