Scrum迭代開發、增量交付的開發方法建築在Scrum團隊之上，Scrum團隊中的開發團隊應當是特性團隊，而不是元件團隊。離開特性團隊，Scrum就難以實現迭代開發、增量交付。深入瞭解元件團隊的固有問題，準確理解什麼是特性團隊，對於指導組織轉型至關重要。

什麼是特性團隊？按照Ken Rubin的定義，特性團隊是一個跨職能、跨元件的團隊，能夠從產品待辦列表中抽取並完成最終客戶想要的特性。Ken Rubin的定義裡談到了“職能”、“元件”和“特性”三個名詞，這三個名詞分別是什麼意思呢？

首先，應該準確理解“特性”。這個特性指從產品的終端使用者的角度看，對終端使用者有價值，終端使用者能夠感知到的東西。

第二、職能

第三、元件。當軟體系統龐大、複雜時，通常把一個系統分解為多個元件。當這個複雜的軟體系統由很多開發者共同開發時，傳統組織通常把開發者按照元件分組。負責某個元件的這樣一組開發者是這個元件的專家，他們熟練掌握自己負責的元件的相關知識，也只有這組人有許可權修改、維護這個元件。

當一個終端使用者想要的特性需要三個元件協同工作才能完成時，這個特性就是跨元件的。要開發這樣一個跨元件的特性，就需要分別來自三個元件團隊的開發者來協同工作。

舉個極端的例子，Facebook的最初版本是扎克伯格一個人在大學宿舍裡開發的。UI設計、程式設計和測試都是他做，他跨職能；網頁介面和資料庫都是他做，他跨元件。他一個人構成了一個最小的跨職能、跨元件開發團隊，具備交付終端使用者想要的特性的能力。當然我們不能期望每一位開發者都像扎克伯格一樣是全才，但我們可以組建這樣的團隊，這個團隊相對於某個產品，相對於從產品待辦項中抽取的某個或某些特性，擁有必備的職能，擁有必備的知識和許可權。這樣的團隊不需要依賴外部的力量就可以承諾並完成終端使用者想要的特性。這樣的團隊就是特性團隊。

以元件團隊為主的組織難以實現迭代開發、增量交付。這是因為特性會因涉及到不同的元件而分散在不同團隊中進行開發。每個元件團隊對自己的待辦列表有自己的優先順序排序，多個待辦項列表，優先順序如何協調呢？眾所周知，跨團隊的協作比團隊內部的協作更麻煩，需要更多的溝通成本。在傳統開發方法中，只是在開發末期一次性集中交付，協調多個元件團隊這個問題並不突出。但在Scrum中，每個衝刺都要協調，勢必消耗大量溝通成本，而且難以保證及時交付。

以某傳統組織為例，該組織按照職能劃分組織結構，有UI部門、軟體研發部門和測試部門。軟體研發部門內部按照元件劃分為多個團隊，每個團隊負責開發和維護一到多個元件。該組織每年平行開發的產品不下數十個。某產品採用Scrum開發方式，每3週一個衝刺，但團隊結構仍然是傳統的元件團隊，於是經常出現這樣的現象：軟體研發團隊把它放在最高優先順序，UI設計團隊把它放在最低優先順序，在等待UI設計的時間裡，開發者無事可做。等到UI終於設計完成，留給軟體編碼的時間就很緊張，程式設計師拼命加班還是無法完成。如果這個特性不僅依賴UI，還跨元件，問題就更多。各個元件團隊有自己的開發任務優先順序列表，有的元件更新好了，有的元件還沒有更新好。臨近釋出截止日期，產品經理將當前的程式碼提交測試，測出很多缺陷也就無法避免。長期以來，這樣的問題反覆出現，嚴重困擾著軟體研發團隊，使他們面臨極大壓力。

管理層拷問，為什麼還有這麼多bug？要求分析bug產生的原因，提出預防措施。經過分析、總結，bug的主要原因來自兩個方面：一是UI設計完成太晚，來不及編碼；二是某些元件不穩定；提出的預防改進措施有2點：建議UI部門早點完成設計；建議其他元件團隊提供穩定的元件。事實證明，這些建議從未起作用。

讓我們從團隊結構的角度重新審視這一問題。上述案例中的開發團隊跨職能嗎？跨元件嗎？毫無疑問，答案是“否”。按照職能、元件劃分的團隊結構，容易導致各職能團隊，各元件團隊各自為政，協作較弱，難以按照特性對齊。所以，上述案例的問題，是團隊結構的問題。

以特性團隊為主的組織更容易實現迭代開發、增量交付。面對同樣的情況，Ken Robin描述的跨職能特性團隊應該這樣開展工作：一名UI設計師，分別來自相關元件團隊的幾名軟體開發者，一名軟體測試者，結組形成一個7人左右的小團隊。整個團隊面對同一個產品待辦列表，對於這個版本要釋出某個特性，先完成UI設計，然後完成軟體開發，最後完成軟體測試。然後針對下一個特性，如此迴圈往復。特性團隊，按照特性的維度協調工作，逐個特性開發，優先順序自然向當前特性對齊。寧可一個衝刺少從產品待辦列表中抽取幾個低價值的特性，也要保證高質量地完成高價值的特性。這樣就不會出現幾個職能責任人的優先順序對不齊，幾個元件開發者的優先順序對不齊的問題。對於大型產品，由很多人並行開發，則建立多個特性團隊，並行開發多組特性。

全球已經有很多組織成功建立了跨職能、跨元件的特性團隊，基於特性團隊成功實施Scrum，為創新型產品的成長、成功提供了理想環境。以2012~2016年間的Facebook為例，他們的專案採用Scrum開發方法，開發團隊的結構是：設計師加工程師。如果做一個簡單的小功能，一般是一個設計師加兩個工程師，比較大的專案，比如說改版、在新版開發兩三個工，基本上兩三個工程師一起做，也可能擴充套件到五到十位工程師。Facebook沒有專職的測試員，工程師自己測。整個流程中，設計師和工程師互相合作，聯絡是非常緊密的。不同職能的人坐在一起討論，有任何進展馬上當面溝通。

綜上所述，以特性團隊為主的組織在實現“迭代開發、增量交付”方面有天然的優勢，成功的Scrum組織應以特性團隊為主。

一個組織的團隊結構以特性團隊為主，實現“迭代開發、增量交付”就會順利。但同時，元件的維護、可複用性就會有問題。如果軟體架構簡單，這個矛盾或許並不突出。如果軟體架構複雜，不同特性團隊對元件的修改意見相互矛盾、期望完成修改的時間相互競爭，該怎麼辦呢？這就需要適當的混合組件團隊，以協調維護元件的問題。一個組織的團隊結構以元件團隊為主，元件的開發、維護、可複用性就會順利，但又難以實現增量交付，在不確定環境下的應變能力也不會那麼強。所以，特性團隊和元件團隊到底哪種好，如果混合，以哪種為主，應視業務特點而定。強調業務不確定性強、靈活多變，需要增量交付，應以特性團隊為主。強調業務基本穩定，元件、平臺可複用，應以元件團隊為主。

參考文件

1.Essential Scrum – A PracticalGuide to the Most Popular Agile Process.(Kenneth S. Rubin)

2.Facebook的專案開發流程和工程師的績效管理機制，覃超