PMI-ACP官方教材：《敏捷實踐指南》及ACP知識體系介紹

原創(chuàng)2023-04-17小艾老師

PMI-ACP認證是由美國項目管理協(xié)會（PMI）于2011年推出的一種敏捷項目管理認證。它是PMI針對敏捷實踐者的資格認證，同時也是敏捷項目管理的行業(yè)標準。該認證旨在評估從業(yè)者在敏捷方法、實踐和工具方面的知識和技能，以及在敏捷環(huán)境中管理項目的能力。通過PMI-ACP認證，可以證明個人在敏捷項目管理方面的專業(yè)能力和實踐經驗。

中文名ACP敏捷項目管理認證
英文名Agile Certified Practitioner
英文簡稱ACP
頒證機構PMI（美國項目管理協(xié)會）
證書類別敏捷
同類認證Scrum Master、ITIL4 HVIT、DevOps

《敏捷實踐指南》

ACP官方教材選用PMI官方推薦的《敏捷實踐指南》，它是理解、評估和使用敏捷和混合的敏捷方法的資源。該實踐指南為何時、何地以及如何應用敏捷方法提供指導，并為希望增強敏捷性的實踐者和組織提供實用工具。該實踐指南也是ACP認證考試的基礎。

文章目錄

ACP官方教材目錄結構

1.引論
2.敏捷概述
2.1可確定的工作與高度不確定的工作
2.2《敏捷宣言》及思維模式
2.3精益與看板方法
2.4不確定性、風險和生命周期選擇
3.生命周期選擇
3.1項目生命周期的特征
3.1.1預測型生命周期的特征
3.1.2迭代型生命周期的特征
3.1.3增量型生命周期的特征
3.1.4敏捷生命周期的特征
3.1.5敏捷適用性篩選器
3.1.6混合生命周期的特征
3.1.7結合了敏捷和預測的方法
3.1.8以預測法為主、敏捷方法為輔的方法
3.1.9以敏捷方法為主、預測法為輔的方法
3.1.10符合目的的混合生命周期
3.1.11混合型生命周期作為過渡策略
3.2混合敏捷方法
3.3影響裁剪的項目因素
4.實施敏捷：創(chuàng)建敏捷環(huán)境
4.1從敏捷思維模式開始
4.2仆人式領導為團隊賦權
4.2.1仆人式領導的職責
4.2.2項目經理在敏捷環(huán)境中的角色
4.2.3項目經理應用仆人式領導
4.3團隊構成
4.3.1敏捷團隊
4.3.2敏捷的角色
4.3.3通才型專家
4.3.4團隊結構
4.3.5專職小組成員
4.3.6團隊工作場所
4.3.7克服組織孤島
5.實施敏捷：在敏捷環(huán)境中交付
5.1項目章程和團隊章程
5.2常見敏捷實踐
5.2.1回顧
5.2.2待辦事項列表編制
5.2.3待辦事項列表的細化
5.2.4每日站會
5.2.5展示/評審
5.2.6規(guī)劃基于迭代的敏捷
5.2.7幫助團隊交付價值的執(zhí)行實踐
5.2.8迭代和增量如何幫助交付工作產品
5.3解決敏捷項目的挑戰(zhàn)
5.4敏捷項目的衡量指標
5.4.1敏捷團隊的衡量結果
6.關于項目敏捷性的組織考慮因素
6.1組織變革管理
6.1.1變革管理驅動因素
6.1.2變革就緒情況
6.2組織文化
6.2.1創(chuàng)建安全環(huán)境
6.2.2評估文化
6.3采購和合同
6.4商業(yè)實踐
6.5多團隊協(xié)作和依賴關系（擴展）
6.5.1框架
6.5.2考慮事項
6.6敏捷和項目管理辦公室(PMO)
6.6.1敏捷PMO為價值驅動型
6.6.2敏捷PMO為面向創(chuàng)新型
6.6.3敏捷PMO為多學科型
6.7組織結構
6.8組織演變
7.行動呼吁
附錄A1―《PMBOK指南》映射
附錄A2―《敏捷宣言》映射
附錄A3―敏捷和精益框架概述
附件X1
貢獻者和評審
附件X2
影響裁剪的屬性
附件
敏捷適用性篩選工具
參考文獻
參考書目
術語表（英文排序）
索引

ACP知識體系介紹

ACP七大知識領域

ACP知識體系可以概括為7大知識領域，包括敏捷原則和理念、價值驅動交付、干系人參與、團隊績效、適應性規(guī)劃、問題發(fā)現(xiàn)和解決、持續(xù)改進(產品、流程、人員)。

知識領域1：敏捷原則和理念（9項任務）
在項目團隊和組織的范圍內，探索、接受、應用敏捷原則和理念。

知識領域2：價值驅動交付（4個子領域，14項任務）
基于干系人的優(yōu)先級，通過產生高價值的增量并進行評審，盡早和頻繁的交付有價值的成果。讓干系人對于這些增量提供反饋，使用這些反饋來制定優(yōu)先級，并改進未來的增量。

知識領域3：干系人參與（3個子領域，9項任務）
通過建立信任的環(huán)境，協(xié)調干系人的需求和期望，用可以理解的成本和工作量來平衡好他們的要求，讓現(xiàn)在和未來的利益相關方參與進來。在項目生命周期中，促進參與和協(xié)作，提供工具來進行有效和明智的決策。

知識領域4：團隊績效（3個子領域，9項任務）
建立信任、學習、協(xié)作、解決沖突的環(huán)境，促進團隊的自組織、增強團隊成員間的聯(lián)系、建立高績效的文化。

知識領域5：適應性規(guī)劃（3個子領域，10項任務）
從項目開始到結束，基于目標、價值、風險、約束、干系人反饋、評審結果，制定并維護一個持續(xù)發(fā)展的計劃。

知識領域6：問題發(fā)現(xiàn)和解決（5項任務）
持續(xù)發(fā)現(xiàn)問題、障礙、風險；制定優(yōu)先級，在有限的時間內解決；監(jiān)控和溝通問題解決狀態(tài)；實施流程改進，防止問題再次發(fā)生。

知識領域7：持續(xù)改進（產品、流程、人員）（6項任務）
持續(xù)改進質量、效率、產品價值、流程和團隊。

ACP敏捷工具箱

《敏捷實踐指南》各章節(jié)精粹內容

1. 引論
本實踐指南適用于對于預測法和敏捷方法難以取舍的項目團隊，試圖解決快速創(chuàng)新和復雜性問題的項目團隊，以及致力于團隊改進的項目團隊。本實踐指南將提供有益的指導方針，它們將有助于項目取得成功，幫助項目團隊順利交付商業(yè)價值，滿足客戶的期望和需求。

2. 敏捷概述

2.1 可確定的工作與高度不確定的工作

項目工作包括可確定的工作與高度不確定的工作?？纱_定的工作項目具有明確的流程，它們在以往類似的項目中被證明是行之有效的。在完成設計后制造汽車、電器或建造住宅，這些都是可確定的工作的例子，其所涉及的生產領域和過程通常都很好理解，并且執(zhí)行的不確定性和風險通常較低。
新的設計、解決問題和之前未做過的工作都是探索性的。它要求主題專家攜手合作，解決問題，并創(chuàng)建解決方案。遭遇高度不確定的工作的人員包括軟件系統(tǒng)工程師、產品設計師、醫(yī)生、教師、律師和許多解決問題的工程師等。隨著可確定的工作日益實現(xiàn)自動化，項目團隊也越來越多地從事高度不確定的工作，從事這些工作就需要使用本實踐指南所述的有關技術。
高度不確定的項目變化速度快，復雜性和風險也高。這些特點可能會給傳統(tǒng)預測法帶來問題，傳統(tǒng)預測法旨在預先確定大部分需求，并通過變更請求過程控制變更。而敏捷方法的出現(xiàn)是為了在短時間內探討可行性，根據(jù)評估和反饋快速調整。

2.2 《敏捷宣言》及思維模式

一般而言，可通過兩種策略踐行敏捷價值觀和原則。一種策略是采用正規(guī)的敏捷方法，它們為特意設計，經證明可達成期望的成果。那么，在變更和裁剪之前，就需要花時間學習和理解敏捷方法。不成熟和隨意的裁剪會讓敏捷方法的效果大打折扣，從而限制了收益。(參見附件 X2 中的“裁剪考慮事項”)。

第二種策略是，以一種適合項目背景的方式對項目實踐進行變更，以便在核心價值觀或原則方面取得進展。使用時間盒創(chuàng)建功能，或者使用特定技術迭代優(yōu)化功能。在適用于特定項目背景下，考慮將一個大項目劃分為幾部分發(fā)布。實現(xiàn)有助于項目成功的變更，這些變更不必是組織的正式實踐的組成部分。_終目標不是為了敏捷而敏捷，而是為了向客戶持續(xù)交付價值流，并達成更好的商業(yè)成果。

2.3 精益與看板方法

看待精益、敏捷與看板方法三者之間關系的一種思路是，將敏捷和看板方法視為精益思想的衍生物。換言之，精益思想是一個超集，與敏捷和看板方法擁有共性。
這種共性非常相似，重點在于交付價值、尊重人、減少浪費、透明化、適應變更以及持續(xù)改善等方面。項目團隊有時會發(fā)現(xiàn)將各種方法結合起來使用更為有用，只要是對組織或團隊有效的方法，無論來源如何，都應該采納。無論使用什么方法，目標都是為了實現(xiàn)_佳結果。
看板方法受到_初的精益制造體系的啟發(fā)，專門用于知識型工作。它在 2000 年代中期出現(xiàn)，是當時非常盛行的敏捷方法的一種替代方法。
看板方法不如某些敏捷方法規(guī)范，破壞性也較小，原因在于它是原始的“原地出發(fā)”方法。在有必要或適當?shù)那闆r下，項目團隊可以相對輕松地應用看板方法，并向其他敏捷方法發(fā)展。關于看板方法的更多信息，請參見“附錄 A3 敏捷和精益框架概述”。

