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