概要
無論你對度量標準有什麼看法，公司都會期望以此來評估你的團隊。你不想只衡量乙個方面而忽略其他資訊，但你也不希望評估太多的東西，以至於分散了團隊的焦點。以下四個指標可以均衡地評估敏捷團隊的生產力，工作質量，可**性和健康狀況。
評估專案的指標數量與構建專案的指標數量一樣多。不幸的是，這些指標中的很多都沒有用。埃里克里斯稱他們為「虛榮指標」，因為他們看起來不錯，讓你感覺良好，但沒有可操作性。
無論你你對度量標準有何看法，在（專案）結束那天，企業都會期望獲得評估結果。以「幫助團隊自我反思和提高」為標準，並提醒你「你的里程可能會有所不同」，以下是我對敏捷團隊的四項指標，以及一些有效經驗。
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個為期六個月的滾動視窗，因為如果你遠遠超出這個範圍，事情就會發生改變，並且與團隊正在做的事情無關。
週期時間
峰值代表團隊轉向乙個新專案，並且隨著一系列組織變更，他們也快速的適應了新專案的工作。
積壓變化的波動導致低質量的故事。當他們挖掘出乙個他們不明白的故事並轉向他們所做的工作時，該團隊的發展足夠讓他們停下來。這降低了計畫完成比，因為並非所有承諾的工作都可以完成，而週期時間很短，因為他們處理了他們已經很好理解的事情。
評估敏捷團隊的4個平衡指標
概要 無論你對度量標準有什麼看法，公司都會期望以此來評估你的團隊。你不想只衡量乙個方面而忽略其他資訊，但你也不希望評估太多的東西，以至於分散了團隊的焦點。以下四個指標可以均衡地評估敏捷團隊的生產力，工作質量，可 性和健康狀況。評估專案的指標數量與構建專案的指標數量一樣多。不幸的是，這些指標中的很多都...
乙個成功敏捷團隊的失敗歷程
很多人可能疑惑，很多案例都是從失敗到成功，這個怎麼反了。很多成功背後都有其原因，可能很勵志，但從失敗中我們能夠獲取更多。畢竟我們的知識大多源於失敗而非成功。故事是這樣的 括號中的是筆者的情緒表達 在很久很久以前 某公司成立了乙個團隊，開發一款全新的產品。產品的開發模式是產品需求獲取和開發同步進行，團...
乙個團隊的工作流程 敏捷
例 步驟1 讓我們擁有乙個由9人組成的scrum團隊，其中包括1個產品所有者，1個scrum master，2個測試人員，4個開發人員和1個dba。步驟2 sprint決定遵循4周的週期。所以我們從6月5日到 7 月4 日開始為期乙個月的sprint 步驟3 產品所有者在產品待辦事項中具有優先順序的...