團隊層介紹

詳述

敏捷團隊采用SAFe ScrumXP或團隊看板，同時應用內建質量的實踐，確保最終產品質量。每個團隊有5～9名團隊成員（ScrumXP），并包括所有必要的角色，確保在每一次迭代中構建一個高質量且有價值的發布增量。ScrumXP角色包括Scrum Master、產品負責人、全職工作的團隊成員，以及其他能為團隊創造價值的資源。團隊應該完全有能力在每次迭代中定義、開發、測試和交付可以工作并經過測試的系統。

項目群增量和迭代

所有團隊遵循相同的迭代起止日期和時間周期，也就是有相同的迭代和項目群增量（PI）邊界，以便與ART上的其他團隊保持同步和集成。每個PI都起始于團隊的PI計劃，他們構建團隊的PI目標，再匯總成項目群的PI目標，這些目標有助于指導團隊的迭代執行。

每個迭代提供有價值的新功能增量，迭代過程按照以下模式循環進行：迭代計劃、承諾交付一些功能、通過構建和測試用戶故事執行迭代、演示新功能、執行迭代回顧，在下一個迭代再重復進行這些活動。

每個PI的迭代數量

經驗表明，PI持續時間一般是在8～12周的效果最好，并且傾向于最短的持續時間。

用戶故事和團隊待辦事項列表

團隊使用用戶故事來交付價值，產品負責人負責用戶故事的創建和接收。用戶故事承載客戶的需求，通過價值流進入到實現階段。團隊待辦事項列表由用戶故事和使能故事組成，其中大部分故事是在PI計劃中，當產品經理向團隊展示愿景、路線圖和項目群待辦事項列表時進行確定的。在團隊層基本的需求管理流程是：用戶故事的識別、排序、排期、細化、實施、測試和接收。

敏捷團隊

SAFe敏捷團隊是一個跨職能小組，他們有能力和權力來定義、構建和測試解決方案價值，所有的這些活動都在一個短迭代的時間盒內完成。

敏捷團隊是由專職成員組成的一個小團隊（在Scrum中是5～9人），他們具有一些必備技能，可以在短時間盒內定義（細化和設計他們的組件/特性）、構建（實現這些組件/特性）以及測試（運行測試用例并驗證組件/特性）價值增量。

角色和責任

價值的交付：

● 團隊負責管理自己的工作。

● 團隊估算工作的大小和復雜度。

● 團隊在架構指導下根據所關注領域決定技術設計。

● 團隊承諾在迭代或項目群增量時間盒中完成的工作。

● 團隊負責價值和構建，從而持續提升交付成果的質量。

● 團隊承諾不斷地提升工作方式。

緊密合作

團隊最好能夠在同一地點，每小時、每天、每周都進行溝通。

標準的團隊會議可能包括每日站立會議、迭代計劃、團隊演示，以及每個迭代最后的回顧。

每個團隊成員都完全專注于單一的團隊。

團隊成員之間的關系彼此信任，持續反饋提高團隊的合作。

敏捷團隊共同計劃、共同集成和演示、共同學習

共同計劃

所有團隊共同參加PI計劃會議（如果可能的話，所有的團隊成員最好都要參加）。在計劃會議上，大家一起計劃和承諾一系列的PI目標。大家都有一個共同的愿景和路線圖，共同協作以達成目標。在計劃和執行中，有清晰的工作授權。

共同集成和演示

團隊在內部和這個火車上，都應用了內建質量并在迭代內進行持續集成，同時所有團隊共同協作，從而可以在每個迭代完成時進行系統演示。

共同學習

團隊也會參與更大的檢視和調整會議，通過這種方式識別優先級，按優先級對改進故事進行排序，并將其放入后續的PI計劃會議中進行處理。

學習也是在實踐社區中不斷發生的，實踐社區的建立可以幫助個人和團隊不斷提升本職能和跨職能的技能。

產品負責人

產品負責人（Product Owner, PO）是團隊的一員，負責定義用戶故事和確定團隊待辦事項列表的優先級，從而銜接項目群優先級事項的執行，并維護團隊所負責的特性和組件在概念和技術上的完整性。產品負責人是質量保證的關鍵人物，并且是團隊中唯一有權力接收已完成用戶故事的人。對于正在向敏捷方式轉型的企業來說，產品負責人是一個新的并且非常重要的角色。產品負責人通常是全職的，一個產品負責人通常可以支持一個團隊（最多兩個團隊）。

