作為BA，估算會議是我目前所在專案的日常工作之一，其目的是對近期即將開發的story進行大小的預估。組織了幾次估算會議後，我發現會議常常超時很久，team會花大量時間去討論估計結果是否足夠準確。實際上既然是估算，就意味著誤差，那麼花過多的時間在確保準確性上很可能意味著浪費時間。下面的曲線是根據《敏捷軟體開發實踐－估算與計劃》一書作者Mike Cohn的經驗所得，進一步說明了這個結果：當估算會議用時超過一定時長後，其準確度反而下降了。
圖1-1 在特定點之後，在估算中投入額外的工作量不會產生多少價值（第40頁）
道理我都懂，可是……
既然如此，為什麼在估算時，team依然傾向於謹慎的再花時間“多想想”？讓我們去回顧日常工作的一些場景中，看看能否找到一些可能的答案：
“在我們們專案，1個點的story大概需要花費一對Dev兩天的時間來完成。”
“這個story雖然簡單，但是AC很多，工作量大，2個點恐怕做不完。”
“這個story是2個點的，已經做了5天了，已經超一天了。”
“這個story估小了，重估吧，否則velocity會下降。”
“這批story整體都估小了，總是超時完成，team估點還是不夠準。”
“這個月的velocity下降了，我們需要多計劃幾個story進來。” ……
讀一遍這些曾經出現過的相關對話，我們不難發現，story的估點結果總是跟另外一個詞緊密的聯絡在一起：Velocity速度。
“速度”是隱藏在“估點不準”這個擔憂背後真正的壓力。我們意識到team每次伸出手指，不再是單純的示意一個估算結果，而是變成了一個承諾——“當給出兩個點的結果時，意味著我承諾了在4天內完成它，我必須更謹慎些。”
這是一種解釋，也是另一個疑問的開始：如果1個點＝2天，那麼故事點和傳統專案管理中的“人天”有什麼區別？使用velocity的初衷真的是作為敏捷團隊生產率表現的小鞭子嗎？如果是這樣，如此使用velocity作為敏捷的一項實踐工具，是否違背了敏捷思想更多在於提升團隊應對變化的響應力而非純粹提高效率的價值取向？
敏捷實踐引入Velocity的初衷是什麼？
帶著上一小節留下的一系列問題，我們首先來看一看 “velocity” 在敏捷實踐中的定義是什麼，Wikipedia對velocity是這麼描述的：
“Velocity is a capacity planning tool sometimes used in Agile software development. The velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project…”
即： 速度 = Σ(單次迭代中完成的story所分配的故事點數) ［V1］
如果只看到這裡，跟我們說 “一個點大概等於兩天”［V2］去表示速度，區別是微妙的。但是如果有人告訴你：根據“速度”的大小變化，我們可以不斷調整專案的釋出計劃。那麼這種微妙的區別就變得很重要了，因為這代表著兩種完全不同的使用目的：V2強調工作規模與工作時長的直接對應，且期待“速度”值保持不變甚至更高；而V1強調對制定計劃的參考價值，且不主張刻意保持“速度”值的恆定。實際上，Kent最初在他那本經典的小冊子《Extrem Programming: Embrace Change》中，就是將velocity作為協助製作釋出計劃的 “均衡器” 來使用的：
The proper use of velocity is as a calibration tool, a way to help do capacity-based planning.”
- Kent Beck, Extreme Programming: Embrace Change
均衡器的理想用法是怎樣的？
如果看到上一節後你開始好奇 “速度” 到底怎麼發揮 “均衡器” 的作用，我們就具體來看一看，下圖中的模型說明了 “速度” 在專案中起作用的節點以及如何協助制定釋出計劃：
開始計劃時，如果將從客戶那兒獲得的需求拆分成story並分別估點加總，我們就會得到對專案總體大小（或者下一階段工作總體規模，針對那些長期的專案）的估算。如果知道team的速度，就可以通過用 “加總的大小/速度” 來推算出迭代的次數，再把這個持續時間對映到日曆上，就可以得到最初的進度表。
我們舉個具體的例子來看。例如，假設下一階段總體工作規模估算值為200個故事點，又根據過去的經驗知道，team的的速度是每次2周的迭代可以完成25個故事點。那麼200/25=8，我們可以估算出專案需要8次迭代，因為每次迭代的週期是2周，那麼我們可以推算出一個16周的釋出計劃，再在日曆上往後數16周，就得到了具體的進度表。
接下來我們就來看看如何使用 “速度” 完成對計劃誤差對自我修正：
在初始的計劃中，team選用了［25點/迭代］作為歷史速度，因為team一開始認為能在每次迭代中完成25個點的story，但是在專案開始後，他們發現速度只能達到［20點/迭代］，那麼200/20=10，在計劃工作總量不變的情況下，不需要對任何story進行重估，team就能正確地儀式到專案需要10次迭代，而不是8次。
再舉一個生活中的例子來幫助我們理解上面的內容。假設team受僱去粉刷一套不知道具體面積的房子，並且他們只有房子的平面圖，看不到實際大小，但是我們仍然希望知道他們多久能夠完工，這就需要team對其進行估算。如果team估計粉刷兩個臥室的工作量都是5個點，這裡 “5” 本身沒有任何意義，它不直接意味著 “3天” 或是 “5天” 完成，但是它能說明兩間臥室的大小大約是一致的，從平面圖上能看到車庫大概是臥室的兩倍大，於是team估算車庫的工作量是10個點。
team估算的是粉刷牆壁的“相對工作量”。
因為看不到房子的面積，team只能大概估計一個，比如猜測臥房是2mx3.5m，預測完成粉刷的速度，然後用整體的工作量/預測速度得出我們想要知道的完成時間。真正開工後，如果進度比想象的慢，是不是說之前的估算就沒有任何用了呢？不是的，因為他們估算的是粉刷每個房間的 “相對工作量”， 如果team發現臥室的尺寸是他們假想值的2倍， 那麼主臥的尺寸也會是假想值的兩倍。對於工作量的相對值是不變的，但是由於房間的面積是預期的4倍，因此team的生產率會變慢。如果你還記得第二節中的那句質疑 “這批story整體都估小了，總是超時完成，team估點還是不夠準”，在這個例子之後，是不是有了新的解讀？
最後一個例子真正重要的意義在於，如果我們希望有效的使用 “均衡器”，前提是我們要意識到story的故事點是相對的，原始點值本身並不重要，重要的是點值的相對大小。在 “一個點大概等於兩天” 這樣的描述下，我們則無法體現這種相對性。
這一小節中使用的例子引用了《敏捷軟體開發實踐－估算與計劃》（Mike Cohn著， 金明 譯）一書第四章的內容，感興趣的讀者可以在書中看到更多的詳細內容。
看似很美好，問題出在哪兒？
如果一個工具能估快速有效的修正計劃的誤差，提高專案對變化的響應能力，那麼這個工具當然值得被引入到敏捷實踐中。然而現狀是team依然承受著來自velocity的壓力，好像只有那些有幸在 “愉快的敏捷實踐樂園” 中工作的人們才會把速度當作均衡器來使用。但是我們不要忘記還有一位重要的角色，那就是客戶——他們可不是樂園的股東。
Oh no，客戶來了！
作為客戶，首要天然的訴求當然就是追求收益，任何跟生產力相關的資訊都會成為他們關注的重點。不得不說，相比在敏捷專案中作為“均衡器”的工具，“速度”更普遍的是作為度量生產率的工具而被廣泛應用於眾多行業和領域中。如果沒有任何的解釋，在客戶眼中，velocity就是衡量team生產效率的度量工具，這很直觀也很容易理解。在經歷初期的幾次迭代後，客戶發現2個點的story，大概需要一對dev耗費兩天的時間去完成。於是客戶開始要求我們統計team的velocity，並且將velocity能否保持在一個恆定的水平上（其實更希望越來越高），作為驗收team工作表現的主要度量維度。
那麼很容易想象，當我們告知客戶team的速度“下降”了，客戶看到的不會是一個 “均衡器” 正在起調節作用，而是team “懈怠了”，於是在站會上，我們往往就會收到來自客戶的質疑。
結果：均衡器 “失效” 了
應對客戶的質疑，一個最簡單有效的方法就是順應客戶的要求，用 “平穩的速率曲線”構築起抵禦客戶質疑的邊境長城。
當速度被期待恆定後，為了保證計劃的有效，常見的 “承諾” 模式就代替 “均衡器” 起作用了，那麼計劃的誤差則通過team不斷提高估算的準確性來修正，故事變得越來越熟悉，於是一次超長時間的估點會議開始了。
點之殤：不只是“失效”
說了這麼多，回到文章一開始提出的疑問：使用velocity的初衷真的是作為敏捷團隊生產率表現的小鞭子嗎？答案是否定的。那麼“速度” 失去調節作用轉而成為只專注度量團隊效率是否會有副作用呢？這時候起碼產生了兩個困惑：
- 交付業務特性的優先順序永遠高於技術優化？
- 重構變成 “浪費時間” ？
都是客戶的錯？Any Action？
當我們認為上一節提到的那些 “副作用” 產生負面影響力時，我們常常會聽到 “沒辦法，客戶就是這麼要求的” 這樣看似無奈的聲音。真的是這樣嗎？都是客戶的錯？
反思一下我們應對客戶的方法，當我們努力去維護那條穩定的 “速度” 曲線時，站在客戶角度去看，其實是在不斷的向客戶強化一個資訊：Velocity＊時間＝工作量
然而我們知道，在軟體行業這個等式是不成立的，我們並不是在做重複簡單的體力工作，我們需要抵禦的也不是客戶的質疑，而是應該跟客戶站在統一戰線上，共同去應對外界不斷髮生的變化和知識工作本身帶來的複雜度。而應對複雜度表現的度量，只依靠 “生產率” 這個單一的維度是遠遠不夠的。
於是當我們去抱怨客戶只看收益的時候，反過來想想我們是否為客戶提供了更有價值的資訊？那些有價值的資訊是否都被那道高高的 “velocity” 曲線擋住了？ 是否能夠構向客戶展現其它更立體的維度來度量team的performance？
所以，“愉快的敏捷時間樂園”本來就不會存在，而客戶也並不是那邊境以北我們需要抵禦的 “異鬼”。
參考文獻：
- 《敏捷關鍵開發實踐－估算與計劃》
- The Problem with Velocity in Agile Software Development, Hayim Makabee, November11,2015
- Velocity is Killing Agility!, Jim Highsmith, November02, 2011