自2011年我初次在敏捷之旅蘇州站分享《敏捷中的度量》以來，對這個問題的求解就一直9012年末。
最近與一些X-Developer試用申請者、使用者交流，針對開發(fā)者的績效評估，需求的分解與度量依然是難點?？蛻粽J為，如果在需求上無法做到均勻，那么針對需求個數的統(tǒng)計就是不公平的，但是要做到需求的均勻，又是一個難以解決的問題。另一些業(yè)界觀點又認為，只要拆、拆、拆，最后需求一定會“接近于均勻”的，但這個觀點除非有數學上的極限證明，或者統(tǒng)計學上的回歸分析，只能說是一種假設。
本文利用一些財務方法，設計并提供了一套完整的敏捷模式下的研發(fā)產能度量方法。
本質是經營方式變化了為什么從大版本到小版本，版本到迭代，迭代到持續(xù)交付，看似簡單——不就是縮短交付周期嘛——企業(yè)做起來如此困難？本質是經營方式變化了。對制造企業(yè)、零售公司和服務公司，其管理和凈利潤計算方式都是不一樣的：制造業(yè)的特點是廠房和土地等資產的折舊管理，而零售公司的特點是存貨管理，而服務公司特點是費用管理。
作為軟件公司，其交付模式就代表了最為核心的經營模式，交付模式變了，經營管理不變，一切都會錯亂。總體而言，傳統(tǒng)的以采購廠商軟件為主的IT部門，接近于制造企業(yè)；研發(fā)中心接近于零售公司，而現在，都在向服務公司的輕資產轉型：比如云服務費用替代硬件折舊成本，研發(fā)成本資產化。
由于并未真正做到完全沒有存貨（需求積壓），敏捷模式下的度量，更多是借鑒了零售的存貨成本計算方式，版本制向迭代制的轉變，很類似于定期盤存制向永續(xù)盤存制的轉變：及時性的提升。在永續(xù)盤存制的模式下，貨物的每筆收發(fā)都需要記錄和結存，以隨時了解企業(yè)的財產和物資，但加大了會計的工作量。對需求而言，采用迭代的模式，召開需求收集會議更加頻繁，工作量加大，但可以更加及時地了解和處理需求。所以是不是采取迭代開發(fā)，需要企業(yè)根據自己需要的響應周期進行判斷，甚至可以多種方式并存。
估算要不要做估算（Estimate）在軟件中是一個非常有爭議的名詞，因為管理者總是把估算當作承諾，估算又非常不準確，所以許多人都想把它“干掉”。然而Estimate還真是一個會計詞匯，應收/應付往往不一定收/付真實的帳面價值，所以會計上對作出估計。在項目管理中，由于缺少對估算的實際調整，所以導致了偏差，也導致了管理真實交付周期的困難。
估算真正的困難在于什么呢？在于沒有依據。或者說許多企業(yè)將估算的實施弄錯了。以下是關于估算的一道（經典）題目，用來測試你的理解：
a. 三天b. 五天c. 四天d. 兩天項目經理讓開發(fā)人員小王估算需求B的開發(fā)周期，項目經理自己評估，需要兩天做完，之前小王做過一個相似規(guī)模的需求A，用了三天，小王評估需求B后，認為需要五天才能做完，需求B的估算開發(fā)周期應該是：
你選擇了什么？
對估算技術理解無誤的話，正確答案是a，三天。因為這是事實數據，估算是基于過去發(fā)生的事實進行評估，而非主觀想法，或者算平均數。
研發(fā)產出到底怎么算？第一段提到，基于需求數量的產出計算存在兩個問題：
需求拆分方法的難度；假設需求規(guī)模的極限是平均值缺乏證明。基本術語定義
如果你對精益系統(tǒng)中的名詞還不太了解，這一節(jié)可以補充背景知識。主要是三個關于時間的定義：前置時間、周期時間和節(jié)拍時間。
前置時間（Lead Time）
前置時間在精益系統(tǒng)中衡量的是訂單響應的周期，就是指從接受訂單到交貨成功經過的自然日。舉個例子，8月30號接到訂單，9月27號交貨到用戶手上，前置時間就是28天。在軟件研發(fā)中，前置時間是指需求接受到發(fā)布上線過程中經過的所有自然日。對需求接受的定義，就是產品/研發(fā)部門與業(yè)務部門確認了這是一個有效的需求，將會被開發(fā)，而不是直接拒絕掉，所以，后面的需求澄清、分析、變更花費的時間，都會被計入前置時間之內。
前置時間是評估整個需求響應能力的重要指標，由于業(yè)務、運維都包括在內，所以它反映的是綜合能力，影響因素也較多，比如，可能各個環(huán)節(jié)都很快，但手工回歸測試工作量太大、太慢，整個前置時間就會非常長。缺少自動化能力的公司，不適合采用前置時間作為評估指標。
周期時間（Cycle Time）
周期時間在精益系統(tǒng)中衡量的是生產制造本身“有多快”，所以它統(tǒng)計的是從開始生產到發(fā)貨經過的所有自然日。舉個例子，9月12號開始執(zhí)行生產計劃，9月15號發(fā)出貨物，周期時間就是三天。對軟件研發(fā)而言，周期時間是“進入開發(fā)”到“準備發(fā)布”過程中經過的所有自然日。對需求開始設計，原則上就是“進入開發(fā)”了，因為敏捷倡導的是設計編碼不劃分不同階段。準備發(fā)布是指向生產環(huán)境的發(fā)布，如果轉型迭代前期，業(yè)務還做不到及時的驗收，也可以把準備發(fā)布UAT（用戶驗收環(huán)境）作為臨時的終點，然后慢慢牽引業(yè)務融入節(jié)奏。
由于周期時間去掉了需求澄清、上線部署的影響，所以它是衡量研發(fā)效率的重要指標。換句話說，這個指標不好看，改進范圍就在研發(fā)內部，包括開發(fā)和測試。
X-Developer對周期時間的計算是針對某個需求，從第一次代碼提交時間到最后一次代碼提交時間經過的自然日，所以是非常精確的，也是非常及時的。在試用時有產品經理說，“我們的需求都是兩周一迭代，不可能出現超過兩周周期時間的需求?！钡菙祿f明了，這里就是有一些兩周后針對這些需求的代碼提交，不管是因為配置腳本，還是因為環(huán)境切換，還是因為客戶數據導入，它們其實是沒有在兩周內真正完成的。
節(jié)拍時間（Takt Time）
節(jié)拍時間指的是單個產品生產花費的時間，它衡量的是單位產出的時間成本。比如說周期時間三天里，共生產出了30件待發(fā)貨產品，節(jié)拍時間就是1/10天。在軟件研發(fā)里，可以視為一個時期內需求的平均周期時間。
節(jié)拍時間可以度量到任務，并且可以分別度量開發(fā)和測試的任務。以2018年在某零售銀行的度量為例，我們把周期時間的度量粒度放在特性上，流動效率的度量粒度放在任務上，這樣一來，當特性的周期時間很短時，看任務流動性可以評估規(guī)模。
這種度量方式完美解決了需求顆粒度不均勻的問題，在此基礎上我們定義出了一條公式：
研發(fā)產能 = 需求個數 * 周期時間
這條公式背后的思想是：凡是加減法搞不定的計算，用乘法搞定。
然而偉大的會計準則早就給出了更完善的解決辦法，它們叫：平均成本法、先進先出法、后進先出法和個別辯認法。具體就不展開了，我們借鑒會計存貨成本計算直接給出不同辦法的計算方式與適用模式。
平均周期時間法 ACT - Average cycle time
平均周期時間法下的研發(fā)產能計算使用所有需求交付的平均周期時間作為第二個計算因子。“所有需求”的范圍可以根據情況設定在項目內、團隊內甚至跨團隊。其實主要取決于你現在有多少事實數據。
研發(fā)產能 = 需求個數 * 平均周期時間
每一次需求發(fā)布上線，平均周期時間都會發(fā)生一次變化，所以如果采用的是所有的歷史平均成本的話，又可以稱之為移動平均法。平均法的優(yōu)點是計算簡單，缺點是如果團隊發(fā)生較大的變化，平均周期時間會不準確，比如說，三個月前是大版本制，需求的周期時間全是三個月，現在是兩周一迭代了，平均一下，還是兩個月，難以及時捕捉改進。所以就有了接下來的方法。
先進先出法 FIFO - First in, first out
制定一個評估時間段，將這個時間段開始的部分的平均周期時間作為計算因子。
研發(fā)產能 = 需求個數 * 初期平均周期時間
舉個例子，某公司從2019年7月開始改進，希望在三個月內看到效果。根據先進先出法：
在2019年7月，取2019年5月的平均周期時間作為因子計算研發(fā)成本在2019年8月，取2019年6月作為因子計算研發(fā)成本，以此類推……在2018年9月，因為計算因子是2019年7月，就可以評估改進的效果了。后進先出法 LIFO - Last in, first out
與先進先出法不同的地方是，取評估周期的末期，即與當期最近的一個時間段作為計算因子。
研發(fā)產能 = 需求個數 * 末期平均周期時間
例：在2019年7月，取2019年6月的平均周期時間作為因子計算研發(fā)成本。后進先出法能夠更及時地發(fā)現改進，但缺點是時間太近，可能改進真的不明顯，也不太能說明問題。
個別辨認法 SI - Specific identification
個別辯認法是針對每個需求都統(tǒng)計出周期時間然后相加。
研發(fā)產能 = Sum(需求周期時間）
這種方法適用于在每個周期內完成的需求數量少、需求顆粒度大，并且特別不衡量的情況。比如剛開始改進時，7月，當期就可以采用個別辨認法，對每個需求的周期時間進行統(tǒng)計和計算。例：7月共完成3個需求，周期時間分別是12天、18天、24天，那么研發(fā)產能就是54天。
這時候可能很多讀者會問了，如果需求個數 * 周期時間等于產能，那是不是需求個數等于周期時間的時候，團隊的產能利用就達到最大化了？團隊是不是可以輕易地作弊了？還有就是，如果我們縮短了周期時間，那在這個計算公式里，產能豈不是下降了？以下我們就來求解一下。
關于產能公式的評估比如某團隊利用FIFO方法評估，初期周期內交付n個需求，周期時間為t，現在周期時間縮短為 t-x，那么如何評估產能是上升還是下降了呢？我們先假設產能不變，即：
nt = n'(t-x) => n' = nt/(t-x)
即在縮短周期時間的情況下，如果團隊保持現有產能不變，應交付 nt/(t-x) 個需求。那么就分為以下三種情況：
n' < nt/(t-x) 說明團隊產出有所下降，需求變小了，但交付容量沒有增加n' == nt/(t-x) 說明團隊產能未有改善，需求多做了一些，但每個需求更小了n' > nt/(t-x) 說明團隊的產能提升了，需求不但做得快，而且做得更多了舉個例子，團隊過去做 5 * 30 個需求量，現在做 5 * 20 個需求量，產能是下降了；但現在做 10 * 20 個需求量，產能是增加了。當團隊達到 15 * 15 = 225 的“近似最大化”時，不代表就無法改進了，因為 16 * 15 = 240 就叫產能提升。
精益模式下的度量升級簡單說，敏捷看節(jié)奏，精益看流動效率——不止是速率，還要看浪費。度量公式升級如下：
研發(fā)產能 = 需求個數 * 周期時間 - 浪費
浪費的計算為每個需求在周期時間內的間隔等待時間超過1天的累計自然日。比如說某個需求在等待狀態(tài)下停留了2天，浪費時間為 2-1 = 1 天。
X-Developer對浪費的計算是代碼提交間隔超過1天的累計自然日，比如說9月1號提交了代碼，9月2號未提交，9月3號提交了，累計浪費計為0；如果9月3號也未提交，累計浪費就開始計為1，以此類推。這種計算方式的好處是，不但捕捉到真實的研發(fā)活動數據，而且可以加快真正的持續(xù)集成節(jié)奏。因為只有代碼被提交到倉庫，集成部署才可能開始工作，可交付的軟件這時才被構建出來——無提交，無產出。
這一產能度量的方法是場量科技首創(chuàng)（如有雷同，實屬巧合），也在X-Developer商業(yè)版中率先實施。在社區(qū)版的應用中，我們發(fā)現許多團隊都尚未實施最基本的代碼提交規(guī)范（注釋中包含需求編號），希望能夠實施起來，因為這不但是眾多大廠（微軟、Google、Facebook、阿里……），也是許多開源項目（Jenkins、Spark……）的基本規(guī)范，它不但可以幫助團隊縮短解決問題的時間（快速回溯需求到代碼），還可以在數據驅動的時代給予科學的反饋與指導。
場量科技專注于產品研發(fā)效能領域的探索與實踐，我們提供具備行業(yè)前瞻性的產品、解決方案、培訓和資訊服務，幫助客戶在高度不確定性領域低風險完成探索。
