開始導入 Scrum 之後不久，一定會有人問：「我們做得怎麼樣？」這不是一個能用「我們做得很好」這樣的簡單答案回應的問題。同樣地，你也無法簡化為「我們是 Scrum 第三級」這種說法。導入 Scrum 是一個複雜的過程，回答進展如何也需要一個複雜的答案。幸運的是，許多先行者已經嘗試了不同方法，並記錄了幾種可用的方式。
本章依序介紹三種通用敏捷度評估方法、如何建立自訂評估、以及使用平衡計分卡從多個面向來檢視 Scrum 轉型的進展。
衡量的目的#
在深入討論衡量什麼之前，先思考為什麼要衡量。多數人認為衡量的目的是確定某事物有多大、多重、多長——但這是一個過度野心的定義。衡量的真正目的是降低不確定性（reduce uncertainty）。衡量不需要絕對精確，只要能幫助我們減少不確定性就夠了。
軟體度量的討論經常因追求完美而陷入泥沼。我們不需要完美的衡量——我們需要的是能幫助我們回答問題的衡量。關於 Scrum 導入成功與否，最常見的問題包括：
- 我們投入 Scrum 的投資值得嗎？
- 我們下一步應該專注改善什麼？
- 我們應該繼續使用 Scrum 嗎？
- 我們的軟體開發能力比一年前更好了嗎？
- 我們的產品品質更好了嗎？缺陷更少了嗎？
- 我們的速度更快了嗎？
通用敏捷度評估#
許多問題可以直接回答，例如比較採用 Scrum 前後的缺陷數量。但有時候我們感興趣的是更深層的問題：我們有多敏捷？
作者認為，雖然有人主張不該在意「有多敏捷」，而應該只關心是否更快更好地產出產品，但團隊的敏捷程度是一個有用的代理指標（proxy metric）。透過評估團隊是否更擅長在 sprint 中工作、是否更好地協作、是否更穩定地產出可交付的產品增量，我們可以預測這些改善最終將帶來更好的商業成果。
以下介紹三種通用方法：
Shodan Adherence Survey#
Shodan Adherence Survey 是最早的評估方法之一，由 Bill Krebs 開發。這是一份涵蓋 15 個 Extreme Programming 實踐領域的自評問卷，每個問題包含一段簡短描述和一組完全遵循該實踐時應成立的事實列表。回答的評分範圍為 0（不認同使用此實踐）到 10（對此實踐狂熱）。
最終分數由各實踐領域的回答結合 Krebs 預設的權重計算得出，結果為 0 到 100% 的數字。其中 daily scrum 的權重最低（不到 1%），而 pair programming 的權重最高（12.5%）。
使用建議：
- 不建議每個 sprint 結束時都做——太頻繁會讓趨勢難以辨識
- 建議每六個月進行一次，最多不超過每三個月一次
- 不要將此問卷取代 sprint retrospective 中的開放式討論
優點： 只有 15 個問題，簡潔快速。 缺點： 結果不具直接可操作性——某個實踐的低分可能源自其中任何一個要素，需要進一步調查才能知道如何改善。
Agile: EF#
Krebs 和他在 IBM 的同事後續開發了 Agile Evaluation Framework（Agile:EF）。這個方法更強調簡潔，更像是一個評估流程而非固定框架。
核心做法是讓團隊成員定期填寫一份極短的問卷，可以在每個 sprint 結束時進行。每個問題針對一個敏捷實踐，使用 1-10 的量表評分（1 表示從未執行，5 表示 50% 的時間執行，10 表示 100% 執行）。Agile:EF 不推薦特定的問題集，而是建議使用既有的問題集（例如 Shodan 的問題）。
Figure 21.1: Sample results from an Agile:EF survey
Figure 21.1 展示了 Agile:EF 評估結果的呈現方式：實心長條代表團隊平均值，較細的線條顯示意見的離散程度（標準差或最高/最低值）。
使用建議： 作者建議不要每個 sprint 都問同一組 15 個問題，而是準備多組問題，每組聚焦在軟體開發流程的不同面向。每個 sprint 或每個月輪換一組，等到輪完一輪時，團隊已有足夠時間在各領域做出有意義的改善。
優點： 定期、快速、不打擾的評估方式，回覆率較高。 缺點： 不推薦特定問題集讓它難以真正作為一個「框架」運作。
Comparative Agility Assessment#
作者與 Kenny Rubin 共同開發了 Comparative Agility（CA） 評估。CA 的核心理念來自一個客戶的問題：「跟競爭對手相比，我們做得怎麼樣？」
作者起初認為不該關心競爭對手，但後來意識到：企業不需要追求完美，只需要比競爭對手更好。敏捷度不是為了追求某個理想化的標準，而是為了能比競爭對手更快更好地交付產品。
CA 評估在七個維度上評估敏捷度：teamwork、requirements、planning、technical practices、quality、culture 和 knowledge creation。回答者可以基於問卷回覆，也可以由資深 ScrumMaster、教練或顧問根據訪談或觀察代為填寫。
Figure 21.2: The results of an Agile:EF assessment across three dimensions
結果可以與整個 CA 資料庫或其子集進行比較——例如與所有做 web 開發的公司、所有導入 Scrum 約六個月的公司等。Figure 21.2 展示了一個團隊在 Planning、Requirements 和 Quality 三個維度上與資料庫平均值的比較：零代表資料庫中所有匹配團隊的平均值，-2 到 +2 代表標準差。
每個維度由 3 到 6 個特徵（characteristic）組成。例如 Planning 維度包括：規劃發生的時機、誰參與、是否同時進行 release 和 sprint planning、關鍵變數是否被鎖定、如何追蹤進度。問題使用 true / more true than false / neither true nor false / more false than true / false / not applicable 的量表回答。
優點： 比較性質是最大的優勢——能看到組織在業界中的位置；設計上更容易導出可操作的結果，因為可以逐層深入到具體特徵。 缺點： 問卷包含近 125 個問題，篇幅較大。建議每年做一到兩次完整評估，或每月只評估七個維度中的一個。
建立自訂評估#
部分組織選擇自行建立評估，例如 Ultimate Software、JDA Software、Yahoo! 和 Salesforce.com 都這麼做。自訂評估的好處是能完全貼合組織需求：
- 從 Shodan 或 CA 等既有評估中借用問題作為起點
- 丟棄與組織無關或不會產生有趣結果的問題
- 加入針對員工對變革看法的定性問題
例如 Yahoo! 在轉型期間問了以下問題：
- 採用 Scrum 後，你認為團隊的生產力如何？
- 採用 Scrum 後，士氣有什麼變化？
- 採用 Scrum 後，你對專案的責任感和擁有感有什麼變化？
- 採用 Scrum 後，團隊的協作程度有什麼變化？
- 採用 Scrum 後，你認為開發產出的整體品質如何？
回答選項為 Scrum is much worse / Scrum is worse / Scrum is about the same / Scrum is better / Scrum is much better。
Salesforce.com 也問了類似問題，包括「你認為 Scrum 是有效的方法嗎？」、「Scrum 對產品品質的影響是什麼？」、「你會向公司內外的同事推薦 Scrum 嗎？」
有人質疑「誰在乎員工怎麼想」，但開發人員處於最佳位置來評估工作方式的改變。只要沒有「如果 Scrum 讓生產力翻倍就發獎金」這類扭曲激勵，多數員工會如實回答。
Scrum 團隊的平衡計分卡#
單一指標無法完整呈現團隊的表現。如果告訴團隊將依據缺陷追蹤系統中的缺陷數量來評估，缺陷數可能會下降——可能是因為真正的改善，也可能是因為團隊找到方法繞過追蹤系統非正式地溝通 bug。我們需要一個更平衡的觀點。
Robert Kaplan 和 David Norton 提出的平衡計分卡（balanced scorecard）概念認為，要完整了解一個企業的績效，必須從多個視角來看。作者自 2000 年起將此方法應用於軟體開發團隊，並推薦以下四個視角（源自 Liz Barnett for Forrester Research）：
- Operational Excellence（卓越營運）： 團隊追求高品質產品、高生產力，同時達成目標成本與時程
- User Orientation（使用者導向）： 團隊專注於交付使用者和客戶想要的功能
- Business Value（商業價值）： 團隊以成本節省、營收增加等形式為企業交付價值
- Future Orientation（未來導向）： 在交付當前產品和功能的同時，團隊也為未來建立技能與能力
建構平衡計分卡#
每個視角下設定 1 到 4 個策略目標。針對每個目標，需要辨識至少一個領先指標（leading indicator）和一個落後指標（lagging indicator），並為每個指標設定目標值。
- 領先指標：預期在達成目標之前就能觀察到變化的指標。例如為了改善品質，領先指標可以是測試案例數量的增加——更多測試不保證品質更好，但它是一個好的預兆
- 落後指標：只能在目標達成（或未達成）之後才能衡量的指標。例如客戶回報的發佈後缺陷數量。落後指標能確認目標是否真正達成，但缺點是事後才知道
結合領先和落後指標最為有效。以下是作者提供的平衡計分卡範例（Table 21.3）：
| 視角 | 目標 | 領先指標 | 落後指標 |
|---|---|---|---|
| Operational Excellence | 提升生產力 | Sprint 中被刪除的 backlog 項目百分比（目標：5-15%）；週末 source control check-in 百分比（目標：< 5%） | 每位開發者交付的功能數（目標：提升 20%） |
| 時程可預測性 | 在專案中期預測的 -1 到 +2 個 sprint 內完成的專案數（目標：95%） | ||
| 更高品質 | CI 建構中通過的測試百分比（目標：95%） | 發佈後 30 天內回報的缺陷數（目標：減少 50%） | |
| User Orientation | 提升系統可用性 | 伺服器停機時間（計畫+非計畫）< 120 分鐘/年 | |
| 提升使用者滿意度 | 客戶焦點小組回覆率增加（目標：提升 20%） | Net promoter score（目標：提升 25%）；季度客戶滿意度調查（目標：80% 表示「超出」或「遠超預期」） | |
| Business Value | 更頻繁的主要發佈 | 所有專案製作並展示 release burndown chart（目標：100%） | 每季至少一次主要發佈（目標：兩次發佈間不超過 90 天） |
| 發佈中包含更多功能 | 每次發佈中使用者可見的 backlog 項目數（目標：300） | ||
| Future Orientation | 提升員工滿意度 | 人力資源部門收到的投訴數（目標：每月 1 件） | 表示「在這裡工作是最美好的時光」的員工數（目標：80%） |
| 提升對 Scrum 和敏捷的理解 | 參加敏捷會議的人數（目標：今年送 40 人參加） | 願意向朋友推薦 Scrum 的員工數（目標：80%） |
偏好簡單指標#
從上表可以看出，許多指標相當簡單。例如「每位開發者交付的功能數」——你可能會質疑這太過粗糙，功能大小不一、重要性不同。確實如此，但簡單指標在長時間跨度下進行比較時仍然很有幫助，尤其是與其他簡單指標結合使用時。
Salesforce.com 就是使用簡單指標的成功案例。導入 Scrum 12 個月後，公司測量到每位開發者交付的功能數比前一年增加了 38%。這個指標幫助消除了不確定性——Enterprise Transition Community 之前不確定 Scrum 是否讓團隊更有生產力，測量之後他們有了答案。
另一個 Salesforce.com 使用的簡單指標是 Steve Greene 和 Chris Fry 製作的 cumulative value（累積價值） 圖表。這張圖同時展示了多少新功能被交付以及何時被交付。曲線下的面積代表使用者獲得的整體價值——越早交付的功能價值越高。2006 年（導入 Scrum 前），Salesforce.com 直到一月才向使用者交付新功能；2007 年，更頻繁的發佈帶來更多的總交付功能，展示了 568% 的改善。
Figure 21.3: Cumulative value (features) delivered after adopting Scrum
真的值得費這個功夫嗎？#
收集指標即使是簡單指標也需要付出努力，而軟體產業在這方面的記錄並不出色。作者認為答案是肯定的，並指出三個主要好處：
- 指標幫助對抗組織慣性（organizational gravity）： 如同第 2 章討論的 ADAPT 模型，組織慣性會試圖將人拉回採用 Scrum 前的舊狀態。定期評估和指標是對抗這種慣性的最佳方式之一
- 指標幫助推廣轉型工作： 好的評估計畫不僅對抗慣性，還能幫助吸引其他團隊加入 Scrum。回想 ADAPT 模型中「推廣」步驟的重要性——指標能量化你的早期成功，吸引更多人參與
- 指標幫助聚焦進一步的改善： 指標應該導向行動。如果收集的數據從未引發行動，就停止收集那些數據，改而收集不同的數據。好的評估計畫能辨識需要改善的領域（以及值得表揚的領域）
作者以一個警告結束本章：每當數字被收集，組織中總會有人過度重視這些數字，然後用它們來打擊團隊。本章描述的指標應該被用來聚焦努力方向和增進理解，而非用來追究責任或強制合規。