開發速度正在殺死敏捷嗎？

敏捷宣言的簽署者之一，Jim Highsmith在他最近的博客“開發速度正在殺死敏捷”中描繪了對開發速度“饑渴”的經理會用開發速度作為生產率的衡量指標。他寫道：“……他們通常狂熱的衡量開發速度——團隊開發速度、不同團隊間開發速度的比較、組織級的開發速度、甚至是每個開發人員的開發速度（呸！）”

Highsmith指出開發速度正被越來越多的用來衡量生產率。原因顯而易見。任何衡量生產率的方法，可以幫助你了解什么方法有效、什么方法無效，以便調整。而且，開發速度數據容易獲得、便于計算并被視為是大量輸出的計量結果。但Highsmith警告說，這種度量太過關注交付故事點的數量。“這個數量降低了交付的客戶體驗的質量”，并在他所謂的“交付引擎”上投入過多。

讓問題更加復雜的是，敏捷運動專注于高度客戶參與——總的來說這是好事——但我們走得太遠了。很多“敏捷主義者”公開抱怨他們不能讓組織專注于技術實踐——但為什么我們鼓勵產品經理對優先級做出決定，然后當他們用速度來衡量工作情況時，而大吃一驚呢？在傳統方法中，我們太過缺少客戶參與——從而賦予產品經理安排優先級的控制權。

Highsmith不是第一個質疑敏捷實踐中開發速度的用法的人。Mark Levison在他去年的博客文章“敏捷項目中開發速度的誤用”中，他定義了開發速度是團隊完成的工作量除以完成時間。他寫道“工作量通常以故事點數（一個相對大小的數量）計算。”

Levison談論了用開發速度比較兩個團隊的生產力。但Levison指出：

敏捷/Scrum團隊使用相對大小的估算（比如，這個用戶故事/功能是大于還是小于我們的“基準”用戶故事？），而不是像傳統方法中的絕對大小估算。互相比較、標桿對照、或者任何比較開發速度的嘗試時，都會遇到這個問題：我的故事點數 ≠ 你的故事點數，因為不同的項目采用了不同的基準用戶故事。不同的項目的問題域不一樣，項目成員也不一樣。

Scott Ambler也在幾年前寫過有關“在不同團隊間比較開發速度的危險”這一主題的文章，他建議不要計算每個團隊的加速度。Ambler認為，這種做法的優勢在于：容易計算、易于自動化并難于博弈。缺點是，這種度量是間接的，很大程度上依賴于Ambler稱之為的“捏造因數”。

可能是Highsmith標題黨了，他和Levison都不是說開發速度是完全邪惡的。Highsmith寫道，“開發速度的正確用法是一個校準工具，是一種有助于做基于能力的計劃的方法”，Levison說，“開發速度和發布計劃的真正價值在于讓產品經理清楚在下個發布時能得到什么。”

查看英文原文：Is Velocity Killing Agile?