敏捷新人的兩個常見問題包括“敏捷團隊中的角色是什麼？” 和“你如何組織敏捷團隊？”
本文的目的是通過研究如何為一個相對較小的敏捷團隊（可能是15人或更少人）以及一個 大型敏捷團隊（可能是50人或更多人）來解決這些問題 。對於介於這些規模之間的團隊，您需要在兩者之間的某個位置定製解決方案。
本文中描述的角色和組織結構具有代表性 - 您的方法可能略有不同，因為您處於不同的情況。但是，如果您認為您的方法需要有顯著差異，那麼您可能還沒有完全放棄 傳統IT角色背後的思考，並且可能會使您的敏捷採用處於風險之中。此外，本文不涉及 企業級角色。
敏捷的團隊組織方法與傳統方法之間存在幾個關鍵差異。
- 敏捷團隊是“整個團隊”。整個團隊是一項 極限編程（XP）實踐，建議您在團隊內部擁有足夠的技能來完成工作。這意味著開發團隊擁有必要的 測試 技能，數據庫技能， 用戶界面技能等等，並且不依賴於外部專家或專家團隊來完成這些事情。
- 敏捷團隊（大多數）是由廣義專家組成的。一個 摹eneralizing專家，有時被稱為工匠，是指具有一個或多個技術專長（例如Java編程，項目管理，數據庫管理......）的人，這樣他們可以為團隊貢獻一些直接的價值，至少具有一般知識軟件開發及其工作的業務領域，最重要的是積極尋求在現有專業以及其他領域（包括技術領域和領域領域）獲得新技能。顯然，新手IT專業人員和經常專注於一個領域的傳統IT專業人員需要努力實現這一目標。推廣專家是專家的兩個極端，對狹隘領域瞭解很多的人，以及對廣泛主題有一點了解的通才的最佳點。
- 敏捷團隊穩定。敏捷專家瞭解改變團隊結構 - 這次迭代Sally是團隊的一部分，但是下一次迭代她是為了幫助另一個團隊 - 對項目的成功是不利的。我們努力使我們的團隊儘可能保持穩定，如果人們推廣專家，這個目標更容易實現。
小敏捷團隊
有幾個角色，根據所遵循的方法有不同的名稱，敏捷團隊通用。角色不是職位，任何給定的人擔任一個或多個角色並且可以隨著時間的推移切換角色，並且任何給定的角色在項目的任何給定點都可以有零個或多個人。常見的敏捷角色是：
- 團隊領導。這個角色在 Scrum中稱為“Scrum Master”， 或者是其他方法的團隊教練或項目負責人，負責為團隊提供便利，為團隊獲取資源並保護團隊免受問題的影響。這個角色包括項目管理的軟技能，但不包括技術，如計劃和日程安排，最好留給整個團隊的活動（稍後將詳細介紹）。
- 團隊成員。此角色（有時稱為開發人員或程序員）負責創建和交付系統。這包括建模，編程，測試和發佈活動，以及其他活動。
- 產品所有者。該 產品負責人，被稱為現場客戶在XP和 積極的利益攸關方在上午，代表的利益相關者。這是負責 優先工作項目列表（稱為Scrum中的產品積壓），及時做出決策以及提供信息的團隊（或 大型項目的子團隊）的 一個人。及時。
- 利益相關者。一個 利益相關者是人誰是直接用戶，間接用戶，用戶的經理，高級經理，業務人員，“金老闆”誰的資金項目，支持（幫助臺）工作人員，審計師，你的程序/投資組合經理，開發人員在其他系統上工作，這些系統與正在開發的系統或可能受軟件項目開發和/或部署影響的維護專業人員集成或交互。
圖1概述了一個小型敏捷團隊的結構。您在敏捷文獻中通常閱讀的內容是，由團隊負責人領導的開發團隊如何與產品負責人密切合作， 逐步構建高質量的工作系統。您經常聽不到的是我稱之為“支持演員”：
- 技術專家。有時，團隊需要技術專家的幫助，例如構建主人來設置他們的構建腳本或 敏捷的DBA來幫助設計和測試他們的數據庫。技術專家是根據需要臨時引入的，以幫助團隊克服困難問題並將他們的技能轉移給團隊中的一個或多個開發人員。
- 領域專家。正如您在圖2中所看到的，產品所有者代表了廣泛的利益相關者，而不僅僅是最終用戶，並且在實踐中期望他們成為您域中每個細微差別的專家是不合理的。因此，產品所有者有時會聘請領域專家與團隊合作，可能是稅務專家解釋需求的詳細信息，或贊助執行人員解釋項目的願景。
- 獨立測試員。有效的敏捷團隊通常會有一個 獨立的測試團隊並行工作，以驗證他們在整個生命週期中的工作。這是一個可選角色，通常僅在非常複雜的項目（或大規模）上採用。
圖1。一個小型敏捷團隊的組織結構。
圖2。產品所有者代表一系列利益相關者。
大型敏捷團隊
當敏捷團隊的規模達到20左右或更多時，您會發現需要分而治之並採取“團隊團隊”方法。典型的策略是將您的大型團隊組織成一個較小團隊的集合，最有效的方法是圍繞您的系統架構。每個子團隊應負責一個或多個子系統，使他們能夠作為一個小型敏捷團隊，負責及時交付工作軟件。梅爾文康威在20世紀60年代後期引入該策略之後，這種策略通常被稱為康威定律，並且是幾種 精益發展治理策略之一。
大規模敏捷團隊的其他角色包括：
- 架構師。此人負責促進子團隊的架構決策，並且是架構所有者團隊的一部分，該團隊負責項目的整體架構方向。架構所有者通過其子系統的初始 架構來引導他們的子團隊 ，並將參與整個系統的初始架構設想（作為架構所有者團隊的一部分，見下文）。建築所有者與傳統建築師的不同之處在於，他們並不單獨負責設定建築方向，而是促進其創建和發展。
- 子團隊。子團隊通常負責一個或多個子系統，整個團隊越大，通常構建的系統越大，越複雜。在這些情況下，整個團隊可能需要一個或多個擔任集成商角色的人員，他們負責從各個子系統構建整個系統。這些人經常與獨立測試團隊密切合作，如果有的話，他們希望在整個項目中定期進行系統集成測試。
正如圖3所示，在大型敏捷團隊需要協調的幾個關鍵問題：
- 項目管理活動。在規模上，僅僅關注項目領導並允許自組織來解決項目管理的技術方面是不夠的。這可能適用於各個子團隊，但在整個項目/項目中， 項目管理的技術方面 ，如依賴管理，合同管理，資源跟蹤，供應商管理變得至關重要。圖3的項目管理團隊，有時稱為項目管理團隊，由各個子團隊的團隊負責人組成。他們的目標是協調整個團隊的管理方面。該團隊每天可能會舉行一次簡短的協調會議，稱為Scrum方法中的“Scrum scrum”，其中共享當前狀態並確定問題。
- 技術/架構問題。架構所有權團隊由子團隊的架構所有者組成，負責 架構構想在項目開始時確定初始技術方向併為組織子團隊提供基礎。在項目的第一週左右（有時在更復雜的項目上有幾周），他們的目標是識別子系統及其接口，這種策略稱為“管理接縫”，減少子系統之間的耦合，從而減少子系統的數量。子團隊要求的協調。一旦接口定義良好，各個子團隊就可以專注於實現這些子系統的內部結構。在整個項目中，該團隊將定期召開會議，分享想法並解決技術問題，尤其是那些圍繞子系統接口變化的問題。他們可能選擇每天見面，
- 要求/產品所有權問題。產品所有權團隊由每個子團隊的產品所有者組成，負責協調子團隊中的需求工作。他們需要與他們所代表的更多利益相關者協商要求，並在子團隊中適當地進行分配。他們還需要就子團隊之間不可避免的爭議進行談判，以確定誰應該做什麼以及要求實際意味著什麼。他們還管理子團隊之間的需求依賴關係，並努力減少子團隊之間的重疊工作。
- 系統集成。系統集成對於任何規模的項目團隊都很重要，但它通常對大型團隊（通常解決複雜問題）至關重要。大型項目的複雜性通常需要向團隊添加一個系統集成商或幾個（有時稱為構建主人）。系統集成發生在整個 敏捷生命週期中，而不僅僅是在傳統項目的系統集成測試階段的項目結束時。在第一次開發迭代中，稱為統一過程中的“精化階段”，一個重要的目標是子團隊根據之前商定的接口規範創建其子系統的模擬。目標是對模擬系統進行完整的端到端構建，以確保子團隊能夠實現相同的技術願景。毫無疑問，當你遇到在迭代0期間沒有想過的技術問題時，你需要發現你需要進一步改進接口。在項目早期製作子系統的模型有幾個優點。第一，現在，各個子團隊可以在他們自己的工作上前進，而對其他子團隊的依賴性很小。每個團隊都將在整個項目中發展他們的子系統，用真實的工作代碼替換模擬的代碼部分。這些新版本可供其他子團隊使用，而這些子團隊又會選擇何時將這些新版本集成到他們自己的環境中。根據我的經驗，早些時候比以後好，但是你要等到你知道新版本是穩定的，這是擁有一個獨立測試團隊的優勢之一，直到你將它集成到你自己的工作中。其次，您的獨立測試團隊現在可以根據自己的需要對整個構建進行測試。當然，起初他們只有系統的模型，但他們至少可以在此時開始為系統組織他們的測試框架。第三，您可以類似地組合您的集成框架，以支持整個系統的持續集成工作以及各個子團隊的集成工作。第四，個別子團隊在他們在自己的環境中測試後會推廣他們的代碼。在大型敏捷團隊中，這些新的子系統構建通常由您的獨立測試團隊在其他子團隊可用之前進行審查，這個過程應該快速且經常地完成。測試團隊通常會進行完整的系統集成測試，由於時間考慮（集成測試通常需要很長時間才能運行）或由於資源限制（測試團隊通常有一個更復雜的測試平臺），子團隊可能很難做到這一點。子團隊可能會選擇使用預先批准的子系統，風險取決於您組織的文化。
圖3。大型敏捷團隊的組織結構。
我想分享一些意見：
- 圖3的一個有趣特徵是圖1的兩個支持演員，敏捷DBA和用戶體驗專家已經成為子團隊的成員。這些角色是一些子團隊普遍需要的例子，包括一些專門從事特定活動的技術專家。通過組織架構周圍的團隊，一些子團隊專注於整個系統的某些方面，因此包含一些“過於專業化”的人來解決子團隊正在處理的子組件的特定方面是有意義的。
- 隨著團隊規模的擴大，開發人員的日常活動幾乎沒有差異。它們通過協調員的活動與大型團隊的複雜性隔離開來，甚至可能不知道這種情況正在發生。
所有傳統角色 去哪兒了？
正如您在圖1和圖3中看到的 許多傳統工作角色，例如項目經理，業務分析師和設計師（僅舉幾例）。項目經理的領導活動由團隊教練負責，許多技術技能由團隊成員通過自我組織執行。 敏捷分析發生，但不是由專業 業務分析師執行， 而是由產品所有者（許多BA選擇 過渡到產品所有者的角色）和開發人員協作。 敏捷設計 發生，但不是由專業設計師執行，而是由敏捷開發人員執行，他們可能或可能不是由架構所有者領導。
關鍵在於，雖然角色可能已經改變，但我對傳統角色的活動仍在發生。這並不完全準確，真正發生的事情是，傳統角色的人們所採取的活動所解決的目標現在正由敏捷角色的人們所採取的活動來解決。例如，正在探索需求背後的細節，但它們是由產品所有者和開發人員以敏捷方式完成的，而不是由業務分析師以傳統方式完成的。這一開始可能令人不安，特別是如果它違背了您多年來接受的培訓和教育，更重要的是違背了您根據傳統經驗建立的信念體系。轉向敏捷需要一種範式轉換，
閱讀更多 大漠森林789 的文章
