Mike Cohn 氏らは、ソフトウェアの"コンポーネント"よりもむしろソフトウェアの"機能"を元にチームを構成することを考慮すべきである理由として、彼らのケースを提示した。
Cohn 氏は、彼らのコンポーネントチーム組織スタイルが彼らに"怪物を殺すには弱すぎる武器、抜け穴を見つけるには暗すぎる色、最も根気強いプレイヤさえ失望させた障害"を作らせた、以前のテレビゲーム開発における彼の顧客を思い出す。
"ソフトウェアコンポーネント"と対照的に、"機能チーム"、エンドツーエンドの機能の開発に対して責任があるチーム、をアジャイル組織が好むようにアドバイスを構成するために、彼はこの話を使う。彼は、以下の機能チームにおける五つの長所を挙げる。
- "機能チームは、よりデザイン決定の影響を評価することができる。" エンドツーエンドで構築された機能性は、ユーザの欲求／ニーズがどれくらい良く満たされていたかという真のフィードバックを獲得します。構造上にわたって動作したレイアは、内部／技術的な決定の結果についての情報を提供します。
- "機能チームは、ハンドオフによって発生する無駄を削減する。" ハンドオフを考慮することは、他のコンポーネントチームおよび／または実は必要とされていたこと越える、必要性を満たしていないコンポーネントチームのリスクを引き起こします。
- "適切な人々が話していることを確実にする。" 機能チームは、価値連鎖の中で互いに関連付けられたままにしておくように、全員のための環境を作ります。
- "コンポーネントチームは、スケジュールにリスクを引き起こす。" コンポーネントチームの作業は、何らかの具体的な価値を得るために、統合されてなければなりません。複数のチームにわたって散らかされた未知の情報に依存していますので、この活動を予定することは困難です。
- "機能を納品することに集中し続ける。" アジャイルなマントラの核心は、それぞれのイテレーションでチームのために"動くソフトウェア"を届けることであり、機能チームは、みんなの焦点の最前線でこれを続けることを支援します。
おそらく、機能チームに対する最近のサポートで最も注目すべき情報源は、Bas Vodde 氏と Craig Larmen 氏らの本、Scalling Lean & Agile Development からである。Mike Cottmeyer 氏による記事では、こう言っている。
Larman 氏と Vodde 氏は、理想的な機能チームを機能上の横断、コンポーネント横断、同一場所に配置されるとしてまとめています。彼らは、完全にユーザの機能性に取り組んでいます。チームは一般的に、専門家、そして通常は６～８人の人々で構成されています。言い換えると、私たちのスクラムチームの原型です。
[Larmen 氏と Vodde 氏] 機能チームのアプローチでのいくつかの挑戦も指摘します… 私は、途中で本当にその良さが分かりました。共通の障壁は…コードへの並列アクセス、デザインへの共有された責任、技術を学ぶことの難しさ、組織構造、を含んでいます。彼らの主張は、最新のツールを使うことで、これらの挑戦に打ち勝つことができるということです…しかし、それには何年もかかるかもしれません。
同じ記事における、Dean Leffingwell 氏の Scaling Software Agility の本による対照的なメッセージへの、Cottmeyer 氏の主張はコンポーネントチームへのサポートを提供している。
コンポーネントチーム［Leffingwell 氏によって提案される］は、それが小さく、ユーザストーリの納品に必要なすべてのスキルセットを含むという点で機能チーム [Vodde 氏／Larmen 氏と Cohn 氏によって提案される] の同じ属性の多くを共有しています。Leffingwell 氏のコンポーネントチームは、権限を与えられていて、自己組織化されて、自己管理されています。要するに、彼らは典型的なスクラムチームです。しかし･･･これは大きいなことですが･･･彼らはコンポーネント機能に取り組んでいます･･･エンドユーザ機能ではありません。
この記事へのコメントは、彼らの視点のコンテキストに、Leffingwell 氏、Cottmeyer 氏、Vodde 氏による更なる見識を提供する。
機能チームに関する他のアイデアを含んでいる、チーム構成に関する以前のいくつかの議論は、この前の InfoQ の記事をチェックしてほしい。