交通渋滞は、交通が衝突するときに交差点で始まります。 あるスレッドが動いている間、別のスレッドは強制的に待機します。 ソフトウェア製品の次のリリースがリリースされると、同様のことが起こります。まともな品質の製品をリリースするには、開発を停止する必要があります。
エラーのないプログラムはありません。 何か便利なことをしながら、意図しないことをコードに意図的に導入します。 一見無関係な変化の合流点で驚きが時々生じる。 マウスドライバーを最適化してOutlookのアドレス帳を更新できないようにする方法の良い例を次に示します 。 したがって、チームがバグのテストと修正に専念するときが常にあります。 現時点で新しい機能を追加することは禁止されています。
しかし、新しい要件、希望、およびその他のウィッシュリストのソースは貧困ではありません。 リリースが安定している間、製品の隣接する信号機/バックログのキューは増え続けています。 それは古典的なコルクに変わります。 この競合を解決する方法は？
有名なマクデブルク水橋は、紛争の成功した解決の印象的なデモンストレーションです。 船は互いに干渉することなく独立した流れで移動します。 
極端なプログラミングでは、開発を停止することなく、発見されたバグを修正することをお勧めします。 そして一般に、エラーなしでプログラムすることが必要です。 クールな方法、私はそれが好きですが、残念ながら、開発者はまだエラーでプログラムします。
しかし、ローバーソフトウェアについては、お勧めしません。 
もう1つの極端な方法は、古典的なウォーターフォールです。 まず、すべてを設計してから、慎重に実装し、慎重にテストし、エラーを修正して、結果を顧客に転送します。
このアプローチは、コストの最適化という点では非常に合理的ですが、不確実性に直面するとあまり効果的ではないことがよくあります。 新しい製品を作成するとき、何をどのように実装すべきかを確実に見つけることができないことがよくあります。 多くのことが「試用のため」に行われ、後でやり直されています。 アイデアから検証までのフェーズを順番に通過するとき、時間がかかりすぎます。
試行錯誤に満ちた荒れ果てた道を進むと、新製品を開発する際に必要な柔軟性を提供すると同時に、高レベルの品質を維持するために、これらの両極端の間に合理的な妥協を見つけることができたように思えます。 この記事では、私たちの経験を共有したいと思います。多分それは誰かに役立つでしょう。
最初に、短い反復で作業してみました。その結果、動作するテスト済みバージョンになりました。 反復範囲が限られているため、チームは集中でき、気が散ることはありません。 反復の終了までのすべての粗さをなくすための時間を確保するために、コードを安定させるためにある程度の時間を置くのが慣習です。 現時点では、コードに対する重大な変更は行われず、エラーのみが修正されます。
安定化期間が必要であり、コードの変更回数を制限し、プロセスを収束させます。 実際には、現時点ではチームのかなりの部分が退屈していることが判明しました。すべての人にとって十分なエラーはありません。 もちろん、反復の限界を超える作業は常にありますが、変更を加えることはできません-安定化が進行中です。 そして、次のイテレーションの開始時に、テスターは新しいエラーを待つのに退屈しています...管理者は、ワーカーがアイドル状態であることを確認し、他のプロジェクトに転送する恐れがあります。
次のステップは、かんばん方式に従って作業する試みでした。 タスクは、各タスクの完了後、バージョンが取得された後、連続ストリームで実行されます。 しかし、品質への期待は有機化学の基本法則を破壊します。蜂蜜の樽とたわごとのスプーンを混ぜると、たわごとの樽ができます。 各タスクの後にバージョンを完全にテストすることで状況を改善できますが、人件費と時間の両方の面で高すぎることが判明しました。
状況は絶望的であるように思えます...しかし、安定化が行われているのと同じ場所に変更を加える必要があると誰が言ったでしょうか？
現在、「3つのレベルの不安定性」のモデルに取り組んでいます。
- 開発ブランチの安定性は十分に制御されていません。 ここでは、タスクは「将来のために」行われますが、現在のリリースには含まれません。
- リリースブランチは、ボラティリティの制御された削減です。 このスレッドで実装される一連の変更は制限されており、非常に厳密に修正されています。
- 安定バージョンとは、許容可能なレベルの品質で、ある時点で修正された状態です。 変更は非常にまれで非常に小さい（修正プログラム）
このように動作します。
製品のバックログから、1か月でリリースするようにリリースタスクを募集します。 これが現在のスプリントです。 チームはリリースの実装を開始し、変更がほとんどなく、全員に十分な作業がない場合、次のスプリントに向けてスムーズな準備作業を開始します。 作業は、Giraの別のブランチ、Jiraのかんばんボードの別のセクションで実行されます。 現在のリリースのスコープが完成、テスト、安定化されると、リリースブランチが安定し、開発ブランチが次のスプリントのベースになり、開発ブランチが次のスプリントの終了を見越してフリーズします。
すみません、誰かが言うでしょうが、開発ブランチには実際の編集はありません。 また、エラーがあると不便です。2つのブランチで一度に修正する必要があります。 このような問題を回避するために、リリースブランチから変更を注入することにより、開発ブランチでの作業に先立って合意しました。 この手順の後、開発ブランチには、関連するすべての開発とバグ修正が含まれます。
開発ブランチからの変更は、安定化が完了するまでリリースに反映されません。 これにより、リリースを完了し、安定したバージョンを営業部門に転送することができます。 そして、次のリリースの開始前に、すべての開発はリリースブランチに分類されます。
現在、リリースを安定させるためのタスクの連続ストリームとノンブロッキング手順があり、開発を停止することなく高品質バージョンをリリースできます。
取り組みの次の適用ポイントは、安定化期間を短縮してブランチ間のギャップを減らし、TimeToMarketの合計時間を短縮することです。