2.4 不確定性、風險和生命周期選擇

有些項目在項目需求、以及如何使用現(xiàn)有知識和技術滿足這些需求方面，具有很大的不確定性。
這些不確定因素可能導致大量變更和項目復雜性的提高。上述特點如圖 2-5 所示。
隨著項目不確定性的增加，返工的風險和使用不同方法的需求也會增加。為了減輕這些風險的
影響，團隊選擇的生命周期要能夠通過較少的工作增量解決項目的大量不確定性問題。
團隊可以利用較少的工作增量驗證自身的工作，并且可以對接下來的工作做出相應變更。與靜態(tài) 書面規(guī)范相比，當團隊交付小的增量時，他們能夠更快更準確地理解真正的客戶需求。

團隊可以用明確穩(wěn)定的管理要求規(guī)劃并管理項目，輕松解決各種技術挑戰(zhàn)。但是，隨著項目不確
定性的增加，變更、做無用功和返工的可能性也會隨之增加，而這不僅代價高昂，而且耗費時間。
有些團隊讓項目生命周期發(fā)生演變，以便使用迭代和增量方法。許多團隊發(fā)現(xiàn)，在探討迭代需求、更頻繁地交付增量時，團隊會更容易適應變更。由于團隊獲得反饋，這些迭代和增量方法減少了浪費和返工。這些方法應用了:

非常短的反饋循環(huán);
頻繁調整過程;
重新進行優(yōu)先級排序;
定期更新計劃;
頻繁交付；

對于涉及新穎的工具、技術、材料或應用領域的項目，這些迭代、增量和敏捷方法非常有效。 (參見第 3 章“生命周期選擇”)。它們也適用于具有以下特點的項目:

需要研究和開發(fā);
變更速度極快;
具有不明確或未知的需求、不確定性或風險;
_終目標難以描述。

通過構建一個小的增量，然后對其進行測試和評估，團隊可以在短時間內以低成本探索不確定性，降低風險，_大程度地實現(xiàn)商業(yè)價值的交付。這種不確定性可能集中于適用性和需求(正在構建的產品是否正確?);技術可行性和性能(產品是否可以采用這種方法構建?);或過程和人員(這是否為團隊工作的一種有效方式?)。以上三個特點(產品規(guī)格、生產能力和過程適用性)通常都具有高度不確定性因素。
不過，迭代和增量管理方法也有其應用局限性。當技術和需求的不確定性都很高時(圖 2-5 右上部分),項目就會極端復雜，陷入無序狀態(tài)。為了使項目盡可能可靠，需要遏制其中一個不確定性變量。

3. 生命周期選擇

項目有多種形式，也有多種實施方式。項目團隊需要認識到相關特征和方案，以選擇_可能使項目成功的方法。
本實踐指南涉及四種生命周期，分別定義如下:

預測型生命周期。這是一種更為傳統(tǒng)的方法，提前進行大量的計劃工作，然后一次性執(zhí)行;執(zhí)行是一個連續(xù)的過程。
迭代型生命周期。這種方法允許對未完成的工作進行反饋，從而改進和修改該工作。
增量型生命周期。這種方法向客戶提供各個已完成的，可能立即使用的可交付成果。
敏捷生命周期。這種方法既有迭代，也有增量，便于完善工作，頻繁交付。

3.1 項目生命周期的特征

需要注意的是，所有的項目都具有這些特征，沒有一個項目能夠完全不考慮需求、交付、變更和目標這些因素。項目的固有特征決定了其適合采用哪種生命周期。
另一種理解不同項目生命周期的方法是，使用一個連續(xù)區(qū)間，從一端的預測型周期到另一端的敏捷型周期，連續(xù)區(qū)間中間還有更多的迭代型周期或增量型周期。
第六版《PMBOK? 指南》附件 X3 圖 X3-1 將連續(xù)區(qū)間顯示為一條直線。該圖強調了從線的一端到另一端，項目特征的變化情況。另一種形象化的方法是，用一個二維正方形表示這個連續(xù)區(qū)間，如圖 3-1 所示。

沒有哪個生命周期能夠完美地適用于所有的項目。相反，每個項目都能在連續(xù)區(qū)間中找到一個點，根據(jù)其背景特征，實現(xiàn)_佳平衡。特別是，

預測型生命周期。充分利用已知和已經證明的事物。不確定性和復雜性的減少，允許項目團隊將工作分解為一系列可預測的小組。
迭代型生命周期。允許對部分完成或未完成的工作進行反饋，從而對該工作進行改進和修改。
增量型生命周期。可向客戶提供完成的可交付成果，讓客戶能夠立即使用。
敏捷生命周期。它同時利用迭代屬性和增量特征。團隊使用敏捷方法時，他們會對產品進行迭代，創(chuàng)建完成的可交付成果。團隊將獲得早期的反饋，并能提供客戶可見性、信心和對產品的控制。由于團隊可以提前發(fā)布產品，而團隊將率先交付價值_高的工作，所以項目可以更早產生投資回報。

3.1.1 預測型生命周期的特征

預測型生命周期預計會從高確定性的明確的需求、穩(wěn)定的團隊和低風險中獲益。因此，項目活動通常以順序方式執(zhí) 行，如圖 3-2 所示。
為了實現(xiàn)這種方法，團隊需要詳細的計劃，了解要交付什么以及怎樣交付。當其他潛在變更受到限制時，這些項目就會成功(例如:需求變更;項目團隊成員修改團隊交付的成果)。團隊領導的目標是盡可能減少預測型項目的變更。
團隊在項目開始時創(chuàng)建詳細的需求和計劃時，他們可以闡明各種制約因素。然后，團隊可以利用這些制約因素管理風險和成本。進而，團隊在實施詳細計劃時，他們會監(jiān)督并控制可能影響范圍、進度計劃或預算的變更。
預測型項目強調根據(jù)部門劃分的、有效的、順序的工作，并且通常不會在項目結束前交付商業(yè)價值。如果遇到變更或需求分歧，或者技術解決方案變得不再簡單明了，預測型項目就將產生意想不到的成本。
計劃始終貫穿其中
要記住的關鍵一點是，每種生命周期都有計劃要素。生命周期的不同之處并非在于計劃是否完成，而在于完成了多少計劃以及何時完成。
在連續(xù)區(qū)間的預測一端，是計劃驅動著工作。有多少計劃，就有多少提前執(zhí)行的可能性。盡可能詳細地定義需求。團隊估算何時能夠交付可交付成果，并全面開展采購工作。
在迭代方法中，也計劃了原型和驗證，但是輸出的目的是修改一開始所創(chuàng)建的計劃。對未完成的工作的早期評審將有助于未來的項目工作。
與此同時，增量方法計劃交付整個項目后續(xù)部分。團隊可以提前計劃可交付成果的若干次連續(xù)交付，或者一次只計劃交付一個?？山桓冻晒麨槲磥淼捻椖抗ぷ魈峁┝讼嚓P信息。
敏捷項目也有計劃。主要區(qū)別在于，通過對頻繁交付的可交付成果的評審，團隊將能獲得更多的信息，從而在此基礎上進行計劃和重新計劃。無論采用哪種項目生命周期，項目都需要計劃。

3.1.2 迭代型生命周期的特征

迭代型生命周期通過連續(xù)的原型或概念驗證來改進產品或成果。每一個新的原型都能帶來新的相關方新的反饋和團隊見解。然后，團隊在下一周期重復一個或多個項目活動，在其中納入新的信息。團隊可能會在長達數(shù)周時間的一個特定迭代中使用時間盒，集中各種見解，然后根據(jù)這些見解對活動進行返工。這樣，迭代有利于識別和減少項目的不確定性。
當項目復雜性高、變更頻繁或當項目范圍受到相關方對所需_終產品的不同觀點的支配時，采用迭代型生命周期會有優(yōu)勢。迭代型生命周期可能需要更長的時間，因為它是為學習而優(yōu)化，而不是為交付速度而優(yōu)化。
圖 3-3 顯示迭代型項目生命周期的一個產品交付的某些要素。

3.1.3 增量型生命周期的特征

有些項目優(yōu)化是為了加快交付速度。許多企業(yè)和項目無法等待所有的事情全部完成;這種情況下，客戶愿意接受整個解決方案的一個部分。這種少量可交付成果的頻繁交付稱為增量型生命周期(參見圖 3-4)

3.1.4 敏捷生命周期的特征

在敏捷環(huán)境中，團隊預料需求會發(fā)生變更。迭代和增量方法能夠提供反饋，以便改善項目下一部分的計劃。不過，在敏捷項目中，增量交付會發(fā)現(xiàn)隱藏或誤解的需求。圖 3-5 顯示了實現(xiàn)增量交付的兩種可能的方法，這樣將便于項目與客戶需求保持一致，并根據(jù)需要進行調整。

在基于迭代的敏捷中，團隊以迭代(相等持續(xù)時間的時間盒)形式交付完整的功能。團隊集中于_重要的功能，作為一個團隊合作完成其工作。然后，團隊再集中于下一項_重要的功能，并合作完成其工作。團隊可決定一次進行若干功能的開發(fā)工作，但團隊不會同時完成所有的迭代工作(即團隊不會在完成全部分析等工作后再解決所有需求)。
對于建立在流程基礎上的敏捷方法，團隊將根據(jù)自身能力，從待辦事項列表中提取若干功能開始工作，而不是按照基于迭代的進度計劃開始工作。團隊定義任務板各列的工作流，并管理各列的進行中的工作。完成不同功能所花費的時間可能有所不同。團隊讓進行中的工作的規(guī)模盡量小，以便盡早發(fā)現(xiàn)問題，并在需要變更時減少返工。無需利用迭代定義計劃和審核點，而由團隊和業(yè)務相關方決定規(guī)劃、產品評審與回顧的_適當?shù)倪M度計劃。
敏捷生命周期是符合《敏捷宣言》原則的周期。特別是，客戶滿意度將隨著有價值產品的早期交付和持續(xù)交付不斷提升。此外，功能性的、提供價值的增量可交付成果，是衡量進展的主要尺度。為了適應更頻繁的變更，和更頻繁地交付項目價值，敏捷生命周期結合了迭代和增量方法。

