敏捷開發中，績效管理是管理層非常關心的問題，而敏捷（或Scrum）中沒有關於績效的定義或做法。本文是Ken Rubin基於自己20多年的敏捷開發經驗總結出來的、敏捷團隊中如何進行績效管理。

幾乎我教過的每堂課或輔導過的每個組織都有下面這個問題：“我應該用什麼指標來確定團隊是否執行良好？”我可以理解這個問題的背景是，大多數人想問開發團隊的績效，而不是整個Scrum團隊（包含產品負責人、ScrumMaster和開發團隊），也不是整個組織的績效。

有時候我也想知道開發團隊做得怎麼樣，所以我會在本文闡述這個問題。但是，對我來說這個問題和下面兩個問題幾乎不相關：“作為敏捷組織我們做的怎麼樣？”或“Scrum團隊做的怎麼樣？”。這些問題的答案可以使我們在經濟相關性和可操作性層面有更深入的理解。在組織層面我想了解我們是否高效地交付客戶期望的價值。為了理解這一點，我會採用如下指標：

無用功（Idle work） 和閒散員工（idle workers） — 衡量工作流受阻的時間和頻率（而不是衡量員工有多忙）。

交付可工作和驗證過的產品—如果我們交付的產品客戶不用的話，那麼按時及在預算內交付就沒有任何意義。

作為組織我們的學習速度—採用如innovation accounting （精益創業的概念）的指標來評估我們學習的速度，該速度可以作為匯聚業務價值結果的進度指標。

在組織層面之下我會關注整個Scrum團隊。3個角色一起交付正確的客戶價值並快速較好的完成。所以我更喜歡下面這個指標“每個迭代Scrum團隊都在交付較好的價值嗎？”（more on this shortly）。但是如果我們只想衡量開發團隊怎麼辦（以下簡稱“團隊”）？或許我們想知道給團隊分配某人是否是正確的選擇。如果開發團隊會長久在一起，那麼我們就想知道團隊的績效。下面我推薦幾個指標（排除使用開發速率）：

幾乎每次團隊都能完成迭代目標

產品負責人相信團隊交付較好的經濟價值

團隊以可持續的節奏工作

團隊的T型技能（一專多能）

團隊的學習速度

開發速率（不建議使用這個指標）

許多人認為，開發速率是一種衡量團隊績效顯而易見的方法。不幸的是，開發速率應該只是一種計劃工具（如釋出計劃）和團隊診斷指標（如流程改進工作）。速率不應該作為一個績效指標來判斷生產效率。因為速率太容易做假了。如果團隊成員知道速率作為績效指標的話，他們就會在每個迭代隨意增大產品backlog條目的大小（故事點通脹），或者為了完成更多的故事而偷工減料（注：即犧牲質量或增加技術債）。在《Essential Scrum》一書中，詳細描述了什麼是速率，應該如何使用速率以及應用速率的誤區。在本文中，我不會把速率作為團隊績效的指標。

實現迭代目標

排除了開發速率，我們應該用什麼來衡量團隊績效呢？一個指標是團隊以什麼頻率實現迭代目標。作為Scrum原則，每個迭代應該有一個目標（就像可執行的彙總說明），這個目標是團隊一起承諾要實現的。每個迭代團隊盡最大努力實現目標。我寧願每個迭代團隊沒有完成目標，因為這可能是團隊習慣性無法完成承諾的跡象。有時候，團隊為了達到目標做出了相當的努力，但最終由於正當的原因（比如目標的彈性比較大）而沒能完成。這個現象更好地表明瞭團隊應該在合理的限度內進行工作。

交付價值

檢查和平衡團隊“虛報估算”的一種簡單而恰當的方法是，諮詢產品負責人是否每個迭代都能獲得良好的價值。多數的迭代都是固定成本的——我們知道團隊人員和迭代的時間長度都是固定的，因此每個迭代的成本也就是固定的。假設每個迭代的成本是2萬美元，對產品負責人而言一個重要的問題就是，“你覺得每個迭代能至少獲得2萬美元的價值嗎？”好的產品負責人會知道答案。如果產品負責人說，“沒錯，我很滿意團隊正在交付的價值，”那麼這就是團隊良好績效的表現。再說明一點，產品負責人對迭代級別和釋出級別的經濟性是總體負責的。因此，如果產品負責人草率地花了2萬美元，讓團隊只交付1萬美元的價值的話，那麼這個產品負責人就是不負責任。總之，交付良好價值是整個Scrum團隊（產品負責人，ScrumMaster和開發團隊）的責任，當評估開發團隊時可以考慮這個指標。

可持續的節奏工作

我還想要知道是否每個迭代團隊都能以可持續地節奏交付良好的價值。我們都見過為了交付迭代目標而一週工作80小時的情況。對於這個情況的第一個反應可能是，“看看，多麼棒的團隊，他們為了完成工作願意加班！” 常常一個迭代中為了完成目標，工作更長時間切更努力一點是必須的。因為總是有一些難以預料的事情。然而，人們不能長時間以這種節奏工作，所以一週工作80小時的團隊不會長久的成為“優秀團隊”，很快他們就變成“疲憊不堪的團隊”了。因此，第三個衡量高績效團隊的指標是，每個迭代都以可持續的節奏交付良好的價值。

擴充套件T型技能

另一個高績效團隊的指標是：“團隊成員有沒有更進一步擴充套件T型技能？”T型技能職這樣一個比喻，用來描述一個人在專業領域有深入的垂直技能，同時其它相關領域擁有廣泛的（沒必要那麼深入）水平技能。由T型技能的人組成的團隊更不易受到工作變化的影響，因為可能多個團隊成員都可以工作在該領域上，所以在有大量工作時團隊可以蜂擁式的集中工作。我認為團隊成員的T型技能是團隊健康和高效能的重要指標。

快速頻繁地學習能力

最後，需要評估團隊的學習能力。尤其是，我想評估團隊完成學習迴圈的能力：假設、構建、反饋、檢視和調整。高效能團隊總是快速驗證重要的假設，並根據結果而採取行動。高效能團隊以最大化學習重要細節能力的方式組織工作，因此他們可以根據學習進行調整。考慮到快速而頻繁學習的重要性，我會在組織層面和團隊層面都採用這個指標。快速學習重要資訊並盡最大的努力工作，超越那些學習慢的團隊，就像團隊那樣，學習最快的組織常常痛擊他們的對手。

總結

總結一下，當衡量績效的時候，首先考慮的是較高層面如組織、Scrum團隊級別的。當評估開發團隊的時候，不要採用速率。相反，考慮之前我提到的一套多維的指標會獲得團隊績效的全面情況。最後一點意見。以我的經驗，組織裡好的經理實際上不需要任何官方團隊績效的指標。這樣的經理和團隊保持緊密聯絡，細心觀察發生的一切。諮詢一個好的經理關於團隊績效，包含強項和弱點，這個經理都會馬上給出全面的答案。

摘自PM圈子網(www.pmleader.cn)一個集專案管理、敏捷開發、產品管理、DevOps的綜合智庫，是IT網際網路、從事專案工作的經理人、技術人員的學習充電之地。