TFSで「完了」したがリリースできないコードを管理する
私は、同じコードベースで開発している11のスクラムチームを持つ組織で働いています。現在、すべての開発はトランクで行われており、スプリントの最後にすべてをリリース可能にする必要があります。そうでない場合は、リリースがカットされるときにバックアウトする必要があります（困難なプロセス）。
私の意見では、スプリントでの作業は（理想的には）スプリントの最後に「完了」しますが、必ずしもリリースの準備ができているとは限りません。リリースするMinimumViable Productがないが、いくつかのストーリーが完成している可能性があります。ストーリーが完了していない場合、またはストーリーがより大きな機能の一部にすぎない場合は、これをリリース可能なコードから切り離しておくのは簡単です。それがすべてバックアウトされた瞬間に、リリースカットが取られ、それがチェックインされます。膨大な時間の無駄です！
継続的インテグレーションを使用します。これは、トランクで開発するすべての人にとっての主要な議論です。チームがチームブランチを使用することもありますが、これは現在眉をひそめています。
私は単に 'dev'と 'release'ブランチを持ち、それらがMVPであるときに機能をリリースするようにプッシュすること、または各ストーリーまたは機能にブランチを持つことを検討してきましたが、これはTFSの管理者にとって非常に重いです。他の人々が過去に同様の問題に対処したことがありますか、そしてあなたの最善の方法についてどう思いますか？残念ながら、短期的にはTFSに縛られています。
あなたはその分岐の欠如に完全に夢中になっているように見えます。少なくとも、コードが機能していて「リリース可能」になったら、Devブランチで開発し、完成したコードをMainにマージする必要があります。これにより、期限に間に合わず、後で再コミットした場合に、コミットされた作業を元に戻すという愚かさがなくなります。 VSSを使用する時代は過ぎ去りました!!
すべてのチームに独自の開発ブランチが必要ですが、すべてのチームが単一の開発ブランチで作業したいかどうかは理解できます。
CIはDevブランチとMainブランチの両方に適用する必要があり、Mainにも追加の分析を適用する必要があります。以前は、非常に長時間実行される静的分析、ドキュメントの生成、およびMainでのテストを行っていたため、Devの速度が大幅に低下していました。
Microsoftが推奨 TFSモデルのDevブランチとReleaseブランチでMainブランチ（またはトランク）を使用します。 （ 古いドキュメントはここにあります 、彼らは時代遅れだと言っていますが..しかし彼らの現在の見解へのリンクを怠っています）
スクラムガイドは非常に明確です。スプリントの作業は、各スプリントの最後に「完了」製品の潜在的にリリース可能な増分を提供することです。
これにはいくつかの理由がありますが、主な理由は、不必要な技術的負債を負わないようにすることです。製品を潜在的にリリース可能にするまで、実行する必要のある作業の量や、リリースにかかる時間はわかりません。
優れた分岐ポリシーを導入しているようで、継続的な統合を行っていることがわかります。私は何も変えません。
しかし、私が目にする問題の1つは、ストーリーをより大きな機能の一部として説明することです。これがブランチポリシーで問題を引き起こす理由を理解できます。しかし、問題はあなたのpbiにあると思います。優れた製品のバックログ項目は独立している必要があり、分岐を妥協するのではなく、問題を解決するために改善することを検討する傾向があります。
あなたにできることは、サブストーリーで壮大なストーリーを定義することです。
その壮大なストーリーのブランチを作成してから、サブストーリーごとにブランチを分岐します。各サブストーリーが完成したら、そのブランチをエピックストーリーブランチにマージします。エピックが完全に終了したら、そのブランチをマージしてマスターに戻し、すべてを解放できます。
ただし、DerekDavidsonに同意する必要があります。機能を段階的に構築するのではなく、一度に1つずつ作成しているように思えます（同じように聞こえます）。
Spotifyがどのように動作するかについてTwitterで見た写真を思い出します。一度に一輪ずつすぐに車を作る代わりに、彼らはスケートボードを作ることから、キックスクーター、モペットに、...
これは口で言うほど簡単ではないことは承知していますが、今は見えなくても、常に方法があることを忘れないでください。レポートの目的を尋ね、その目標を達成するための最も簡単で簡単な方法を推論することから始めることができます。
レポートとはまったく異なるものになる可能性があります。