The Team †
要約 †
アーキテクチャの創造、成熟、進化のプロセスは、それぞれのリリースと関連するチームとは分けられない
- この節ではアーキテクチャとチーム間の相互作用についての考えを述べる
- より詳細な議論は96年に出した「Journey of the Software Professional」を参照
初期の開発チームについて考える
- 最初のシステムを作る人たちは、主に彼らの経験に基づいて設計上の選択をしていく
- 対して、後続のチームはこの最初のチームの選択に縛られる
- なので、アーキテクチャのパターンに基づいた新しいアーキテクチャでさえ、その提唱者特有の経験が反映される
- アーキテクチャを構築するのに沢山の人が巻き込まれる
- 彼らの互いの関係性は、初期のアーキテクチャに大いに影響を与える
- 端的にいうと、アーキテクチャからチームを引き離すことは無理
経験的には、初期のアーキテクチャは可能な限り小さなチームで構築されるべき
- コミュニケーションのオーバーヘッドを最小化し、チームの結束を最大化できる
- サブシステムが定義され、計画され、正当化されるに従って、自然とスキルのあるメンバーに責任を割り当てていく
- 初期チームのメンバー数は3から多くても10に収めとこう
- おすすめは3から5で、ひとりをアーキテクトとする
- チームが機能するのを最優先で
初期のアーキテクチャでリリースがうまくいくと、チームは機能や性能の追加要件に合わせて大きくなっていく
- 初期のアーキテクチャの範囲からすると自然な流れ
- UI担当者が1名から3名になったり、データベースの管理者が1名から2名になったり
- このやり方ではサブチームは自然と初期のアーキテクチャを強化するように作られていく
- 良い点はサブチームに初期のチームメンバーが、全体の設計を踏襲でき、新しいメンバーと共有できること
チームが大きくなっていくプロセスは、チームとアーキテクチャが安定するか、管理上の制限にたどりつくまで続く
- いくつかの企業は、コミュニケーションの流れ、開放、協調を維持するために特定の人数で制限を設けている
- 別の企業は、システムのニーズに合わせてチームが大きくなるのを許容している
- コンサルしていた国防総省の案件では、開発チームは150人以上のC++開発者で構成され、10のサブシステムで組織化されていた
- かなり大きなチームだったがとてもうまく機能していた
覚えておくべきとても重要なことは、チームとシステムアーキテクチャは絡みあったものだということ