3.1.5 敏捷適用性篩選器

有各種評估模型可用來幫助確定使用敏捷方法的適合性或差距。這些模型評估項目和具有適應性和適用性的組織因素，然后提供分數(shù)表明一致性或潛在風險領域。附件 X3 綜合提供了各種流行的評估模型，它們可用作敏捷適用性篩選器。

3.2 混合敏捷方法

敏捷團隊很少將其實踐局限于一種敏捷方法。每個項目背景都有其各自的獨特性，比如團隊成員技能和背景的不同組合;開發(fā)中的產品的各個組成部分;以及工作環(huán)境中的年齡、規(guī)模、關鍵性、復雜性和監(jiān)管制約因素等。
敏捷框架并不是針對團隊定制的。為了定期交付價值，團隊可能需要對實踐進行裁剪。通常，團隊都會實踐各自特殊的敏捷組合，即便他們使用一個特定的框架作為起點也不例外。
協(xié)調方法
裁剪敏捷框架的一個例子是，一個廣泛使用的常見協(xié)調方法涉及到協(xié)調使用 Scrum 框架、看板方法和極限編程 (XP) 方法的要素。Scrum 為產品待辦事項列表、產品負責人、Scrum 主管以及跨職能開發(fā)團隊的使用提供指導，包括沖刺計劃、每日例會、沖刺評審和沖刺回顧會議。看板面板幫助團隊進一步提高效率，方法是將工作流可視化、使障礙更容易被察覺，以及通過調整在制品限制來實現(xiàn)流程管理。此外，受極限編程啟發(fā)的工程實踐，如使用故事卡、持續(xù)集成、重構、自動化測試和測試驅動開發(fā)，將進一步提高敏捷團隊的效力?？傊c孤立采用各種實踐相比，協(xié)調這些不同來源的實踐將產生更好的協(xié)同成果。

3.3 影響裁剪的項目因素

有時，為了更好地配合，根據(jù)項目屬性對方法進行裁剪。表 3-2 列出一些要考慮的項目因素和裁剪方案。

4. 實施敏捷:創(chuàng)建敏捷環(huán)境

4.1 從敏捷思維模式開始

使用敏捷方法管理項目，要求項目團隊采用敏捷思維模式。以下問題的答案將有助于制定實施策略:

項目團隊如何以敏捷方式行動?
為了使下一交付周期受益，團隊需要快速交付哪些成果并獲得早期反饋?
團隊如何以一種透明的方式行動?
為了專注于高優(yōu)先級的項目，可以避免哪些工作?
仆人式領導對團隊達成目標有何益處?

4.2 仆人式領導為團隊賦權

敏捷方法強調，仆人式領導是一種為團隊賦權的方法。仆人式領導是通過對團隊服務來領導團隊的實踐，它注重理解和關注團隊成員的需要和發(fā)展，旨在使團隊盡可能達到_高績效。
仆人式領導的作用是促進團隊發(fā)現(xiàn)和定義敏捷。仆人式領導實踐并傳播敏捷。仆人式領導按照以下順序從事項目工作:

目的。與團隊一起定義“為什么”或目的，以便他們能圍繞項目目標進行合作互動。整個團隊在項目層面而不是在人員層面優(yōu)化。
人員。目標確立后，鼓勵團隊創(chuàng)造一個人人都能成功的環(huán)境。要求每個團隊成員在項目工作中做出貢獻。
過程。不要計劃遵循“完美”的敏捷過程，而是要注重結果。如果跨職能團隊能夠常常交付完成的價值并反思產品和過程，團隊就是敏捷的。團隊將其過程稱作什么并不重要。

以下仆人式領導的特征讓項目領導變得更加敏捷，促進團隊的成功:

提升自我意識;
傾聽;
為團隊服務;
幫助他人成長;
引導與控制;
促進安全、尊重與信任;
促進他人精力和才智提升。

仆人式領導并不是敏捷所獨有的。但經過實踐，仆人式領導通常能了解到仆人式領導是怎樣融入敏捷思維模式和價值觀的。
領導在發(fā)展自身仆人式領導力或促進技巧后，他們就更愿意成為敏捷踐行者。因此，仆人式領導可以幫助他們的團隊通過合作更快地交付價值。
成功的敏捷團隊信奉成長思維模式，團隊成員自己能夠學到新技能。如果團隊和仆人式領導都相信自己能夠學習，那么所有人的能力都能得到提高。

4.2.1 仆人式領導的職責

仆人式領導通過管理關系，在團隊內和組織中建立溝通與協(xié)作。這些關系可以幫助領導在組織中得心應手地為團隊提供支持。這種支持有助于消除障礙，促進團隊理順過程。由于仆人式領導了解敏捷，在應用具體方法時踐行敏捷，因而他們能幫助滿足團隊的需要。

4.2.1.1 仆人式領導的促進作用

項目經理成為仆人式領導時，工作重點就會從“管理協(xié)調”轉向“促進合作”。促進者將幫助每個人各盡所能地思考和工作。促進者鼓勵團隊參與、理解，并對團隊輸出共同承擔責任。促進者幫助團隊創(chuàng)建可接受的解決方案。
仆人式領導促進團隊內部和團隊之間的合作與對話。例如，仆人式領導在團隊內部和團隊之間幫助發(fā)現(xiàn)瓶頸問題，并進行相應溝通。然后，團隊將解決這些瓶頸問題。
此外，促進者還鼓勵大家通過交互式會議、非正式對話和知識共享展開協(xié)作。仆人式領導要通過成為公正的搭橋者和教練來做到這一點，而不是代替他責任人做出決策。

4.2.1.2 仆人式領導消除組織障礙

《敏捷宣言》的_個價值觀關乎個人與過程和工具的交互。對仆人式領導而言，更好的職責是認真審視那些阻礙團隊敏捷或組織敏捷的過程，并努力使其合理化。例如，如果一個部門需要大量文檔，仆人式領導的角色就能發(fā)揮作用，他們可以與部門合作審查所需的文檔，就敏捷交付如何滿足這些需求達成共識提供協(xié)助，并對所需的文檔數(shù)量進行評估，從而使團隊能夠將時間更多地用于提供有價值的產品，而不是創(chuàng)建詳盡的文檔。
仆人式領導還應該關注其他冗長的過程，這些過程往往造成瓶頸問題，阻礙團隊或組織的敏捷性。可能需要處理的過程或部門的例子包括，財務部門、變更控制委員會或審計部門。仆人式領導可以與他人攜手合作，共同質疑和審核他們的過程，為敏捷團隊和領導提供支持。例如，對團隊而言，每兩周交付一個工作產品僅僅是為了讓產品進入隊列或過程，而冗長的發(fā)布過程卻可能需要 6 周或更長時間，這樣做有什么好處呢?太多的組織都有這些“瓶頸”過程，正是它們阻礙了團隊快速交付有價值的產品或服務。仆人式領導有能力改變或消除這些組織障礙，為交付團隊提供支持。

4.2.2 項目經理在敏捷環(huán)境中的角色

項目經理在敏捷項目中的角色有些是未知的，原因是許多敏捷框架和方法都不涉及項目經理的角色。一些敏捷實踐者認為，并不需要項目經理的角色，因為自組織團隊承擔了項目經理之前的職責。不過，務實的敏捷實踐者和組織認識到，在許多情況下，項目經理都能夠創(chuàng)造重要的價值。關鍵的區(qū)別在于，他們的角色和職責看起來有些不同。

4.2.3 項目經理應用仆人式領導

第六版《PMBOK? 指南》將項目經理定義為“由執(zhí)行組織委派，領導團隊實現(xiàn)項目目標的個人”。
許多項目經理已經習慣于作為項目的協(xié)調中心，負責跟蹤團隊的狀態(tài)，并向組織中的其他成員反映。當項目被分解為孤立的功能時，這種方法沒有問題。
然而，對于高不確定性項目，項目的復雜性是一個人所無法管理的。而跨職能團隊既能協(xié)調自身的工作，還能與業(yè)務代表(產品負責人)開展合作。
從事敏捷項目工作時，項目經理的角色就會從團隊的中心轉變成為團隊和管理人員提供服務。在敏捷環(huán)境中，項目經理充當仆人式領導，其工作重點轉變?yōu)橐龑枰獛椭娜?，促進團隊的合作，保持與相關方的需要一致。作為仆人式領導，項目經理要鼓勵將責任分配給團隊成員，分配給那些掌握完成任務所需知識的人。

4.3 團隊構成

《敏捷宣言》的價值觀和原則的一個核心宗旨是強調個人和交互的重要性。敏捷優(yōu)化了價值流，強調了向客戶快速交付功能，而不是怎樣“用”人。
團隊在考慮如何優(yōu)化價值流時，以下好處是顯而易見的:

人員更有可能合作。
團隊更快地完成有價值的工作。
由于不從事多任務，也不必重新建立環(huán)境，團隊減少了時間浪費。

4.3.1 敏捷團隊

