軟件項目規(guī)模估計，怎么估？

?侯世達(dá)在《哥德爾、埃舍爾、巴赫》中提到：“做事所花費的時間總是比你預(yù)期的要長，即使你的預(yù)期中已經(jīng)考慮了侯世達(dá)定律。”

周三的下午，我像平常一樣，寫著代碼聽著歌，突然一個莫名其妙的故事列表從天而降，說讓我給個人天，投標(biāo)要用。作為一個技術(shù)異常牛逼的高端程序員，這對我來說豈不是小（pi）事一樁（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ā)人天，差不多，再加緩沖，算150吧！差不多了吧……

各位看官，這一幕是不是有點兒眼熟？然而，這樣的做法可能會帶來下面幾個問題。

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

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

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

前面的估算看起來是采用的經(jīng)典的“理想人天”估算法，如果使用這樣的估算法，勢必要考慮一些不在故事卡工作量內(nèi)，但也一定會花費時間的事務(wù)，包括但不限于以下活動：

• 回復(fù)電子郵件（溝通成本）
• 面試（內(nèi)部耗損）
• 參加會議（包括內(nèi)部會議，比如站會、retro、code diff、技術(shù)研討會議和客戶溝通會議等）
• 為當(dāng)前發(fā)布提供支持（上線支持）
• 培訓(xùn)？（內(nèi)部的）
• 任務(wù)之間切換／被人打斷（程序員出棧入棧的消耗……）
• 修復(fù)bug（一定會有bug，一定會花時間修……）
• 寫各種文檔（對于比較看重文檔的客戶，這一部分會占用不少的時間）

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

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

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

問題可能的答案

想要解決或者緩解這些問題，可以選用哪些方案呢？科恩（Mike Cohn）《敏捷估算與規(guī)劃》介紹了一些基本的方法。

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

其次，是方法。《敏捷估算與規(guī)劃》介紹了兩種基本的方法：理想人天法和故事點法。

1. 理想人天法

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

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

2. 故事點法

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

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

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

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

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

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

功能緩沖

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

進度緩沖

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

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

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

1. “輸出高于結(jié)果”（output over outcome）。客戶更關(guān)注功能列表的完成，而不是產(chǎn)生的業(yè)務(wù)價值。

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

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

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

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

估計和計劃會使團隊和客戶更多聚焦在工作量而不是工作的價值上。如果能夠引導(dǎo)客戶從輸出導(dǎo)向思維轉(zhuǎn)變?yōu)榻Y(jié)果導(dǎo)向，那么團隊就不用再疲于奔命地完成那些并不會用到的功能（feature）上，而是可以有更多的時間去提升產(chǎn)品質(zhì)量，進一步提升業(yè)務(wù)價值。

---

（1）　請訪問ThoughtWorks洞見公眾號同名文章。