團隊層介紹

詳述

敏捷團隊采用SAFe ScrumXP或團隊看板，同時應(yīng)用內(nèi)建質(zhì)量的實踐，確保最終產(chǎn)品質(zhì)量。每個團隊有5～9名團隊成員（ScrumXP），并包括所有必要的角色，確保在每一次迭代中構(gòu)建一個高質(zhì)量且有價值的發(fā)布增量。ScrumXP角色包括Scrum Master、產(chǎn)品負責(zé)人、全職工作的團隊成員，以及其他能為團隊創(chuàng)造價值的資源。團隊?wèi)?yīng)該完全有能力在每次迭代中定義、開發(fā)、測試和交付可以工作并經(jīng)過測試的系統(tǒng)。

項目群增量和迭代

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

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

每個PI的迭代數(shù)量

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

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

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

敏捷團隊

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

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

角色和責(zé)任

價值的交付：

● 團隊負責(zé)管理自己的工作。

● 團隊估算工作的大小和復(fù)雜度。

● 團隊在架構(gòu)指導(dǎo)下根據(jù)所關(guān)注領(lǐng)域決定技術(shù)設(shè)計。

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

● 團隊負責(zé)價值和構(gòu)建，從而持續(xù)提升交付成果的質(zhì)量。

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

緊密合作

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

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

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

團隊成員之間的關(guān)系彼此信任，持續(xù)反饋提高團隊的合作。

敏捷團隊共同計劃、共同集成和演示、共同學(xué)習(xí)

共同計劃

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

共同集成和演示

團隊在內(nèi)部和這個火車上，都應(yīng)用了內(nèi)建質(zhì)量并在迭代內(nèi)進行持續(xù)集成，同時所有團隊共同協(xié)作，從而可以在每個迭代完成時進行系統(tǒng)演示。

共同學(xué)習(xí)

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

學(xué)習(xí)也是在實踐社區(qū)中不斷發(fā)生的，實踐社區(qū)的建立可以幫助個人和團隊不斷提升本職能和跨職能的技能。

產(chǎn)品負責(zé)人

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

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

責(zé)任

SAFe產(chǎn)品負責(zé)人的主要責(zé)任如下。

籌備和參加PI計劃會議

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

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

迭代執(zhí)行

● 待辦事項列表梳理

● 迭代計劃

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

● 支持ATDD——產(chǎn)品負責(zé)人參加用戶故事接收標準的制訂和起草，并提供示例以支持ATDD（Acceptance Test-Driven-Development，接收測試驅(qū)動開發(fā)）規(guī)范制訂。

● 故事接收——產(chǎn)品負責(zé)人是唯一可以接收用戶故事完成的團隊成員。

● 理解使能工作

● 參加團隊演示和回顧

項目群執(zhí)行

● 迭代和團隊都服務(wù)于一個更大的目標——頻繁、可靠和持續(xù)地發(fā)布以便實現(xiàn)解決方案的增值。

● 產(chǎn)品負責(zé)人在為項目群和價值流利益相關(guān)者進行演示的過程中也起到關(guān)鍵作用。

檢視和調(diào)整

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

● PI系統(tǒng)演示在檢視和調(diào)整工作坊中進行，產(chǎn)品負責(zé)人在為項目群利益相關(guān)者進行PI系統(tǒng)演示時發(fā)揮重要作用。

● 產(chǎn)品負責(zé)人也參與PI系統(tǒng)演示的準備，以確保能夠為利益相關(guān)者展現(xiàn)解決方案的最關(guān)鍵環(huán)節(jié)。

內(nèi)容授權(quán)

產(chǎn)品經(jīng)理、產(chǎn)品負責(zé)人和敏捷團隊的人員配比

每個產(chǎn)品經(jīng)理通?？梢灾С肿疃?個產(chǎn)品負責(zé)人，每個產(chǎn)品負責(zé)人最多可以負責(zé)1～2個敏捷團隊的待辦事項列表。

PM/PO的人員比例模型

Scrum Master

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

在團隊中的責(zé)任

優(yōu)秀的SAFe Scrum Master是基于團隊的仆人式領(lǐng)導(dǎo)：

● 展現(xiàn)精益-敏捷的領(lǐng)導(dǎo)力

● 支持規(guī)則

● 引導(dǎo)團隊向著目標前進

● 領(lǐng)導(dǎo)團隊進行持續(xù)改進

● 引導(dǎo)會議

● 支持產(chǎn)品負責(zé)人

● 消除障礙

● 宣傳推廣SAFe質(zhì)量實踐

● 建立高效團隊

● 保護和溝通

在敏捷發(fā)布火車上的責(zé)任

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

● 與其他團隊進行協(xié)調(diào)

● 引導(dǎo)敏捷發(fā)布火車儀式的準備和就緒

● 協(xié)助估算

ScrumXP

詳述

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

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

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

產(chǎn)品負責(zé)人（PO）

每個ScrumXP團隊有一個產(chǎn)品負責(zé)人負責(zé)團隊待辦事項列表。

Scrum Master（SM）

Scrum Master是團隊的引導(dǎo)者和敏捷教練，其主要職責(zé)包括：確保團隊遵循開發(fā)流程，向團隊提供Scrum、XP和SAFe實踐的培訓(xùn)，以及提供持續(xù)改進的環(huán)境。

Scrum流程

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

迭代計劃

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

可視化工作

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

協(xié)調(diào)每日站會

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

價值演示和過程改進

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

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

內(nèi)建質(zhì)量

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

ScrumXP團隊“在火車上”

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

ScrumXP團隊領(lǐng)導(dǎo)力

團隊管理人員的日常管理職責(zé)存在一個質(zhì)的轉(zhuǎn)變，即從指導(dǎo)團隊具體技術(shù)實現(xiàn)的專家管理者，轉(zhuǎn)變?yōu)槭鼓軉T工、發(fā)展員工的精益-敏捷領(lǐng)導(dǎo)者。

團隊看板

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

一般來講用于開發(fā)的看板系統(tǒng)包括以下幾個主要方面：

● 系統(tǒng)包含一系列需要經(jīng)歷的工作狀態(tài)的定義；

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

● 團隊對于每個工作狀態(tài)的在制品（WIP）限制數(shù)達成一致，并在必要時更改WIP以優(yōu)化工作流；

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

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

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

團隊初始看板示例

度量流動

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

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

通過服務(wù)等級改進流動

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

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

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

SAFe看板團隊“在火車上”

估算工作內(nèi)容

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

計算“導(dǎo)出”速度

估算大的工作項

團隊待辦事項列表

待辦事項列表的定義：

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

2．未完成的任務(wù)或未處理資料的聚集

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

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

● 待辦事項列表有唯一的責(zé)任人——團隊的產(chǎn)品負責(zé)人。

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

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

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