敏捷團隊注重快速開發(fā)產品，以便能獲得反饋。在實踐中，_有效的敏捷團隊往往由三到九個成員組成。理想情況下，敏捷團隊應該集中在一個團隊工作場所工作。團隊成員 100% 為專職成員。敏捷鼓勵自我管理團隊，由團隊成員決定誰執(zhí)行下一階段定義的范圍內的工作。敏捷團隊與仆人式領導一起茁壯成長。領導支持團隊的工作方法。
跨職能敏捷團隊頻繁創(chuàng)造功能性產品增量。這是因為團隊集體對工作負責并共同擁有完成工作所需的所有必要技能。
無論整體的敏捷方法是什么，團隊越是限制其在制品，團隊成員就越有可能通過合作來加快整個團隊的工作。在成功的敏捷團隊中，團隊成員在工作中以各種方式開展合作(如結對、群集、群體開發(fā))，因而，他們會協(xié)同工作，而不會落入迷你瀑布的陷阱中。團隊在給定時間解決所有的需求，然后試圖完成所有的設計，繼而又去完成所有的構建，就會發(fā)生迷你瀑布的情況。使用這個場景，在構建中或構建后測試中的某一時刻，團隊可能會意識到，原先的假設已經不再有效。這種情況下，團隊解決所有的需求根本是在浪費時間。相反，當團隊成員合作打造全部功能中的少量功能時，隨著工作的推進和交付少量已完成的功能，他們也在不斷學習。
敏捷項目得益于項目團隊結構，這種結構能改善團隊內部和團隊之間的合作。圖 4-1 展示了團隊成員如何通過合作提高工作效率、促進創(chuàng)造性地解決問題。

4.3.2 敏捷的角色

敏捷團隊中有三種常見的角色:

跨職能團隊成員;
產品負責人;
團隊促進者。
表 4-2 描述了這些團隊角色。

4.3.3 通才型專家

敏捷團隊是跨職能的，但其人員往往不會一開始就做到這樣。不過，許多成功的敏捷團隊都由通才型專家組成，他們也稱為 T 型人才。
這意味著這些團隊成員在具備一項擅長的專業(yè)化技能的同時，還擁有多種技能的工作經驗，而不是單一的專業(yè)化。由于密切協(xié)作和自我組織，敏捷團隊成員才能夠敏捷開發(fā)并迅速完成工作，而這就需要使互相幫助成為常態(tài)。敏捷團隊成員都要致力于培養(yǎng)這樣的特質。
一個人的能力大小無關緊要。如果給團隊其他成員帶來瓶頸問題，集中于某一個人的能力甚至是有害的。團隊的目的是優(yōu) 化已完成的工作，并獲得反饋。
如果客戶希望獲得好的結果，如快速交付功能并且質量優(yōu) 良，那么團隊就不能僅僅為了盡可能有效利用資源而構建專門的角色。團隊的目標是提高過程效率，優(yōu)化整個團隊的產能。團隊規(guī)模小會促進團隊的合作。產品負責人的工作是確保團隊從事_高價值的工作。

4.3.4 團隊結構

許多行業(yè)的團隊都會采用敏捷原則和實踐。他們將人員組織到跨職能團隊中，迭代開發(fā)工作產品。
有些組織已經能夠建立集中辦公的跨職能團隊;還有組織有不同的情況。有些組織并不是所有團隊成員都為集中辦公，而是擁有分布式或分散式團隊。分布式團隊可以在不同地點擁有多個跨職能團隊。分散式團隊可能會讓各團隊成員分別在不同的地點工作，或在辦公室，或在家里。鑒于通信成本的增加，這些安排并非理想，但它們仍然是可行的。

4.3.5 專職小組成員

如果團隊成員并非 100% 為團隊專職工作，會有什么情況發(fā)生?遺憾的是，這種情況雖然并不理想，但有時卻無法避免。
讓一個人在團隊中只投入 25% 或 50% 的能力，這帶來的關鍵問題是，他們會進行多任務處理和任務切換。多任務處理會降低團隊工作的產出，并影響團隊預測交付能力的一致性。
任務切換時，人員工作效率的損失在 20% 到 40% 之間。隨著任務數(shù)量的增加，效率損失會呈指數(shù)級增長。
當一個人在兩個項目之間進行多任務切換時，他投入到每個項目上的精力并非各占 50%。相反，由于存在任務切換成本，他在每個項目上的投入降低到 20% 到 40%之間。
人們在一心多用的時候更容易犯錯誤。任務切換消耗工作記憶，人們在多任務處理時不太可能記住相應工作的背景。
當團隊中所有的人都被分配到一個項目時，他們能夠作為一個團隊持續(xù)協(xié)作，從而使每個人的工作更加有效。

4.3.6 團隊工作場所

團隊需要一個工作場所，他們可以一起工作，了解他們作為團隊的狀態(tài)，并進行協(xié)作。有些敏捷團隊的所有成員都集中在一個房間里工作。有些團隊擁有一個團隊工作場所用于開例會以及張貼各種圖表，但團隊成員分別在各自的小隔間或辦公室里獨立工作。
隨著各公司邁向開放、協(xié)作的工作環(huán)境，組織也必須為需要不間斷時間來思考和工作的員工創(chuàng) 造安靜的空間。因此，各公司紛紛設計各自的辦公室，以平衡公共和社交區(qū)域(有時被稱為“公共區(qū)”)與個人工作不被打擾的安靜區(qū)域或私人區(qū)域。
擁有在不同地點工作的成員時，團隊會決定他們各自的工作場所有多少是虛擬的，多少是實際的。諸如文檔共享、視頻會議和其他虛擬協(xié)作工具等技術可以幫助人員實現(xiàn)遠程協(xié)作。
在不同地點工作的團隊成員需要虛擬的工作空間。另外，要考慮讓團隊成員定期聚集一堂，以便建立信任，學習怎樣開展合作。
分散式團隊管理溝通的一些技術包括魚缸窗口和遠程結對:

通過在團隊分布的各個地點之間建立長期視頻會議鏈接，創(chuàng)建一個魚缸窗口。每天工作開始時，人們打開鏈接，工作結束時，關閉鏈接。通過這種方式，人員可以自然地看到彼此并進行互動，減少了身處不同地點工作所固有的協(xié)作滯后問題。
通過使用虛擬會議工具來共享屏幕，包括語音和視頻鏈接，建立遠程結對。只要考慮了時區(qū)差異因素，這種方法幾乎和面對面的結對一樣有效。

4.3.7 克服組織孤島

組建敏捷團隊的_好開端是構建一個擁有基本信任和安全的工作環(huán)境，以此確保所有團隊成員都有平等的話語權，他們的意見都能被聽到并得到考慮。這一點再加上構建敏捷思維模式，都是潛在的成功因素，在此基礎上，所有其他挑戰(zhàn)和風險都能夠化解。
孤島組織往往給跨職能敏捷團隊的組建帶來重重障礙。需要構建跨職能團隊的團隊成員通常需要向不同的管理人員報告，管理人員會采用不同的標準衡量他們的績效。管理人員需要關注的不是資源利用效率，而是過程效率(和基于團隊的指標)。
為克服組織孤島問題，就要與團隊成員的不同管理者合作，讓他們?yōu)榭缏毮軋F隊安排必要的專職人員。這樣不僅能建立團隊協(xié)同，而且能讓組織看到怎樣用人才能優(yōu)化正在進行中的項目和產品。

5. 實施敏捷：在敏捷環(huán)境中交付

5.1 項目章程和團隊章程

每個項目都需要一個項目章程，這樣項目團隊就能了解項目之所以重要的原因、團隊的前進方向以及項目的目標。不過，對于團隊而言，僅有項目章程還不夠。敏捷團隊需要有團隊規(guī)范以及對一起工作方式的理解。這種情況下，團隊可能需要一個團隊章程。
制定章程的過程能幫助團隊學習如何一起工作，怎樣圍繞項目協(xié)作。
對于敏捷項目而言，團隊至少還需要項目愿景或目標，以及一組清晰的工作協(xié)議。敏捷項目章程要回答以下問題:

我們?yōu)槭裁匆鲞@個項目?這是項目愿景。
誰會從中受益?如何受益?這可能是項目愿景和/或項目目標的一部分。
對此項目而言，達到哪些條件才意味著項目完成?這些是項目的發(fā)布標準。
我們將怎樣合作?這說明預期的工作流。
仆人式領導可以促進章程的制定過程。團隊可以通過一起工作實現(xiàn)協(xié)作，而制定項目章程是一種很好的開始工作的的方式。此外，團隊成員可能希望通過協(xié)作了解他們將如何一起工作。
只要團隊知道如何一起工作，制定章程就不需要一個正式的過程。有些團隊可以從團隊制定章程的過程中受益。下面是對團隊成員制定章程的一些建議，可以將其作為制定團隊社會契約的基礎:
團隊價值觀，例如可持續(xù)的開發(fā)速度和核心工作時間;
工作協(xié)議，例如“就緒”如何定義，這是團隊可以接受工作的前提;“完成”如何定義，這樣
團隊才能一致地判斷完整性;考慮時間盒;或使用工作過程限制;
基本規(guī)則，例如有關一個人在會議上發(fā)言的規(guī)定;
團隊規(guī)范，例如團隊如何對待會議時間。
仆人式領導可以與團隊一起決定處理其他行為。
請記住，團隊的社會契約，即團隊章程，將規(guī)定團隊成員之間彼此互動的方式。團隊章程的目標是創(chuàng)建一個敏捷的環(huán)境，在這個環(huán)境中，團隊成員可以發(fā)揮他們作為團隊的_大能力。

5.2 常見敏捷實踐

5.2.1 回顧

回顧是_重要的一個實踐，原因是它能讓團隊學習、改進和調整其過程。
回顧可以幫助團隊從之前的產品開發(fā)工作及其過程中學習?！睹艚菪浴繁澈蟮脑瓌t之一是:“團隊要定期反省如何能夠做到更加有效，并相應地調整團隊的行為。”
許多團隊使用迭代，尤其是為期兩周的迭代，因為迭代在_后會提示進行演示和回顧。不過，團隊回顧并不需要迭代。團隊成員可以決定在這些關鍵時刻進行回顧:

