高橋（徹）です。
<200107021750.BDD81885.BIJH@....jp> の、
"[XP-jp:02066] Re: ObjectDay2001 ... XP related sessions" において、
"Yasuo Higa <higa@....jp>"さんは書きました：
> 今のプロジェクトは、大きく分けて、3つのチームに分かれていて、
> ふだん、チーム間でのコミュニケーションはそれほどありません。
> 各チームでやっていることは、週1の全体ミーティングで、
> 知ることができます。
プロジェクトの初期にある程度設計を進めた結果として３つに分割されたのか、
あるいは体制（人数やチーム）がまずありきで分割されたのか、という点に
興味があります。
デマルコ著「デッドライン」では、初期の分割が設計の結果ではなく遊んでいる
人に仕事をさせるために実施されてしまう点を警告しています。また、身の回り
では、初期のシステム分割がハードウェア単位（装置単位）で行われてしまうこ
とが多く、後々Ｉ/Ｆが複雑になってしまうことがよくあります。
> 各チーム間のシステムの結合は、各イテレーションの最後に行われます。
> 各チームのリーダは、他チームの動向を常にウォッチしていて、
> 機能がかぶっているクラスがあれば、リファクタリングによって統合されます。
その際は、各チームが担当しているソフトウェア間のインタフェースも頻繁に
変更されるのではないかと思います。同一チーム内であれば面と向かっての
対話が濃いため、変更が頻繁に起こっても速やかに収束していくと思われます。
＃「ここ変更したよ、以後呼び出すときはこうしてね。」「あいよっ」
しかし、チーム間で変更が波及する場合、変更が短いイテレーション期間内で
どのように収束していくのでしょうか。また、リファクタリングするにしても、
両方のチームのコードを十分に知っていないとなかなか手を出せないのではと
思います。
＃両チームのリーダー同士がペアプロするならうまくいきそうですね。
ここの辺りが複数XPチームでプロジェクトを構成するときのキーなのかなと
思いました。
---
TAKAHASHI, Toru