私が働いている会社は、プロジェクトでスクラムを試行しており、現在、3 つまたは 4 つの異なるプロジェクト チームにスカムを展開しようとしています。これらのチームは別々の機能ブランチで作業することを想定しています (SVN を使用しています)。
異なるチームのスプリントを同時に終了する必要があるのか、それともスプリントの終了とリリースが別々になるようにスプリントをずらすべきなのかはわかりません。製品は Web サイトなので、展開は問題ありません。
3 つのチームが同時にコードを統合すると、競合が発生する可能性があるので、コードの統合について懸念しています。しかし、リリースがずらされている場合、この負荷はスプリントの途中にあるチームに移されるだけかもしれません。
どちらかのアプローチを試した人はいますか?
また、いくつかのチームがあり、スプリントが調整され、ストーリーが完成したときに継続的に統合されます。これは面倒なこともありますが、そうすることで、痛みを伴う可能性のある長い統合期間を回避できます。各ストーリーは個別のブランチで開発され、メイン ブランチに統合されます。2 つのチームが統合されていないものを共有する必要がある場合、それらは同じブランチで作業します。
パッケージ化された製品を構築しているため、展開は問題ではありません。
2 つの質問は結び付いています。スプリントの最後にのみ統合する場合 (これはお勧めしません)、スプリントをずらした方がよいでしょう。
Henrik Kniberg (Scrum and XP from the Trench の著者) は、Multiple Agile Teams のバージョン管理に関する記事を書きました。
スプリントが同期しているチームが2つあり、非常にうまく機能しているようです。私たちの戦略は、ストーリーを小さく保つことです。ストーリーを完成させ、スプリント中に頻繁にトランクに公開します。はい、マージの競合は発生しますが、管理可能です。
ああ、チームがお互いにうまくコミュニケーションしていることを確認してください。
この記事を見て、これらの問題を簡潔に説明してください。http://www.infoq.com/news/2008/04/kniberg-agile-version-control
継続的インテグレーション。一日の終わりや反復の終わりまで待たずに、チェックインのたびに常に統合してください。単体テストと、チェックインのたびに実行される自動化された受け入れテストを用意して、誰もコードを壊さないことを確認します。
より小さな機能を計画し、より小さな作業に取り組みます。チャンクが小さいほど、問題が発生したときに簡単に修正できます。すべてのチームが同じ製品/コード ラインに取り組んでいますか? 機能が別のチームが取り組んでいる機能に影響を与えないように、機能の計画を試すことができます。統合の競合を早期に解決できるように、他のチームのスタンドアップに参加してみてください。機能が競合する場合は、作業を共有します。