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