id:takubonさんからいただいたコメントに触発されてちょっと書いてみます。
リリースを行う際に利用者に公開したインターフェイスが「公布済みインターフェイス(published interface)」になります。短い期間のイテレーションを繰り返してチーム間で結合を繰り返していく場合には、利用者は他のチームとなります。イテレーションの期間に応じて不完全な形でインターフェイスを公布する機会があるかもしれませんし、実際に機能を制限してリリースを行ったりもします。
短い期間で反復開発しているということは、インターフェイスを公布する機会が増えるということです。公布する機会が増えれば、リファクタリングの範囲が公布済みインターフェイスに引っかかる確率も増えます。すると、公布済みインターフェイスの変更はリファクタリングの枠を越えて「仕様変更」となってしまうことが多くなってしまいます。
これがイテレーション期間を短く取って複数チーム開発を行う際のジレンマだと思っています。イテレーション期間を短く取ると、本当に自由にリファクタできる時間もまた短くなってしまうというジレンマです。
しかし、不完全であっても公布し、結合してフィードバックを得て本当のニーズを探すことに短期イテレーションのねらいがあります。そして短期イテレーションで開発されたものの結合の方が、ビッグバン結合よりも楽であることは間違いありません。むしろ開発規模が大きくなればなればなるほど、Integrate early, integrate often(早めに結合、こまめに結合)というのが生命線になると考えます。
チーム間で並行開発を行う際には、チーム間で公布済みインターフェイスの変更を伴う変更があることを認識して了解を取り、公布済みインターフェイスの変更を伴っても開発の速度を鈍らせないような、結合重視、フィードバック重視の文化(規律)を作る必要があると考えています。
私達のチームも並行開発している他チームの公布済みインターフェイスに依存して開発しています。公布済みインターフェイスが変更された際にはMainline(そのときの開発の中心になっているブランチ)からブランチを切って他チームの成果物の反映を行い、全てのテストがパスした後にMainlineにマージしています。結構変更の範囲が大きいものもあり、1日以上反映に時間がかかることもありますが、それでも納得ずくで作業を行っています。結構しんどいですが、ビッグバンよりはきっとましだろうという思いが心の支えとなっています。