當團隊完成一個發(fā)布或者加入一些功能時。這不一定是一個巨大的增量。它可以是任何發(fā)布，無論它有多小。
自上次回顧以來，又過了幾周時間。
當團隊出現(xiàn)問題時，以及團隊協(xié)作完成工作不順暢時。
當團隊達到任何其他里程碑時。
團隊可以通過分配足夠的時間學習受益，無論是在項目中間回顧，還是在項目結束時回顧。團隊需要了解他們的工作產品和工作過程。例如，有些團隊在完成工作時遇到困難。團隊可以計劃用充足的時間組織回顧，以此收集數(shù)據(jù)、處理數(shù)據(jù)、再決定之后要嘗試的實驗做法。
首要的是，回顧并不是責備;回顧是讓團隊從以前的工作中學習并做出小的改進。
回顧針對定性的(人的感覺)和定量的(衡量指標)數(shù)據(jù)，然后利用這些數(shù)據(jù)找到根源，設計對策，并制定行動計劃。項目團隊可以采取許多行動事項來消除障礙。
考慮限制行動事項的數(shù)量，使團隊在即將進行的迭代或工作期間有能力改進。嘗試一次改進太多的事情卻沒有完成其中任何一件，比計劃完成較少的事情并成功全部完成要糟糕得多。然后，在時間允許的情況下，團隊可以進行列表中的下一個改進。團隊選擇改進時，要決定如何衡量結果。然后，在下一段時間內要衡量結果，以驗證每個改進成功與否。
來自團隊的一位促進者引導團隊通過一個活動對所有改進事項的重要性進行排序。完成對改進事項的排序后，團隊為下一次迭代選擇合適的數(shù)量(或者在流程基礎上增加工作)。

5.2.2 待辦事項列表編制

待辦事項列表是所有工作的有序列表，它以故事形式呈現(xiàn)給團隊。工作開始之前，不需要為整個項目創(chuàng)建所有的故事，只需要了解_個發(fā)布的主要內容正確即可，然后就可以為下一個迭代開發(fā) 足夠的項目。
產品負責人(或產品負責人價值團隊，包括產品經理和產品領域的所有相關產品負責人)可能會制作一個產品路線圖，以顯示預期的可交付成果序列。產品負責人根據(jù)團隊的實際成果重新規(guī) 劃路線圖。(關于路線圖的示例請參見附件 X3“敏捷適用性篩選工具”。)

5.2.3 待辦事項列表的細化

在基于迭代的敏捷中，產品負責人往往在迭代中期的一次或多次會議中與團隊合作，為即將進行的迭代準備一些故事。這些會議的目的是細化足夠的故事，讓團隊了解故事的內容，以及故事之間的相互關系。
至于細化過程應該有多長時間，還沒有達成共識。有一個連續(xù)區(qū)間:

基于流程的敏捷的即時細化。團隊將下一張卡片從待辦事項列表中拿出來討論。
許多基于迭代的敏捷團隊在兩周的迭代中用 1 小時的時間盒討論。(團隊選擇一個迭代持續(xù) 時間，為他們提供足夠頻繁的反饋。)
基于迭代的敏捷團隊的多次細化討論。團隊可以在陌生的產品、產品領域或問題領域使用這一技巧。
細化會議上，產品負責人可以向團隊介紹故事的創(chuàng)意，讓團隊了解故事中潛在的挑戰(zhàn)或問題。如果產品負責人不確定依賴關系，還可以請求團隊對相應功能進行刺探，以了解風險。
產品負責人有很多方法處理待辦事項列表的細化準備與會議，其中包括:
鼓勵團隊在開發(fā)人員、測試人員、業(yè)務分析人員和產品負責人三方面開展合作，一起討論和撰寫故事。
把整個故事的概念呈現(xiàn)給團隊。團隊進行討論，并根據(jù)需要將其細化為許多故事。
與團隊一起尋找各種方法探索和撰寫故事，確保所有的故事都足夠小，以便團隊能源源不斷地
交付完成的工作?？紤]每天至少完成一個故事。
團隊通常有一個目標，就是每周用不超過 1 小時的時間來為下一批工作細化故事。團隊希望把時間盡可能花在工作上，而不是計劃上。如果團隊需要每周花 1 小時以上的時間來細化故事，那么，產品負責人可能會過度準備，或者團隊可能缺乏評估和細化工作所需的一些關鍵技能。

5.2.4 每日站會

團隊成員利用每日站會對彼此做出小的_，發(fā)現(xiàn)問題，并確保團隊工作順利進行。
為每日站會規(guī)定時間盒，不超出 15 分鐘。團隊以某種方式“過一下”看板或任務板，而團隊中的任何人都可以主持站會。
在基于迭代的敏捷中，每個人都輪流回答下列問題:

上次站會以來我都完成了什么?
從現(xiàn)在到下一次站會，我計劃完成什么?
我的障礙(或風險或問題)是什么?
從這樣的問題得出的答案能夠讓團隊自我組織，并讓團隊成員為完成之前和整個迭代中_完成的工作承擔彼此的責任。
基于流程的敏捷有一種不同的方法，可以將注意力集中在團隊的產出上。團隊從右到左對看板進行評估。問題包括:
我們還需要做些什么來推進這一工作?
有人在做看板上所沒有的事情嗎? uu作為一個團隊，我們需要完成什么?
工作流程是否存在瓶頸或阻礙?
站會中常見的一個反模式是，站會變成了狀態(tài)報告會議。傳統(tǒng)上在預測環(huán)境中工作的團隊可能傾向于采用這種反模式，因為他們習慣于報告狀態(tài)。
另一個典型的反模式是，當問題變得明顯時，團隊才開始解決問題。站會是為了發(fā)現(xiàn)存在問題，而不是解決它們。將問題添加到停車場區(qū)，然后創(chuàng)建另一次會議，它可以在站會之后立即召開，并在會上解決問題。
團隊可以舉辦自己的站會。只要體現(xiàn)了團隊工作需要的密切合作，進行順利，站會便會非常有用。要針對團隊何時需要站會、站會是否有效等問題有意識地做出決定。

5.2.5 展示/評審

當團隊以用戶故事的形式完成特定功能時，團隊會定期展示工作產品?？催^展示后，產品負責人接受或拒絕故事。
在基于迭代的敏捷中，團隊在迭代結束時展示所有已完成的工作項。在基于流程的敏捷中，團隊在需要時展示完成的工作，通常是當完成的功能累積到足以構成一個連貫組合時。團隊，包括產品負責人在內，都需要反饋來決定何時需要產品反饋。
一般的指導方針是，每兩周至少展示一次團隊的工作產品。這種頻率對于大多數(shù)團隊來說是足夠的，這樣，團隊成員就可以得到反饋，防止他們朝著錯誤的方向前進。這種頻率也足夠頻繁，讓團隊可以保持產品開發(fā)足夠清晰，按照自己希望或需要的頻率構建一個完整的產品。
使項目敏捷的一個基本要素是頻繁地交付工作產品。一個沒有展示或發(fā)布的團隊，其學習的速度不會快，并且很可能并未采用敏捷技術。團隊可能需要額外的引導來_頻繁的交付。

5.2.6 規(guī)劃基于迭代的敏捷

不同團隊的能力各不相同。不同產品負責人的典型故事大小也各不相同。團隊應考慮自身故事大小，避免提交更多的故事，而超出團隊在一個迭代中所能完成工作的能力。
產品負責人了解，當人員不可用時(例如，公共假期，度假期間，或阻止人員參加下一組工作的任何事情)，團隊能力降低。團隊將無法完成與前一時期相同的工作量。在能力降低的情況下，團隊只會計劃相應能力能夠完成的工作。
團隊估算能夠完成的工作，這也是一種能力的衡量(示例參見 4.10 節(jié))。團隊不能 100% 確定自己能交付什么，因為他們無法知道意外情況。當產品負責人拆分故事使其變小時，團隊看到的是產品的完成進度，團隊就會知道他們將來能夠做什么。
敏捷團隊在一個工作塊中不會只計劃一次。相反，敏捷團隊會開始計劃一點，交付、學習，然后在一個持續(xù)的循環(huán)中重新規(guī)劃更多的東西。

5.2.7 幫助團隊交付價值的執(zhí)行實踐

如果團隊不重視質量，很快就會無法快速發(fā)布任何東西。下面的技術實踐中，很多都來自于極限編程，它們可以幫助團隊以_快的速度交付:

持續(xù)集成。無論產品如何，都要頻繁地將工作集成到整體中，然后再進行重新測試，以確定整個產品仍然按照預期工作。
在不同層面測試。對端到端信息使用系統(tǒng)級測試，對構建塊使用單元測試。在兩者之間，了解是否需要進行集成測試，以及在何處進行測試。團隊發(fā)現(xiàn)冒煙測試有助于測試工作產品是否良好。團隊發(fā)現(xiàn)，決定何時以及對哪些產品運行回歸測試，可以幫助他們在維護產品質量的同時，良好地構建性能。敏捷團隊非常偏愛自動化測試，因此他們可以借此構建和保持交付的勢頭。
驗收測試驅動開發(fā) (ATDD)。在 ATDD 中，整個團隊聚集一堂討論工作產品的驗收標準。然后，團隊創(chuàng)建測試，這讓團隊能夠編寫足夠的代碼，進行自動化測試，滿足標準要求。對于非軟件項目，要考慮怎樣在團隊完成大量價值時對工作進行測試。
測試驅動開發(fā) (TDD) 和行為驅動開發(fā) (BDD)。在編寫/創(chuàng)建產品之前編寫自動化測試，實際上可以幫助人員設計產品，防范產品錯誤。對于非軟件項目，要考慮如何通過“測試驅動”團隊的設計。硬件和機械類項目經常使用模擬進行設計的中間測試。
刺探(時間盒研究或實驗)。刺探對學習很有用，可以在諸如評估、驗收標準定義以及通過產品了解用戶行為的流程中使用。在團隊需要學習一些關鍵技術或功能要素時，刺探會很有幫助。

