1. 敏捷項目里估算和計劃為什么總是“看起來很美跑起來很累”做過幾年項目的人大概都有這種體會需求評審會上大家點頭如搗蒜排期表一拉出來漂漂亮亮結(jié)果迭代跑到一半進度條像被焊死了一樣紋絲不動。問題出在哪十有八九根子就埋在“估算”和“計劃”這兩個環(huán)節(jié)里。我接觸過不少團隊用著各種項目管理工具看板、燃盡圖、故事點一應(yīng)俱全但真正問一句“你們這個8點是怎么估出來的”回答往往是“感覺差不多”“上次類似的需求大概這么久”。這種憑直覺的估算在敏捷項目里幾乎是災(zāi)難的開始。因為敏捷的核心是快速響應(yīng)變化而快速響應(yīng)的前提是你得知道自己現(xiàn)在站在哪、下一步大概要邁多大步子。這篇內(nèi)容我想圍繞“敏捷項目管理中的估算與計劃”這個主題把我在多個項目里踩過的坑、試過的招以及那些真正能落地的做法掰開揉碎了講清楚。不管你是剛接手敏捷團隊的項目負責人還是被排期折磨得頭大的開發(fā)同學或者是想搞清楚“故事點到底是個啥”的產(chǎn)品經(jīng)理都能從這里找到可以直接抄作業(yè)的東西。核心關(guān)鍵詞會貫穿始終敏捷估算、故事點、迭代計劃、速率、計劃撲克、需求拆解。這些詞不是拿來裝門面的每一個背后都對應(yīng)著一套具體的操作方法和判斷邏輯。2. 先搞明白敏捷估算到底在估什么2.1 估算的不是時間是“相對大小”很多人一上來就犯一個根本性錯誤把估算等同于“猜工期”。傳統(tǒng)瀑布模型里我們習慣問“這個功能要做幾天”然后填進甘特圖。但敏捷估算的邏輯完全不同——它估的是相對工作量而不是絕對時間。打個比方你要搬一堆東西有箱子、有袋子、有零碎物件。你不會去精確計算每個箱子搬下樓需要幾分鐘而是會判斷這個大箱子大概是小箱子的三倍重那個袋子跟小箱子差不多。這就是相對估算。故事點就是那個“重量單位”它沒有物理意義只是一個團隊內(nèi)部統(tǒng)一的標尺。為什么這么做因為人對絕對時間的判斷極不靠譜。你說“這個需求三天能做完”三天后大概率打臉。但你說“這個需求比那個已經(jīng)做完的需求復(fù)雜一倍”這個判斷的準確率會高得多。敏捷估算利用的就是人類這種相對比較的能力。2.2 故事點、理想天、T恤尺碼選哪個常見的估算單位有這么幾種各有各的適用場景估算方式適用場景優(yōu)點坑點故事點大多數(shù)敏捷團隊純相對不受個人效率影響新人容易換算成時間理想天團隊剛轉(zhuǎn)型敏捷直觀好理解容易被當成承諾工期T恤尺碼早期快速估算極簡適合大顆粒需求精度低不適合迭代內(nèi)細化斐波那契數(shù)列配合故事點使用強制拉開差距避免假精確需要團隊達成共識我個人的建議是新團隊從T恤尺碼起步穩(wěn)定后切換到故事點配斐波那契數(shù)列。理想天盡量別用因為它太容易變成“你說了三天就得三天完成”的隱形承諾。斐波那契數(shù)列1、2、3、5、8、13、21……的好處在于它強迫你在“5”和“8”之間做選擇而不是糾結(jié)“到底是6還是7”。這種模糊化處理反而讓估算更誠實因為精確到個位數(shù)本身就是一種幻覺。2.3 估算的錨點怎么定團隊需要一個基準故事作為錨點。比如選一個大家都做過、復(fù)雜度中等的需求定為5點。以后所有新需求都跟它比比它簡單一半的3點比它復(fù)雜一倍的8點再大的13點甚至需要拆分。這個錨點故事最好滿足幾個條件已經(jīng)完成、團隊所有人都參與過、復(fù)雜度適中、沒有太多外部依賴。定好之后把它貼在顯眼的地方每次估算都拿出來參照。我見過有的團隊把基準故事打印出來貼在白板上新需求一來就先問“跟這個比怎么樣”效果非常好。注意錨點不是一成不變的。團隊能力提升、技術(shù)棧熟悉之后同樣的需求可能從8點變成5點。這時候要么調(diào)整錨點要么接受“速率提升”這個事實別硬把點數(shù)往回拉。3. 計劃撲克怎么玩才不流于形式3.1 計劃撲克的完整操作流程計劃撲克是敏捷估算里最經(jīng)典也最實用的方法但很多團隊玩成了走過場。問題通常出在流程細節(jié)上。我把一個完整的、能真正產(chǎn)出有效估算的流程拆解一下需求講解產(chǎn)品經(jīng)理或需求提出者用不超過3分鐘講清楚這個需求要解決什么問題、驗收標準是什么。注意是講“問題”和“標準”不是講“實現(xiàn)方案”。澄清提問團隊成員自由提問把模糊點、邊界條件、技術(shù)難點都問出來。這一步最容易被壓縮但恰恰最重要。我一般會留至少5分鐘。各自出牌每個人獨立選擇一張牌同時亮出。不要互相看不要討論。解讀差異如果最大和最小差距超過兩個檔位比如有人出3有人出13就必須讓兩端的人分別說明理由。往往是出小牌的人忽略了某個復(fù)雜度或者出大牌的人想到了一個隱藏的坑。重新出牌討論后再來一輪通常第二輪就能收斂。記錄結(jié)果把最終點數(shù)記在需求卡片上同時記下討論中發(fā)現(xiàn)的風險點和假設(shè)條件。整個過程一個需求控制在10分鐘以內(nèi)。如果超過10分鐘還估不出來說明這個需求太大或者太模糊應(yīng)該先拆分或補充信息。3.2 為什么你的計劃撲克總是估不準估不準的原因我總結(jié)下來無非這么幾類需求本身模糊產(chǎn)品經(jīng)理自己都沒想清楚團隊只能靠猜。這時候估出來的點數(shù)沒有任何意義。技術(shù)方案未定同一個需求用緩存和不用緩存工作量差三倍。方案沒定就估算等于賭博。有人“帶節(jié)奏”團隊里有個聲音特別大的人先出牌其他人就跟著走了。計劃撲克的核心價值在于獨立判斷一旦被帶節(jié)奏就失效了。把點數(shù)當KPI如果管理層拿故事點考核個人產(chǎn)出那估算必然失真。大家會故意往高了估或者把簡單需求拆成多個來刷點數(shù)。實操心得我通常會在第一輪出牌后先讓出最小牌和最大牌的人發(fā)言而且要求他們只講“我為什么這么估”不許說服別人。這樣能最大程度保留獨立判斷的空間。3.3 遠程團隊怎么玩計劃撲克現(xiàn)在很多團隊是分布式的沒法圍在一張桌子前出牌。工具可以解決這個問題但有幾個細節(jié)要注意用支持同時亮牌的在線工具避免有人看到別人的選擇再改。語音溝通要保持暢通視頻更好因為表情和肢體語言能傳遞很多信息。指定一個主持人專門負責控制節(jié)奏、確保每個人都有發(fā)言機會。估算結(jié)果和討論要點要實時記錄在共享文檔里方便沒參會的成員異步補充。我試過純文字聊天的方式做估算效率極低而且容易產(chǎn)生誤解。語音加在線出牌工具是目前遠程場景下最靠譜的組合。4. 從估算到計劃迭代計劃會怎么開4.1 速率迭代計劃的“油門”和“剎車”速率Velocity是團隊在一個迭代內(nèi)實際完成的故事點總和。注意是實際完成不是“計劃完成”。一個迭代結(jié)束后把所有真正達到驗收標準的需求點數(shù)加起來就是這次的速率。速率的作用是給下一個迭代的計劃提供參考。如果過去三個迭代的速率分別是21、24、22那下一個迭代的計劃總量大概就在22點左右。不要貪心不要覺得“這次大家加把勁能做到30”。速率反映的是團隊的穩(wěn)定產(chǎn)出能力不是極限沖刺能力。新團隊沒有歷史速率怎么辦前兩個迭代可以“試探性”地定一個量然后根據(jù)實際情況調(diào)整。我一般建議新團隊第一個迭代少排一點寧可提前完成也不要大面積延期因為第一個迭代的體驗會影響整個團隊對敏捷的信心。4.2 迭代計劃會的標準議程一個高效的迭代計劃會我通常按這個節(jié)奏走回顧上個迭代10分鐘速率是多少有哪些沒做完的為什么沒做完。確認迭代目標5分鐘這個迭代最重要的一件事是什么用一句話說清楚。挑選需求20分鐘按優(yōu)先級從產(chǎn)品待辦列表里往下拿直到總量接近歷史速率。拆分任務(wù)30分鐘對每個選中的需求拆成具體的技術(shù)任務(wù)每項任務(wù)不超過一天。確認容量10分鐘考慮請假、會議、支持工作等調(diào)整計劃量。承諾與共識5分鐘團隊確認這個計劃是可行的不是被強加的。整個會議控制在1.5小時以內(nèi)。超過這個時間要么是需求太多要么是討論跑偏了。4.3 容量計算別忽略那些“看不見”的消耗很多團隊排計劃時只看速率不看容量結(jié)果迭代一開始就注定完不成。容量計算要考慮人員可用性有人請假、有人被借調(diào)、有人要參加培訓。非迭代工作線上問題處理、技術(shù)債務(wù)償還、代碼評審、會議。緩沖系數(shù)我一般會留出15%到20%的緩沖應(yīng)對突發(fā)情況。舉個例子團隊5個人迭代周期兩周歷史速率24點。但這次有1個人請假3天另外還有大約10%的時間要處理線上問題。那么實際可用容量大概是24 × (1 - 0.1) × (1 - 0.15) ≈ 18點。計劃時就按18點左右來排而不是硬塞24點。提示容量計算不是精確科學但哪怕粗略估一下也比完全不算強。我見過太多團隊因為忽略容量導致迭代中期瘋狂加班最后質(zhì)量崩盤。5. 需求拆解估算和計劃的地基5.1 什么樣的需求算“太大”一個需求如果滿足以下任何一條就說明它太大了需要拆分估算點數(shù)超過13斐波那契數(shù)列里13以上就屬于“需要拆分”的信號。一個迭代內(nèi)做不完。驗收標準超過5條。涉及三個以上模塊或服務(wù)。團隊在估算時反復(fù)出現(xiàn)“這個要看情況”的討論。大需求就像一塊大石頭你沒法直接搬得先砸成小塊。拆解的目的是讓每個小塊都能獨立開發(fā)、獨立測試、獨立交付價值。5.2 常見的拆解維度拆解不是隨便切要有邏輯。我常用的拆解維度有這么幾個按工作流拆比如一個下單功能可以拆成“瀏覽商品→加入購物車→填寫地址→支付→確認訂單”。按規(guī)則拆先實現(xiàn)基本規(guī)則再實現(xiàn)異常規(guī)則。比如先支持正常支付再支持退款、部分退款。按數(shù)據(jù)拆先支持一種數(shù)據(jù)類型再擴展。比如先支持文本再支持圖片、視頻。按接口拆先做核心接口再做管理接口、統(tǒng)計接口。按性能拆先做功能正確的版本再做性能優(yōu)化的版本。拆解之后每個子需求都應(yīng)該能獨立估算、獨立排期。如果拆完之后還是估不出來那就繼續(xù)拆。5.3 拆解中的常見誤區(qū)拆成技術(shù)任務(wù)而不是用戶價值比如“建數(shù)據(jù)庫表”“寫接口”這些是任務(wù)不是需求。需求應(yīng)該以用戶能感知的價值為單位。拆得太碎每個子需求只有1點導致管理成本比開發(fā)成本還高。一般子需求在2到8點之間比較合適。拆完忘了合拆解是為了更好地估算和交付不是為了拆而拆。拆完之后要確認所有子需求加起來仍然覆蓋原始需求的完整價值。6. 估算與計劃的持續(xù)校準6.1 回顧會議上的估算復(fù)盤每個迭代結(jié)束后的回顧會應(yīng)該留出專門的時間復(fù)盤估算準確性。具體做法對比計劃完成點數(shù)和實際完成點數(shù)算出偏差率。找出偏差最大的需求分析原因是估算偏了還是執(zhí)行中出了意外還是需求變了。把原因分類記錄形成團隊的“估算經(jīng)驗庫”。比如如果發(fā)現(xiàn)“涉及第三方接口的需求總是超估”那下次遇到類似需求時就可以適當調(diào)高點數(shù)。如果發(fā)現(xiàn)“前端頁面改版總是估高了”那就可以適當調(diào)低。6.2 速率波動的正常范圍速率不可能每個迭代都一樣波動是正常的。但如果波動超過±30%就需要警惕了。可能的原因包括迭代周期太短偶然因素影響大。需求粒度差異太大有的迭代全是小需求有的全是大需求。團隊人員變動頻繁。外部干擾太多比如線上問題、臨時插入需求。我一般會看最近三個迭代的移動平均速率而不是單個迭代的速率。這樣更能反映真實趨勢。6.3 什么時候該調(diào)整估算基準如果團隊連續(xù)三四個迭代的實際速率都明顯高于或低于計劃而且排除了外部干擾因素那就說明估算基準可能需要調(diào)整了。調(diào)整的方式有兩種調(diào)整錨點故事把基準故事的點數(shù)重新定義。比如原來5點的故事現(xiàn)在團隊覺得只值3點那就把錨點改成3點。接受速率變化不調(diào)整錨點但接受速率上升或下降的事實在計劃時按新速率來排。兩種方式都可以關(guān)鍵是團隊內(nèi)部要達成共識并且記錄下來避免以后混淆。7. 常見問題與排查技巧實錄7.1 估算分歧太大怎么辦分歧大通常是因為信息不對稱。出小牌的人可能沒意識到某個技術(shù)難點出大牌的人可能想到了一個別人不知道的約束條件。解決辦法就是讓兩端的人分別講理由而且要求講具體事實不是講感覺。如果講完理由還是無法收斂那就說明這個需求需要拆分或者需要先做一個技術(shù)驗證Spike。技術(shù)驗證本身也要估算和排期但它的產(chǎn)出是“搞清楚怎么做”而不是“做完這個功能”。7.2 產(chǎn)品經(jīng)理總是插需求怎么辦這是敏捷團隊最頭疼的問題之一。我的做法是建立明確的插入規(guī)則比如迭代進行到一半后不再接受新需求除非是緊急線上問題。用數(shù)據(jù)說話記錄每次插入需求對迭代完成率的影響拿數(shù)據(jù)跟產(chǎn)品經(jīng)理溝通。預(yù)留緩沖在容量計算時留出10%到15%的緩沖專門應(yīng)對插入需求。如果緩沖用完了還有插入那就必須替換掉等量的已排需求。關(guān)鍵是讓產(chǎn)品經(jīng)理明白插入需求不是免費的它的代價是其他需求被推遲。這個賬要算清楚。7.3 團隊對故事點理解不一致怎么辦新團隊常見的問題有人覺得5點是一天有人覺得5點是一周。解決辦法是定期做估算校準。具體做法每隔幾個迭代挑一個已經(jīng)完成的需求讓所有人重新估一遍。對比當時的估算和現(xiàn)在的估算討論差異原因。更新團隊對“1點大概是多少工作量”的共同理解。這個校準過程不需要很頻繁一兩個月一次就夠了。但它能有效防止團隊內(nèi)部的估算標準漂移。7.4 估算準確率速查表問題現(xiàn)象可能原因排查方向解決建議實際用時總是遠超估算估算時忽略了測試、評審、部署時間檢查任務(wù)拆分是否包含完整交付流程把測試和部署任務(wù)顯式列入計劃速率忽高忽低需求粒度差異大檢查迭代內(nèi)需求點數(shù)分布盡量保持需求粒度均勻團隊對點數(shù)爭議大缺乏共同基準檢查是否有錨點故事建立并維護基準故事庫計劃總是完不成容量計算遺漏檢查是否考慮了請假、會議、支持工作引入緩沖系數(shù)估算越來越慢需求太大或太模糊檢查需求是否超過13點強制拆分或補充需求信息7.5 幾個我踩過的坑坑一把故事點當工時用。早期我試圖把1點換算成4小時結(jié)果整個估算體系崩潰。因為不同需求的技術(shù)難度、風險、協(xié)作成本完全不同根本沒法線性換算。后來徹底放棄換算只做相對比較反而準了?？佣屢粋€人估所有需求。技術(shù)負責人大包大攬一個人把所有點數(shù)定了。結(jié)果執(zhí)行時其他人各種意外因為估算時沒有他們的參與很多細節(jié)沒被考慮到。計劃撲克的價值就在于集體智慧不能省?？尤型靖男枨蟛桓曼c數(shù)。需求變了但點數(shù)沒變導致速率數(shù)據(jù)失真。后來我們定了個規(guī)矩任何需求變更只要影響工作量就必須重新估算并更新點數(shù)。哪怕只是口頭確認一下也要記錄。坑四用速率考核團隊。管理層看到速率高就表揚速率低就批評。結(jié)果團隊開始刷點數(shù)把簡單需求拆成多個或者故意往高了估。速率數(shù)據(jù)徹底失去參考價值。后來我們明確速率只用于計劃參考不用于績效考核。8. 工具在估算與計劃中的角色8.1 工具能解決什么不能解決什么項目管理工具在估算和計劃環(huán)節(jié)能幫上忙的地方包括記錄和展示故事點、計算速率、生成燃盡圖、管理待辦列表、支持在線計劃撲克。但它解決不了核心問題團隊對需求的理解是否一致、技術(shù)方案是否清晰、估算標準是否統(tǒng)一。我見過有的團隊工具用得很溜各種報表花花綠綠但估算依然一塌糊涂。也見過有的團隊就用白板加便利貼估算和計劃做得井井有條。工具是輔助不是萬能藥。8.2 選擇工具的幾個判斷標準支持故事點字段能記錄每個需求的故事點并能按迭代匯總。支持速率計算能自動計算歷史速率最好能看移動平均。支持在線計劃撲克如果團隊是分布式的這個功能很實用。支持需求拆分能把大需求拆成子需求并保持關(guān)聯(lián)。報表清晰燃盡圖、速率圖要直觀不需要額外導出加工。至于具體用哪個工具我覺得只要滿足上面幾條用順手的就行。沒必要追求功能大而全很多高級功能團隊根本用不上反而增加了學習成本。8.3 工具使用的幾個實操建議故事點字段要統(tǒng)一所有需求都用同一個字段記錄點數(shù)不要有的用故事點、有的用理想天。迭代命名要規(guī)范比如“2024-S1”“2024-S2”方便回溯歷史數(shù)據(jù)。定期清理待辦列表過期的、不再做的需求要及時關(guān)閉或移出避免干擾速率計算。保留估算討論記錄在需求卡片上附上估算時的討論要點和假設(shè)條件方便后續(xù)復(fù)盤。9. 讓估算和計劃真正服務(wù)于交付說到底估算和計劃不是目的交付價值才是。我見過太多團隊在估算方法上糾結(jié)來糾結(jié)去卻忘了問一個根本問題這個估算幫我們做出更好的決策了嗎如果估算結(jié)果只是填在報表里好看對實際交付沒有任何指導作用那還不如不估。好的估算應(yīng)該能回答這些問題這個迭代我們能做多少下一個需求大概什么時候能交付如果插入一個新需求會影響什么團隊當前的產(chǎn)出能力是上升還是下降計劃也一樣。計劃不是用來“控制”團隊的而是用來對齊預(yù)期和暴露風險的。一個健康的迭代計劃應(yīng)該讓每個人都知道自己要做什么、為什么做、大概什么時候做完。如果計劃只是管理層的一廂情愿執(zhí)行層根本不認同那這個計劃從第一天起就是廢紙。我個人在實際操作中的體會是估算的準確性會隨著團隊成熟度自然提升但前提是團隊有意識地在復(fù)盤和改進。如果每次估算完就扔到一邊從不回頭看那估十年也還是老樣子。反過來哪怕一開始估得很不準但只要堅持記錄、復(fù)盤、調(diào)整三五個迭代之后就能達到相當靠譜的水平。最后再分享一個小技巧每次迭代計劃會結(jié)束前讓每個人用一句話說說“這個迭代我最擔心什么”。往往那些被忽略的風險就藏在這些擔心里面。提前說出來比迭代中期爆雷要好得多。