敏捷实践指南
目錄
- 申明
- 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.2 混合敏捷方法
- 3.3 影響裁剪的項目因素
- 4. 實施敏捷:創建敏捷環境
- 4.1 從敏捷思維模式開始
- 4.2 仆人式領導為團隊賦權
- 4.2.1 仆人式領導的職責
- 4.2.1.1 仆人式領導的促進作用
- 4.2.1.2 仆人式領導消除組織障礙
- 4.2.2 項目經理在敏捷環境中的角色
- 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. 實施敏捷：在敏捷環境中交付
- 5.1 項目章程和團隊章程
- 5.2 常見敏捷實踐
- 5.2.1 回顧
- 5.2.2 待辦事項列表編制
- 5.2.3 待辦事項列表的細化
- 5.2.4 每日站會
- 5.2.5 展示/評審
- 5.2.6 規劃基于迭代的敏捷
- 5.2.7 幫助團隊交付價值的執行實踐
- 5.2.8 迭代和增量如何幫助交付工作產品
- 5.3 解決敏捷項目的挑戰
- 5.4 敏捷項目的衡量指標
- 5.4.1 敏捷團隊的衡量結果
- 6. 關于項目敏捷性的組織考慮因素
- 6.1 組織變革管理
- 6.1.1 變革管理驅動因素
- 6.1.2 變革就緒情況
- 6.2 組織文化
- 6.2.1 創建安全環境
- 6.2.2 評估文化
- 6.3 采購和合同
- 6.4 商業實踐
- 6.5 多團隊協作和依賴關系(擴展)
- 6.5.1 框架
- 6.5.2 考慮事項
- 6.6 敏捷和項目管理辦公室 (PMO)
- 6.6.1 敏捷 PMO 為價值驅動型
- 6.6.2 敏捷 PMO 為面向創新型
- 6.6.3 敏捷 PMO 為多學科型
- 6.7 組織結構
- 6.8 組織演變
- 7. 專欄知識鏈接
申明
??本文章屬于原創，參考了《敏捷實踐指南》，侵刪。
1. 引論
??本實踐指南適用于對于預測法和敏捷方法難以取舍的項目團隊，試圖解決快速創新和復雜性問題 的項目團隊，以及致力于團隊改進的項目團隊。本實踐指南將提供有益的指導方針，它們將有助于 項目取得成功，幫助項目團隊順利交付商業價值，滿足客戶的期望和需求。
2. 敏捷概述
2.1 可確定的工作與高度不確定的工作
??項目工作包括可確定的工作與高度不確定的工作。可確定的工作項目具有明確的流程，它們在以往 類似的項目中被證明是行之有效的。在完成設計后制造汽車、電器或建造住宅，這些都是可確定的工 作的例子，其所涉及的生產領域和過程通常都很好理解，并且執行的不確定性和風險通常較低。
??新的設計、解決問題和之前未做過的工作都是探索性的。它要求主題專家攜手合作，解決問題， 并創建解決方案。遭遇高度不確定的工作的人員包括軟件系統工程師、產品設計師、醫生、教師、 律師和許多解決問題的工程師等。隨著可確定的工作日益實現自動化，項目團隊也越來越多地從事 高度不確定的工作，從事這些工作就需要使用本實踐指南所述的有關技術。
??高度不確定的項目變化速度快，復雜性和風險也高。這些特點可能會給傳統預測法帶來問題， 傳統預測法旨在預先確定大部分需求，并通過變更請求過程控制變更。而敏捷方法的出現是為了 在短時間內探討可行性，根據評估和反饋快速調整。
2.2 《敏捷宣言》及思維模式
??一般而言，可通過兩種策略踐行敏捷價值觀和原則。一種策略是采用正規的敏捷方法，它們 為特意設計，經證明可達成期望的成果。那么，在變更和裁剪之前，就需要花時間學習和理解 敏捷方法。不成熟和隨意的裁剪會讓敏捷方法的效果大打折扣，從而限制了收益。(參見附件 X2 中的“裁剪考慮事項”)。
??第二種策略是，以一種適合項目背景的方式對項目實踐進行變更，以便在核心價值觀或原則方面取 得進展。使用時間盒創建功能，或者使用特定技術迭代優化功能。在適用于特定項目背景下，考慮將 一個大項目劃分為幾部分發布。實現有助于項目成功的變更，這些變更不必是組織的正式實踐的組成 部分。最終目標不是為了敏捷而敏捷，而是為了向客戶持續交付價值流，并達成更好的商業成果。
2.3 精益與看板方法
??看待精益、敏捷與看板方法三者之間關系的一種思路是，將敏捷和看板方法視為精益思想的衍生物。換言之，精益思想是一個超集，與敏捷和看板方法擁有共性。
??這種共性非常相似，重點在于交付價值、尊重人、減少浪費、透明化、適應變更以及持續改善等 方面。項目團隊有時會發現將各種方法結合起來使用更為有用，只要是對組織或團隊有效的方法， 無論來源如何，都應該采納。無論使用什么方法，目標都是為了實現最佳結果。
??看板方法受到最初的精益制造體系的啟發，專門用于知識型工作。它在 2000 年代中期出現，是當 時非常盛行的敏捷方法的一種替代方法。
??看板方法不如某些敏捷方法規范，破壞性也較小，原因在于它是原始的“原地出發”方法。在有 必要或適當的情況下，項目團隊可以相對輕松地應用看板方法，并向其他敏捷方法發展。關于看板 方法的更多信息，請參見“附錄 A3 敏捷和精益框架概述”。
2.4 不確定性、風險和生命周期選擇
??有些項目在項目需求、以及如何使用現有知識和技術滿足這些需求方面，具有很大的不確定性。
這些不確定因素可能導致大量變更和項目復雜性的提高。上述特點如圖 2-5 所示。
??隨著項目不確定性的增加，返工的風險和使用不同方法的需求也會增加。為了減輕這些風險的
影響，團隊選擇的生命周期要能夠通過較少的工作增量解決項目的大量不確定性問題。
??團隊可以利用較少的工作增量驗證自身的工作，并且可以對接下來的工作做出相應變更。與靜態 書面規范相比，當團隊交付小的增量時，他們能夠更快更準確地理解真正的客戶需求。
??團隊可以用明確穩定的管理要求規劃并管理項目，輕松解決各種技術挑戰。但是，隨著項目不確
定性的增加，變更、做無用功和返工的可能性也會隨之增加，而這不僅代價高昂，而且耗費時間。
??有些團隊讓項目生命周期發生演變，以便使用迭代和增量方法。許多團隊發現，在探討迭代需 求、更頻繁地交付增量時，團隊會更容易適應變更。由于團隊獲得反饋，這些迭代和增量方法減 少了浪費和返工。這些方法應用了:
- 非常短的反饋循環;
- 頻繁調整過程;
- 重新進行優先級排序;
- 定期更新計劃;
- 頻繁交付；
??對于涉及新穎的工具、技術、材料或應用領域的項目，這些迭代、增量和敏捷方法非常有效。 (參見第 3 章“生命周期選擇”)。它們也適用于具有以下特點的項目:
- 需要研究和開發;
- 變更速度極快;
- 具有不明確或未知的需求、不確定性或風險;
- 最終目標難以描述。
??通過構建一個小的增量，然后對其進行測試和評估，團隊可以在短時間內以低成本探索不確定性， 降低風險，最大程度地實現商業價值的交付。這種不確定性可能集中于適用性和需求(正在構建的產 品是否正確?);技術可行性和性能(產品是否可以采用這種方法構建?);或過程和人員(這是否 為團隊工作的一種有效方式?)。以上三個特點(產品規格、生產能力和過程適用性)通常都具有高 度不確定性因素。
??不過，迭代和增量管理方法也有其應用局限性。當技術和需求的不確定性都很高時(圖 2-5 右上部 分),項目就會極端復雜，陷入無序狀態。為了使項目盡可能可靠，需要遏制其中一個不確定性變量。
3. 生命周期選擇
??項目有多種形式，也有多種實施方式。項目團隊需要認識到 相關特征和方案，以選擇最可能使項目成功的方法。
??本實踐指南涉及四種生命周期，分別定義如下:
- 預測型生命周期。這是一種更為傳統的方法，提前進 行大量的計劃工作，然后一次性執行;執行是一個連 續的過程。
- 迭代型生命周期。這種方法允許對未完成的工作進行反 饋，從而改進和修改該工作。
- 增量型生命周期。這種方法向客戶提供各個已完成的， 可能立即使用的可交付成果。
- 敏捷生命周期。這種方法既有迭代，也有增量，便于完 善工作，頻繁交付。
3.1 項目生命周期的特征
??需要注意的是，所有的項目都具有這些特征，沒有一個項目能夠完全不考慮需求、交付、變更和 目標這些因素。項目的固有特征決定了其適合采用哪種生命周期。
??另一種理解不同項目生命周期的方法是，使用一個連續區間，從一端的預測型周期到另一端的敏 捷型周期，連續區間中間還有更多的迭代型周期或增量型周期。
??第六版《PMBOK? 指南》附件 X3 圖 X3-1 將連續區間顯示為一條直線。該圖強調了從線的一端到 另一端，項目特征的變化情況。另一種形象化的方法是，用一個二維正方形表示這個連續區間， 如圖 3-1 所示。
??沒有哪個生命周期能夠完美地適用于所有的項目。相反，每個項目都能在連續區間中找到一個點，根據其背景特征，實現最佳平衡。特別是，
- 預測型生命周期。充分利用已知和已經證明的事物。不確定性和復雜性的減少，允許項目團隊 將工作分解為一系列可預測的小組。
- 迭代型生命周期。允許對部分完成或未完成的工作進行反饋，從而對該工作進行改進和修改。
- 增量型生命周期。可向客戶提供完成的可交付成果，讓客戶能夠立即使用。
- 敏捷生命周期。它同時利用迭代屬性和增量特征。團隊使用敏捷方法時，他們會對產品進行 迭代，創建完成的可交付成果。團隊將獲得早期的反饋，并能提供客戶可見性、信心和對產 品的控制。由于團隊可以提前發布產品，而團隊將率先交付價值最高的工作，所以項目可以 更早產生投資回報。
3.1.1 預測型生命周期的特征
??預測型生命周期預計會從高確定性的明確的需求、穩定 的團隊和低風險中獲益。因此，項目活動通常以順序方式執 行，如圖 3-2 所示。
??為了實現這種方法，團隊需要詳細的計劃，了解要交付什么以及怎樣交付。當其他潛在變更受到限制時，這些項目就會成 功(例如:需求變更;項目團隊成員修改團隊交付的成果)。 團隊領導的目標是盡可能減少預測型項目的變更。
??團隊在項目開始時創建詳細的需求和計劃時，他們可以闡明各種制約因素。然后，團隊可以利用這些制約因素管理風險和成本。進而，團隊在實施詳細計劃時，他們會監督并控制可能 影響范圍、進度計劃或預算的變更。
??預測型項目強調根據部門劃分的、有效的、順序的工作，并 且通常不會在項目結束前交付商業價值。如果遇到變更或需求 分歧，或者技術解決方案變得不再簡單明了，預測型項目就將 產生意想不到的成本。
計劃始終貫穿其中
??要記住的關鍵一點是，每種生命周期都有計劃要素。生命 周期的不同之處并非在于計劃是否完成，而在于完成了多少計劃以及何時完成。
??在連續區間的預測一端，是計劃驅動著工作。有多少計 劃，就有多少提前執行的可能性。盡可能詳細地定義需求。 團隊估算何時能夠交付可交付成果，并全面開展采購工作。
??在迭代方法中，也計劃了原 型和驗證，但是輸出的目的是修改一開始所創建的計劃。對未完成的工作的早期評審將有助于未來的項目工作。
??與此同時，增量方法計劃交付整個項目后續部分。 團隊可以提前計劃可交付成 果的若干次連續交付，或者一次只計劃交付一個。可交付成果為未來的項目工作提供了相關信息。
??敏捷項目也有計劃。主要區別在于，通過對頻繁交付的可交付成果的評審，團隊將能獲得更多的信息，從而在此基礎上進行計劃和重新計劃。無論采用哪種項目生命周期，項目都需要計劃。
3.1.2 迭代型生命周期的特征
??迭代型生命周期通過連續的原型或概念驗證來改進產品或成果。每一個新的原型都能帶來新的 相關方新的反饋和團隊見解。然后，團隊在下一周期重復一個或多個項目活動，在其中納入新的信息。團隊可能會在長達數周時間的一個特定迭代中使用時間盒，集中各種見解，然后根據這些見解 對活動進行返工。這樣，迭代有利于識別和減少項目的不確定性。
??當項目復雜性高、變更頻繁或當項目范圍受到相關方對所需最終產品的不同觀點的支配時，采用 迭代型生命周期會有優勢。迭代型生命周期可能需要更長的時間，因為它是為學習而優化，而不是為交付速度而優化。
??圖 3-3 顯示迭代型項目生命周期的一個產品交付的某些要素。
3.1.3 增量型生命周期的特征
??有些項目優化是為了加快交付速度。許多企業和項目無法等待所有的事情全部完成;這種情況下，客戶愿意接受整個解決 方案的一個部分。這種少量可交付成果的頻繁交付稱為增量型生命周期(參見圖 3-4)
3.1.4 敏捷生命周期的特征
??在敏捷環境中，團隊預料需求會發生變更。迭代和增量方法能夠提供反饋，以便改善項目下一部 分的計劃。不過，在敏捷項目中，增量交付會發現隱藏或誤解的需求。圖 3-5 顯示了實現增量交付的 兩種可能的方法，這樣將便于項目與客戶需求保持一致，并根據需要進行調整。
??在基于迭代的敏捷中，團隊以迭代(相等持續時間的時間盒)形式交付完整的功能。團隊集中 于最重要的功能，作為一個團隊合作完成其工作。然后，團隊再集中于下一項最重要的功能，并合作完成其工作。團隊可決定一次進行若干功能的開發工作，但團隊不會同時完成所有的迭代工 作(即團隊不會在完成全部分析等工作后再解決所有需求)。
??對于建立在流程基礎上的敏捷方法，團隊將根據自身能力，從待辦事項列表中提取若干功能開始 工作，而不是按照基于迭代的進度計劃開始工作。團隊定義任務板各列的工作流，并管理各列的進 行中的工作。完成不同功能所花費的時間可能有所不同。團隊讓進行中的工作的規模盡量小，以便 盡早發現問題，并在需要變更時減少返工。無需利用迭代定義計劃和審核點，而由團隊和業務相關 方決定規劃、產品評審與回顧的最適當的進度計劃。
??敏捷生命周期是符合《敏捷宣言》原則的周期。特別是，客戶滿意度將隨著有價值產品的早期交 付和持續交付不斷提升。此外，功能性的、提供價值的增量可交付成果，是衡量進展的主要尺度。 為了適應更頻繁的變更，和更頻繁地交付項目價值，敏捷生命周期結合了迭代和增量方法。
3.1.5 敏捷適用性篩選器
??有各種評估模型可用來幫助確定使用敏捷方法的適合性或差距。這些模型評估項目和具有適應性 和適用性的組織因素，然后提供分數表明一致性或潛在風險領域。附件 X3 綜合提供了各種流行的評 估模型，它們可用作敏捷適用性篩選器。
3.2 混合敏捷方法
??敏捷團隊很少將其實踐局限于一種敏捷方法。每個項目 背景都有其各自的獨特性，比如團隊成員技能和背景的不同 組合;開發中的產品的各個組成部分;以及工作環境中的年 齡、規模、關鍵性、復雜性和監管制約因素等。
??敏捷框架并不是針對團隊定制的。為了定期交付價值，團隊 可能需要對實踐進行裁剪。通常，團隊都會實踐各自特殊的敏 捷組合，即便他們使用一個特定的框架作為起點也不例外。
協調方法
??裁剪敏捷框架的一個例子 是，一個廣泛使用的常見協調 方法涉及到協調使用 Scrum 框 架、看板方法和極限編程 (XP) 方法的要素。Scrum 為產品待辦 事項列表、產品負責人、Scrum 主管以及跨職能開發團隊的使 用提供指導，包括沖刺計劃、 每日例會、沖刺評審和沖刺回 顧會議。看板面板幫助團隊進 一步提高效率，方法是將工作 流可視化、使障礙更容易被察 覺，以及通過調整在制品限制 來實現流程管理。此外，受極 限編程啟發的工程實踐，如使 用故事卡、持續集成、重構、 自動化測試和測試驅動開發， 將進一步提高敏捷團隊的效 力。總之，與孤立采用各種實 踐相比，協調這些不同來源的 實踐將產生更好的協同成果。
3.3 影響裁剪的項目因素
??有時，為了更好地配合，根據項目屬性對方法進行裁剪。表 3-2 列出一些要考慮的項目因素和裁剪方案。
4. 實施敏捷:創建敏捷環境
4.1 從敏捷思維模式開始
使用敏捷方法管理項目，要求項目團隊采用敏捷思維模式。以下問題的答案將有助于制定實施策略:
- 項目團隊如何以敏捷方式行動?
- 為了使下一交付周期受益，團隊需要快速交付哪些成果并獲得早期反饋?
- 團隊如何以一種透明的方式行動?
- 為了專注于高優先級的項目，可以避免哪些工作?
- 仆人式領導對團隊達成目標有何益處?
4.2 仆人式領導為團隊賦權
??敏捷方法強調，仆人式領導是一種為團隊賦權的方法。仆人式領導是通過對團隊服務來領導團隊的實踐，它注重理解和關注團隊成員的需要和發展，旨在使團隊盡可能達到最高績效。
??仆人式領導的作用是促進團隊發現和定義敏捷。仆人式領導實踐并傳播敏捷。仆人式領導按照以 下順序從事項目工作:
- 目的。與團隊一起定義“為什么”或目的，以便他們能圍繞項目目標進行合作互動。整個團隊 在項目層面而不是在人員層面優化。
- 人員。目標確立后，鼓勵團隊創造一個人人都能成功的環境。要求每個團隊成員在項目工作 中做出貢獻。
- 過程。不要計劃遵循“完美”的敏捷過程，而是要注重結果。如果跨職能團隊能夠常常交付完 成的價值并反思產品和過程，團隊就是敏捷的。團隊將其過程稱作什么并不重要。
以下仆人式領導的特征讓項目領導變得更加敏捷，促進團隊的成功:
- 提升自我意識;
- 傾聽;
- 為團隊服務;
- 幫助他人成長;
- 引導與控制;
- 促進安全、尊重與信任;
- 促進他人精力和才智提升。
??仆人式領導并不是敏捷所獨有的。但經過實踐，仆人式領導通常能了解到仆人式領導是怎樣融入敏捷思維模式和價值觀的。
??領導在發展自身仆人式領導力或促進技巧后，他們就更愿意成為敏捷踐行者。因此，仆人式領導可以幫助他們的團隊通過合作更快地交付價值。
??成功的敏捷團隊信奉成長思維模式，團隊成員自己能夠學到新技能。如果團隊和仆人式領導都相信自己能夠學習，那么所有人的能力都能得到提高。
4.2.1 仆人式領導的職責
??仆人式領導通過管理關系，在團隊內和組織中建立溝通與協作。這些關系可以幫助領導在組織中得心應手地為團隊提供支持。這種支持有助于消除障礙，促進團隊理順過程。由于仆人式領導了解敏捷，在應用具體方法時踐行敏捷，因而他們能幫助滿足團隊的需要。
4.2.1.1 仆人式領導的促進作用
??項目經理成為仆人式領導時，工作重點就會從“管理協調”轉向“促進合作”。促進者將幫助每個人各盡所能地思考和工作。促進者鼓勵團隊參與、理解，并對團隊輸出共同承擔責任。促進者幫 助團隊創建可接受的解決方案。
??仆人式領導促進團隊內部和團隊之間的合作與對話。例如，仆人式領導在團隊內部和團隊之間幫助發現瓶頸問題，并進行相應溝通。然后，團隊將解決這些瓶頸問題。
??此外，促進者還鼓勵大家通過交互式會議、非正式對話和知識共享展開協作。仆人式領導要通過成為公正的搭橋者和教練來做到這一點，而不是代替他責任人做出決策。
4.2.1.2 仆人式領導消除組織障礙
??《敏捷宣言》的第一個價值觀關乎個人與過程和工具的交互。對仆人式領導而言，更好的職責是 認真審視那些阻礙團隊敏捷或組織敏捷的過程，并努力使其合理化。例如，如果一個部門需要大量 文檔，仆人式領導的角色就能發揮作用，他們可以與部門合作審查所需的文檔，就敏捷交付如何滿 足這些需求達成共識提供協助，并對所需的文檔數量進行評估，從而使團隊能夠將時間更多地用于 提供有價值的產品，而不是創建詳盡的文檔。
??仆人式領導還應該關注其他冗長的過程，這些過程往往造成瓶頸問題，阻礙團隊或組織的敏捷性。 可能需要處理的過程或部門的例子包括，財務部門、變更控制委員會或審計部門。仆人式領導可以與 他人攜手合作，共同質疑和審核他們的過程，為敏捷團隊和領導提供支持。例如，對團隊而言，每兩 周交付一個工作產品僅僅是為了讓產品進入隊列或過程，而冗長的發布過程卻可能需要 6 周或更長時 間，這樣做有什么好處呢?太多的組織都有這些“瓶頸”過程，正是它們阻礙了團隊快速交付有價值 的產品或服務。仆人式領導有能力改變或消除這些組織障礙，為交付團隊提供支持。
4.2.2 項目經理在敏捷環境中的角色
??項目經理在敏捷項目中的角色有些是未知的，原因是許多敏捷框架和方法都不涉及項目經理的角色。一些敏捷實踐者認為，并不需要項目經理的角色，因為自組織團隊承擔了項目經理之前 的職責。不過，務實的敏捷實踐者和組織認識到，在許多情況下，項目經理都能夠創造重要的價值。關鍵的區別在于，他們的角色和職責看起來有些不同。
4.2.3 項目經理應用仆人式領導
??第六版《PMBOK? 指南》將項目經理定義為“由執行組織委派，領導團隊實現項目目標的個人”。
??許多項目經理已經習慣于作為項目的協調中心，負責跟蹤團隊的狀態，并向組織中的其他成員反映。 當項目被分解為孤立的功能時，這種方法沒有問題。
??然而，對于高不確定性項目，項目的復雜性是一個人所無法管理的。而跨職能團隊既能協調自身 的工作，還能與業務代表(產品負責人)開展合作。
??從事敏捷項目工作時，項目經理的角色就會從團隊的中心轉變成為團隊和管理人員提供服務。在敏捷環境中，項目經理充當仆人式領導，其工作重點轉變為引導需要幫助的人，促進團隊的合作，保持與相關方的需要一致。作為仆人式領導，項目經理要鼓勵將責任分配給團隊成員，分配給那些 掌握完成任務所需知識的人。
4.3 團隊構成
??《敏捷宣言》的價值觀和原則的一個核心宗旨是強調個人和交互的重要性。敏捷優化了價值流，強調了向客戶快速交付功能，而不是怎樣“用”人。
團隊在考慮如何優化價值流時，以下好處是顯而易見的:
- 人員更有可能合作。
- 團隊更快地完成有價值的工作。
- 由于不從事多任務，也不必重新建立環境，團隊減少了時間浪費。
4.3.1 敏捷團隊
??敏捷團隊注重快速開發產品，以便能獲得反饋。在實踐中，最有效的敏捷團隊往往由三到九個成 員組成。理想情況下，敏捷團隊應該集中在一個團隊工作場所工作。團隊成員 100% 為專職成員。敏 捷鼓勵自我管理團隊，由團隊成員決定誰執行下一階段定義的范圍內的工作。敏捷團隊與仆人式領 導一起茁壯成長。領導支持團隊的工作方法。
??跨職能敏捷團隊頻繁創造功能性產品增量。這是因為團隊集體對工作負責并共同擁有完成工作所 需的所有必要技能。
??無論整體的敏捷方法是什么，團隊越是限制其在制品，團隊成員就越有可能通過合作來加快整 個團隊的工作。在成功的敏捷團隊中，團隊成員在工作中以各種方式開展合作(如結對、群集、 群體開發)，因而，他們會協同工作，而不會落入迷你瀑布的陷阱中。團隊在給定時間解決所有 的需求，然后試圖完成所有的設計，繼而又去完成所有的構建，就會發生迷你瀑布的情況。使用 這個場景，在構建中或構建后測試中的某一時刻，團隊可能會意識到，原先的假設已經不再有 效。這種情況下，團隊解決所有的需求根本是在浪費時間。相反，當團隊成員合作打造全部功能 中的少量功能時，隨著工作的推進和交付少量已完成的功能，他們也在不斷學習。
??敏捷項目得益于項目團隊結構，這種結構能改善團隊內部和團隊之間的合作。圖 4-1 展示了團隊成 員如何通過合作提高工作效率、促進創造性地解決問題。
4.3.2 敏捷的角色
敏捷團隊中有三種常見的角色:
- 跨職能團隊成員;
- 產品負責人;
- 團隊促進者。
表 4-2 描述了這些團隊角色。
4.3.3 通才型專家
??敏捷團隊是跨職能的，但其人員往往不會一開始就做到這 樣。不過，許多成功的敏捷團隊都由通才型專家組成，他們也 稱為 T 型人才。
??這意味著這些團隊成員在具備一項擅長的專業化技能的同 時，還擁有多種技能的工作經驗，而不是單一的專業化。由于 密切協作和自我組織，敏捷團隊成員才能夠敏捷開發并迅速完 成工作，而這就需要使互相幫助成為常態。敏捷團隊成員都要 致力于培養這樣的特質。
??一個人的能力大小無關緊要。如果給團隊其他成員帶來瓶頸 問題，集中于某一個人的能力甚至是有害的。團隊的目的是優 化已完成的工作，并獲得反饋。
??如果客戶希望獲得好的結果，如快速交付功能并且質量優 良，那么團隊就不能僅僅為了盡可能有效利用資源而構建專門 的角色。團隊的目標是提高過程效率，優化整個團隊的產能。 團隊規模小會促進團隊的合作。產品負責人的工作是確保團隊 從事最高價值的工作。
4.3.4 團隊結構
??許多行業的團隊都會采用敏捷原則和實踐。他們將人員組織到跨職能團隊中，迭代開發工作產品。
??有些組織已經能夠建立集中辦公的跨職能團隊;還有組織有不同的情況。有些組織并不是所有團 隊成員都為集中辦公，而是擁有分布式或分散式團隊。分布式團隊可以在不同地點擁有多個跨職能 團隊。分散式團隊可能會讓各團隊成員分別在不同的地點工作，或在辦公室，或在家里。鑒于通信 成本的增加，這些安排并非理想，但它們仍然是可行的。
4.3.5 專職小組成員
??如果團隊成員并非 100% 為團隊專職工作，會有什么情況發生?遺憾的是，這種情況雖然并不理想，但有時卻無法避免。
??讓一個人在團隊中只投入 25% 或 50% 的能力，這帶來的關鍵問題是，他們會進行多任務處理和任 務切換。多任務處理會降低團隊工作的產出，并影響團隊預測交付能力的一致性。
??任務切換時，人員工作效率的損失在 20% 到 40% 之間。隨著任務數量的增加，效率損失會呈指 數級增長。
??當一個人在兩個項目之間進行多任務切換時，他投入到每個項目上的精力并非各占 50%。相反， 由于存在任務切換成本，他在每個項目上的投入降低到 20% 到 40%之間。
??人們在一心多用的時候更容易犯錯誤。任務切換消耗工作記憶，人們在多任務處理時不太可能記 住相應工作的背景。
??當團隊中所有的人都被分配到一個項目時，他們能夠作為一個團隊持續協作，從而使每個人的 工作更加有效。
4.3.6 團隊工作場所
??團隊需要一個工作場所，他們可以一起工作，了解他們作為團隊的狀態，并進行協作。有些敏捷 團隊的所有成員都集中在一個房間里工作。有些團隊擁有一個團隊工作場所用于開例會以及張貼各 種圖表，但團隊成員分別在各自的小隔間或辦公室里獨立工作。
??隨著各公司邁向開放、協作的工作環境，組織也必須為需要不間斷時間來思考和工作的員工創 造安靜的空間。因此，各公司紛紛設計各自的辦公室，以平衡公共和社交區域(有時被稱為“公共 區”)與個人工作不被打擾的安靜區域或私人區域。
??擁有在不同地點工作的成員時，團隊會決定他們各自的工作場所有多少是虛擬的，多少是實際的。 諸如文檔共享、視頻會議和其他虛擬協作工具等技術可以幫助人員實現遠程協作。
??在不同地點工作的團隊成員需要虛擬的工作空間。另外，要考慮讓團隊成員定期聚集一堂，以便 建立信任，學習怎樣開展合作。
??分散式團隊管理溝通的一些技術包括魚缸窗口和遠程結對:
- 通過在團隊分布的各個地點之間建立長期視頻會議鏈接，創建一個魚缸窗口。每天工作開始 時，人們打開鏈接，工作結束時，關閉鏈接。通過這種方式，人員可以自然地看到彼此并進行 互動，減少了身處不同地點工作所固有的協作滯后問題。
- 通過使用虛擬會議工具來共享屏幕，包括語音和視頻鏈接，建立遠程結對。只要考慮了時區差 異因素，這種方法幾乎和面對面的結對一樣有效。
4.3.7 克服組織孤島
??組建敏捷團隊的最好開端是構建一個擁有基本信任和安全的工作環境，以此確保所有團隊成員都 有平等的話語權，他們的意見都能被聽到并得到考慮。這一點再加上構建敏捷思維模式，都是潛在 的成功因素，在此基礎上，所有其他挑戰和風險都能夠化解。
??孤島組織往往給跨職能敏捷團隊的組建帶來重重障礙。需要構建跨職能團隊的團隊成員通常需要 向不同的管理人員報告，管理人員會采用不同的標準衡量他們的績效。管理人員需要關注的不是資 源利用效率，而是過程效率(和基于團隊的指標)。
??為克服組織孤島問題，就要與團隊成員的不同管理者合作，讓他們為跨職能團隊安排必要的專職 人員。這樣不僅能建立團隊協同，而且能讓組織看到怎樣用人才能優化正在進行中的項目和產品。
5. 實施敏捷：在敏捷環境中交付
5.1 項目章程和團隊章程
??每個項目都需要一個項目章程，這樣項目團隊就能了解項目之所以重要的原因、團隊的前進方向 以及項目的目標。不過，對于團隊而言，僅有項目章程還不夠。敏捷團隊需要有團隊規范以及對一 起工作方式的理解。這種情況下，團隊可能需要一個團隊章程。
??制定章程的過程能幫助團隊學習如何一起工作，怎樣圍繞項目協作。
??對于敏捷項目而言，團隊至少還需要項目愿景或目標，以及一組清晰的工作協議。敏捷項目章程 要回答以下問題:
- 我們為什么要做這個項目?這是項目愿景。
- 誰會從中受益?如何受益?這可能是項目愿景和/或項目目標的一部分。
- 對此項目而言，達到哪些條件才意味著項目完成?這些是項目的發布標準。
- 我們將怎樣合作?這說明預期的工作流。
??仆人式領導可以促進章程的制定過程。團隊可以通過一起工作實現協作，而制定項目章程是一 種很好的開始工作的的方式。此外，團隊成員可能希望通過協作了解他們將如何一起工作。
??只要團隊知道如何一起工作，制定章程就不需要一個正式的過程。有些團隊可以從團隊制定章程 的過程中受益。下面是對團隊成員制定章程的一些建議，可以將其作為制定團隊社會契約的基礎: - 團隊價值觀，例如可持續的開發速度和核心工作時間;
- 工作協議，例如“就緒”如何定義，這是團隊可以接受工作的前提;“完成”如何定義，這樣
團隊才能一致地判斷完整性;考慮時間盒;或使用工作過程限制; - 基本規則，例如有關一個人在會議上發言的規定;
- 團隊規范，例如團隊如何對待會議時間。
??仆人式領導可以與團隊一起決定處理其他行為。
??請記住，團隊的社會契約，即團隊章程，將規定團隊成員之間彼此互動的方式。團隊章程的目標 是創建一個敏捷的環境，在這個環境中，團隊成員可以發揮他們作為團隊的最大能力。
5.2 常見敏捷實踐
5.2.1 至 5.2.8 節描述了一些最常見的敏捷項目實踐。
5.2.1 回顧
??回顧是最重要的一個實踐，原因是它能讓團隊學習、改進和調整其過程。
??回顧可以幫助團隊從之前的產品開發工作及其過程中學習。《敏捷宣言》背后的原則之一是:“團隊 要定期反省如何能夠做到更加有效，并相應地調整團隊的行為。”
??許多團隊使用迭代，尤其是為期兩周的迭代，因為迭代在最后會提示進行演示和回顧。不過， 團隊回顧并不需要迭代。團隊成員可以決定在這些關鍵時刻進行回顧:
- 當團隊完成一個發布或者加入一些功能時。這不一定是一個巨大的增量。它可以是任何發布， 無論它有多小。
- 自上次回顧以來，又過了幾周時間。
- 當團隊出現問題時，以及團隊協作完成工作不順暢時。
- 當團隊達到任何其他里程碑時。
??團隊可以通過分配足夠的時間學習受益，無論是在項目中間回顧，還是在項目結束時回顧。團隊 需要了解他們的工作產品和工作過程。例如，有些團隊在完成工作時遇到困難。團隊可以計劃用充 足的時間組織回顧，以此收集數據、處理數據、再決定之后要嘗試的實驗做法。
??首要的是，回顧并不是責備;回顧是讓團隊從以前的工作中學習并做出小的改進。
??回顧針對定性的(人的感覺)和定量的(衡量指標)數據，然后利用這些數據找到根源，設計對策，并制定行動計劃。項目團隊可以采取許多行動事項來消除障礙。
??考慮限制行動事項的數量，使團隊在即將進行的迭代或工作期間有能力改進。嘗試一次改進太多的事情卻沒有完成其中任何一件，比計劃完成較少的事情并成功全部完成要糟糕得多。然后， 在時間允許的情況下，團隊可以進行列表中的下一個改進。團隊選擇改進時，要決定如何衡量結果。然后，在下一段時間內要衡量結果，以驗證每個改進成功與否。
??來自團隊的一位促進者引導團隊通過一個活動對所有改進事項的重要性進行排序。完成對改進事 項的排序后，團隊為下一次迭代選擇合適的數量(或者在流程基礎上增加工作)。
5.2.2 待辦事項列表編制
??待辦事項列表是所有工作的有序列表，它以故事形式呈現給團隊。工作開始之前，不需要為整個 項目創建所有的故事，只需要了解第一個發布的主要內容正確即可，然后就可以為下一個迭代開發 足夠的項目。
??產品負責人(或產品負責人價值團隊，包括產品經理和產品領域的所有相關產品負責人)可能 會制作一個產品路線圖，以顯示預期的可交付成果序列。產品負責人根據團隊的實際成果重新規 劃路線圖。(關于路線圖的示例請參見附件 X3“敏捷適用性篩選工具”。)
5.2.3 待辦事項列表的細化
??在基于迭代的敏捷中，產品負責人往往在迭代中期的一次或多次會議中與團隊合作，為即將進行 的迭代準備一些故事。這些會議的目的是細化足夠的故事，讓團隊了解故事的內容，以及故事之間 的相互關系。
??至于細化過程應該有多長時間，還沒有達成共識。有一個連續區間:
- 基于流程的敏捷的即時細化。團隊將下一張卡片從待辦事項列表中拿出來討論。
- 許多基于迭代的敏捷團隊在兩周的迭代中用 1 小時的時間盒討論。(團隊選擇一個迭代持續 時間，為他們提供足夠頻繁的反饋。)
- 基于迭代的敏捷團隊的多次細化討論。團隊可以在陌生的產品、產品領域或問題領域使用這 一技巧。
??細化會議上，產品負責人可以向團隊介紹故事的創意，讓團隊了解故事中潛在的挑戰或問題。 如果產品負責人不確定依賴關系，還可以請求團隊對相應功能進行刺探，以了解風險。
??產品負責人有很多方法處理待辦事項列表的細化準備與會議，其中包括: - 鼓勵團隊在開發人員、測試人員、業務分析人員和產品負責人三方面開展合作，一起討論和撰寫故事。
- 把整個故事的概念呈現給團隊。團隊進行討論，并根據需要將其細化為許多故事。
- 與團隊一起尋找各種方法探索和撰寫故事，確保所有的故事都足夠小，以便團隊能源源不斷地
交付完成的工作。考慮每天至少完成一個故事。
??團隊通常有一個目標，就是每周用不超過 1 小時的時間來為下一批工作細化故事。團隊希望把時 間盡可能花在工作上，而不是計劃上。如果團隊需要每周花 1 小時以上的時間來細化故事，那么， 產品負責人可能會過度準備，或者團隊可能缺乏評估和細化工作所需的一些關鍵技能。
5.2.4 每日站會
??團隊成員利用每日站會對彼此做出小的承諾，發現問題，并確保團隊工作順利進行。
??為每日站會規定時間盒，不超出 15 分鐘。團隊以某種方式“過一下”看板或任務板，而團隊中的 任何人都可以主持站會。
??在基于迭代的敏捷中，每個人都輪流回答下列問題:
- 上次站會以來我都完成了什么?
- 從現在到下一次站會，我計劃完成什么?
- 我的障礙(或風險或問題)是什么?
??從這樣的問題得出的答案能夠讓團隊自我組織，并讓團隊成員為完成之前和整個迭代中承諾完成 的工作承擔彼此的責任。
??基于流程的敏捷有一種不同的方法，可以將注意力集中在團隊的產出上。團隊從右到左對看板進行評估。問題包括: - 我們還需要做些什么來推進這一工作?
- 有人在做看板上所沒有的事情嗎? uu作為一個團隊，我們需要完成什么?
- 工作流程是否存在瓶頸或阻礙?
??站會中常見的一個反模式是，站會變成了狀態報告會議。傳統上在預測環境中工作的團隊可能傾 向于采用這種反模式，因為他們習慣于報告狀態。
??另一個典型的反模式是，當問題變得明顯時，團隊才開始解決問題。站會是為了發現存在問題， 而不是解決它們。將問題添加到停車場區，然后創建另一次會議，它可以在站會之后立即召開， 并在會上解決問題。
??團隊可以舉辦自己的站會。只要體現了團隊工作需要的密切合作，進行順利，站會便會非常有用。 要針對團隊何時需要站會、站會是否有效等問題有意識地做出決定。
5.2.5 展示/評審
??當團隊以用戶故事的形式完成特定功能時，團隊會定期展示工作產品。看過展示后，產品負責人接受或拒絕故事。
??在基于迭代的敏捷中，團隊在迭代結束時展示所有已完成的工作項。在基于流程的敏捷中，團隊 在需要時展示完成的工作，通常是當完成的功能累積到足以構成一個連貫組合時。團隊，包括產品 負責人在內，都需要反饋來決定何時需要產品反饋。
??一般的指導方針是，每兩周至少展示一次團隊的工作產品。這種頻率對于大多數團隊來說是足夠 的，這樣，團隊成員就可以得到反饋，防止他們朝著錯誤的方向前進。這種頻率也足夠頻繁，讓團 隊可以保持產品開發足夠清晰，按照自己希望或需要的頻率構建一個完整的產品。
??使項目敏捷的一個基本要素是頻繁地交付工作產品。一個沒有展示或發布的團隊，其學習的速度 不會快，并且很可能并未采用敏捷技術。團隊可能需要額外的引導來保證頻繁的交付。
5.2.6 規劃基于迭代的敏捷
??不同團隊的能力各不相同。不同產品負責人的典型故事大小也各不相同。團隊應考慮自身故事大小，避免提交更多的故事，而超出團隊在一個迭代中所能完成工作的能力。
??產品負責人了解，當人員不可用時(例如，公共假期，度假期間，或阻止人員參加下一組工作的 任何事情)，團隊能力降低。團隊將無法完成與前一時期相同的工作量。在能力降低的情況下，團 隊只會計劃相應能力能夠完成的工作。
??團隊估算能夠完成的工作，這也是一種能力的衡量(示例參見 4.10 節)。團隊不能 100% 確定自己 能交付什么，因為他們無法知道意外情況。當產品負責人拆分故事使其變小時，團隊看到的是產品 的完成進度，團隊就會知道他們將來能夠做什么。
??敏捷團隊在一個工作塊中不會只計劃一次。相反，敏捷團隊會開始計劃一點，交付、學習，然后 在一個持續的循環中重新規劃更多的東西。
5.2.7 幫助團隊交付價值的執行實踐
??如果團隊不重視質量，很快就會無法快速發布任何東西。 下面的技術實踐中，很多都來自于極限編程，它們可以幫助團隊以最快的速度交付:
- 持續集成。無論產品如何，都要頻繁地將工作集成到整體中，然后再進行重新測試，以確定整 個產品仍然按照預期工作。
- 在不同層面測試。對端到端信息使用系統級測試，對構建塊使用單元測試。在兩者之間，了解是 否需要進行集成測試，以及在何處進行測試。團隊發現冒煙測試有助于測試工作產品是否良好。 團隊發現，決定何時以及對哪些產品運行回歸測試，可以幫助他們在維護產品質量的同時，良好 地構建性能。敏捷團隊非常偏愛自動化測試，因此他們可以借此構建和保持交付的勢頭。
- 驗收測試驅動開發 (ATDD)。在 ATDD 中，整個團隊聚集一堂討論工作產品的驗收標準。然后， 團隊創建測試，這讓團隊能夠編寫足夠的代碼，進行自動化測試，滿足標準要求。對于非軟件 項目，要考慮怎樣在團隊完成大量價值時對工作進行測試。
- 測試驅動開發 (TDD) 和行為驅動開發 (BDD)。在編寫/創建產品之前編寫自動化測試，實際上可 以幫助人員設計產品，防范產品錯誤。對于非軟件項目，要考慮如何通過“測試驅動”團隊 的設計。硬件和機械類項目經常使用模擬進行設計的中間測試。
- 刺探(時間盒研究或實驗)。刺探對學習很有用，可以在諸如評估、驗收標準定義以及通過產品 了解用戶行為的流程中使用。在團隊需要學習一些關鍵技術或功能要素時，刺探會很有幫助。
5.2.8 迭代和增量如何幫助交付工作產品
??迭代可以幫助團隊為交付和多種反饋創建一個節奏。團隊會為交付和反饋創建增量。交付的第一 部分是一次演示。團隊會收到關于產品的外觀和運行方式的反饋。團隊成員回顧如何檢查和調整有關過程以取得成功。
??演示或評審是敏捷項目流程的必要組成部分。為團隊的交付節奏安排適當的演示。
5.3 解決敏捷項目的挑戰
??出于解決具有高變化率、不確定性和復雜性的項目相關問題的需要，敏捷方法應運而生。由于這些原因，敏捷方法包含了各種各樣的工具和技術，用于處理預測法中出現的問題。參見表 5-1.
5.4 敏捷項目的衡量指標
??過渡到敏捷意味著要使用不同的衡量指標。使用敏捷意味著要審視對團隊和管理層都很重要的新指標。這些衡量指標很重要，因為它們關注的是客戶價值。
??狀態報告的一個問題是，團隊預測完成或使用交通燈狀態來描述項目的能力。例如，項目領導將 項目描述為“90% 完成”。此時，團隊正試圖將一個個片段集成到一個產品中。團隊發現，有缺少的 需求或者意外出現，或是產品沒有按照他們的想法集成。
??項目只是完成了一半，而交通燈狀態報告并未反映項目真實的狀態。項目團隊往往認識到，他們 還需要同樣長的時間才能完成項目的剩余部分。太多的項目存在這種情況:由于發現了問題，團隊 才認識到，自己最多只完成了 10% 的工作。
??預測型衡量指標的問題在于，它們往往并不反映真實的情況。往往直到發布日期前 1 個月，項目 狀態綠燈一直是亮的;這種項目有時被稱為西瓜項目(外面綠，里面紅)。項目狀態燈經常會變成 紅色，似乎沒有任何警告，因為直到發布日期前 1 個月，才會得到關于項目的經驗數據。
??敏捷項目的衡量指標包含有意義的信息，這些信息提供了歷史記錄，因為敏捷項目要定期交付 價值(完成的工作)。項目團隊可以利用這些數據改進預測和決策。
??替代衡量指標(如完成百分比)不如經驗指標(如已完成功能)更有用。有關價值管理的更多 信息，請參見 4.10 節。敏捷幫助團隊發現問題和難題，以便團隊能夠診斷和解決問題。
??除了定量指標之外，團隊還可以考慮收集定性衡量指標。其中一些定性衡量指標側重于團隊選擇 的實踐，評估團隊使用這些實踐的情況，例如，對交付功能的業務滿意度、團隊的士氣;團隊希望 跟蹤的任何東西等都是定性衡量指標。
5.4.1 敏捷團隊的衡量結果
??敏捷傾向于使用基于經驗和價值的衡量指標，而不是預測型 衡量指標。敏捷衡量團隊所交付的成果，而不是團隊預測將交 付的成果。
??對于一個習慣于掌握項目基準、估算的掙值和投資回報率 (ROI) 的團隊，可能會對實施一個項目而不是管理一個基準感 到茫然。敏捷是基于對客戶有可見價值的工作產品。
??基準通常是嘗試預測的產物。在敏捷中，團隊的估算最 多限于未來幾周時間。在敏捷中，如果團隊工作的可變性不 高，如果團隊成員沒有從事多任務，則團隊的能力就會變得 穩定。這樣才能對未來幾周做出更好的預測。
??完成迭代或流程中的工作后，團隊就可以進行重新規劃。敏 捷并不能創造出更多的工作能力。然而，有證據表明，工作量 越少，人員就越有可能交付。
??與其他知識型工作一樣，軟件產品開發關乎在交付價值的同時 進行學習。在項目的設計部分，硬件開發和機械開發是相似的。 學習的過程是通過實驗，交付微小的價值增量，并獲得對目前已 完成工作的反饋。其他許多產品的開發項目也包括學習。
??項目發起人通常想知道項目 什么時候能夠完成。一旦團隊 建立了穩定的速度(每個迭代 的故事或故事點的平均數量) 或平均周期時間，團隊就能夠 預測項目將花費多長時間。
??舉例來說，如果團隊平均每 個迭代有 50 個故事點，而團隊 估算還剩下大約 500 個點，于 是，團隊估算，還剩下大約 10 個迭代。隨著產品負責人對剩 余的故事進行細化，團隊對估 算進行細化，項目估算雖然可 能有升有降，但團隊卻能提供 一個估算。
??如果團隊平均完成每個故事 的周期為三天，還有 30 個故事 要完成，那么團隊將需要 90 個 剩余工作日，大約 4 到 5 個月。
??用颶風圖反映估算的可變性，也可使用發起人能夠理解 的其他一些可變性衡量方法。
??由于學習是項目的重要組成部分，因而，團隊需要在平衡不確定性的同時為客戶提供價值。團隊 要規劃項目要完成的下一個小部分。團隊報告經驗數據，并重新規劃其他小的增量，以此管理項目 的不確定性。
??某些基于迭代的項目使用燃盡圖查看項目隨時間的進展情況。圖 5-1 顯示了一個燃盡圖的例子， 其中，團隊計劃交付 37 個故事點。故事點對需求或故事的相關工作、風險和復雜性進行評估。許多 敏捷團隊使用故事點估算工作量。燃盡圖中的虛線表示計劃。圖 5-1 中，團隊可以看到，在第 3 天他們面臨交付的風險。
某些項目團隊更喜歡用燃起圖。如圖 5-2 所示的燃起圖中的數據與圖 5-1 相同。
??燃起圖顯示已完成的工作。圖 5-1 和圖 5-2 都是基于相同的數據，但分別以兩種不同的方式顯示。團隊可以選擇如何查看他們的數據。
??看到在迭代中尚未完成的工作時，團隊可能會變得沮喪，并且可能因為急于完成工作，而不滿足 驗收標準。不過，團隊可能有很多理由不按預期完成工作。燃盡圖顯示了團隊成員的多任務處理、 過于龐大的故事或團隊成員缺勤的效果。
??特別是對新建的敏捷團隊，燃起圖將顯示迭代過程中范圍內的變化。利用燃起圖，團隊能查看他 們已經完成的工作，這將有助于團隊進行下一項工作。
??無論使用燃盡圖還是燃起圖，團隊都能看到在迭代過程中完成的工作。在迭代結束時，他們可能 會根據自己在這個迭代中完成工作的能力(多少故事或故事點)來建立他們下一個迭代的能力衡量 指標。這樣，產品負責人與團隊一起重新規劃，團隊就更有可能在下一次迭代中成功交付。
??速度，也即本次迭代中實際完成功能的故事點大小的總和，讓團隊得以通過觀察歷史表現來更準 確地規劃下階段的能力。
??基于流程的敏捷團隊使用不同的衡量指標:交付周期(交付一個工作項目花費的總時間，從項目 添加到看板直至項目完成)、周期時間(處理一個工作項目所需的時間)和響應時間(一個工作項 目等待工作開始的時間)。團隊通過衡量周期時間發現瓶頸和延遲問題，問題不僅限于團隊內部。
??交付周期有助于理解從第一次查看特定功能到向客戶發布該功能所需的周期時間。在制品(WIP) 限制 位于各列頂部(此處在框中顯示)，讓團隊了解如何從看板上提取工作。達到 WIP 限制后，團隊就不 能將工作從左邊提取到下一列。此時，團隊就要從最右邊的列中提取工作，并提出問題:“作為一個 團隊，我們應該怎樣做才能將這項工作移到下一列中?”
??每個功能都是獨一無二的，所以它的周期時間也是獨一無二的。不過，產品負責人可能會注意 到，較小的功能周期時間也較短。產品負責人希望看到產出，因此產品負責人創建較小的功能，或者與團隊合作創建。
??燃起圖、燃盡圖(能力衡量指標)和交付周期，以及周期時間(可預測的衡量指標)對于實時測 量非常有用。它們可幫助團隊了解他們共有多少工作，以及團隊是否能按時完成工作。
??故事點衡量與已完成的故事或功能的衡量有所不同。有些團隊試圖在沒有完成實際功能或故事的 情況下衡量故事點。團隊僅衡量故事點時，衡量的是能力，而不是已完成的工作，這違背了“可用 的軟件(或者，如果不是軟件，則是其他的產品)是衡量進度的主要指標”的原則。
??每個團隊都有自己的能力。在使用故事點時，團隊要認識到，在給定時間內能夠完成的故事點數 量對一個團隊而言是唯一的。
??根據自身的指標單位進行衡量，團隊就能更好地評估和估算自己的工作，并最終交付。相對估算 的缺點是，無法比較各個團隊或者在團隊之間增加速度。
??團隊可以在一個功能燃起圖/燃盡圖和一個產品待辦事項列表中衡量已完成的工作。這些圖表提供 了隨時間變化的完成趨勢，如圖 5-4 所示。
??功能燃起圖/燃盡圖可顯示項目期間需求的發展。功能完成線顯示團隊以正常速度完成功能。總功能線顯示了項目的總功能隨時間的變化。剩余的燃盡線顯示功能完成速度的變化。每次在項目中添加功能時，燃盡線都會有改變。
??在敏捷中的掙值是基于已完成的功能，如圖 5-5 所示。產品待辦事項列表燃起圖顯示已完成的工作 與區間里程碑或迭代中的預期工作總量的比較。
??一個團隊一次只能完成一個故事。為了完成一個包含多個故事的大功能，團隊會有待完成的剩余故事，并且除非擁有更多的時間，否則可能無法完成整個功能。團隊可以用一個產品待辦事項列表 燃起圖來顯示已完成的價值，如圖 5-5 所示。
??如果一個團隊需要衡量掙值，可以考慮使用燃起圖，以圖 5-6 為例:請注意，左邊 Y 軸代表了故事點的范圍，右邊 Y 軸代表項目的支出。
??傳統的掙值管理 (EVM) 衡量指標，如進度績效指數 (SPI) 和成本績效指數 (CPI) 可以很容易地轉換為敏捷 術語。例如，如果團隊計劃在一次迭代中完成 30 個故事點，但是只完成了 25 個，那么 SPI 是 25/30 或 者 0.83(該團隊的工作速度只有計劃的 83%)。同樣，CPI 是迄今為止的勞動價值(已完成的功能值) 除以實際的成本，如圖 5-6 所示，$2.2M / $2.8M = 0.79。這意味著，與計劃相比，僅能得到 79 美分的結 果(當然，這是假定預測仍然正確)。
??圖 5-7 中所示的累積流圖顯示了看板上進行中的工作。如果一個團隊有許多等待測試的故事，測試 團隊將會擴大。累積工作可一目了然。
??團隊在處理累積工作方面有困難:團隊有進行中的工作，而不是已完成工作。如果團隊有大量進 行中的工作，就會延遲整體功能的交付。團隊交付的時間越長，在相同時間內有更多功能，團隊的壓力就越大。
將此累積流調整到項目任務板。
6. 關于項目敏捷性的組織考慮因素
??每個項目都存在于組織環境下。文化、結構和政策可能會影 響到所有項目的方向和成果。這些動態變化可能會對項目領導 提出挑戰。
??項目領導可能無法根據自己的意愿來改變組織動態變化， 但可以有技巧地引導這些動態變化。
??本章探討了組織以及(在某些情況下)項目環境影響項目的 方式。領導可以通過探討變革方案來提高項目成功率。
6.1 組織變革管理
??組織變革管理一節涵蓋了會影響敏捷應用情況的技能和技術。
??PMI 出版物《組織變革管理實踐指南》[2] 介紹了成功引入有 意義變革的全面整體性方法。該指南提供的建議包括:
- 說明變革動態變化的模型;
- 實現變革的框架;
- 項目、項目集和項目組合層面的變革管理實踐的應用。
6.1.1 和 6.1.2 節探討了特定敏捷環境中變革管理的考慮事項。 圖 6-1 顯示了這兩個主題之間的關系。
6.1.1 變革管理驅動因素
??所有項目都涉及到變革。但是，有兩種主要因素會進一步激勵敏捷環境中變革管理實踐的應用:
- 與加速交付相關的變革。敏捷方法強調頻繁并盡早交付項目輸出。但是，接收組織可能尚未做 好加速納入這些輸出的充分準備。加速交付將會考驗組織適應該交付的能力。成功發現和交付 項目功能是不夠的。如果組織抗拒項目輸出，則會延遲目標投資回報。客戶接受并支持項目輸 出在敏捷環境中日益盛行。
- 與敏捷方法相關的變革。組織在剛開始采用敏捷方法時也會經歷更高程度的變革。高級別協 作可能需要團隊、部門或供應商之間更頻繁地交流。將工作分解到迭代原型時會涉及到不利 的返工。領導應考慮利用變革管理技術來解決過渡到敏捷方法時所遇到的阻礙。
6.1.2 變革就緒情況
??組織在開始采用敏捷方法時應了解這些方法與其當前方法之間的相對兼容性。某些組織的特征可能
更容易支持跨部門協作、持續學習和內部過程演變等敏捷原則。這些變革友好型特征的示例包括:
- 管理層的變革意愿;
- 組織在員工認知、審核和評估方式上做出改變的意愿;
- 集中或分散項目、項目集和項目組合管理職能;
- 專注于短期預算和指標而不是長期目標;
- 人才管理成熟度和能力。
??相反，還有其他一些機構特征可能會成為實現組織敏捷性相關變革的障礙。這些特征示例包括:
- 工作被分解為部門孤島，從而創造出阻礙加速交付的依賴關系，而不是構建在能力中心指導下 的跨職能團隊。
- 采購策略基于短期定價策略，而不是長期能力。
- 獎勵領導的依據是本地效率而不是端到端項目交付流或整體優化情況(就組織而言)。
- 員工屬于特定領域人才，實現技能多元化的工具或激勵有限，不重視培養T型專家人才。
- 分散化項目組合使員工同時分配到過多的項目，而無法專注于單個項目。
??組織審查和修改這些實踐的意愿程度將決定采用敏捷方法的速度和效率。但是，為了解決這些敏捷組織障礙，項目領導可以嘗試多種方法來加速文化兼容性: - 積極明確的管理層支持;
- 變革管理實踐，包括溝通和引導;
- 逐個項目應用敏捷實踐；
- 向團隊增量地引入敏捷實踐;
- 通過采取適用的敏捷技術和實踐示范引導。
6.2 組織文化
??組織文化就是組織的 DNA – 組織的核心標識。文化始終影響 敏捷方法的使用。組織文化一直在連續運轉，從高預測型計劃 到一切皆為實驗的精益創業階段均有體現。盡管敏捷方法與 精益創業文化相當吻合，高預測型組織可以鼓勵實證的衡量指 標、小型實驗和不斷學習以便向敏捷方向轉變。
6.2.1 創建安全環境
??組織文化難以改變，但組織中最重要的文化規范—愿意嘗試任何新方法或技術—將有利于構建安全的工作環境。
??只有在安全、誠實和透明的環境中，團隊成員和領導才可以 真正反思其成功，確保項目持續進步，或者應用從失敗項目中 所吸取的教訓，不再重蹈覆轍。
6.2.2 評估文化
??每個項目都會遇到相關方意愿相左的棘手情況。團隊如何在 不影響質量的情況下取得快速進展?團隊如何在保留靈活性的 同時確保時效性?更重要的是，團隊如何滿足客戶需求?
??項目領導可能感覺其職責就是滿足各個相關方的期望;但是 在面對選擇時，通常需要根據組織業務環境的文化和要求來確定優先級。例如，移動電信項目偏重于速度，而政府項目可能偏重于大眾化和穩定性。
??要引導這些動態變化，項目領導應花費時間去評估組織通常所關注的重點。圖 6-2 顯示了有關如何 評估的示例。在這個例子中，項目領導發起了與相關方、團隊成員和高層管理者的對話以討論組織優先級。這些優先級根據滑動標尺在這兩個極端之間的位置來進行記錄，然后再利用該結果去找到最適合這些優先級的敏捷技術。
??有一些模型可用于評估這些動態變化;但是，采取何種模型或方法并不重要，關鍵是讓項目領 導了解其環境的驅動因素。了解某組織需要滿足的組織與行業需求后才能選擇合適的對話、權衡 尤其是技術。
6.3 采購和合同
??如本實踐指南中前面所述，《敏捷宣言》認為“客戶協作高于合同協商”。許多項目失敗源于客戶供應商關系破裂。如果合同相關方懷有非贏即輸的想法，通常會給項目帶來更多的風險。協 作方法提倡共擔項目風險和共享項目獎勵的關系，實現所有方共贏。設計這種動態特性的合同簽 署技術包括:
- 多層結構。除了在單個文檔中正式說明整個合同關系，項目方可以通過在不同文檔中說明不同方面來提高靈活性。通常固定項目(如擔保、仲裁)可以鎖定在主協議中。同時，所有方將可能會變更的其他項目(如服務價格、產品說明)列在服務明細表中。合同主要服 務協議中注明這些服務參考。最后，范圍、進度計劃和預算等更多動態變化項目可以列在 輕量級工作說明書中。通過將合同中的更多變化因素隔離到單獨的文檔中，將會簡化修改 工作并提高靈活性。
- 強調價值交付。許多供應商關系是由專注于中間人為因素的固定里程碑或“階段關口”控制，而不是由增量業務價值的完全可交付成果控制。通常，這些控制會限制利用反饋來改 進產品。與之相反的是，里程碑和支付項目可以根據價值驅動可交付成果來構建，以增強 項目敏捷性。
- 總價增量。項目可以將范圍分解為總價微型可交付成果(例如用戶故事)，而不是將整個項 目范圍和預算鎖定到單個協議中。對于客戶而言，這可以更好地控制資金流向。對于供應商 而言，這可以限制對單個功能或可交付成果的過多承諾所帶來的財務風險。
- 固定時間和材料。客戶在采用傳統的時間和材料方法時會產生不必要的風險。一種替代方法 是將整體預算限制為固定數量。這就允許客戶在最初未計劃的項目中納入新的觀點和創新。 如果客戶需要納入新的觀點，則必須管理給定能力，用新的工作來替代原有工作。應密切監 控工作，防止所分配的時間超過其限制。此外，在認為有用的情況下，還可以在最大預算中 規劃額外應急時間。
- 累進的時間和材料。另一種替代方法是共擔財務風險法。在敏捷方法中，質量標準是已完成工 作的一部分。因此，如果在合同期限之前交付，則可對供應商的高效率進行獎勵。相反，如果 供應商延遲交付，則將扣除一定費用。
- 提前取消方案。如果敏捷供應商在僅完成一半范圍時便可交付足夠的價值，且客戶不再需要另 外一半范圍，則不必支付這部分費用。但合同中可以規定客戶應為項目剩余部分支付一定的取 消費用。因為不再需要這些服務，客戶可以限制預算敞口，而供應商也可獲得可觀的收入。
- 動態范圍方案。對于具有固定預算的合同，供應商可為客戶提供在項目特定點改變項目范圍 的方案。客戶可調整功能以適應該能力。這樣客戶便可利用創新機會，同時限制供應商的過 度承諾風險。
- 團隊擴充。大多數協作合同方法是將供應商服務直接嵌入客戶組織中。通過資助團隊而不是特 定范圍，可以保留客戶自行確定需要完成工作這方面策略的權力。
- 支持全方位供應商。為了分化風險，客戶可能需要采取多供應商策略。但是，這樣簽署合同的結 果是，每家供應商只能負責一項工作，這就會產生許多依賴關系，阻礙可行服務或產品的交付。 相反，要強調提供全面價值的合約(這與已完成獨立功能集中的觀點相符)。
??可以創建敏捷合同。敏捷是在協作和信任的共同基礎上建立的。如果供應商能夠盡早頻繁交付價值，則有助于實現這一點。如果客戶能夠提供及時反饋，則有助于實現這一點。
6.4 商業實踐
??在需求產生時，組織創建新能力的意愿和能力即是組織敏捷性的標志。對于關注敏捷及其所提供結果的組織而言，這些不必是顛覆性的變革，破壞性較小。透明和開放協作至關重要。
??在跨職能團隊交付價值時，團隊和個人可能會遇到組織多種支持職能方面的問題。
??如果團隊定期交付價值，財務部門可能有機會以不同的方式獲得產品收益。如果團隊與其他組織簽署了合同，采購部門可能需要變更這些合同，以幫助其他組織頻繁交付價值并與團隊保持同步。
??團隊開始以團結協作的方式展開工作后，將會對內部管理策略提出挑戰。人力資源可能注意到個人激勵不足，而經理可能會在自組織員工的績效評估方面絞盡腦汁。在各種情況下都有機會評審現 有實踐對敏捷工作方式的支持程度。
??當組織發展到更高敏捷性時，其他業務部門將有必要更改其交互方式并履行自己的職責。現在應擁護對組織其他領域有益的變更，以此來提高整個組織的效率。
6.5 多團隊協作和依賴關系(擴展)
??多個項目之間會產生依賴關系，即使不是在給定項目集中進行管理。因此有必要了解敏捷工作在現有項目集和項目組合管理環境下的工作方式。
6.5.1 框架
??大多數流行敏捷方法(如 Scrum 和極限編程)的指導專注于單個小型且通常是集中辦公的跨職能 團隊活動。這對于需要單個團隊的工作非常有用，但對于需要在一個項目集或項目組合中進行多個敏捷團隊協作的舉措卻顯得捉襟見肘。
6.5.2 考慮事項
??有多種擴展工作的方式。團隊可能需要將多個敏捷項目工作擴展到單個敏捷項目集中。或者，組織可以設計出支持整個項目組合中不同敏捷方法的結構。
??例如，可以從小項目著手，然后盡快了解組織環境中比較適合的方式。即使一切還未完全轉換到敏捷方法，團隊仍可獲得成功。
??無論采用哪種方法，關鍵成功因素是健康的敏捷團隊。如果單個團隊采取敏捷方法無法獲得成功， 則勿嘗試將其擴展到更大范圍;而是要先行解決阻止團隊敏捷工作的組織障礙。
??大規模敏捷項目的目標是協調不同團隊的工作以便為客戶提供價值。這有多種實現方式。團隊可 以采用正式的框架或應用敏捷思維調整現有項目集管理實踐。
6.6 敏捷和項目管理辦公室 (PMO)
??設立 PMO 的目的是引導組織實現商業價值。可以通過幫助實現項目目標來做到這一點。PMO 有時還會提供團隊教育(或安排培訓)和項目支持。PMO 還會針對給定項目或項目集提供相關商業價值 方面的管理建議。
??由于敏捷會帶來文化變更，隨著時間的推移，組織可能也需要變更，包括 PMO。例如，經理會決 定資助的項目及其時間，團隊會決定培訓或建議需求。
6.6.1 敏捷 PMO 為價值驅動型
??所有項目都應在合適的時間為合適的受眾提供合適的價值。PMO 的目標是幫助促進這個目標的 實現。基于敏捷的 PMO 方法以客戶協作思維為基礎，并存在于所有 PMO 項目集中。在許多情況下，這意味著 PMO 的運營方式類似于咨詢企業，需要根據給定項目的特定需求來定制其工作。有 些項目可能需要工具和模板，還有些項目可能會從管理層引導中獲益。PMO 應努力按需交付并緊 跟客戶需求，確保了解并適應他們的需求。這種內部創業方法專注于能為所支持的項目提供最大 價值的 PMO 活動。
6.6.2 敏捷 PMO 為面向創新型
??為了在基于價值的章程下加速發展，PMO 可能需要強制執行某些解決方案或方法，例如，保持所 有人行動的一致性以快速獲得成功。但需要確保員工的參與意愿才能提高效率。只邀請感興趣的人 員參與 PMO 服務即可實現這一點。PMO 實踐的參與度越高，便更容易提高這些實踐的“粘合力”。 如果 PMO 為其客戶提供了價值，則客戶很可能會要求這種服務并采用其實踐。
6.6.3 敏捷 PMO 為多學科型
??為了支持特定項目需求，PMO 還需要熟悉項目管理本身以外的其他一些能力，因為不同的項目要 求不同的能力。例如，一個項目可能需要組織設計來解決人員配備挑戰，而另一個項目可能需要組 織變革管理技術來確保相關方參與或獲得獨特的業務模型以支持客戶目標。
??某些組織已將其 PMO 轉換為卓越敏捷中心以提供以下服務:
- 制定和實施標準。提供用戶故事、測試案例、累積流圖等模板，提供敏捷工具并培訓支持小組了解迭代開發概念。
- 通過培訓和指導發展人才。協調敏捷培訓課程、教練和導師以幫助員工過渡到敏捷思維模式并 升級其技能。鼓勵和支持員工參與本地敏捷活動。
- 多項目管理。通過不同項目交流協調敏捷團隊。考慮分享進度、問題、回顧性發現和改進實驗 等內容。借助適當的框架，幫助管理項目層的主要客戶發布和項目組合層的投資主題。
- 促進組織學習。收集項目進度信息并獲取、存儲和記錄回顧性發現成果。
- 管理相關方。提供產品負責人培訓，指導驗收測試以及評估方法，并提供系統反饋。宣揚主題專家 (SME) 對項目的重要性。
- 招聘、篩選和評估項目領導。制定敏捷實踐者訪談指南。
- 執行專業化項目任務。培訓和提供回顧促進者，與敏捷項目問題解決者訂立協議，并提供導師和教練。
6.7 組織結構
??組織結構會嚴重影響其轉向新信息或轉變市場需求的能力。下面列出了主要特征:
- 地理。地理分散的項目組織可能會在各種項目中發現阻礙工作進展的一些挑戰。項目領導和區域經理可能持有不同或相反的目標。此外，文化差異、語言障礙和低可視化可能會降低工作效率。幸運得是，采用敏捷方法可以鼓勵更好的協作并提高信心。在這些環境下，項目領導應鼓 勵團隊和管理層對話，定制該環境所需的技術并管理對工作需求的期望。
- 職能結構。有些組織按照高度項目型、矩陣型或高度職能型的方式構建。具有高度職能結構的 項目可能會在組織內部協作方面遇到很大阻力。
- 項目可交付成果的大小。縮小項目可交付成果將會激勵部門之間更頻繁的交流，由此帶來更頻 繁的交互以及組織內部更快速的價值流動。
- 項目人員分配。另一種方法是在各個部門中抽出一個人，將其臨時完全分配到最高優先級項目。
- 重采購型組織。有些組織選擇主要通過供應商實施項目。盡管項目目標可能非常明確，供應商也有責任監管自己的財務狀況。但是，供應商完成其義務并退出合約后，相關項目知識也 將隨之帶走。這就會限制持續靈活性和速度所需的內部能力。如果在供應商還參與時采用敏 捷技術(例如回顧和跟蹤可能改進的領域)，則可幫助緩解產品知識缺失情況。
6.8 組織演變
??應對單個挑戰領域或實施新的混合或敏捷方法時，建議以累積方式承接工作。常用實踐是將變更過程視為一個敏捷項目，團隊可以根據自己的價值觀或其他考慮事項引入自己的變更待辦事項列表 并確定其優先級。每個變更可以被視為一個實驗，將進行短時間測試以確定每個變更的適應性以及 進一步細化/考慮需求。
??使用看板面板跟蹤進度，顯示已作為“已完成”使用的新方法、被視為“進行中”的方法、以及仍 在等待被引入“待辦事項”的方法。請參見圖 6-3 以了解具有待辦事項列表排序的初始面板。圖 6-4 顯示了面板工作進度的示例。
??通過使用這些工具來組織和管理變更實施，將可提供進度的可視化并對正在實施的方法進行建模。以透明和吸引人的方式部署變更，將可以提高成功可能性。
7. 專欄知識鏈接
項目管理綜述
項目整合管理
項目范圍管理
項目進度管理
項目成本管理
項目質量管理
項目資源管理
項目溝通管理
項目風險管理
項目采購管理
項目相關方管理
敏捷實踐指南
總結
