周三的下午,，我像平常一樣，寫著代碼聽著歌,，突然從天而降一份莫名其妙的故事列表,，說讓我給個人天，用來投標(biāo)用,。作為一個技術(shù)異常牛逼的高端程序員,，這對我來說豈不是 A Piece Of Shit…哦不，Cake,。拿著列表,，打眼一看就知道是做什么 — 又是個審批流系統(tǒng)。注冊,、登錄,、忘記密碼…這些也需要時間？,！哦,，還要做個SSO，可能要做點數(shù)據(jù)集成,，給個15人天吧,！又是一堆CRUD... CRUD 各給2人天一共8個,。看起來有4個 Model,，乘個4,，32個人天差不多。前端還有些工作量,，找前端估一下...還有些跟遺留系統(tǒng)集成的部分,，這塊應(yīng)該比較麻煩，給個30人天差不多…還要用微服務(wù)架構(gòu),，估計需要一些基礎(chǔ)環(huán)境,，每個組件給3個人天，一共8個組件,，算24吧....總共算起來130個開發(fā)人天,，差不多，再加點buffer,，算150吧,！差不多了吧...

這一幕是不是有點眼熟？不過,，這樣的做法可能會帶來下面的幾個問題：

1. 估計者的估計點數(shù)是否能代表團(tuán)隊的估計點數(shù),？

問題的答案顯而易見。 那么有同學(xué)會說,，此時團(tuán)隊的人員還沒完成配置,，沒辦法讓真實團(tuán)隊進(jìn)行功能的估計。確實是這個樣子,，所以我們只能力所能及的去模擬真實團(tuán)隊進(jìn)行估計,。一般，交付項目的團(tuán)隊肯定不會全上非常有經(jīng)驗的同學(xué),，人員配比一定會有 leverage,，也就是 Senior 人員和 Junior 人員的比例。所以,，在估計的過程中,，至少要引入 Junior 的同事，能夠從不同經(jīng)驗的角度來看待同樣的問題,，來使估計不會過分“樂觀”,。

2. 是否有故事卡片之外的工作時間沒有考慮到呢？

上文中的估計看起來是采用的經(jīng)典的“理想人天”估計法,，如果使用這樣的估計方法,，勢必要考慮一些雖然沒有在故事卡工作量中，但也一定會花費時間的事務(wù)，包括但不限于：

• 回復(fù)電子郵件（溝通成本）

• 面試（內(nèi)部耗損）

• 參加會議（包括內(nèi)部會議,，比如站會,、Retro、Code Diff,、技術(shù)研討會議,、客戶溝通會議等）

• 為當(dāng)前發(fā)布提供支持（上線支持）

• 培訓(xùn)？（內(nèi)部的 Session）

• 任務(wù)之間切換/被人打斷（程序員出棧入棧的消耗…）

• 修復(fù)bug（一定會有 Bug,，一定會花時間修...）

• 寫各種文檔（對于對文檔比較看重的客戶,，這一部分會占用不少的時間）

這些事務(wù)會伴隨整個交付過程中發(fā)生，基本上都是正常交付必不可少的工作內(nèi)容,，而且根據(jù)筆者的經(jīng)驗,，這些事情占據(jù)的時間并不比完成故事卡的編碼工作要少。

3. 故事卡的需求是否清晰呢,？

在項目啟動前拿到的故事列表,，往往只有 Epic 級別的，也就是很粗粒度的故事卡,。故事卡中的 AC（Acceptance Criteria,，驗收條件）往往只考慮了最簡單的 Happy Path，然而大部分項目中（尤其是 ToB項目）,，Exception 才是相對復(fù)雜的,，這些異常情況往往需要花費更多的時間完成。在這種情況下進(jìn)行估計,，可想而知,，一些隱藏的需求點往往難以發(fā)現(xiàn)。

問題可能的答案

那么想要解決上面的問題,，或者說更好一點的緩解上述問題的方案是什么呢？《敏捷估計與規(guī)劃》中介紹了一些基本的方法,。

首先,，要進(jìn)行集體估計。

