概要
無論你對度量標準有什麼看法，公司都會期望以此來評估你的團隊。你不想只衡量乙個方面而忽略其他資訊，但你也不希望評估太多的東西，以至於分散了團隊的焦點。以下四個指標可以均衡地評估敏捷團隊的生產力，工作質量，可**性和健康狀況。
評估專案的指標數量與構建專案的指標數量一樣多。不幸的是，這些指標中的很多都沒有用。埃里克里斯稱他們為「虛榮指標」，因為他們看起來不錯，讓你感覺良好，但沒有可操作性。
無論你你對度量標準有何看法，在（專案）結束那天，企業都會期望獲得評估結果。以「幫助團隊自我反思和提高」為標準，並提醒你「你的里程可能會有所不同」，以下是我對敏捷團隊的四項指標，以及一些有效經驗。
1四個聯鎖小組度量
為什麼有四個？如果你只是衡量乙個指標的話，就很容易陷入到狹窄的認知中。無論是團隊專注於制定指標（通常是通過改變原有體系）還是管理層使用這些措施來推動所有決策，你最終只能得到乙個看起來不錯，但實際上已經處於懸崖邊上的產品或組織。
同樣，有多達10個指標，更可能導致團隊的不同部分聚焦不同的指標，從而影響團隊的架構。人類最好每次處理三到五個概念，因此四個主要度量標準看起來就像是最佳的儀表板。
週期時間
週期時間是你與生產力的直接聯絡。週期時間越短，給定時間盒中的事情越多。
你可以從工作開始到功能完成時進行測量。在軟體開發的背景下，我更想把這個時間看做是大家實際工作在軟體開發上的時間。測量週期時間最好是通過你選擇的敏捷生命週期工具自動完成，即使使用物理任務板進行度量也能為你提供有用的資料。
缺陷逃逸
這項措施是客戶滿意度與團隊之間的聯絡。缺陷率越低，客戶對該產品的滿意度越高。缺陷率很高，即使是最棒的產品也會有很多不滿意的客戶。
你可以通過產品傳送給使用者後發現的問題（bug，缺陷等）數量來衡量。在乙個故事完成之前，它仍在進行中，所以關注故事的執行比追蹤正在進行的缺陷更可取。
計畫與完成比率
此度量標準是衡量可**性的一種方式。如果乙個團隊承諾30個故事並且只交付了9個故事，那麼po就有30％的機會獲得他們想要的東西。另一方面，如果團隊承諾10個故事並交付9個，則po有大概90％的機會獲得他們想要的東西。
衡量是乙個簡單的運用，記錄團隊在sprint開始時承諾的工作量，以及結束時他們完成的工作量。
幸福感
這是團隊的「健康」指標。它創造了將其他三個指標置於更好環境中的意識。如果其他指標都是完美的，而幸福感很低，那麼團隊可能會很快就筋疲力盡了。
把它建立到你的sprint回顧中。在每次回顧會上（無論規模）都讓大家協商自己的幸福指數。從乙個sprint到另乙個sprint的過程中觀察這些資料的趨勢。
2為什麼選擇這些指標？
週期時間和缺陷逃逸是高度量化的，並且在各個行業都很好理解。較小的數字意味著你可以更快地提供更高質量的產品。我原本增加了計畫完成比率，主要是因為這是團隊可以立即產生實際影響的因素，所以這實現了「早期獲勝」的想法。它在繪製可**性方面長期有用。幸福指標是「人為因素」，它讓我們衡量整個團隊的健康狀況。
前三項措施形成乙個自我支撐的三角形。如果你的週期時間縮短，那麼缺陷幾乎肯定會增加。高計畫完成比例可能非常好，除非週期時間已經過去了，這表明在每次sprint中團隊完成得很少。最後，通過將幸福感與其他人分享，你可以看到等式中的人的一面。低幸福分數幾乎總是潛在問題的標誌，並且可能是其他事物的主要指標。
你可能想知道速率。我也跟蹤速率，但我認為它有乙個非常具體的地方。這四個指標是為了讓團隊在回顧中進行反思並關注改進的。
另一方面，速率是團隊在sprint計畫中使用的度量。它的唯一用處是粗略衡量下一次sprint需要做多少工作。如果分享管理鏈，它也可能被誤用 - 有更好的方法可以**乙個團隊何時完成或者其效果如何。
測量速度時，我測量故事點和故事計數速度。通過這樣做，我發現該團隊已經對其工作負載進行了內建的檢查和平衡。舉例來說，假設團隊有三個sprint平均50個故事點和10個故事。如果他們的下一次sprint是48個點和9個故事，那麼他們可能會完成所有的工作。如果他們超過了其中乙個數字 - 比如說，做48個點但是20個故事（一堆小的） - 那麼sprint可能會有風險，因為這是很多情境切換。如果他們超過這兩個數字 - 比如說，達到70個點和15個故事 - 那麼這是乙個明確的警告標誌，而一位優秀的教練可能希望與團隊保持聯絡，以確保他們相信自己能比平均成績好。
3行動中的指標
這些圖表基於真實資料，並且是敏捷轉型18個月左右的寫照。我傾向於堅持1個為期六個月的滾動視窗，因為如果你遠遠超出這個範圍，事情就會發生改變，並且與團隊正在做的事情無關。
週期時間
峰值代表團隊轉向乙個新專案，並且隨著一系列組織變更，他們也快速的適應了新專案的工作。
缺陷逃逸
此圖顯示了乙個相當典型的，已轉移到跨職能角色和自動化測試團隊的曲線。由於團隊中的每個人都對故事和質量負有共同責任，並更加關注測試自動化，我們發現產品發布後的缺陷急劇下降。
計畫到完成率
這個團隊失去了scrummaster，這影響了它的整體效能，如第乙個sprint的資料所反映的那樣。在第二次衝刺中，有經驗的scrummaster進來幫忙。早期的**代表團隊習慣了一套新的規範，後來的下降是由於程式變化導致團隊積壓清晰度降低的結果。
幸福感
這些資料顯示了scrummaster的支援如何改善了團隊的整體健康狀況。該圖還反映了產品和組織的流失影響了團隊以後的幸福感。
根據這些圖表，我計畫的第一件事就是與團隊進行交流，並聽取前幾次sprint中發生的事情。計畫完成率和幸福指標的下降足以告訴我可能會發生一些事情。低週期時間和缺陷逃逸會讓我懷疑問題是團隊外部因素造成的。
真正的挑戰來自混亂的產品戰略，這導致團隊在優先順序事項中來回切換。積壓變化的波動導致低質量的故事。當他們挖掘出乙個他們不明白的故事並轉向他們所做的工作時，該團隊的發展足夠讓他們停下來。這降低了計畫完成比，因為並非所有承諾的工作都可以完成，而週期時間很短，因為他們處理了他們已經很好理解的事情。
試一試這些指標
我很幸運的使用了這些度量團隊的指標。他們之間的內在關係使得可以在不改變其他條件的情況下實施這個度量。他們為團隊提供有用的資料進行回顧性改進，對領導力和**有幫助。
評估敏捷團隊的4個平衡指標
概要 無論你對度量標準有什麼看法，公司都會期望以此來評估你的團隊。你不想只衡量乙個方面而忽略其他資訊，但你也不希望評估太多的東西，以至於分散了團隊的焦點。以下四個指標可以均衡地評估敏捷團隊的生產力，工作質量，可 性和健康狀況。評估專案的指標數量與構建專案的指標數量一樣多。不幸的是，這些指標中的很多都...
乙個成功敏捷團隊的失敗歷程
很多人可能疑惑，很多案例都是從失敗到成功，這個怎麼反了。很多成功背後都有其原因，可能很勵志，但從失敗中我們能夠獲取更多。畢竟我們的知識大多源於失敗而非成功。故事是這樣的 括號中的是筆者的情緒表達 在很久很久以前 某公司成立了乙個團隊，開發一款全新的產品。產品的開發模式是產品需求獲取和開發同步進行，團...
乙個團隊的工作流程 敏捷
例 步驟1 讓我們擁有乙個由9人組成的scrum團隊，其中包括1個產品所有者，1個scrum master，2個測試人員，4個開發人員和1個dba。步驟2 sprint決定遵循4周的週期。所以我們從6月5日到 7 月4 日開始為期乙個月的sprint 步驟3 產品所有者在產品待辦事項中具有優先順序的...