チームは、製品またはサービスの周りに編成されています。
チームはコヒーレントな機能セットを中心に構成された** Feature Teams であり、このセットに必要なすべてのスキル**で構成されています。
たとえば、Business Expert + Web Developer + Java Developer + Architect + DBA + Operationalなどです。
責任は集団です。機能チームはこの責任のために必要な力を持っています。
フィーチャーチーム**のサイズを制限する（5人から12人まで）。
フィーチャーチームのサイズを制限する：** 5〜12人**。
5歳未満では、彼女は外部の出来事にはあまりにも敏感で、創造性に欠けています。 12を超えると、生産性が失われます。
「** 2ピザチーム」という用語**は、フィーチャーチームのサイズが2ピザを摂取できる人数を超えてはならないことを示しています。
やり方を知っているや**誰がやりたいのか多才な人にベットしてください。
最も重要なのは、開発の文化、スケーラビリティ、適応性です。
ソフトウェア職人とフルスタック開発者を募集することで、彼らはノウハウと全体的なビジョンを通じて真の付加価値をもたらします。
それにもかかわらず、モバイル開発者は通常、専門開発者です。
魅力的 最高のを募集する。
モビリティ、家庭作業、CYOD (Choose Your Own Device）。
実験に時間を費やし、作業時間にする。
組織はスリープエンジンでなければなりません
前日は仕事の一部です。
組織は継続教育またはビジネス大学のようなシステムをセットアップすることによってデイケアエンジンでなければなりません。
**コーディングDojos *、* Brown Bag Lunchs 、 External ** Conferencesなどの他のより多くの非公式な方法と自由に組み合わせてください。
コンバージェンスの目標に賭けて、取引の間の障壁を取り除く。
トレード間の障壁を解消するために、一般的な製品を共通の場所でグループ化するだけでは不十分です。
アジャイルアプローチは、目的のコンバージェンスを確実にするためにこれらの障壁を排除します**。
これらのプラクティスは成功への鍵の不可欠な部分です。組織は保証人です。
** DevOps **プラクティスでは、壁がBuildとRunの間に入ることができます。
共通の目標に向けて** Dev と Ops を統合するには、 DevOps **を採用してください。
取引は変わりません！ DevOpsは、同じ人がDevとOpsのタスクを実行することを意味しません。 開発者と運用は** ** スキルからを恩恵を受けるために共同作業を要求され、共感**を改善する必要があります。
フィーチャーチームによって厳しいタスクが実行されます。
オートメーションは続いています。
伝統的な組織では、チーム間の理解の欠如は、通常、距離やコミュニケーションの欠如**に関連しています。
フィーチャーチームのメンバーはすべてのタスクに対して共同責任と固いです。
痛みは、継続的改善の重要な要素です。
サービスセンターは集団コミットメントとは調和しません。
フィーチャーチームは、コラボレーションと集団エンゲージメントに大きく依存する原則に基づいて構築されています。
サービスセンターは、企業によるITの合理化と統合に向かっており、これは集合的コミットメントのこの概念に反しています。
組織は独断的ではなく、検証**の役割を担っています。
組織がツールと用途で検証の役割を保持していることを確認してください。特に遺産に影響を与えるツール（例：ソースコードの管理）。
** の機能チームは、その選択肢をサポートするを意味します。
独断的ではない 実験を励ますことを忘れないでください**。
フィーチャーチームはコミュニケーションを期待し、経験とスキルを共有することが期待されます。
** Feature Teams **の間に障壁を作りません。
フィーチャーチームが互いにコミュニケーションを取り、スキルと経験を共有するために必要な組織とアジリティを設定します。
** Spotify （部族、章および組合）における横断の組織は、雄弁な例です。