5.2.8 迭代和增量如何幫助交付工作產品

迭代可以幫助團隊為交付和多種反饋創(chuàng)建一個節(jié)奏。團隊會為交付和反饋創(chuàng)建增量。交付的_ 部分是一次演示。團隊會收到關于產品的外觀和運行方式的反饋。團隊成員回顧如何檢查和調整有關過程以取得成功。
演示或評審是敏捷項目流程的必要組成部分。為團隊的交付節(jié)奏安排適當?shù)难菔尽?/p>

5.3 解決敏捷項目的挑戰(zhàn)

出于解決具有高變化率、不確定性和復雜性的項目相關問題的需要，敏捷方法應運而生。由于這些原因，敏捷方法包含了各種各樣的工具和技術，用于處理預測法中出現(xiàn)的問題。參見表 5-1.

5.4 敏捷項目的衡量指標

過渡到敏捷意味著要使用不同的衡量指標。使用敏捷意味著要審視對團隊和管理層都很重要的新指標。這些衡量指標很重要，因為它們關注的是客戶價值。
狀態(tài)報告的一個問題是，團隊預測完成或使用交通燈狀態(tài)來描述項目的能力。例如，項目領導將項目描述為“90% 完成”。此時，團隊正試圖將一個個片段集成到一個產品中。團隊發(fā)現(xiàn)，有缺少的需求或者意外出現(xiàn)，或是產品沒有按照他們的想法集成。
項目只是完成了一半，而交通燈狀態(tài)報告并未反映項目真實的狀態(tài)。項目團隊往往認識到，他們還需要同樣長的時間才能完成項目的剩余部分。太多的項目存在這種情況:由于發(fā)現(xiàn)了問題，團隊才認識到，自己_多只完成了 10% 的工作。
預測型衡量指標的問題在于，它們往往并不反映真實的情況。往往直到發(fā)布日期前 1 個月，項目狀態(tài)綠燈一直是亮的;這種項目有時被稱為西瓜項目(外面綠，里面紅)。項目狀態(tài)燈經常會變成紅色，似乎沒有任何警告，因為直到發(fā)布日期前 1 個月，才會得到關于項目的經驗數(shù)據(jù)。
敏捷項目的衡量指標包含有意義的信息，這些信息提供了歷史記錄，因為敏捷項目要定期交付價值(完成的工作)。項目團隊可以利用這些數(shù)據(jù)改進預測和決策。
替代衡量指標(如完成百分比)不如經驗指標(如已完成功能)更有用。有關價值管理的更多信息，請參見 4.10 節(jié)。敏捷幫助團隊發(fā)現(xiàn)問題和難題，以便團隊能夠診斷和解決問題。
除了定量指標之外，團隊還可以考慮收集定性衡量指標。其中一些定性衡量指標側重于團隊選擇的實踐，評估團隊使用這些實踐的情況，例如，對交付功能的業(yè)務滿意度、團隊的士氣;團隊希望跟蹤的任何東西等都是定性衡量指標。

5.4.1 敏捷團隊的衡量結果

敏捷傾向于使用基于經驗和價值的衡量指標，而不是預測型衡量指標。敏捷衡量團隊所交付的成果，而不是團隊預測將交付的成果。
對于一個習慣于掌握項目基準、估算的掙值和投資回報率 (ROI) 的團隊，可能會對實施一個項目而不是管理一個基準感到茫然。敏捷是基于對客戶有可見價值的工作產品。
基準通常是嘗試預測的產物。在敏捷中，團隊的估算_ 多限于未來幾周時間。在敏捷中，如果團隊工作的可變性不高，如果團隊成員沒有從事多任務，則團隊的能力就會變得穩(wěn)定。這樣才能對未來幾周做出更好的預測。
完成迭代或流程中的工作后，團隊就可以進行重新規(guī)劃。敏捷并不能創(chuàng)造出更多的工作能力。然而，有證據(jù)表明，工作量越少，人員就越有可能交付。
與其他知識型工作一樣，軟件產品開發(fā)關乎在交付價值的同時進行學習。在項目的設計部分，硬件開發(fā)和機械開發(fā)是相似的。學習的過程是通過實驗，交付微小的價值增量，并獲得對目前已完成工作的反饋。其他許多產品的開發(fā)項目也包括學習。
項目發(fā)起人通常想知道項目什么時候能夠完成。一旦團隊建立了穩(wěn)定的速度(每個迭代的故事或故事點的平均數(shù)量) 或平均周期時間，團隊就能夠預測項目將花費多長時間。
舉例來說，如果團隊平均每個迭代有 50 個故事點，而團隊估算還剩下大約 500 個點，于是，團隊估算，還剩下大約 10 個迭代。隨著產品負責人對剩余的故事進行細化，團隊對估算進行細化，項目估算雖然可能有升有降，但團隊卻能提供一個估算。
如果團隊平均完成每個故事的周期為三天，還有 30 個故事要完成，那么團隊將需要 90 個剩余工作日，大約 4 到 5 個月。
用颶風圖反映估算的可變性，也可使用發(fā)起人能夠理解的其他一些可變性衡量方法。
由于學習是項目的重要組成部分，因而，團隊需要在平衡不確定性的同時為客戶提供價值。團隊要規(guī)劃項目要完成的下一個小部分。團隊報告經驗數(shù)據(jù)，并重新規(guī)劃其他小的增量，以此管理項目的不確定性。
某些基于迭代的項目使用燃盡圖查看項目隨時間的進展情況。圖 5-1 顯示了一個燃盡圖的例子，其中，團隊計劃交付 37 個故事點。故事點對需求或故事的相關工作、風險和復雜性進行評估。許多敏捷團隊使用故事點估算工作量。燃盡圖中的虛線表示計劃。圖 5-1 中，團隊可以看到，在第 3 天他們面臨交付的風險。

某些項目團隊更喜歡用燃起圖。如圖 5-2 所示的燃起圖中的數(shù)據(jù)與圖 5-1 相同。

燃起圖顯示已完成的工作。圖 5-1 和圖 5-2 都是基于相同的數(shù)據(jù)，但分別以兩種不同的方式顯示。團隊可以選擇如何查看他們的數(shù)據(jù)。
看到在迭代中尚未完成的工作時，團隊可能會變得沮喪，并且可能因為急于完成工作，而不滿足驗收標準。不過，團隊可能有很多理由不按預期完成工作。燃盡圖顯示了團隊成員的多任務處理、過于龐大的故事或團隊成員缺勤的效果。
特別是對新建的敏捷團隊，燃起圖將顯示迭代過程中范圍內的變化。利用燃起圖，團隊能查看他們已經完成的工作，這將有助于團隊進行下一項工作。
無論使用燃盡圖還是燃起圖，團隊都能看到在迭代過程中完成的工作。在迭代結束時，他們可能會根據(jù)自己在這個迭代中完成工作的能力(多少故事或故事點)來建立他們下一個迭代的能力衡量指標。這樣，產品負責人與團隊一起重新規(guī)劃，團隊就更有可能在下一次迭代中成功交付。
速度，也即本次迭代中實際完成功能的故事點大小的總和，讓團隊得以通過觀察歷史表現(xiàn)來更準確地規(guī)劃下階段的能力。
基于流程的敏捷團隊使用不同的衡量指標:交付周期(交付一個工作項目花費的總時間，從項目添加到看板直至項目完成)、周期時間(處理一個工作項目所需的時間)和響應時間(一個工作項目等待工作開始的時間)。團隊通過衡量周期時間發(fā)現(xiàn)瓶頸和延遲問題，問題不僅限于團隊內部。

交付周期有助于理解從_次查看特定功能到向客戶發(fā)布該功能所需的周期時間。在制品(WIP) 限制位于各列頂部(此處在框中顯示)，讓團隊了解如何從看板上提取工作。達到 WIP 限制后，團隊就不能將工作從左邊提取到下一列。此時，團隊就要從_右邊的列中提取工作，并提出問題:“作為一個團隊，我們應該怎樣做才能將這項工作移到下一列中?”
每個功能都是_的，所以它的周期時間也是_的。不過，產品負責人可能會注意到，較小的功能周期時間也較短。產品負責人希望看到產出，因此產品負責人創(chuàng)建較小的功能，或者與團隊合作創(chuàng)建。
燃起圖、燃盡圖(能力衡量指標)和交付周期，以及周期時間(可預測的衡量指標)對于實時測量非常有用。它們可幫助團隊了解他們共有多少工作，以及團隊是否能按時完成工作。
故事點衡量與已完成的故事或功能的衡量有所不同。有些團隊試圖在沒有完成實際功能或故事的情況下衡量故事點。團隊僅衡量故事點時，衡量的是能力，而不是已完成的工作，這違背了“可用的軟件(或者，如果不是軟件，則是其他的產品)是衡量進度的主要指標”的原則。
每個團隊都有自己的能力。在使用故事點時，團隊要認識到，在給定時間內能夠完成的故事點數(shù) 量對一個團隊而言是_的。
根據(jù)自身的指標單位進行衡量，團隊就能更好地評估和估算自己的工作，并_終交付。相對估算的缺點是，無法比較各個團隊或者在團隊之間增加速度。
團隊可以在一個功能燃起圖/燃盡圖和一個產品待辦事項列表中衡量已完成的工作。這些圖表提供了隨時間變化的完成趨勢，如圖 5-4 所示。

功能燃起圖/燃盡圖可顯示項目期間需求的發(fā)展。功能完成線顯示團隊以正常速度完成功能?？偣δ芫€顯示了項目的總功能隨時間的變化。剩余的燃盡線顯示功能完成速度的變化。每次在項目中添加功能時，燃盡線都會有改變。
在敏捷中的掙值是基于已完成的功能，如圖 5-5 所示。產品待辦事項列表燃起圖顯示已完成的工作與區(qū)間里程碑或迭代中的預期工作總量的比較。