產品負責人是敏捷團隊的成員之一，他是團隊與客戶之間的接口，負責與產品管理人員以及其他利益相關者（包括其他產品負責人）協作來確定團隊待辦事項列表中用戶故事的優先級，以便解決方案能夠有效處理項目群優先級事項（特性/使能），同時保持技術的完整性。

責任

SAFe產品負責人的主要責任如下。

籌備和參加PI計劃會議

● 作為產品管理團隊的一員，產品負責人積極參與項目群待辦事項列表細化和準備PI計劃會議的工作，同時也積極參與PI計劃。在PI計劃之前，產品負責人更新團隊待辦事項列表，審查和參與制訂愿景、路線圖和進行內容展示。

● 在PI計劃期間，產品負責人參與用戶故事定義，為團隊澄清產品需求，以便團隊進行用戶故事估算和用戶故事排序，并為項目群增量起草團隊目標。

迭代執行

● 待辦事項列表梳理

● 迭代計劃

● 準時制（Just-in-Time, JIT）的用戶故事細化

● 支持ATDD——產品負責人參加用戶故事接收標準的制訂和起草，并提供示例以支持ATDD（Acceptance Test-Driven-Development，接收測試驅動開發）規范制訂。

● 故事接收——產品負責人是唯一可以接收用戶故事完成的團隊成員。

● 理解使能工作

● 參加團隊演示和回顧

項目群執行

● 迭代和團隊都服務于一個更大的目標——頻繁、可靠和持續地發布以便實現解決方案的增值。

● 產品負責人在為項目群和價值流利益相關者進行演示的過程中也起到關鍵作用。

檢視和調整

● 團隊可以在PI的檢視和調整工作坊上來處理那些較大的障礙。在工作坊中，各團隊產品負責人協同工作來定義和實施改進故事，以提高項目群的速度和質量。

● PI系統演示在檢視和調整工作坊中進行，產品負責人在為項目群利益相關者進行PI系統演示時發揮重要作用。

● 產品負責人也參與PI系統演示的準備，以確保能夠為利益相關者展現解決方案的最關鍵環節。

內容授權

產品經理、產品負責人和敏捷團隊的人員配比

每個產品經理通常可以支持最多4個產品負責人，每個產品負責人最多可以負責1～2個敏捷團隊的待辦事項列表。

PM/PO的人員比例模型

Scrum Master

Scrum Master的角色由團隊中的一員承擔，主要職責是幫助自組織、自我管理的團隊實現其目標。Scrum Master通過教學和指導SAFe，實施并支持SAFe的原則和實踐，識別和消除不利因素的影響，引導流動。

在團隊中的責任

優秀的SAFe Scrum Master是基于團隊的仆人式領導：

● 展現精益-敏捷的領導力

● 支持規則

● 引導團隊向著目標前進

● 領導團隊進行持續改進

● 引導會議

● 支持產品負責人

● 消除障礙

● 宣傳推廣SAFe質量實踐

● 建立高效團隊

● 保護和溝通

在敏捷發布火車上的責任

Scrum Master幫助協調團隊之間的合作，以便團隊真正地成為“在火車上的團隊”。

● 與其他團隊進行協調

● 引導敏捷發布火車儀式的準備和就緒

● 協助估算

ScrumXP

詳述

ScrumXP敏捷團隊是一個包括5～9人的自組織、自管理的跨職能團隊，并且盡可能工作在一起。

團隊是跨職能的，因此具備用于交付增量的所有角色和技能。

Scrum定義了兩個特殊的角色：產品負責人和Scrum Master，他們是SAFe ScrumXP團隊的成員，各自被賦予特定且具體的職責。

產品負責人（PO）

每個ScrumXP團隊有一個產品負責人負責團隊待辦事項列表。

Scrum Master（SM）

Scrum Master是團隊的引導者和敏捷教練，其主要職責包括：確保團隊遵循開發流程，向團隊提供Scrum、XP和SAFe實踐的培訓，以及提供持續改進的環境。

Scrum流程

Scrum流程本身是一個輕量級的項目管理框架，能夠促進快速、迭代式高級解決方案能力的構建，并且有利于持續改進以支持更高效的產能和更好的交付。