集體估計可以緩解因為個人能力不同所引發(fā)的單點偏差,，不同的開發(fā)成員對于某個需求在不同角度的闡述,，也容易讓大家對需求有更全面的理解，也易于發(fā)現(xiàn)潛藏在需求中的風(fēng)險,。闡述的過程中,，出現(xiàn)復(fù)雜問題時，可以及時聯(lián)系相應(yīng)的專家資源,。對于一些規(guī)模較大的卡片,，也可以綜合大家的意見，進(jìn)行更合理的拆解。同時,，需要由要做次工作的人來進(jìn)行估計,，這樣會產(chǎn)生更多的責(zé)任感，可以在一定程度上緩解樂觀估計的問題（Lederer and Prasad 1992）,。

其次,，是方法。

《敏捷估計與規(guī)劃》介紹了2種基本的方法：理想人天法和故事點法,。

1. 理想人天法

理想人天法就是直接把故事卡估計成理想人天,。所謂理想人天，就是”在需求非常明確的情況下,，進(jìn)行編碼,、測試工作所花費的時間“。就好像籃球比賽一樣,， 每節(jié)12分鐘,，4節(jié)總共48分鐘，這是比賽的理想時間,。但是誰都知道,，一般NBA每場比賽都要2個半小時左右，比賽激烈的話三個小時都有可能,，比賽真正持續(xù)的時間與理想時間是有較大差距的,。相比于籃球比賽，軟件項目”場外“的工作就更多了,，除了上面問題2列出的哪些實務(wù)之外,，像是方案變更引發(fā)的大量溝通、集成聯(lián)調(diào),、測試過程中的需求講解,、項目的交接等等，這些工作也需要算到項目時間之內(nèi),。同時,，對于同一個項目，不同的人根據(jù)其能力,、經(jīng)驗的不同,，會有不同的理想人天。

所以在估計完理想人天之后,，如何進(jìn)行實際人天的換算,，在實際應(yīng)用中，仍然是個大問題,，所以...最好就不要用了,。

2. 故事點法

故事點法就是按照故事卡的規(guī)模和難度,，給予每張故事卡一個點數(shù)。注意,，這里的點數(shù)代表的不是所需的人天,，而更多的是難度系數(shù)。

開發(fā)人員因為自己技能,、經(jīng)驗,、能力的不同，解決同樣的問題,，所花的時間差別是很大的,，但對規(guī)模的估計卻是一樣的。就好比從北京到上海,，坐飛機(jī)1個多小時,，高鐵5個小時，步行要….一個月左右吧,，距離是一樣的,，根據(jù)不同的速度，會花費不同的時間,。

同時,，人們一般很難對一個規(guī)模進(jìn)行準(zhǔn)確的估計，比如從北京到上海的絕對距離是多少,，估計沒幾個人知道,。但是，人們能夠比較容易的比較兩件事物的差距或者說倍數(shù)關(guān)系,，比如：北京到上海的距離跟從上海到香港的距離是差不多的,，這個距離是北京到鄭州距離的兩倍。所以我們在做估計的時候,，可以按照難度系數(shù)分成幾波,，然后在內(nèi)部在進(jìn)行一些比較和排序，然后按照比較的差距分配一個規(guī)模點數(shù),，比如1,、2、3,、5、8,、13,。

大家可以看到，這個規(guī)模點數(shù)并不是連續(xù)的數(shù)字,，而是采用了菲波那切這一個神器的數(shù)列,。這樣的數(shù)列有2個好處,，一個是不會出現(xiàn)連續(xù)的倍數(shù)關(guān)系，比如4點的故事卡片是2點故事卡片的2倍,；其次是表明出規(guī)模越大的卡片,，其不確定性也承遞增趨勢，所以會給更高的點數(shù),。