一個團隊一次只能完成一個故事。為了完成一個包含多個故事的大功能，團隊會有待完成的剩余故事，并且除非擁有更多的時間，否則可能無法完成整個功能。團隊可以用一個產品待辦事項列表燃起圖來顯示已完成的價值，如圖 5-5 所示。
如果一個團隊需要衡量掙值，可以考慮使用燃起圖，以圖 5-6 為例:請注意，左邊 Y 軸代表了故事點的范圍，右邊 Y 軸代表項目的支出。

傳統(tǒng)的掙值管理 (EVM) 衡量指標，如進度績效指數(shù) (SPI) 和成本績效指數(shù) (CPI) 可以很容易地轉換為敏捷術語。例如，如果團隊計劃在一次迭代中完成 30 個故事點，但是只完成了 25 個，那么 SPI 是 25/30 或者 0.83(該團隊的工作速度只有計劃的 83%)。同樣，CPI 是迄今為止的勞動價值(已完成的功能值) 除以實際的成本，如圖 5-6 所示，$2.2M / $2.8M = 0.79。這意味著，與計劃相比，僅能得到 79 美分的結果(當然，這是假定預測仍然正確)。

圖 5-7 中所示的累積流圖顯示了看板上進行中的工作。如果一個團隊有許多等待測試的故事，測試團隊將會擴大。累積工作可一目了然。
團隊在處理累積工作方面有困難:團隊有進行中的工作，而不是已完成工作。如果團隊有大量進行中的工作，就會延遲整體功能的交付。團隊交付的時間越長，在相同時間內有更多功能，團隊的壓力就越大。

將此累積流調整到項目任務板。

6. 關于項目敏捷性的組織考慮因素

每個項目都存在于組織環(huán)境下。文化、結構和政策可能會影響到所有項目的方向和成果。這些動態(tài)變化可能會對項目領導提出挑戰(zhàn)。
項目領導可能無法根據(jù)自己的意愿來改變組織動態(tài)變化，但可以有技巧地引導這些動態(tài)變化。
本章探討了組織以及(在某些情況下)項目環(huán)境影響項目的方式。領導可以通過探討變革方案來提高項目成功率。

6.1 組織變革管理

組織變革管理一節(jié)涵蓋了會影響敏捷應用情況的技能和技術。
PMI 出版物《組織變革管理實踐指南》[2] 介紹了成功引入有意義變革的全面整體性方法。該指南提供的建議包括:

說明變革動態(tài)變化的模型;
實現(xiàn)變革的框架;
項目、項目集和項目組合層面的變革管理實踐的應用。
6.1.1 和 6.1.2 節(jié)探討了特定敏捷環(huán)境中變革管理的考慮事項。圖 6-1 顯示了這兩個主題之間的關系。

6.1.1 變革管理驅動因素

所有項目都涉及到變革。但是，有兩種主要因素會進一步激勵敏捷環(huán)境中變革管理實踐的應用:

與加速交付相關的變革。敏捷方法強調頻繁并盡早交付項目輸出。但是，接收組織可能尚未做好加速納入這些輸出的充分準備。加速交付將會考驗組織適應該交付的能力。成功發(fā)現(xiàn)和交付項目功能是不夠的。如果組織抗拒項目輸出，則會延遲目標投資回報?？蛻艚邮懿⒅С猪椖枯?出在敏捷環(huán)境中日益盛行。
與敏捷方法相關的變革。組織在剛開始采用敏捷方法時也會經歷更高程度的變革。高級別協(xié) 作可能需要團隊、部門或供應商之間更頻繁地交流。將工作分解到迭代原型時會涉及到不利的返工。領導應考慮利用變革管理技術來解決過渡到敏捷方法時所遇到的阻礙。

6.1.2 變革就緒情況

組織在開始采用敏捷方法時應了解這些方法與其當前方法之間的相對兼容性。某些組織的特征可能
更容易支持跨部門協(xié)作、持續(xù)學習和內部過程演變等敏捷原則。這些變革友好型特征的示例包括:

管理層的變革意愿;
組織在員工認知、審核和評估方式上做出改變的意愿;
集中或分散項目、項目集和項目組合管理職能;
專注于短期預算和指標而不是長期目標;
人才管理成熟度和能力。

相反，還有其他一些機構特征可能會成為實現(xiàn)組織敏捷性相關變革的障礙。這些特征示例包括:

工作被分解為部門孤島，從而創(chuàng)造出阻礙加速交付的依賴關系，而不是構建在能力中心指導下的跨職能團隊。
采購策略基于短期定價策略，而不是長期能力。
獎勵領導的依據(jù)是本地效率而不是端到端項目交付流或整體優(yōu)化情況(就組織而言)。
員工屬于特定領域人才，實現(xiàn)技能多元化的工具或激勵有限，不重視培養(yǎng)T型專家人才。
分散化項目組合使員工同時分配到過多的項目，而無法專注于單個項目。
組織審查和修改這些實踐的意愿程度將決定采用敏捷方法的速度和效率。但是，為了解決這些敏捷組織障礙，項目領導可以嘗試多種方法來加速文化兼容性:
積極明確的管理層支持;
變革管理實踐，包括溝通和引導;
逐個項目應用敏捷實踐；
向團隊增量地引入敏捷實踐;
通過采取適用的敏捷技術和實踐示范引導。

6.2 組織文化

組織文化就是組織的 DNA – 組織的核心標識。文化始終影響敏捷方法的使用。組織文化一直在連續(xù)運轉，從高預測型計劃到一切皆為實驗的精益創(chuàng)業(yè)階段均有體現(xiàn)。盡管敏捷方法與精益創(chuàng)業(yè)文化相當吻合，高預測型組織可以鼓勵實證的衡量指標、小型實驗和不斷學習以便向敏捷方向轉變。

6.2.1 創(chuàng)建安全環(huán)境

組織文化難以改變，但組織中_重要的文化規(guī)范—愿意嘗試任何新方法或技術—將有利于構建安全的工作環(huán)境。
只有在安全、誠實和透明的環(huán)境中，團隊成員和領導才可以真正反思其成功，確保項目持續(xù)進步，或者應用從失敗項目中所吸取的教訓，不再重蹈覆轍。

6.2.2 評估文化

每個項目都會遇到相關方意愿相左的棘手情況。團隊如何在不影響質量的情況下取得快速進展?團隊如何在保留靈活性的同時確保時效性?更重要的是，團隊如何滿足客戶需求?
項目領導可能感覺其職責就是滿足各個相關方的期望;但是在面對選擇時，通常需要根據(jù)組織業(yè)務環(huán)境的文化和要求來確定優(yōu)先級。例如，移動電信項目偏重于速度，而政府項目可能偏重于大眾化和穩(wěn)定性。
要引導這些動態(tài)變化，項目領導應花費時間去評估組織通常所關注的重點。圖 6-2 顯示了有關如何評估的示例。在這個例子中，項目領導發(fā)起了與相關方、團隊成員和高層管理者的對話以討論組織優(yōu)先級。這些優(yōu)先級根據(jù)滑動標尺在這兩個極端之間的位置來進行記錄，然后再利用該結果去找到_適合這些優(yōu)先級的敏捷技術。

有一些模型可用于評估這些動態(tài)變化;但是，采取何種模型或方法并不重要，關鍵是讓項目領導了解其環(huán)境的驅動因素。了解某組織需要滿足的組織與行業(yè)需求后才能選擇合適的對話、權衡尤其是技術。

6.3 采購和合同

如本實踐指南中前面所述，《敏捷宣言》認為“客戶協(xié)作高于合同協(xié)商”。許多項目失敗源于客戶供應商關系破裂。如果合同相關方懷有非贏即輸?shù)南敕?，通常會給項目帶來更多的風險。協(xié) 作方法提倡共擔項目風險和共享項目獎勵的關系，實現(xiàn)所有方共贏。設計這種動態(tài)特性的合同簽署技術包括:

