敏捷中的跨職能 vs 自組織 vs 功能 vs 組件團隊

傳統上，一個項目是圍繞 組件團隊 （即 UX、Dev、Business、Tester 等）組織的，任何需要一系列組件專業知識的發布都需要涉及多個組件團隊。通常，不同的團隊會有不同的優先級，這不可避免地會導致產品發布週期的瓶頸。

根據維基百科，跨職能團隊是一群具有不同職能專業知識的人，他們朝著共同的目標努力。提高團隊質量的最佳方法之一是使其具有跨職能。跨職能團隊擁有將想法轉化為工作產品的所有必要技能。

“跨職能團隊擁有完成工作所需的  所有能力，而不依賴於不屬於團隊的其他人”——Scrum 指南

與組件團隊方法相比， 跨職能團隊 是由來自公司不同職能領域的人員組成的小組。— 它不僅應該由技術專家（後端、前端開發人員、QA 工程師等）組成，還應該由業務分析師、市場營銷和用戶體驗專家或任何積極參與項目的人員組成。

自 組織團隊 是一個可以自主選擇如何最好地完成工作的團隊，而不是由團隊外的其他人指導。與傳統的管理原則不同，自組織授權的團隊不是由高層指揮和控制的；相反，它們是從團隊成員積極和集體參與所有 Scrum 實踐和活動演變而來的。

傳統團隊 vs 敏捷團隊

“一個 自組織團隊 由一組必須管理自己的知識工作者組成。他們必須擁有自主權”—— 彼得·德魯克。

Scrum 指南指出“Scrum 團隊由產品負責人、開發團隊和 Scrum Master 組成。他們是：

“ Scrum 團隊 是 自組織 和 跨職能的” —  Scrum 指南：

組件團隊與功能團隊

傳統的方法是將產品或多或少地在邏輯上和有意義地分解成組件，並將組件團隊分配給它們。但是，這些組件與客戶的觀點完全無關。

與技術堆棧團隊相反，特性團隊方法現在幾乎是普遍接受的組織團隊的方式，特別是在持續交付方法中，它強調解決用戶需求的特性（即係統的垂直切片），這通常可以加速重視任何功能或工作軟件的交付，並縮短來自真實用戶的反饋循環。功能團隊將擁有執行必要任務級工作以完成工作的所有技能。特別是，假設一個三層架構，團隊成員將從事與這個故事的 GUI、中間層和數據庫部分相關的任務。

組件組織的一大缺點是顯而易見的：它減慢了價值流動。大多數係統功能創建依賴關係，需要組件團隊之間的合作來構建、部署和最終發布。團隊花費大量時間討論團隊之間的依賴關係和跨組件測試行為，而不是能夠交付最終用戶價值。