4.1.3 ガイド：フィーチャーチーム導入マップ
Y 軸: チームの作業範囲が徐々に増加することを表す
X 軸: 徐々に増加する Done の定義として表現されたチームのクロスファンクショナルの度合いを表す
https://scrapbox.io/files/649a89299dc231001bf90898.png
図が示す 4 つの領域
コンポーネントチーム
作業範囲が狭くなり、専門化が進むほどコンポーネントチームの問題は大きくなる
以下の事柄いずれかに重点を置くチームは コンポーネントチーム
エンドユーザー中心の機能ではなく、プロダクトの一部に重点を置く
プロダクトインクリメントを提供するのではなく、タスクを完了することに重点を置く
フィーチャーチーム
プロダクト全体に焦点を当て、顧客中心の機能に携わり、それらをテストするチームは フィーチャーチーム
フィーチャーチームにも作業範囲の大きさがある
e.g. 必要とされる機能を実装するだけ / 顧客の問題を特定し、周囲を巻き込みながらプロダクト全体を共創する
専門よりも機能チーム
過度な専門化は、タスクの受け渡しにより多くの無駄が発生するため、避けるべき
広いスコープで限られたタスクのみを実施する、 過度な専門化がされているチーム
拡張コンポーネントチーム
拡張コンポーネントチームは素のコンポーネントチームよりも改善されていますが、フィーチャーチームによるメリットには遠く及ばない
特定のコンポーネントに作業のスコープが限定されていても、より広い範囲で動作することに責任を持つチームは 拡張コンポーネントチーム
チームには「コンポーネントスコープ」と「プロダクト全体スコープ」の両方の制約があるため、内部的に競合する。この競合によって無駄が発生する
「複数のチームが同じテストを作成する」という作業の重複
「プロダクト重視」のテストをチーム感で調整する（余計な手間）
要求の明確化においても同じ競合が発生する
このチームになってしまっていたら、プロダクトオーナーはスプリントの最後にアイテムを完全に完了させることを、チームに思い出させる必要が出てくる（参考: 8.1.10 ガイド：良い人になるな）