多層結構。除了在單個文檔中正式說明整個合同關系，項目方可以通過在不同文檔中說明不同方面來提高靈活性。通常固定項目(如擔保、仲裁)可以鎖定在主協(xié)議中。同時，所有方將可能會變更的其他項目(如服務價格、產品說明)列在服務明細表中。合同主要服務協(xié)議中注明這些服務參考。_后，范圍、進度計劃和預算等更多動態(tài)變化項目可以列在輕量級工作說明書中。通過將合同中的更多變化因素隔離到單獨的文檔中，將會簡化修改工作并提高靈活性。
強調價值交付。許多供應商關系是由專注于中間人為因素的固定里程碑或“階段關口”控制，而不是由增量業(yè)務價值的完全可交付成果控制。通常，這些控制會限制利用反饋來改進產品。與之相反的是，里程碑和支付項目可以根據(jù)價值驅動可交付成果來構建，以增強項目敏捷性。
總價增量。項目可以將范圍分解為總價微型可交付成果(例如用戶故事)，而不是將整個項目范圍和預算鎖定到單個協(xié)議中。對于客戶而言，這可以更好地控制資金流向。對于供應商而言，這可以限制對單個功能或可交付成果的過多_所帶來的財務風險。
固定時間和材料?？蛻粼诓捎脗鹘y(tǒng)的時間和材料方法時會產生不必要的風險。一種替代方法是將整體預算限制為固定數(shù)量。這就允許客戶在_初未計劃的項目中納入新的觀點和創(chuàng)新。如果客戶需要納入新的觀點，則必須管理給定能力，用新的工作來替代原有工作。應密切監(jiān) 控工作，防止所分配的時間超過其限制。此外，在認為有用的情況下，還可以在_大預算中規(guī)劃額外應急時間。
累進的時間和材料。另一種替代方法是共擔財務風險法。在敏捷方法中，質量標準是已完成工作的一部分。因此，如果在合同期限之前交付，則可對供應商的高效率進行獎勵。相反，如果供應商延遲交付，則將扣除一定費用。
提前取消方案。如果敏捷供應商在僅完成一半范圍時便可交付足夠的價值，且客戶不再需要另外一半范圍，則不必支付這部分費用。但合同中可以規(guī)定客戶應為項目剩余部分支付一定的取消費用。因為不再需要這些服務，客戶可以限制預算敞口，而供應商也可獲得可觀的收入。
動態(tài)范圍方案。對于具有固定預算的合同，供應商可為客戶提供在項目特定點改變項目范圍的方案?？蛻艨烧{整功能以適應該能力。這樣客戶便可利用創(chuàng)新機會，同時限制供應商的過度_風險。
團隊擴充。大多數(shù)協(xié)作合同方法是將供應商服務直接嵌入客戶組織中。通過資助團隊而不是特定范圍，可以保留客戶自行確定需要完成工作這方面策略的權力。
支持全方位供應商。為了分化風險，客戶可能需要采取多供應商策略。但是，這樣簽署合同的結果是，每家供應商只能負責一項工作，這就會產生許多依賴關系，阻礙可行服務或產品的交付。相反，要強調提供全面價值的合約(這與已完成獨立功能集中的觀點相符)。
可以創(chuàng)建敏捷合同。敏捷是在協(xié)作和信任的共同基礎上建立的。如果供應商能夠盡早頻繁交付價值，則有助于實現(xiàn)這一點。如果客戶能夠提供及時反饋，則有助于實現(xiàn)這一點。

6.4 商業(yè)實踐

在需求產生時，組織創(chuàng)建新能力的意愿和能力即是組織敏捷性的標志。對于關注敏捷及其所提供結果的組織而言，這些不必是顛覆性的變革，破壞性較小。透明和開放協(xié)作至關重要。
在跨職能團隊交付價值時，團隊和個人可能會遇到組織多種支持職能方面的問題。
如果團隊定期交付價值，財務部門可能有機會以不同的方式獲得產品收益。如果團隊與其他組織簽署了合同，采購部門可能需要變更這些合同，以幫助其他組織頻繁交付價值并與團隊保持同步。
團隊開始以團結協(xié)作的方式展開工作后，將會對內部管理策略提出挑戰(zhàn)。人力資源可能注意到個人激勵不足，而經理可能會在自組織員工的績效評估方面絞盡腦汁。在各種情況下都有機會評審現(xiàn) 有實踐對敏捷工作方式的支持程度。
當組織發(fā)展到更高敏捷性時，其他業(yè)務部門將有必要更改其交互方式并履行自己的職責。現(xiàn)在應擁護對組織其他領域有益的變更，以此來提高整個組織的效率。

6.5 多團隊協(xié)作和依賴關系(擴展)

多個項目之間會產生依賴關系，即使不是在給定項目集中進行管理。因此有必要了解敏捷工作在現(xiàn)有項目集和項目組合管理環(huán)境下的工作方式。

6.5.1 框架

大多數(shù)流行敏捷方法(如 Scrum 和極限編程)的指導專注于單個小型且通常是集中辦公的跨職能團隊活動。這對于需要單個團隊的工作非常有用，但對于需要在一個項目集或項目組合中進行多個敏捷團隊協(xié)作的舉措?yún)s顯得捉襟見肘。

6.5.2 考慮事項

有多種擴展工作的方式。團隊可能需要將多個敏捷項目工作擴展到單個敏捷項目集中?；蛘?，組織可以設計出支持整個項目組合中不同敏捷方法的結構。
例如，可以從小項目著手，然后盡快了解組織環(huán)境中比較適合的方式。即使一切還未完全轉換到敏捷方法，團隊仍可獲得成功。
無論采用哪種方法，關鍵成功因素是健康的敏捷團隊。如果單個團隊采取敏捷方法無法獲得成功，則勿嘗試將其擴展到更大范圍;而是要先行解決阻止團隊敏捷工作的組織障礙。
大規(guī)模敏捷項目的目標是協(xié)調不同團隊的工作以便為客戶提供價值。這有多種實現(xiàn)方式。團隊可以采用正式的框架或應用敏捷思維調整現(xiàn)有項目集管理實踐。

6.6 敏捷和項目管理辦公室 (PMO)

設立PMO的目的是引導組織實現(xiàn)商業(yè)價值?？梢酝ㄟ^幫助實現(xiàn)項目目標來做到這一點。PMO 有時還會提供團隊教育(或安排培訓)和項目支持。PMO 還會針對給定項目或項目集提供相關商業(yè)價值方面的管理建議。
由于敏捷會帶來文化變更，隨著時間的推移，組織可能也需要變更，包括 PMO。例如，經理會決定資助的項目及其時間，團隊會決定培訓或建議需求。

6.6.1 敏捷 PMO 為價值驅動型

所有項目都應在合適的時間為合適的受眾提供合適的價值。PMO 的目標是幫助促進這個目標的實現(xiàn)?；诿艚莸?PMO 方法以客戶協(xié)作思維為基礎，并存在于所有 PMO 項目集中。在許多情況下，這意味著 PMO 的運營方式類似于咨詢企業(yè)，需要根據(jù)給定項目的特定需求來定制其工作。有些項目可能需要工具和模板，還有些項目可能會從管理層引導中獲益。PMO 應努力按需交付并緊跟客戶需求，確保了解并適應他們的需求。這種內部創(chuàng)業(yè)方法專注于能為所支持的項目提供_大價值的 PMO 活動。

6.6.2 敏捷 PMO 為面向創(chuàng)新型

為了在基于價值的章程下加速發(fā)展，PMO 可能需要強制執(zhí)行某些解決方案或方法，例如，保持所有人行動的一致性以快速獲得成功。但需要確保員工的參與意愿才能提高效率。只邀請感興趣的人員參與 PMO 服務即可實現(xiàn)這一點。PMO 實踐的參與度越高，便更容易提高這些實踐的“粘合力”。如果 PMO 為其客戶提供了價值，則客戶很可能會要求這種服務并采用其實踐。

6.6.3 敏捷 PMO 為多學科型

為了支持特定項目需求，PMO 還需要熟悉項目管理本身以外的其他一些能力，因為不同的項目要求不同的能力。例如，一個項目可能需要組織設計來解決人員配備挑戰(zhàn)，而另一個項目可能需要組織變革管理技術來確保相關方參與或獲得獨特的業(yè)務模型以支持客戶目標。
某些組織已將其 PMO 轉換為卓越敏捷中心以提供以下服務:

制定和實施標準。提供用戶故事、測試案例、累積流圖等模板，提供敏捷工具并培訓支持小組了解迭代開發(fā)概念。
通過培訓和指導發(fā)展人才。協(xié)調敏捷培訓課程、教練和導師以幫助員工過渡到敏捷思維模式并升級其技能。鼓勵和支持員工參與本地敏捷活動。
多項目管理。通過不同項目交流協(xié)調敏捷團隊。考慮分享進度、問題、回顧性發(fā)現(xiàn)和改進實驗等內容。借助適當?shù)目蚣?，幫助管理項目層的主要客戶發(fā)布和項目組合層的投資主題。
促進組織學習。收集項目進度信息并獲取、存儲和記錄回顧性發(fā)現(xiàn)成果。
管理相關方。提供產品負責人培訓，指導驗收測試以及評估方法，并提供系統(tǒng)反饋。宣揚主題專家 (SME) 對項目的重要性。
招聘、篩選和評估項目領導。制定敏捷實踐者訪談指南。
執(zhí)行專業(yè)化項目任務。培訓和提供回顧促進者，與敏捷項目問題解決者訂立協(xié)議，并提供導師和教練。

6.7 組織結構

組織結構會嚴重影響其轉向新信息或轉變市場需求的能力。下面列出了主要特征:

地理。地理分散的項目組織可能會在各種項目中發(fā)現(xiàn)阻礙工作進展的一些挑戰(zhàn)。項目領導和區(qū)域經理可能持有不同或相反的目標。此外，文化差異、語言障礙和低可視化可能會降低工作效率。幸運得是，采用敏捷方法可以鼓勵更好的協(xié)作并提高信心。在這些環(huán)境下，項目領導應鼓勵團隊和管理層對話，定制該環(huán)境所需的技術并管理對工作需求的期望。
職能結構。有些組織按照高度項目型、矩陣型或高度職能型的方式構建。具有高度職能結構的項目可能會在組織內部協(xié)作方面遇到很大阻力。
項目可交付成果的大小?？s小項目可交付成果將會激勵部門之間更頻繁的交流，由此帶來更頻繁的交互以及組織內部更快速的價值流動。
項目人員分配。另一種方法是在各個部門中抽出一個人，將其臨時完全分配到_高優(yōu)先級項目。
重采購型組織。有些組織選擇主要通過供應商實施項目。盡管項目目標可能非常明確，供應商也有責任監(jiān)管自己的財務狀況。但是，供應商完成其義務并退出合約后，相關項目知識也將隨之帶走。這就會限制持續(xù)靈活性和速度所需的內部能力。如果在供應商還參與時采用敏捷技術(例如回顧和跟蹤可能改進的領域)，則可幫助緩解產品知識缺失情況。

6.8 組織演變

應對單個挑戰(zhàn)領域或實施新的混合或敏捷方法時，建議以累積方式承接工作。常用實踐是將變更過程視為一個敏捷項目，團隊可以根據(jù)自己的價值觀或其他考慮事項引入自己的變更待辦事項列表并確定其優(yōu)先級。每個變更可以被視為一個實驗，將進行短時間測試以確定每個變更的適應性以及進一步細化/考慮需求。
使用看板面板跟蹤進度，顯示已作為“已完成”使用的新方法、被視為“進行中”的方法、以及仍在等待被引入“待辦事項”的方法。請參見圖 6-3 以了解具有待辦事項列表排序的初始面板。圖 6-4 顯示了面板工作進度的示例。