有了故事點數(shù),，我們?nèi)匀粺o法判定項目什么時間能夠交付，因為缺少一個“速度”,，也就是團(tuán)隊的開發(fā)速度,。如果面對的是一個成熟的團(tuán)隊，并且使用類似的技術(shù)棧,，且與客戶的合作模式基本相同的話,，那么可以參考前一個項目的速度，來進(jìn)行交付時間的計算,。但如果面對的是全新的客戶,、不同的技術(shù)棧，以及完全重新配置的團(tuán)隊,，那么速度基本是不可估的,。這時候，有時候會根據(jù) Tech Lead 和 PM 的（Pai）經(jīng)（Nao）驗（Dai）,，進(jìn)行硬估：把每個點數(shù)轉(zhuǎn)化成N個人天,。比如1個點數(shù)需要2個人天，那么100個點數(shù)的項目就是200個人天,。當(dāng)然,，這種方法...說多了會掉淚 %>_<%

最后，給項目加些緩沖（Buffer）,。

一般來說,，面對這種情況，本著對客戶和我們自己負(fù)責(zé)的態(tài)度,，需要給項目加一些緩沖區(qū)（Buffer）,。Buffer 分兩種，一種是功能Buffer,，一種是進(jìn)度 Buffer,。

功能緩沖

增加功能 Buffer，簡單來說,，就是把全部的故事列表進(jìn)行估計,，假設(shè)得到總點數(shù)是100點；然后按照優(yōu)先級進(jìn)行排序,，挑出其中的MVP,，要少于總量的 70%,，作為必須要做（Must Have）的部分。剩下的 30% 作為做了更好,、不做也不影響主要功能（Nice To Have）的部分,，通過這種方式來緩沖項目里程碑的風(fēng)險。

進(jìn)度緩沖

進(jìn)度 Buffer,，是用來緩沖估計之外的異常情況引發(fā)的項目時間的拉長,。進(jìn)度 Buffer 根據(jù)項目的不確定性的差異，計算的方法和結(jié)果會有較大差異,，有興趣可以參考《敏捷規(guī)劃與估計》,，這里就不贅述了。不過根據(jù) Leach(2000)準(zhǔn)則提出的建議,，至少要保持整個項目的20%以上,，否則也許不能為整個項目提供足夠的保護(hù)。

不是總結(jié)的總結(jié)

上面的這些方法能一定程度的規(guī)避風(fēng)險,，給開發(fā)團(tuán)隊帶來一定的空間,，但過分的強(qiáng)調(diào)估計和交付計劃的準(zhǔn)確性，會帶來更深層級的問題：

1. output over outcome,?？蛻舾P(guān)注功能列表的完成，而不是產(chǎn)生的業(yè)務(wù)價值,。

2. 開發(fā)團(tuán)隊會傾向于裁剪用戶故事的功能,，3個點的故事卡，盡量控制在規(guī)定時間內(nèi)完成,，即使可以花更多時間把事情做的更好,。

3. 控制需求變更：可以進(jìn)行需求變更，但這個過程更像是一個異常的情況,，而不是喜聞樂見的,。

4. 當(dāng)我們發(fā)現(xiàn)了更好的業(yè)務(wù)點、idea時候,，會傾向于隱瞞,，以免額外的業(yè)務(wù)功能會增加工作量。需求變更往往會涉及客戶談判的事情,，尤其是當(dāng)客戶觀念是傳統(tǒng)的供應(yīng)商管理策略：我來控制需求的全景,，能多做點就多做點。

5. 在客戶合作和談判的天平上,，客戶關(guān)系會向談判的方向傾斜,。

估計和計劃會使團(tuán)隊和客戶更多的聚焦在工作量，而不是工作的價值上,。如果能夠引導(dǎo)客戶從 output 導(dǎo)向的思維轉(zhuǎn)變到 outcome 導(dǎo)向上,，那么團(tuán)隊就不用再疲于奔命的完成那些并不會用到的feature上，而是可以有更多的時間去提升產(chǎn)品質(zhì)量,，進(jìn)一步提升業(yè)務(wù)價值,。后面的文章《如何在Fixbid項目上做敏捷開發(fā)》會反思下，如何在目前的情況下,，把項目做到更好,。

最后，是時候展示真正的技術(shù)了,！

本文轉(zhuǎn)自：簡書