BSA / The Team

The Team †

要約 †

アーキテクチャの創造、成熟、進化のプロセスは、それぞれのリリースと関連するチームとは分けられない

• この節ではアーキテクチャとチーム間の相互作用についての考えを述べる
  • より詳細な議論は96年に出した「Journey of the Software Professional」を参照

初期の開発チームについて考える

• 最初のシステムを作る人たちは、主に彼らの経験に基づいて設計上の選択をしていく
• 対して、後続のチームはこの最初のチームの選択に縛られる
  • これが多くの開発者が新規開発に惹かれる理由
• なので、アーキテクチャのパターンに基づいた新しいアーキテクチャでさえ、その提唱者特有の経験が反映される
• アーキテクチャを構築するのに沢山の人が巻き込まれる
  • 彼らの互いの関係性は、初期のアーキテクチャに大いに影響を与える
• 端的にいうと、アーキテクチャからチームを引き離すことは無理

経験的には、初期のアーキテクチャは可能な限り小さなチームで構築されるべき

• コミュニケーションのオーバーヘッドを最小化し、チームの結束を最大化できる
• サブシステムが定義され、計画され、正当化されるに従って、自然とスキルのあるメンバーに責任を割り当てていく
• 初期チームのメンバー数は3から多くても10に収めとこう
  • おすすめは3から5で、ひとりをアーキテクトとする
  • チームが機能するのを最優先で

初期のアーキテクチャでリリースがうまくいくと、チームは機能や性能の追加要件に合わせて大きくなっていく

• 初期のアーキテクチャの範囲からすると自然な流れ
  • UI担当者が1名から3名になったり、データベースの管理者が1名から2名になったり
• このやり方ではサブチームは自然と初期のアーキテクチャを強化するように作られていく
  • 良い点はサブチームに初期のチームメンバーが、全体の設計を踏襲でき、新しいメンバーと共有できること

チームが大きくなっていくプロセスは、チームとアーキテクチャが安定するか、管理上の制限にたどりつくまで続く

• いくつかの企業は、コミュニケーションの流れ、開放、協調を維持するために特定の人数で制限を設けている
• 別の企業は、システムのニーズに合わせてチームが大きくなるのを許容している
  • コンサルしていた国防総省の案件では、開発チームは150人以上のC++開発者で構成され、10のサブシステムで組織化されていた
  • かなり大きなチームだったがとてもうまく機能していた

覚えておくべきとても重要なことは、チームとシステムアーキテクチャは絡みあったものだということ