同じチームの同じ製品の複数のリリースのスプリントを管理する
同じチームがスプリントサイクル中に両方のリリースで作業する場合、2つのリリースで同じ製品のスプリントをどのように計画しますか？
背景を説明するために、当社の製品は6か月ごとにお客様にリリースされ、バグ修正と小さな機能を備えた自動リリースが毎週お客様に提供されます。そのリリースをLiveと呼びましょう。ライブリリースを行うときは、それを分岐してトランクのバージョン番号をインクリメントします。これをCoreと呼びます。したがって、Coreが1.20の場合、Liveをオフに分岐すると、Core 1.21になります。
ライブリリースが承認された後は、問題が発生した場合に深刻な被害をもたらす可能性のある重要なデータを処理するため、ライブリリースへの大きな変更は避けようとしています。各リリースにはQAチームとテストチームがあり、TeamCityによる自動ビルドと自動UIテストがあります。
計画に関しては、複数のバージョンにわたるスプリントをどのように計画し、その作業をどこで行うかを決定する必要があります。どのリリース？したがって、計画したいLiveリリースに20時間の欠陥がある場合は、他のすべてのCore機能と一緒にスプリントの一部にしたいのです。どちらも同じ製品です。 Liveで行われた処理はすべてCoreにマージされます。
現在、計画を立てるために、2つのスプリントを別々に計画する作業量に合わせて、チームメンバーの可用性を計算して減らす必要があります。これは、多くの作業です。
計画にはAxosoftを使用します。これには、多くのリリースがある製品があり、各リリースには多くのスプリントが含まれる可能性があります。したがって、意図したとおりに使用すると、LiveとCoreの両方に個別のスプリントが作成されます。両方のスプリントに同じ名前と番号を付けることができますが、両方に取り組んでいるのは同じチームであるため、速度と可用性が2つのスプリント間で共有されないため、プロセスの管理は非常に困難です。これにより、実際には1つのスプリントしか存在しないはずであると私は信じるようになります。
私たちはAxosoftによって制限されているだけなのかどうか疑問に思っています。私たちがすべきことは、各バックログアイテムに修正/完了すべき場所を示すフラグを付けるだけですが、類似の製品を見ると、同じ問題があるようです。
スプリントはリリースとは異なります。スプリントの結果は「リリース可能な増分」ですが、チームはスプリントの任意の時点で「リリース可能な増分」を生成でき、プロダクトオーナーはいつでもそれをリリースできます。
スプリントのコンテキストで考慮すべき重要なことは、タイムボックスが終了する前に作業を完了できるかどうかです。スプリントの最後に到達したら、計画された作業は完了している必要があります。これは、チームが達成できる作業を予測できることを示します。スプリントの途中のリリースがある場合は、スプリントが終了する前に作業のサブセットを完了して実行する必要があるため、これを考慮する必要があります。
あなたの場合、各作業項目（チケット、問題など）には、作業を終了する必要がある場所をラベル付けする必要があります。それ以外の場合、分岐や分岐管理などはスクラムの範囲外です。チームは、計画を立てるときに、スプリントの終了前に予定されている作業を認識し、スプリントの作業を整理するときにこれを考慮する必要があります。
スクラムでは、スプリントとリリースの間に相関関係はありません。リリースには複数のスプリントで行われた作業を含めることができますが、同時に1つのスプリント中に複数のリリースを行うことができます。
チケット（ユーザーストーリー、バグなど）ごとに、リリースが配信される予定のチケットを示し、チームが作業する予定のスプリントを個別に示すことができる必要があります。ツールがそれを許可しない場合、それはツールの制限ですが、スクラムプロセスによって与えられません。