本文要點
- 速度（velocity）預測的準確率通常在50%左右。我們是在擲硬幣打賭
- 蒙特卡洛模擬是更好的預測方法
- 避免設定測量目標
- 關注趨勢，而不是單一的數據點
- 測量系統的多個方面
Doc Norton在2019年體驗敏捷（Experience Agile 2019）大會上表示，速度（Velocity）不適用於預測或診斷。它是一個過於波動的複雜系統的滯後指標，無法知道我們未來的表現如何；它不夠穩定，無法可靠地使用。我們可以使用蒙特卡洛（Monte Carlo）模擬來預測、用累積流圖（cumulative flow diagrams）來跟蹤工作、查看範圍的變化及發現瓶頸問題。
Norton把速度定義爲隨着時間推移交付價值的工作單元。他提到，這需要一個合理的衡量標準。但是，即使速度與實際部署或交付有關，它仍然沒有告訴我們跟流程相關的任何信息。僅憑這個測量結果，我們無法判斷一個團隊的表現是否良好，他這樣說到。
爲了得到更高的概率預測，我們需要知道速度的歷史、積壓量、起始日期以及作爲積壓增長指示器的分割率。Norton演示了我們如何使用蒙特卡洛模擬來預測團隊何時能夠進行交付。根據我們希望擁有的置信度，團隊將需要更多的時間直到他們能夠交付。
關於診斷，Norton展示了我們如何使用累積流圖。它們有助於我們跟蹤在一段時間內完成的和未完成的工作數量、查看範圍的變化以及看到瓶頸的所在。
Doc Norton是一位敏捷和領導力教練，他在2019年體驗敏捷大會上就使用速度和其他指標進行了演講。InfoQ對他進行了採訪。
InfoQ：您如何定義速度？
Doc Norton：用最簡單的話來說，速度是隨着時間推移實現價值的工作單元。在大多數地方，它僅僅是個隨着時間變化的工作單元，但是，那不是速度，因爲它沒有明確的方向。那只是速率。速度是個矢量，它需要一個方向；這就是我們爲什麼要加上“導向價值”這幾個字。它提醒我們，我們在朝着一個特定的方向努力。在我看來，價值是學習、降低風險或增加效用。
對於我來說，我們直到意識到價值，纔算速度。如果團隊學到了一些東西（如新的處理方法是否增加了互動），我們確實降低了風險（如證明新的緩存技術在我們所依賴的脆弱系統宕機時有用），或者我們已經交付了效用（如用戶實際參與的功能），那麼，我們認爲事情完成了，並把它算進速度。在很多地方，在開發完成時會計算速度。如果用戶故事從未上線，它們仍然把它算進速度。我認爲，他們漏掉了一個關鍵點。
在更深的層次上，速度還是一個複雜系統的滯後指標。與所有的滯後指標一樣，關於預測未來，它們不是很有用，但是，在確認趨勢和模式方面，它們做得不錯。想想在多數零售領域的季度銷售額，第4個季度並不是下一個第1個季度銷售額的預測指標，但是，它可以爲我們確定總體趨勢，每年的年尾銷售額都要更高一些。
InfoQ：您在演講中表示，速度幾乎沒有什麼用處。您能闡述一下嗎？
Norton：到目前爲止，我在敏捷大會上已經對1000多人進行了問卷調查。在被調查的人當中，約有90%的人對自己的速度沒什麼信心、速度和部署之間脫節或無法僅用速度來可靠地預測大量工作。
在接受調查的敏捷採用者中，只有10%的人認爲速度對於實際測量和預測工作何時完成並投入生產是有用的。計劃和預測是速度的目的。
基於這些數據，我認爲，可以說速度幾乎是無用的。
InfoQ：有時候，人們說速度是團隊可以控制的東西。您怎麼看？
Norton：這是個危險的觀點，特別是如果我們是管理人員的時候。一個批評行動者的領導者忽視了大局，沒有看到在創造結果的過程他們要扮演的角色。
每個系統都是完美的；它產生的結果與設計的完全一樣。如果現行的系統在生成錯誤的結果，那麼，這不是系統內行動者的錯誤，更多的是系統本身的錯誤。我們可以告誡人們不要成爲更好的行動者。基於人類的某些信仰或規則（一些道德或倫理期望），我們可以堅持他們應該表現得不同。但是，所有人類行爲的一個關鍵因素是人類正在操作的這個系統或環境。一個完全理性的人，如果想要做好工作，那麼，在一個促進和獎勵速度多過促進和獎勵安全的環境中，他會誇大估計或偷工減料。這並非普遍如此。有些工作人員會堅持安全勝於速度。但是，在大多數組織中，大多數團隊確實都受到了影響。
因此，當管理層專注於速度，或更糟的是，爲速度設立目標時，那麼，行動者的結果行爲就是自然的結果。它不是控制系統的團隊，而是創建這種控制的系統設計者。
InfoQ：如果團隊希望使用速度來查看他們是否有改善，這可能嗎？
Norton：也許吧，但是，不是很好。
首先，由於速度通常是每個迭代的故事點，並且，故事點是抽象的，並由團隊估計，因此，速度極易偏移。
偏移是隨着時間的推移而累積的細微變化。我們通常不會在較小的時間範圍內注意到它們，但是，在一個比較廣闊的時間範圍內，它是顯而易見的。以一個團隊爲例，他們知道應該隨着時間的推移而提高速度。可以肯定的是，他們會這麼做。我們可能看到，他們在交付更多的價值。但是，還有多少呢？我們如何能確定呢？在很多情況下，如果我們從幾年前的故事中選一組，要求團隊重新評估它們，那麼，他們會給我們一個比最初估計更高的整體數字。我的前提是，這是因爲我們的估計常常隨着時間的推移而升高。更大的估計偏差在每次迭代之間不是那麼明顯，但是，隨着季度或年份的推移就變得明顯。我們可以使用參考故事來幫助降低這種偏移，但是，我不知道大家是否可以消除它。
其次，即使我們可以證明，估計完全沒有偏移，我們仍然只是測量了一個維度：交付的速率。爲了知道我們是否在改善，我們可能也需要知道代碼質量、客戶採用率、客戶保留率和系統性能等信息。
速度不會告訴我們關於系統健康狀況、團隊健康狀況或公司健康狀況的任何事情。它甚至不會告訴我們交付的健康狀況。很難用這麼少的信息來判斷我們是否有改善。
InfoQ：對於使用速度來預測某事何時會完成，您的建議是什麼？
Norton：預測的好壞取決於用來創建它的數據及技術。對於大多數團隊來說，用速度估計意味着我們大概有一半對一半的機會在預測的日期或之前完成工作。想一想，我們在使用一種平均值和外推法，當然，我們的預測會在可能性範圍內。它還意味着，我們幾乎不知道我們會錯過目標的差異有多大。可能的交付日期範圍是幾天、幾個星期還是幾個月？根據我們使用的技術，我們無法知道這個問題的答案。
我習慣對平均值應用標準差以得到範圍。然後，我意識到，很多速度分佈不符合高斯分佈，而是偏移的。因此，標準差從數學上來講是不正確的。難以用概率來解釋範圍。
目前，我知道的最可靠的技術是運行蒙特卡洛模擬。Focused Objective的人有個專門爲我們做的電子表格；它被稱爲“吞吐量預測器（Throughput Forecaster）”，我們可以從Free Tools和Resources下載它。基於歷史速度數據和大量的工作積壓，他們運行500個模擬的項目來確定在設定日期前或在設定日期前完成工作的概率。這是對於發生了什麼事情的一個簡單解釋，對於基本的理解來說，已經足夠了。
該技術提供一個概率範圍，允許我們更好地進行溝通。通過使用這個技術，很多客戶已經發現他們使用的速度技術所產生的數值的有效率小於50%。當他們意識到，不是因爲他們無法管理好團隊，而是因爲他們的預測制定得不充分，看到他們臉上如釋重負的樣子，真是太好了。
InfoQ：我們如何使用逃逸缺陷（escaped defects）來測量質量？
Norton：逃逸缺陷是在生產過程中發現的缺陷。對我教導的團隊而言，沒有其他類型的缺陷，因此，“逃逸”是多餘的。但是，在一些組織中，存在質量管理（QA）缺陷和逃逸缺陷的概念。我們在這裏關心的是逃逸缺陷。
測量在迭代或吞吐量樣本中引入的逃逸缺陷的數量可能有幫助，但是，也可能會產生誤導。我們可能會發現，每次迭代產生的逃逸缺陷的數量在增加。我們知道，這不是“好”消息，但是，我們是否知道，這個消息有多“壞”嗎？
爲了幫助我們做出決定，我們可以查看相對於吞吐量的逃逸缺陷的數量。這給我們一個比例，我們可以用來查看趨勢。困難的部分是，我們需要作出一致的努力，識別出在哪個迭代或吞吐量採樣週期中引入了缺陷。根據團隊和系統的使用方式，這不總是容易做到的。假設我們有速度歷史，分別爲8，9，12，14，19和21，相應的逃逸缺陷的數量爲2，2，3，3，4，4。如果逃逸缺陷是衡量質量的指標，那麼，該質量是提高了，還是下降了，或者保持不變呢？
如果我們只看逃逸缺陷，那麼，我們可以得出結論，它們顯然在增長。從這一點，我們可以總結出，每個週期我們發佈的軟件質量都在下降。但是，如果，我們把它看作吞吐量與逃逸缺陷的比率，那麼，我們得到0.25，0.12、0.25、0.21、0.21和0.19。從這一點，我們看到通過吞吐量的逃逸缺陷總體上是下降的趨勢。這意味着，儘管在缺陷率上有增加，但是，實際上，相對於值的速率是下降的。
InfoQ：團隊如何能更好地使用指標？
Norton： 如果團隊需要以更有益的方式利用指標，那麼，我認爲，團隊需要考慮這些事情。避免設定測量目標。關注趨勢，而不是單一的數據點。測量系統的多個方面。使用這些信息來通知系統調整。
避免設定測量目標。當測量指標成爲目標時，它就不再是好的測量目標了。古德哈特定律（Goodhart’s Law）就是這樣闡述的。指標是關於系統如何運行的信息。它們是系統的副產品。當我們選取一種測量，通過設定目標，把它轉換成一個控件，我們把該測量注入系統，實際上，我們改變了系統。這個測量指標就不是原來那樣了，結果，我們剛剛設立的目標也完全不是最初預想的那樣了。
關注趨勢，而不是單一數據點。少關心今天的價值，多關心趨勢。指標的趨勢如何？它是否在朝着基於我們策略的期望的方向變化？如果趨勢跟預期不一樣，那麼，要考慮一下，系統中的什麼問題可能是根源，然後去解決它。要知道，有時很好的策略會造成指標跟通常期望方向的趨勢相反。比如，當我們在從單體架構向微服務過渡時，代碼傾向於變得更復雜。一旦舊的單體代碼被移除，那麼，複雜性會再次下降。
測量系統的多個方面。每個系統都有緊密的關係。如果我們只測量一個維度，那麼，我們很可能不瞭解系統真正的健康狀況。比如，如果我們只關注交付速率，那麼，我們很可能沒有注意到對質量、功能的客戶採用率或員工滿意度的影響。這些最終都會影響我們維持系統的能力。
使用這些信息通知系統調整。我們測量是爲了提供信息，而不是爲前進設定目標。我們查看趨勢，把它們跟基於我們策略的預期進行對比。我們查看多個維度的信息以幫助我們確保我們沒有過度優化特定的維度。當我們的趨勢在任何這些維度上都偏離的時候，我們希望考慮需要做什麼調整，使系統更接近健康的平衡。
受訪者介紹
敏捷和領導力教練Doc Norton是軟件交付專家，致力於讓軟件開發世界變得更好。他的經驗涵蓋了廣泛的開發領域。Norton不會宣稱專長哪門語言或方法來宣稱，並對任何宣稱自己專長的人立即表示懷疑。作爲一名作家和國際演說家，Norton熱衷於幫助他人成爲更好的開發人員，與團隊合作以改進交付，並建立偉大的組織。在OnBelay的工作中，Norton每天都有機會揮灑他的熱情。
原文鏈接：