靈活實踐指南

目錄

• 申明
• 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. 專欄知識連結

項目管理綜述

項目整合管理

項目範圍管理

項目進度管理

項目成本管理

項目品質管理

項目資源管理

項目溝通管理

項目風險管理

項目采購管理

項目相關方管理

靈活實踐指南