迭代計劃

迭代開始于迭代計劃，該計劃也是一個遵循時間盒（不超過4小時）的會議，產品負責人可以展示迭代相關的故事。

可視化工作

團隊采用大型可視化信息雷達（big visual information radiators, BVIR）掌握并跟蹤迭代執行過程。

協調每日站會

團隊每天都舉行一個正式的儀式——每日站會（Daily Stand up Meeting, DSU），用于了解團隊目前的狀況，提出問題，以及向其他團隊成員尋求幫助。在會議中，每個團隊成員描述昨天做了什么，今天將要做什么，以及遇到的任何阻礙。

價值演示和過程改進

在演示過程中，團隊展示迭代中每一個完成的故事，其總和就是此次迭代團隊的價值增量。

團隊進行一個簡短的回顧，反思在迭代過程中，哪些地方做得好，以及當前有什么阻礙。

內建質量

內建質量需要從代碼和組件層面抓起，由此生成解決方案；5種來自于極限編程（XP）中的工程和質量實踐，用以擴充Scrum項目管理實踐。它們是：持續集成、測試先行、重構、結對工作和集體代碼所有權。

ScrumXP團隊“在火車上”

作為敏捷發布火車的一部分，ScrumXP團隊共同計劃、共同集成和演示、共同學習，如圖所示。

ScrumXP團隊領導力

團隊管理人員的日常管理職責存在一個質的轉變，即從指導團隊具體技術實現的專家管理者，轉變為使能員工、發展員工的精益-敏捷領導者。

團隊看板

看板（Kanban，意為“可視化的信號”）的本質是一個用于可視化和管理工作的方法。

一般來講用于開發的看板系統包括以下幾個主要方面：

● 系統包含一系列需要經歷的工作狀態的定義；

● 所有的工作都是可視化的，每個任務的進度都會被跟蹤；

● 團隊對于每個工作狀態的在制品（WIP）限制數達成一致，并在必要時更改WIP以優化工作流；

● 團隊制訂工作管理政策；

● 度量流動。工作項從進入系統開始被跟蹤，直至離開；這樣就可以持續地指示在制品數量以及當前的前置時間（Lead Time，一個工作項通過系統所需的平均時間）；

● 通過分配服務等級進行排序，而服務等級是由延遲成本決定的。

團隊初始看板示例

度量流動

為了更好地理解和改進流動與流程，看板團隊采用客觀的度量，包括平均前置時間、WIP、吞吐量。其中常用的一種度量方式是累積流圖（Cumulative Flow Diagram, CFD），如圖所示。

每一個工作項都是有時間戳的，包括其進入工作流的時間（從團隊待辦事項列表拉入開始實施狀態）及完成時間。“到達曲線”表示拉入工作流的工作項數量，“離開曲線”表示完成并被接收的工作項數量。兩條曲線在X軸的差值是平均前置時間——也就是一項工作通過系統所花費的時間。在Y軸的差值是WIP——也就是在任何時間點上，系統中所有工作項的數量。吞吐量——指在給定時間段內完成的工作項數量，它也是一個非常關鍵的指標。

通過服務等級改進流動

1．標準——大部分工作項都屬于這個服務等級：

2．固定日期——有固定日期的工作項意味著里程碑和預先設定日期的依賴關系。其延遲成本是非線性的。

3．加速——“加速”類別工作項有著難以接受的延遲成本，因而需要立即引起團隊關注。

SAFe看板團隊“在火車上”

估算工作內容

為估算建立一個共同的起點

計算“導出”速度

估算大的工作項

團隊待辦事項列表

待辦事項列表的定義：

1．隱藏在舒適表面下的大型列表

2．未完成的任務或未處理資料的聚集

● 待辦事項列表需要包含所有要做的事情，如果工作項處于列表中，那么就需要被完成；如果工作項不在列表中，那么就不會被完成。

● 待辦事項列表是一個“希望實現工作項”的列表，而不是一個承諾。

● 待辦事項列表有唯一的責任人——團隊的產品負責人。

● 所有的團隊成員都可以將自己認為重要的用戶故事放入待辦事項列表。

● 待辦事項列表包含用戶故事、使能故事和“改進故事”，其中“改進故事”是從團隊迭代回顧會議的結果中識別出來的改進內容。

團隊待辦事項列表的三個主要來源。