アジャイルな安定化とリリース管理
私はアジャイルプログラムに取り組んでおり、「安定化スプリント」と呼ばれるものに対処する方法について議論しています。私たちはチームを構築していくつかの重要な項目を決定する必要がありますが、それらを決定するのに役立つ明確に定義されたガイドラインは実際にはない（またはそれらを見つけることができない）ので、これについてあなたの頭脳を選びたいと思っていました。
最初のリリースは6月の予定で、3か月の安定期間がありますが、同時に、チームを構築し、10月に予定されている次のリリースに取り組み、その後、6月の3番目のリリースに取り組む必要があります。
決定したい項目は次のとおりです。
次のリリースと安定化タスクを処理するために2つの別個のチームを構築しますか？一方では、両方に対処する単一のチーム（複数のポッド）を用意することで、リソースの負荷分散を改善し、問題のより深い知識を持つ開発者に修正を要求することができます。一方、次のリリースに専用のチームがないと、次のリリースを計画することが難しくなります。
識別された問題のサイズを決定しますか（安定化中に修正されるバグ、技術的負債）、通常の開発スプリントで行っていたように、バグ修正にポッドの速度のパーセンテージを割り当てて対処しますか？それらのサイジングは、より良い計画に役立ちますが、避けたい議論や会議の必要性を生み出します。
安定化タスクを次期リリースストーリーカードと組み合わせるか、それとも個別に保つか？これは、最初の質問の続きです。安定化と新しいリリースの両方に対処するために単一のチームを持つことを決定した場合、本当に2つのバックログが必要ですか、それとも1つだけ必要ですか？
チームの構造と推定モデルを説明するために特に計画された複数のリリースを備えたアジャイルプロジェクトを処理するためのベストプラクティスを説明した優れた本/記事を探していましたが、良いものは見つかりませんでした。
あなたは安定スプリントを持っているべきではありません。ソフトウェアはリリース可能である必要がありますevery sprint。つまり、必要安定化の場合、リリースの直前ではなく、各スプリント内で発生する必要があります。これを達成すると、リリース計画は製品所有者の懸念（「リリースするために必要な機能は何か」）とチームの懸念の安定化（完了の定義）になります。
同じことがバグと技術的負債にも当てはまります。必要に応じて常に修正され、ストーリーを必要としないものです。実際、通常は各ストーリーの一部です。「実行」することはできません。安定しており、適切にリファクタリングされている場合を除きます。
これはあなたの質問に直接答えることはありませんが、安定化はアジャイルの概念ではありませんなので、スクラムでそれを行う方法を尋ねても意味がありません。
コメントに対処するために編集：
スクラムによると、プレリリースで発見されたバグはイテレーション内で処理されます。バグがある場合、ストーリーは通常「完了」とは見なされません。発送できない場合は、価値がありません。また、アジャイルの基本原則に従って、チームは持続可能なペースで作業する必要があります。借金やバグに対処するために基本的に開発を停止する必要がある場合、持続可能なペースで作業していません。速度を下げ、出荷する機能を減らしますが、バグはありません。
通常、安定化は、個別のQAチームチェック機能post hocを持つチームで発生します。これは、アジャイルモデルやスクラムモデルには適合しません。チームは機能横断的で、機能を個別に出荷できる必要があります。
全体的に言えば、多くの企業は、ソフトウェアの構築方法に伴う深い変更を理解せずにスクラムまたはアジャイルを行うと言っています。これらの方法論に従ってソフトウェアを構築する準備ができていない場合は、さまざまなプラクティスの「管理アドオン」として使用しないでください。
彼らに「安定化」という名前を付けても、単に「スプリント12」に付けても、いずれにせよ、チームはストーリーの最初の開発を中止し、技術的負債のスプリントを行うか、行われていないストーリーを締めくくります。問題が見つかり、それを閉じることができなかったためです。これらは通常のアジャイルスプリントであり、あなたのチームは私たちのチームと同じであり、「私はそのことについて考えていませんでした」ものに対処するためにそのカレンダー時間が必要であることを知っています。
当店では、最初に400ポイントのリリースバックログを予測し、最初に履歴に基づいて100ポイントのベロシティを実行できると考える場合、理論的には4つのスプリントで実行できることを意味します。ただし、速度と合計バックログの見積もりが常に正しいとは限らないことを知るのに十分なプロジェクト経験もあります。 MVPには新しい機能が必要になる場合があり、予期しない遅延により何かが完了するのを妨げられる可能性があるため、それに対処するために同様の「スプリント」を計画します。したがって、不明のレベルを考慮して、5つまたは6つのスプリントをカレンダープランに入れることができます。
ここで、「安定化」を予測している時間の長さは、最初に構築するのとほぼ同じくらい安定化する時間が必要な場合に、配信に関する組織の問題を示しています。他の人が述べたように、フィードバックをより早く受け取るために、フェーズの早い段階でテストを埋め込む必要がある可能性があります。継続的テストの手法を使用することで、チームはストーリーをクリーンアップしていきます。このようにして、チームが実際に「完了」すると、リリースの準備が整います。
この調整を行うと想定：ここで、質問のリリース管理の部分に進みます。新しいリリースを並行して開始しながら、リリースを完了しようとするにはどうすればよいですか？通常、最後の1〜2回のスプリントでは、最初のリリースでチーム全体を忙しくするのに十分な作業がない可能性があります。これは、次のリリースストーリーを取り入れて、チームの能力を維持できるようになるときです。コード管理の観点からは、お気に入りの分岐戦略を使用すると、コードベースを分離しておくことができ、チームは作業中のタスクに基づいて分岐を切り替えることができます。タスク管理の観点からは、機能のリリース先をチームに明確に説明し、どこに機能を配置すべきかを理解できるようにする必要があります。
チームを分割しますか？個人的に、これはチームメンバーの集中力を維持するのに役立ちますが、実際に機能するのは、チームが本当に何でも。専門家がいたとしても、誰もが必要とする能力があり、リリース間をジャンプする柔軟性が必要になります。コアグループを定義して両方のリリースを処理し、他のチームメンバーをフロートできる場合は、よりバランスのとれた攻撃が可能になります。
継続的なテストを行わない場合はどうなりますか？一連のコードを作成し、それを別のチームに渡してから、新しいリリースに移ってフィードバックを待つ場合は、管理する必要があります。あなたのチームは違う。これは、より「ウォーターフォール」な配信方法であり、初期リリースチームは、いつフィードバックが来るか、またはどれだけあるかを予測できないことを意味します。これにより、最初のリリースからどれだけの作業が行われるかわからないため、次のリリースのスプリント計画が難しくなります。このシナリオでは、テストチームからのフィードバックに対応するための能力に「バッファ」を持たせるように、新しいリリーススプリントを計画する必要がある場合があります。最初はチーム全体を新しいリリースに使用する可能性が高く、解決する技術的負債がある場合は、それに対処するためのグループを形成し、それを片付けることができます。
これは少し好戦的で過酷に聞こえるかもしれませんが、申し訳ありませんが、トップレベルのアジャイルゲームをプレイしたい場合は、大きな銃を持ち込み、狂人のように働き、決して妥協しないように準備することをお勧めします。
あなたのスプリントをショートさせ、品質とテストを最優先にすることを検討します。私は毎週と隔週でリリースするアジャイルチームと協力してきましたが、それよりも長いと問題になる可能性があります。優れた確実なテストスイート（100％カバレッジと自動化されたブラウザテスト）およびすべてのコードの必須レビューは、バグを減らすのに大きく役立ちます。毎週のリリースサイクルの利点は、バグがほぼ即座に修正され、安定性スプリントが問題にならないことです。この種の開発には膨大な規律が必要であり、所有者から好戦的に推進する必要があります。あなたの会社がそのレベルの責任を果たそうとしないなら、あなたはもう平凡なアジャイル志望者になるだけなので、時間を無駄にしないでください。
質問にコメントするには：
必要なチームは1つだけです。人々は自分たちのバグを最もよく知っており、毎週のリリーススケジュールでは新鮮なものになるはずなので、バグを修正します。
サイジングと議論は無意味です。開発者にはタスクがあり、見積もりとスケジューリングを担当します。経営陣はこれを明らかに却下できますが、重要なビジネス上の理由がない限り、バグは常に最初に対処する必要があります。バグのような技術的負債を扱います。重大なビジネス上の理由で作成されない限り、何もないはずです。理想的には、技術的債務は過去のコードレビューを行うべきではありません。もしそうなら、バグのように次のリリースで修正します。
バグと新機能は同じです。重要なのは優先事項であるため、区別する理由はありません。
最後に、自動化、自動化、自動化し、さらに自動化する方法を見つけます。自動化なしでこのレベルの努力を達成する方法はありません。
安定化はアジャイルにうまく適合します。それは単に機能ではありません。
これは技術的な負債です。これがアジャイルに適合するのは、提供する責任を受け入れる機能の量です。アジャイルは、このスプリントが何かを「安定させる」ことを製品の所有者に約束しないと言います。それは彼らにとって何の意味もありません。 「クリーンアップの必要性を認識したので、速度が低下すると予想しています。これらの3つのことだけにコミットします。」これらの3つの要素が十分に小さいため、クリーンアップする時間を確保してください。
確かに、あなたはすべてのスプリントを安定させ、きれいにする必要があります。ただし、コードで大きなリファクタリングが必要になる場合があります。アジャイルはあなたがそれをすることができないとは言いません。それはあなたがそれのために信用を得ないと言います。
木を切り倒すことで報酬を得たからといって、斧を研ぐべきではありません。あなたの斧を研ぐために給料を受け取ることを期待しないでください。あなたの斧はあなたの責任です。