做事所花費的時間總是比你預期的要長祷舀，即使你的預期中考慮了侯世達定律瀑梗。
——?侯世達，哥德爾裳扯、埃舍爾抛丽、巴赫
周三的下午，我像平常一樣嚎朽，寫著代碼聽著歌铺纽，突然從天而降一份莫名其妙的故事列表，說讓我給個人天哟忍，用來投標用狡门。作為一個技術異常牛逼的高端程序員，這對我來說豈不是 A Piece Of Shit…哦不锅很，Cake其馏。拿著列表，打眼一看就知道是做什么 — 又是個審批流系統(tǒng)爆安。注冊叛复、登錄、忘記密碼…這些也需要時間扔仓？褐奥！哦，還要做個SSO翘簇，可能要做點數據集成撬码，給個15人天吧！又是一堆CRUD... CRUD 各給2人天一共8個版保∥匦Γ看起來有4個 Model，乘個4彻犁，32個人天差不多叫胁。前端還有些工作量，找前端估一下...還有些跟遺留系統(tǒng)集成的部分汞幢，這塊應該比較麻煩驼鹅，給個30人天差不多…還要用微服務架構，估計需要一些基礎環(huán)境，每個組件給3個人天谤民，一共8個組件堰酿，算24吧....總共算起來130個開發(fā)人天，差不多张足，再加點buffer触创，算150吧！差不多了吧...
這一幕是不是有點眼熟为牍？不過哼绑，這樣的做法可能會帶來下面的幾個問題：
1. 估計者的估計點數是否能代表團隊的估計點數？
問題的答案顯而易見碉咆。 那么有同學會說抖韩，此時團隊的人員還沒完成配置，沒辦法讓真實團隊進行功能的估計疫铜。確實是這個樣子茂浮，所以我們只能力所能及的去模擬真實團隊進行估計。一般壳咕，交付項目的團隊肯定不會全上非常有經驗的同學席揽，人員配比一定會有 leverage，也就是 Senior 人員和 Junior 人員的比例谓厘。所以幌羞，在估計的過程中，至少要引入 Junior 的同事竟稳，能夠從不同經驗的角度來看待同樣的問題属桦，來使估計不會過分“樂觀”。
2. 是否有故事卡片之外的工作時間沒有考慮到呢他爸？
上文中的估計看起來是采用的經典的“理想人天”估計法聂宾，如果使用這樣的估計方法，勢必要考慮一些雖然沒有在故事卡工作量中诊笤，但也一定會花費時間的事務亏吝，包括但不限于：
- 回復電子郵件（溝通成本）
- 面試（內部耗損）
- 參加會議（包括內部會議，比如站會盏混、Retro、Code Diff惜论、技術研討會議许赃、客戶溝通會議等）
- 為當前發(fā)布提供支持（上線支持）
- 培訓？（內部的 Session）
- 任務之間切換/被人打斷（程序員出棧入棧的消耗…）
- 修復bug（一定會有 Bug馆类，一定會花時間修...）
- 寫各種文檔（對于對文檔比較看重的客戶混聊，這一部分會占用不少的時間）
這些事務會伴隨整個交付過程中發(fā)生，基本上都是正常交付必不可少的工作內容乾巧，而且根據筆者的經驗句喜，這些事情占據的時間并不比完成故事卡的編碼工作要少预愤。
3. 故事卡的需求是否清晰呢？
在項目啟動前拿到的故事列表咳胃，往往只有 Epic 級別的植康，也就是很粗粒度的故事卡。故事卡中的 AC（Acceptance Criteria展懈，驗收條件）往往只考慮了最簡單的 Happy Path销睁，然而大部分項目中（尤其是 ToB項目），Exception 才是相對復雜的存崖，這些異常情況往往需要花費更多的時間完成冻记。在這種情況下進行估計，可想而知来惧，一些隱藏的需求點往往難以發(fā)現冗栗。
問題可能的答案
那么想要解決上面的問題，或者說更好一點的緩解上述問題的方案是什么呢供搀？《敏捷估計與規(guī)劃》中介紹了一些基本的方法隅居。
首先，要進行集體估計趁曼。
集體估計可以緩解因為個人能力不同所引發(fā)的單點偏差军浆，不同的開發(fā)成員對于某個需求在不同角度的闡述，也容易讓大家對需求有更全面的理解挡闰，也易于發(fā)現潛藏在需求中的風險乒融。闡述的過程中，出現復雜問題時摄悯，可以及時聯系相應的專家資源赞季。對于一些規(guī)模較大的卡片，也可以綜合大家的意見奢驯，進行更合理的拆解申钩。同時，需要由要做次工作的人來進行估計瘪阁，這樣會產生更多的責任感撒遣，可以在一定程度上緩解樂觀估計的問題（Lederer and Prasad 1992）。
其次管跺，是方法义黎。
《敏捷估計與規(guī)劃》介紹了2種基本的方法：理想人天法和故事點法。
1. 理想人天法
理想人天法就是直接把故事卡估計成理想人天豁跑。所謂理想人天廉涕，就是”在需求非常明確的情況下，進行編碼、測試工作所花費的時間“狐蜕。就好像籃球比賽一樣宠纯， 每節(jié)12分鐘，4節(jié)總共48分鐘层释，這是比賽的理想時間婆瓜。但是誰都知道，一般NBA每場比賽都要2個半小時左右湃累，比賽激烈的話三個小時都有可能勃救，比賽真正持續(xù)的時間與理想時間是有較大差距的。相比于籃球比賽治力，軟件項目”場外“的工作就更多了蒙秒，除了上面問題2列出的哪些實務之外，像是方案變更引發(fā)的大量溝通宵统、集成聯調晕讲、測試過程中的需求講解、項目的交接等等马澈，這些工作也需要算到項目時間之內瓢省。同時，對于同一個項目痊班，不同的人根據其能力勤婚、經驗的不同，會有不同的理想人天涤伐。
所以在估計完理想人天之后馒胆，如何進行實際人天的換算，在實際應用中凝果，仍然是個大問題祝迂，所以...最好就不要用了。
2. 故事點法
故事點法就是按照故事卡的規(guī)模和難度器净，給予每張故事卡一個點數型雳。注意，這里的點數代表的不是所需的人天山害，而更多的是難度系數纠俭。
開發(fā)人員因為自己技能、經驗浪慌、能力的不同柑晒，解決同樣的問題，所花的時間差別是很大的眷射，但對規(guī)模的估計卻是一樣的。就好比從北京到上海，坐飛機1個多小時妖碉，高鐵5個小時涌庭，步行要….一個月左右吧，距離是一樣的欧宜，根據不同的速度坐榆，會花費不同的時間。
同時冗茸，人們一般很難對一個規(guī)模進行準確的估計席镀，比如從北京到上海的絕對距離是多少，估計沒幾個人知道夏漱。但是豪诲，人們能夠比較容易的比較兩件事物的差距或者說倍數關系，比如：北京到上海的距離跟從上海到香港的距離是差不多的挂绰，這個距離是北京到鄭州距離的兩倍屎篱。所以我們在做估計的時候，可以按照難度系數分成幾波葵蒂，然后在內部在進行一些比較和排序交播，然后按照比較的差距分配一個規(guī)模點數，比如1践付、2秦士、3、5永高、8隧土、13。
大家可以看到乏梁，這個規(guī)模點數并不是連續(xù)的數字次洼，而是采用了菲波那切這一個神器的數列。這樣的數列有2個好處遇骑，一個是不會出現連續(xù)的倍數關系卖毁，比如4點的故事卡片是2點故事卡片的2倍；其次是表明出規(guī)模越大的卡片落萎，其不確定性也承遞增趨勢亥啦，所以會給更高的點數。
有了故事點數练链，我們仍然無法判定項目什么時間能夠交付翔脱，因為缺少一個“速度”，也就是團隊的開發(fā)速度媒鼓。如果面對的是一個成熟的團隊届吁，并且使用類似的技術棧错妖，且與客戶的合作模式基本相同的話，那么可以參考前一個項目的速度疚沐，來進行交付時間的計算暂氯。但如果面對的是全新的客戶、不同的技術棧亮蛔，以及完全重新配置的團隊痴施，那么速度基本是不可估的。這時候究流，有時候會根據 Tech Lead 和 PM 的（Pai）經（Nao）驗（Dai）辣吃，進行硬估：把每個點數轉化成N個人天。比如1個點數需要2個人天芬探，那么100個點數的項目就是200個人天神得。當然，這種方法...說多了會掉淚 %>_<%
最后灯节，給項目加些緩沖（Buffer）循头。
一般來說，面對這種情況炎疆，本著對客戶和我們自己負責的態(tài)度卡骂，需要給項目加一些緩沖區(qū)（Buffer）。Buffer 分兩種形入，一種是功能Buffer全跨，一種是進度 Buffer。
功能緩沖
增加功能 Buffer亿遂，簡單來說浓若，就是把全部的故事列表進行估計，假設得到總點數是100點蛇数；然后按照優(yōu)先級進行排序挪钓，挑出其中的MVP，要少于總量的 70%耳舅，作為必須要做（Must Have）的部分碌上。剩下的 30% 作為做了更好、不做也不影響主要功能（Nice To Have）的部分浦徊，通過這種方式來緩沖項目里程碑的風險馏予。
進度緩沖
進度 Buffer，是用來緩沖估計之外的異常情況引發(fā)的項目時間的拉長盔性。進度 Buffer 根據項目的不確定性的差異霞丧，計算的方法和結果會有較大差異，有興趣可以參考《敏捷規(guī)劃與估計》冕香，這里就不贅述了蛹尝。不過根據 Leach(2000)準則提出的建議后豫，至少要保持整個項目的20%以上，否則也許不能為整個項目提供足夠的保護箩言。
不是總結的總結
上面的這些方法能一定程度的規(guī)避風險硬贯，給開發(fā)團隊帶來一定的空間，但過分的強調估計和交付計劃的準確性陨收，會帶來更深層級的問題：
- output over outcome⊥依担客戶更關注功能列表的完成务漩，而不是產生的業(yè)務價值。
- 開發(fā)團隊會傾向于裁剪用戶故事的功能它褪，3個點的故事卡饵骨，盡量控制在規(guī)定時間內完成，即使可以花更多時間把事情做的更好茫打。
- 控制需求變更：可以進行需求變更居触，但這個過程更像是一個異常的情況，而不是喜聞樂見的老赤。
- 當我們發(fā)現了更好的業(yè)務點轮洋、idea時候，會傾向于隱瞞抬旺，以免額外的業(yè)務功能會增加工作量弊予。需求變更往往會涉及客戶談判的事情，尤其是當客戶觀念是傳統(tǒng)的供應商管理策略：我來控制需求的全景开财，能多做點就多做點汉柒。
- 在客戶合作和談判的天平上，客戶關系會向談判的方向傾斜责鳍。
估計和計劃會使團隊和客戶更多的聚焦在工作量碾褂，而不是工作的價值上。如果能夠引導客戶從 output 導向的思維轉變到 outcome 導向上历葛，那么團隊就不用再疲于奔命的完成那些并不會用到的feature上正塌，而是可以有更多的時間去提升產品質量，進一步提升業(yè)務價值啃洋。后面的文章《如何在Fixbid項目上做敏捷開發(fā)》會反思下传货，如何在目前的情況下，把項目做到更好宏娄。
最后问裕，是時候展示真正的技術了！
所以巍杈，4倍的開發(fā)估計應該是比較穩(wěn)的忧饭。。筷畦〈士悖咳咳。鳖宾。吼砂。
