開發團隊

        在傳統的工作方式下，開發團隊會有很多不同的角色，比如專案經理、產品經理、架構師、設計師、使用者體驗設計師，程式設計師，測試人員，DBA等等。但是，在Scrum的工作方式下，總共只有三個角色， 這三個角色分別是產品負責人（PO）,Scrum Master和開發團隊。

我們通常可以以划龍舟的團隊角色來類比Scrum的角色，划龍舟通常有舵手、鼓手、划槳團隊三個角色。Scrum中的PO就是舵手的角色，他對產品的方向負責，對產品的Why和What負責，對產品的願景，產品包括哪些主要的特性負責。Scrum中的Scrum Master鼓手的角色，他幫助團隊保持高昂的士氣，並進行良好的協作，他是一個Scrum的專家，團隊的教練，團隊的服務式領導。Scrum中的團隊，對應到龍舟賽的划槳團隊，團隊必須協調一致，作為一個整體前進，在這樣的環境下單打獨鬥，各自為政沒有任何勝算。

Scrum的開發團隊對實現Sprint目標需要做的所有事情負責，包括技術方案和決策，團隊分工（誰做什麼），執行Sprint開發任務等，而且作為自組織的團隊，他們也對他們的工作進度的跟蹤和管理負責。Scrum開發團隊的主要職責包括如下五個方面：

1.執行Sprint

2.梳理產品Backlog

3.做Sprint計劃

4.每天跟進工作進展，並對他們的工作做檢查和調整

5.每個迭代對產品和團隊的工作過程做檢查和調整

開發團隊的特徵：

自組織、多元化、跨職能的完整團隊、團隊成員符合T型技能，即一專多長、持續改進、最大限制的溝通、透明溝通、2個披薩的團隊大小（5-9人）、專注、投入、

自組織團隊

自組織團隊是敏捷軟體開發的基本觀念 。敏捷宣言的原則中提到 :“最好的架構、需求和設計出於自組織團隊 ”。自組織團隊也叫做自管理團隊、或者被授權的團隊。團隊被授權自己管理他們的工作過程和進度、並且團隊決定如何完成工作。

自組織團隊和經理領導的團隊的區別

對於經理領導的團隊來說，團隊成員被分配任務，團隊成員只有執行任務的權利。

對於經理領導的團隊來說，管理者除了要確定目標、方向，團隊的上下文（組織結構、團隊結構、團隊組成），還需要監督和管理團隊的過程和進度，分配任務即確定誰做什麼。這種團隊的管理方式，更多的是命令與控制，以及微觀管理。

對於自組織團隊來說，他們擁有如下權利：

1.團隊決定誰做什麼，即任務的分配

2.團隊決定如何做，如何實現目標，即團隊做技術決策

3.團隊需要在確保目標的前提下制定團隊內的行為準則

4.團隊有義務保持過程的透明性

5.團隊監督和管理他們的過程和進度

在自組織團隊的環境下，管理層關注在如下幾個方面：

1.確定團隊目標和願景

2.確定團隊上下文，組織結構、團隊結構、團隊組成

3.提供環境和支援（安全感、良好的團隊空間、氛圍，技能輔導等）

4.授權團隊

5.訓練協作

對於自組織團隊的普遍誤解：

誤解1：團隊自己決定目標是什麼 ； 糾正：管理層決定團隊目標

誤解2：團隊自己決定誰進入團隊； 糾正：管理層決定團隊上下文

誤解3：團隊自己設計團隊結構； 糾正：管理層決定團隊上下文

誤解4：自組織團隊不需要管理者； 糾正：管理者從微觀管理轉向目標驅動、授權團隊的管理方式

誤解5：自組織團隊需要員工更加主動； 糾正：自組織讓團隊更加主動，每個人都不喜歡被命令和控制，每個人期望有成就感、期望被認可

誤解6：自組織團隊想幹什麼就幹什麼； 糾正：管理層決定團隊目標，團隊決定如何實現目標

一個自組織的團隊通常由不同職能專業、思考方式和行為模式的成員組成，也就是說它是跨職能的團隊。

自組織的團隊不是與生俱來的，打造一個團隊需要一個過程，打造一個組織團隊也是一樣。打造自組織團隊，首先要讓團隊需要完全自主； 其次，有了自主，管理者需要引導團隊持續改進，幫助團隊持續地挑戰更高的目標；第三，給團隊提供環境和支援，引導團隊往正確地方向邁進。

特性團隊

如果我們的產品開發團隊只有在10人以內，我們使用一個跨職能的Scrum團隊，可以很容易地按照scrum和敏捷的方式開發產品。 但是，如果產品團隊規模較大，比如是幾十人，甚至幾百人的開發團隊的時候，我們就需要考慮團隊的結構和組織方式。

在一個大的開發組織中，Scrum會把大的開發團隊劃分成多個5-9人的小團隊，那麼我們應該按照什麼方式來劃分呢？

在傳統的開發模式下，我們習慣於按照系統的架構模組，或者系統分層組織團隊，也有的團隊按照系統需求、開發、測試結合系統架構混合組織的方式。這種團隊組織的方式，我們稱之為元件團隊，是指每個團隊只是完成系統功能的某一個部件，而不是一個端到端使用者可見的功能。

元件團隊看起來像這個樣子：

按照Scrum和敏捷的交付模式，元件團隊有如下一些限制：

第一：按照元件來組織團隊，很難避免團隊之間的依賴，跨團隊的協調和依賴管理更加複雜，不利於跨元件或者各個層之間的溝通。

第二：每個團隊專注在自己的模組，由於各模組、或分層需求工作量的不同，很容易產生等待，並且容易產生低價值的交付。

第三：由於職責單一，限制了學習，使得專業更加單一化

第四：Sprint結束的時候無法提交可交付的增量產品功能，延遲價值交付

按照Scrum和敏捷的交付模式，以使用者為中心，按照使用者場景作為邊界來組織團隊是比較推薦的做法。這種以使用者為中心的團隊叫做特性團隊。

特性團隊的特點：

1.長期穩定的團隊，逐個端到端完成客戶特性

2.以客戶為中心的特性驅動

3.跨職能、完整團隊

4.共享程式碼庫，統一的持續整合

5.擁有通用型專家

特性團隊看起來像這個樣子：

特性團隊的好處：

1.團隊內可以做到端到端，所以減少了等待，週期加快

2.比較容易在一個Sprint中交付可用的產品增量

3.減少了團隊之間依賴，計劃會更容易

4.責任範圍的擴大，各種不同領域的專家在一個團隊，增加了

5.個人學習和團隊學習的機會