做事所花費(fèi)的時(shí)間總是比你預(yù)期的要長(zhǎng)，即使你的預(yù)期中考慮了侯世達(dá)定律。

——?侯世達(dá)，哥德?tīng)枴Ｉ釥?、巴?/p>

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

這一幕是不是有點(diǎn)眼熟？不過(guò)，這樣的做法可能會(huì)帶來(lái)下面的幾個(gè)問(wèn)題：

1. 估計(jì)者的估計(jì)點(diǎn)數(shù)是否能代表團(tuán)隊(duì)的估計(jì)點(diǎn)數(shù)？

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

2. 是否有故事卡片之外的工作時(shí)間沒(méi)有考慮到呢？

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

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

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

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

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

問(wèn)題可能的答案

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

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

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

其次，是方法

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

（1）理想人天法

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

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

（2）故事點(diǎn)法

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

開(kāi)發(fā)人員因?yàn)樽约杭寄?、?jīng)驗(yàn)、能力的不同，解決同樣的問(wèn)題，所花的時(shí)間差別是很大的，但對(duì)規(guī)模的估計(jì)卻是一樣的。就好比從北京到上海，坐飛機(jī)1個(gè)多小時(shí)，高鐵5個(gè)小時(shí)，步行要…一個(gè)月左右吧，距離是一樣的，根據(jù)不同的速度，會(huì)花費(fèi)不同的時(shí)間。

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

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

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

最后，給項(xiàng)目加些緩沖（Buffer）

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

（1）功能緩沖

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

（2）進(jìn)度緩沖

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

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

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

1. output over outcome?？蛻舾P(guān)注功能列表的完成，而不是產(chǎn)生的業(yè)務(wù)價(jià)值。
2. 開(kāi)發(fā)團(tuán)隊(duì)會(huì)傾向于裁剪用戶故事的功能，3個(gè)點(diǎn)的故事卡，盡量控制在規(guī)定時(shí)間內(nèi)完成，即使可以花更多時(shí)間把事情做的更好。
3. 控制需求變更。可以進(jìn)行需求變更，但這個(gè)過(guò)程更像是一個(gè)異常的情況，而不是喜聞樂(lè)見(jiàn)的。
4. 當(dāng)我們發(fā)現(xiàn)了更好的業(yè)務(wù)點(diǎn)、idea時(shí)候，會(huì)傾向于隱瞞，以免額外的業(yè)務(wù)功能會(huì)增加工作量。需求變更往往會(huì)涉及客戶談判的事情，尤其是當(dāng)客戶觀念是傳統(tǒng)的供應(yīng)商管理策略：我來(lái)控制需求的全景，能多做點(diǎn)就多做點(diǎn)。
5. 在客戶合作和談判的天平上，客戶關(guān)系會(huì)向談判的方向傾斜。

估計(jì)和計(jì)劃會(huì)使團(tuán)隊(duì)和客戶更多的聚焦在工作量，而不是工作的價(jià)值上。如果能夠引導(dǎo)客戶從 output 導(dǎo)向的思維轉(zhuǎn)變到 outcome 導(dǎo)向上，那么團(tuán)隊(duì)就不用再疲于奔命的完成那些并不會(huì)用到的feature上，而是可以有更多的時(shí)間去提升產(chǎn)品質(zhì)量，進(jìn)一步提升業(yè)務(wù)價(jià)值。

作者：張久坤，ThoughtWorks高級(jí)咨詢師。程序員出身，參與過(guò)多個(gè)國(guó)內(nèi)外大型項(xiàng)目的交付工作，對(duì)敏捷有深入的理解，目前專注于敏捷項(xiàng)目的業(yè)務(wù)分析和項(xiàng)目管理的工作。

題圖來(lái)自 unsplash