プロダクトオーナーがリリースを要求したときに、作業の流れを中断させないようにするにはどうすればよいですか？
私のチームは、各スプリントでリリース可能なビルドを提供することを目標に、スクラムを何年も使用しています。最近、タイムボックス配信からフィーチャーボックス配信に移行するかんばんボードの使用を開始しました。これまでのところ、これはチームの自然な働き方により適しているようです。機能ボックス配信では、個人が快適に作業を開始する準備ができていると感じたときに、ストーリーがバックログから取得されます。
チームの平均ストーリーリードタイムは3週間です。したがって、理論的には、製品の所有者がリリースを要求した時点で、チームは3週間後にリリースできるはずです。
POが「開発の停止」トリガーを設定すると、時間のある個人は、ボードをクリアし始めるために、すでに進行中のストーリーを支援し始めることになっています。最初に解放された人々は、通常、「フロントエンド」の人々です...分析と開発に熟練した人々です。彼らは通常、システムテストなどのバックエンド作業を支援するように求められます。
チームのワークフロー、または停止トリガーが設定されるたびにリズムが変化します。この変更を最小限に抑え、チームを可能な限り効率的に機能させるために何をしますか？プロダクトオーナーがリリースを要求することによって引き起こされる混乱をどのように回避しますか？
リリースの準備について説明する方法は、ワークフローが大幅に中断され、それ以外の場合は機能しているように見えます。
私たちのチームにも同様の要求があったため、次のソリューションを導入しました。これは主に、バージョン管理システムのブランチ管理に関係しています。そのコンセプトは私には「トランクにジャンクがない」として知られています。これは基本的に、品質保証（QA）に合格した作業のみが含まれているという点で「クリーン」なブランチがあることを意味します。 Subversionを使用すると、このブランチは「トランク」と呼ばれることがあるため、この名前が付けられます。もちろん、これは他のバージョン管理システムでも機能します。ギット。
新しい機能の作業を開始すると、機能ブランチが作成されます。この機能ブランチは、差異を最小限に抑えるために、少なくとも1日に1回はトランクからのマージで更新されます。さまざまな関係者によるすべてのテスト、品質保証、サインオフは、すべて機能ブランチで行われます。機能が完了すると、「トランク」にマージされ、新しい機能がすでに存在するものと統合される場所に焦点を当てた迅速な統合テストが続きます。
リリースするとき、「トランク」からリリースブランチを作成します。 「トランク」は「クリーン」なので、いつでもリリースできます。リリースはかんばんボードからすべてのストーリーを消去することに依存しないため、通常の開発ワークフローを中断することなく、いつでもリリースを準備できます。
このプロセスは私たちにとって非常にうまく機能します。リリースブランチの作成は完全に自動化されているため、約10秒かかります。リリースブランチで最も重要な項目は、英語を母国語とする人によるリリースノートのレビューです。残念ながら、これは手動のプロセスであり、新しいリリースの新機能とバグ修正の量にもよりますが、約1〜2時間かかります。
いつものように、あなたの環境には、挑戦に対する他の解決策をより良い選択肢にするかもしれない要因があるかもしれません。