Making Software ―エビデンスが変えるソフトウェア開発

185

マイクロソフト内部の組織上の複雑さ

あなたのチームが修正する必要のあるすべてのバグや、実装する必要のあるすべての機能をあらかじ

め予想できないとしても、ソフトウェアプロジェクトの設計フェーズの間に、最も強い依存関係がどこ

にあるかということを考えておくことは、意味がありそうです。そういうコンポーネント間の依存関係

は、調整なしに変更が行われた際に、より大きな影響をもたらしそうな、システムの部品を指し示しま

す。可能なら、相互依存のあるコンポーネントの作業を行うチーム間のコミュニケーションが円滑にな

るような形で、開発者とチームに対するタスクやコンポーネントの割り当てを行うべきです。このこと

は、最終的なチーム構造を決めるのは設計フェーズの後まで遅らせるか、あるいは少なくともチーム構

成に柔軟性を持たせるのが良い、ということを意味します。

Cataldo

らは、構造調和が時間の経過とと

もに減少することと、これは

コード内部の依存関係とチーム構造が対応していたものが変わってしまう

ためだということを述べています。リリースごとに開発者チームの構造を再編成することでこの問題を

緩和でき、より高い構造調和レベルを維持でき、

MR

遂行の時間を短縮できる可能性があります。同様に、

開発者へのタスクやコンポーネントの割り当てに際しては、地理的な事項も考慮すべきです。可能なら、

高度に相互依存するコンポーネントは、より手厚いコーディネーションが行えるように、同じサイトで

働くチームや開発者に割り当てられるようにすべきです。 ...