：從工時預(yù)測到項目排期)
1. 為什么我還在聊 COCOMO II估工時這件事從來不是拍腦袋做項目最怕什么不是技術(shù)選型翻車而是辛辛苦苦寫了三個月老板問“還要多久”你只能憋出一句“感覺快了”。這種感覺驅(qū)動的估算我見過太多翻車現(xiàn)場要么過度樂觀要么被某個強勢角色帶著節(jié)奏走。所以當有人問“項目工作量到底怎么估”我第一個推薦的就是 COCOMO II——一個把軟件成本估算從“感覺”變成“公式”的模型。COCOMO 是 Constructive Cost Model 的縮寫第二代 COCOMO II 解決的核心問題很樸素在軟件項目不同的階段用當前能拿到的信息量估算出合理的開發(fā)工作量、工期和人力投入。它最大的特點是按項目所處階段提供三種子模型應(yīng)用組裝模型、早期設(shè)計模型、后架構(gòu)模型。階段越靠后、信息越充分估算的顆粒度就越細、參數(shù)就越完整。這篇內(nèi)容適合誰一句話凡是需要回答“這個項目要多少人、做多久”的人——項目經(jīng)理、技術(shù)負責人、售前、外包接單的團隊——都值得讀完。后面我會把三種子模型、兩套核心參數(shù)規(guī)模因子和成本驅(qū)動因子、完整算例和踩坑記錄一次講清楚既有公式原理也有可以直接拿走的操作步驟。1.1 一句話說清 COCOMO II 到底在算什么COCOMO II 的核心輸出只有三個數(shù)工作量PM單位人月、日歷工期TDEV和平均人力PM / TDEV。它不直接回答“要花多少錢”但一旦有了人月和工期再疊加上人力單價、差旅、管理成本報價自然就出來了。它的輸入也分兩類一類是規(guī)模Size后架構(gòu)模型里用千行源代碼KSLOC或者功能點FP應(yīng)用組裝模型里用對象點Object Points另一類是項目的“屬性畫像”也就是規(guī)模因子和成本驅(qū)動因子。說白了模型就是一句話規(guī)模決定基準工作量屬性決定放大還是縮小這個基準。理解了這個邏輯你就不會被公式里那一堆字母嚇到。1.2 模型估算和“拍腦袋”差在哪我見過太多團隊這樣估工期需求評審會上產(chǎn)品經(jīng)理說“這個功能不難兩周吧”于是兩周就寫進了計劃。問題不在于兩周這個數(shù)字本身而在于這個數(shù)字沒有任何可追溯的推導(dǎo)過程。COCOMO II 的價值不是“算得準”而是“算得明白”為什么是這個數(shù)字、哪些因素把它推高了、哪些因素把它壓低了全都擺在那兒人人都能復(fù)核。模型當然不是萬能的。它的輸入本身依賴人的判斷評分評錯結(jié)果自然跑偏。但和拍腦袋相比它至少給了團隊一個討論的錨點有爭議就回到某個因子上去吵而不是在最終工期上互相扯皮。這在我看來就是它最大的價值——把估算從“立場之爭”變成“參數(shù)之爭”。2. 三種子模型項目階段不同估算的顆粒度就該不同COCOMO II 最重要的設(shè)計思想是承認“信息是不均勻的”。需求剛起步時你連模塊列表都列不全卻非要用后架構(gòu)模型去做精細測算那是自欺欺人反過來架構(gòu)都定了還只用七個參數(shù)粗算也是浪費。所以它把項目分成三種典型階段每個階段配一個子模型各干各的活。2.1 應(yīng)用組裝模型需求還沒成型時的快速摸底這是最粗的一個子模型我通常會在兩個場景用它一個是項目還沒批、需要快速給領(lǐng)導(dǎo)一個量級判斷一個是做原型驗證想看看這個想法到底值不值得投入。它的計量單位不是代碼行而是對象點Object Points。對象點的計數(shù)邏輯不復(fù)雜把系統(tǒng)要交付的界面屏幕、報表和第三代語言模塊按各自的復(fù)雜度簡單、中等、困難加權(quán)數(shù)出對象點總數(shù)。然后再乘上一個“去重用比例”算出新對象點 NOPNew Object Points。最后除以一個生產(chǎn)率參數(shù) PROD就是工作量PM NOP / PRODPROD 取值范圍大致在 4 到 50 之間取決于開發(fā)者的經(jīng)驗和開發(fā)環(huán)境的成熟度。新手團隊可能只有 4 到 7資深團隊配合成熟的組件庫可以到 25 到 50。舉個例子一個數(shù)據(jù)錄入原型數(shù)出來大概 200 個對象點給一個熟手團隊按 PROD 25 算工作量就是 200 / 25 8 人月左右十分鐘就能給出一個量級判斷。這個模型精度確實一般但勝在便宜適合做“方向盤級”的決策。2.2 早期設(shè)計模型需求有方向、架構(gòu)還沒定型項目正式立項、需求大體方向定了但架構(gòu)還沒評審這時候用早期設(shè)計模型。它支持用功能點或未調(diào)整的代碼行來估算規(guī)模成本驅(qū)動因子也從后架構(gòu)模型的十七個壓縮成了七個RCPX產(chǎn)品可靠性與復(fù)雜度、RUSE復(fù)用性、PDIF平臺難度、PERS人員能力、PREX人員經(jīng)驗、FCIL設(shè)施條件、SCED進度約束。為什么只有七個因為信息不夠你根本沒法精確區(qū)分“數(shù)據(jù)庫大小”和“產(chǎn)品復(fù)雜度”對成本的影響硬拆成十七個因子反而制造虛假精度。把相關(guān)性高的因子合并是對現(xiàn)階段信息量的誠實回應(yīng)。這個階段算出來的結(jié)果通常是一個“區(qū)間”而不是一個“點”我一般會拿它來做立項預(yù)算和人力規(guī)劃的初步依據(jù)。2.3 后架構(gòu)模型架構(gòu)落地后的精細核算這是三種子模型里最常用、也最需要認真對待的一個。架構(gòu)已經(jīng)評審?fù)昴K劃分、接口、關(guān)鍵設(shè)計都有了這時用千行源碼KSLOC或功能點作為規(guī)模用完整的十七個成本驅(qū)動因子去精算。我通常在兩個時間點必須跑一次后架構(gòu)模型一個是詳細設(shè)計完成、開發(fā)啟動之前作為內(nèi)部排期基線另一個是投標階段需求說明書比較完整時作為對外報價的技術(shù)依據(jù)。這個模型篩出來的結(jié)果我也不建議當成一個單點數(shù)字對外承諾而是配合敏感性分析給出一組“最可能 上下限”這樣對外匯報有底氣對內(nèi)排期有彈性。架構(gòu)都定了還估不準那問題往往不在模型而在規(guī)模估算和因子評級這些輸入環(huán)節(jié)。2.4 階段切換不是一刀切實際項目里很少有人說“我們現(xiàn)在不做早期設(shè)計了進入后架構(gòu)”。我的習慣是滾動估算需求澄清一次就更新一次規(guī)模架構(gòu)評審一次就把早期設(shè)計的七因子替換成后架構(gòu)的十七因子。模型的輸出始終是個活文檔而不是立項時寫完就鎖死的死數(shù)字。每次刷新其實都是在強迫團隊重新審視需求變化和風險這個附加價值往往比估算數(shù)字本身還重要。3. 核心公式拆解規(guī)模因子和成本驅(qū)動因子才是發(fā)動機三種子模型的骨架是同一套公式區(qū)別只在于規(guī)?？趶胶统杀掘?qū)動因子的數(shù)量。理解了公式你就能理解整個模型的設(shè)計意圖不理解你就只能當一個“公式填表員”數(shù)字錯了都不知道錯在哪兒。3.1 主公式PM、Size、指數(shù)、EM 的關(guān)系后架構(gòu)模型和早期設(shè)計模型都基于下面這個式子PM A × Size^E × ∏EM_i其中PM 是工作量單位人月A 是校準常數(shù)模型默認給 2.94這是提出者用當年大量項目數(shù)據(jù)擬合出來的基線Size 是規(guī)模后架構(gòu)模型用 KSLOCE 是規(guī)模指數(shù)它不是固定的 1.0而是由五個規(guī)模因子算出來的∏EM_i 是所有選定的成本驅(qū)動因子的連乘。這里有個新手最容易忽略的點Size 頭上的指數(shù) E 不是常量。E 越大說明同樣的規(guī)模增長會帶來更大的工作量增長。這背后是軟件工程里一個真實規(guī)律——項目越大溝通成本、集成成本、返工成本都呈超線性增長10 個模塊和 20 個模塊的溝通復(fù)雜度差得不是一倍是好幾倍。3.2 五個規(guī)模因子決定指數(shù)的區(qū)間E 的計算式是E B 0.01 × ΣSF_j其中 B 取 0.91SF 是五個規(guī)模因子各自的評分值。五個因子分別是 PREC項目先例性、FLEX開發(fā)靈活性、RESL架構(gòu)與風險解決、TEAM團隊凝聚力、PMAT過程成熟度。每個因子分六級評分從 Very Low 到 Extra High對應(yīng)數(shù)值如下表規(guī)模因子Very LowLowNominalHighVery HighExtra HighPREC 先例性6.204.963.722.481.240.00FLEX 開發(fā)靈活性5.074.053.042.031.010.00RESL 架構(gòu)與風險解決7.075.654.242.831.410.00TEAM 團隊凝聚力5.484.383.292.191.100.00PMAT 過程成熟度7.806.244.683.121.560.00打分邏輯也很好理解先例性越高、架構(gòu)風險解決得越好、團隊越默契、過程越成熟評分值越小指數(shù) E 就越低。最理想情況下五個值全取 0E 0.91規(guī)模增長帶來的工作量增長接近線性最差情況下五個值全取最大E 約等于 1.23規(guī)模翻倍工作量要翻接近 2.3 倍。這就是模型對“混亂大項目”最直白的懲罰。3.3 十七個成本驅(qū)動因子后架構(gòu)模型的主戰(zhàn)場后架構(gòu)模型把成本驅(qū)動因子分成四組總共十七個每個因子評六級對應(yīng)一個乘法系數(shù)Effort MultiplierEM。EM 大于 1 表示這個因素把工作量放大小于 1 表示有利因素把工作量縮小。下面這張表是我常用的速查表分組因子含義常見取值區(qū)間產(chǎn)品RELY要求的軟件可靠性0.82 ~ 1.26產(chǎn)品DATA數(shù)據(jù)庫規(guī)模0.90 ~ 1.28產(chǎn)品CPLX產(chǎn)品復(fù)雜度0.73 ~ 1.74產(chǎn)品RUSE要求的可復(fù)用性0.91 ~ 1.36產(chǎn)品DOCU文檔要求0.81 ~ 1.23平臺TIME執(zhí)行時間約束1.00 ~ 1.63平臺STOR主存約束1.00 ~ 1.46平臺PVOL平臺易變性0.87 ~ 1.30人員ACAP分析師能力1.42 ~ 0.71人員PCAP程序員能力1.34 ~ 0.73人員PCON人員連續(xù)性1.29 ~ 0.81人員APEX應(yīng)用經(jīng)驗1.22 ~ 0.81人員PLEX平臺經(jīng)驗1.19 ~ 0.85人員LTEX語言與工具經(jīng)驗1.20 ~ 0.84項目TOOL軟件工具使用1.17 ~ 0.78項目SITE多點開發(fā)1.22 ~ 0.80項目SCED進度約束1.43 ~ 1.00注意 ACAP 這類人員因子數(shù)值方向是反的能力越高 EM 越小比如 ACAP 評到 Very High 時 EM 只有 0.71等于給工作量打七折。這組因子的連乘可以輕松讓最終結(jié)果差出兩三倍所以評級必須認真不能全拍 Nominal。3.4 早期設(shè)計模型為什么只需要七個因子早期設(shè)計模型的七個因子本質(zhì)是把十七個因子按相關(guān)性合并后的結(jié)果RCPX 合并了 RELY、DATA、CPLX 和 DOCUPDIF 合并了 TIME、STOR 和 PVOLPERS 合并了六個人員因子FCIL 合并了 TOOL 和 SITE再單獨留一個 RUSE 和一個 SCED。這樣在信息不完整時打分更穩(wěn)不會因為硬拆出十七個因子而制造虛假精度。這背后是一個工程原則估算的精度應(yīng)當匹配信息的完備度。信息不足時強行細分打分全是猜結(jié)果反而不如合并后粗評可靠。所以階段越早參數(shù)越少不是模型偷懶而是它在替你規(guī)避“虛假精確”的陷阱。3.5 從工作量到日歷工期有了 PM 還不夠還得算日歷工期。COCOMO II 的工期公式是TDEV C × PM^F其中 C 默認 3.67F D 0.2 × (E - B)D 默認 0.28。平均人力約等于 PM / TDEV。這里有個關(guān)鍵點如果老板要求壓縮工期不能直接拿 TDEV 數(shù)值除以 2因為 SCED 因子會在工作量公式里起作用——強行壓工期工作量反而會上升。這是模型里我最欣賞的一個設(shè)計它內(nèi)置了對“趕工幻覺”的警告你以為壓縮時間能省錢其實是在燒更多的人力成本。4. 一次完整的估算實操從定場景到出結(jié)果理論講完下面我?guī)Т蠹易咭槐橥暾墓浪懔鞒?。為了能完全?fù)現(xiàn)我會用一個虛構(gòu)的內(nèi)網(wǎng)管理系統(tǒng)項目做例子規(guī)模按 20 KSLOC 算。你照著走一遍就能把整套流程跑通。4.1 第一步明確估算場景選擇子模型先問三個問題需求到什么程度了架構(gòu)定了嗎這個估算給誰用如果只是立項前的量級判斷用應(yīng)用組裝模型或早期設(shè)計模型如果是要排開發(fā)基線或?qū)ν鈭髢r用后架構(gòu)模型。我們的例子假定已經(jīng)完成架構(gòu)評審所以選后架構(gòu)模型。這一步別跳過選錯模型是整個估算里最傷筋動骨的錯誤后面再精細都白搭。4.2 第二步把需求翻譯成規(guī)模規(guī)模是估算里最影響結(jié)果的輸入。后架構(gòu)模型里規(guī)模指新開發(fā)的代碼量單位 KSLOC。怎么估一般用三種辦法交叉驗證一是類比參考歷史項目每千行的規(guī)模二是分解把系統(tǒng)拆成模塊逐個估再匯總?cè)侨c估算每個模塊給出樂觀值、最可能值、悲觀值按 (O 4M P) / 6 求期望這個公式也叫 PERT 加權(quán)。注意幾個口徑坑注釋和空行通常不計入有效源碼行自動生成的代碼要單獨說明一般不計入或打很低折扣復(fù)用代碼不是零成本改造工作量按當量規(guī)模折算。比如從開源組件里拿來的代碼如果只改 10%就該按改造工作量折算而不是把整段代碼都算成你的開發(fā)規(guī)模。我們估下來這個系統(tǒng)新代碼 20 KSLOC復(fù)用和改造部分折算后等價規(guī)模仍按 20 KSLOC 處理。4.3 第三步逐項評級這一步是估算精度的心臟。建議拉上技術(shù)負責人、一線開發(fā)、測試負責人一起打分背靠背評完再統(tǒng)一討論避免“一個人說了算”。我自己會準備一張評定表每個因子都寫下評級理由哪怕是“參考了上次項目的數(shù)據(jù)庫復(fù)雜度”這種一句話理由都比直接填數(shù)字強。為方便理解我們這個例子的評分設(shè)定如下五個規(guī)模因子分別取 Nominal、High、Nominal、High、Low對應(yīng)數(shù)值 3.72、2.03、4.24、2.19、6.24合計 18.42十七個成本驅(qū)動因子里可靠性、數(shù)據(jù)庫規(guī)模、文檔要求偏高平臺約束寬松人員能力和經(jīng)驗中上工具使用較好。具體評級不必糾結(jié)重點是走通流程每個評級都要有依據(jù)依據(jù)越硬結(jié)果越可信。4.4 第四步代入公式算給你看先算指數(shù) EE 0.91 0.01 × 18.42 1.0942再算規(guī)模的冪20^1.0942 ≈ 26.5然后連乘十七個 EM。這一步最容易漏乘我建議在電子表格里用 SUM 和 PRODUCT 函數(shù)自動算避免手疊。假設(shè)各因子評級代入后連乘等于 0.645——含義是這些“有利因素”整體把基準工作量壓掉了約 35%。最后代入主公式PM 2.94 × 26.5 × 0.645 ≈ 50.2 人月再算工期F 0.28 0.2 × (1.0942 - 0.91) 0.3168TDEV 3.67 × 50.2^0.3168 ≈ 3.67 × 3.47 ≈ 12.7 個月平均人力 ≈ 50.2 / 12.7 ≈ 4 人也就是說按這個屬性畫像大概需要 4 到 5 人左右的團隊干一年出頭。如果你心里先入為主覺得“20 千行三個月搞定”現(xiàn)在這個數(shù)字可以幫你冷靜一下。這不代表模型絕對正確但至少它把“20 千行需要多少成本”這件事從主觀感覺變成了可討論的公式推演。4.5 第五步結(jié)果解讀與敏感性分析我不建議直接把 50.2 人月當作最終答案。更實際的做法是對幾個不確定因子做敏感性分析比如把 ACAP 從 High 降到 Nominal工作量可能漲十幾個百分點把 CPLX 從 Nominal 提到 High整體要再多一成。把最優(yōu)、最可能的幾種組合都算一遍得到一個大致的區(qū)間比如 42 到 72 人月再結(jié)合需求和風險定最終基線。敏感性分析最大的作用是暴露“哪些信息不確定會怎樣影響結(jié)論”。如果某個因子稍微動一下結(jié)果就天差地別那說明當前最大的風險就在那兒應(yīng)該優(yōu)先去把信息補齊而不是糾結(jié)估算數(shù)字本身。我見過太多人拿著模型算出來的單點數(shù)字去跟老板匯報結(jié)果被一個不確定因子打得措手不及。5. 常見問題與排查技巧實錄這部分是我用過幾年之后攢下來的實戰(zhàn)心得踩過的坑都在這兒。模型本身不復(fù)雜真正復(fù)雜的永遠是輸入端的各種“人性陷阱”和“口徑陷阱”。5.1 算出來工作量“離譜”先查這三處第一處是規(guī)?？趶?。最常見的錯誤是拿整個倉庫的代碼量直接當 KSLOC把第三方依賴、自動生成代碼、測試代碼全算進去了。我見過有人把實際 8 KSLOC 的改動量算成 50 KSLOC結(jié)果估算翻了近十倍。第二處是 EM 連乘漏項或者把 EM 相加了。必須是連乘少乘一個 0.85 的因子整體就差 15%十幾個因子下來誤差能到兩三倍。第三處是單位問題有人把 20 KSLOC 填成 20000 KSLOC指數(shù)一拉數(shù)字直接崩壞。還有一個隱蔽坑指數(shù) E 忘了按規(guī)模因子算直接拿 1.0 以外的某個“印象值”硬填。E 每差 0.1在 50 KSLOC 規(guī)模上就是 15% 左右的誤差所以五個規(guī)模因子的評級也要認真對待不能默認取中間。5.2 評級全是“Nominal”等于沒評我見過最典型的偷懶是所有因子全選 Nominal。這樣做不是錯而是白白丟掉了模型最大的價值——把團隊對項目的共識變成量化參數(shù)。我的做法是每個因子至少寫一條客觀依據(jù)比如“接口文檔要求達到對外發(fā)布級別DOCU 評 High”“核心鏈路延遲要求 200 毫秒以內(nèi)TIME 必須考慮”。寫不出來就去查資料、去訪談而不是直接跳過。評級還有一個技巧把“和上一次項目相比”作為錨點。上次項目數(shù)據(jù)庫復(fù)雜度高這次差不多DATA 就參考上次的評級上次團隊凝聚力差導(dǎo)致返工多這次換了組織形式TEAM 就可以向上調(diào)一檔。有歷史參照物比憑空打分穩(wěn)得多。5.3 新人團隊、外包團隊、遠程團隊怎么擺參數(shù)如果團隊里一半是剛畢業(yè)的新人ACAP 和 PCAP 別客氣直接往 Low 甚至 Very Low 偏人員流動大PCON 往 Low 偏遠程多點協(xié)作、溝通鏈路長SITE 和 TEAM 都不會好看。這些參數(shù)調(diào)完之后工作量常常會讓人肉疼但這也是模型的誠實之處團隊現(xiàn)狀差成本就是高。與其把參數(shù)美化來討老板開心不如把真實成本擺出來推動團隊改善現(xiàn)狀。我實際遇到過項目因為把 ACAP 從 Low 調(diào)成 Nominal整體工作量被壓了兩成最后開發(fā)階段瘋狂返工成本全找補回來還倒貼。參數(shù)美化一時爽項目復(fù)盤火葬場這句話真不是段子。5.4 手算還是上工具我自己的習慣是拿電子表格搭一個模板把 KSLOC、SF、EM 放進去公式鏈自動算 PM 和 TDEV再配一個小的腳本做敏感性分析批量跑。市面上也有不少商業(yè)成本估算工具優(yōu)勢是內(nèi)置了完整的校準參數(shù)和歷史數(shù)據(jù)庫適合大規(guī)模組織統(tǒng)一口徑。但如果你只是中小團隊電子表格完全夠用關(guān)鍵是保證公式正確、參數(shù)可追溯。這里分享一個模板設(shè)計思路把五個規(guī)模因子和十七個成本驅(qū)動因子分別做成兩縱列一列填評級、一列填對應(yīng)數(shù)值然后用 PRODUCT 函數(shù)自動連乘 EM用公式引用 SF 合計去算 E。這樣每次改評級結(jié)果自動刷新做敏感性分析時就特別順手。6. 我實際用下來的幾點體會用了幾年 COCOMO II我最深的感受是它改變的不是估算方式而是團隊討論估算的方式。以前評審會里吵的是“我覺得要三個月”“我覺得一個月就行”現(xiàn)在吵的是“RELY 憑什么評 High”“CPLX 是不是低估了”。爭論聚焦在可驗證的參數(shù)上反而更容易達成共識也更容易暴露需求理解的盲區(qū)。這是我一開始完全沒想到的收獲。另外一個很實用的建議是拿歷史項目做回測。把自己做過的兩三個項目翻出來把規(guī)模和評級填進模型看看算出來的人月跟實際差多少。這個校準過程比任何理論都管用——你會發(fā)現(xiàn)自己的團隊到底偏快還是偏慢、哪些評級總是過于樂觀。把常數(shù) A 的 2.94 調(diào)成自己團隊的校準值之后模型才真正變成了“你的工具”而不是“別人的公式”。最后說個小技巧每次估算完把評級表和計算結(jié)果存成一份文檔項目結(jié)束之后回頭對賬。堅持幾個項目你就有了屬于自己的估算基準那時候你拍出來的“感覺”也會比大多數(shù)人準得多。這也是我把這些寫出來的原因——估算能力是攢出來的不是天上掉下來的。模型給你骨架歷次項目數(shù)據(jù)給你血肉兩者合起來才是一套真正能用的成本估算體系。 COCOMO II軟件成本估算實戰(zhàn)：從工時預(yù)測到項目排期
1. 為什么我還在聊 COCOMO II估工時這件事從來不是拍腦袋做項目最怕什么不是技術(shù)選型翻車而是辛辛苦苦寫了三個月老板問“還要多久”你只能憋出一句“感覺快了”。這種感覺驅(qū)動的估算我見過太多翻車現(xiàn)場要么過度樂觀要么被某個強勢角色帶著節(jié)奏走。所以當有人問“項目工作量到底怎么估”我第一個推薦的就是 COCOMO II——一個把軟件成本估算從“感覺”變成“公式”的模型。COCOMO 是 Constructive Cost Model 的縮寫第二代 COCOMO II 解決的核心問題很樸素在軟件項目不同的階段用當前能拿到的信息量估算出合理的開發(fā)工作量、工期和人力投入。它最大的特點是按項目所處階段提供三種子模型應(yīng)用組裝模型、早期設(shè)計模型、后架構(gòu)模型。階段越靠后、信息越充分估算的顆粒度就越細、參數(shù)就越完整。這篇內(nèi)容適合誰一句話凡是需要回答“這個項目要多少人、做多久”的人——項目經(jīng)理、技術(shù)負責人、售前、外包接單的團隊——都值得讀完。后面我會把三種子模型、兩套核心參數(shù)規(guī)模因子和成本驅(qū)動因子、完整算例和踩坑記錄一次講清楚既有公式原理也有可以直接拿走的操作步驟。1.1 一句話說清 COCOMO II 到底在算什么COCOMO II 的核心輸出只有三個數(shù)工作量PM單位人月、日歷工期TDEV和平均人力PM / TDEV。它不直接回答“要花多少錢”但一旦有了人月和工期再疊加上人力單價、差旅、管理成本報價自然就出來了。它的輸入也分兩類一類是規(guī)模Size后架構(gòu)模型里用千行源代碼KSLOC或者功能點FP應(yīng)用組裝模型里用對象點Object Points另一類是項目的“屬性畫像”也就是規(guī)模因子和成本驅(qū)動因子。說白了模型就是一句話規(guī)模決定基準工作量屬性決定放大還是縮小這個基準。理解了這個邏輯你就不會被公式里那一堆字母嚇到。1.2 模型估算和“拍腦袋”差在哪我見過太多團隊這樣估工期需求評審會上產(chǎn)品經(jīng)理說“這個功能不難兩周吧”于是兩周就寫進了計劃。問題不在于兩周這個數(shù)字本身而在于這個數(shù)字沒有任何可追溯的推導(dǎo)過程。COCOMO II 的價值不是“算得準”而是“算得明白”為什么是這個數(shù)字、哪些因素把它推高了、哪些因素把它壓低了全都擺在那兒人人都能復(fù)核。模型當然不是萬能的。它的輸入本身依賴人的判斷評分評錯結(jié)果自然跑偏。但和拍腦袋相比它至少給了團隊一個討論的錨點有爭議就回到某個因子上去吵而不是在最終工期上互相扯皮。這在我看來就是它最大的價值——把估算從“立場之爭”變成“參數(shù)之爭”。2. 三種子模型項目階段不同估算的顆粒度就該不同COCOMO II 最重要的設(shè)計思想是承認“信息是不均勻的”。需求剛起步時你連模塊列表都列不全卻非要用后架構(gòu)模型去做精細測算那是自欺欺人反過來架構(gòu)都定了還只用七個參數(shù)粗算也是浪費。所以它把項目分成三種典型階段每個階段配一個子模型各干各的活。2.1 應(yīng)用組裝模型需求還沒成型時的快速摸底這是最粗的一個子模型我通常會在兩個場景用它一個是項目還沒批、需要快速給領(lǐng)導(dǎo)一個量級判斷一個是做原型驗證想看看這個想法到底值不值得投入。它的計量單位不是代碼行而是對象點Object Points。對象點的計數(shù)邏輯不復(fù)雜把系統(tǒng)要交付的界面屏幕、報表和第三代語言模塊按各自的復(fù)雜度簡單、中等、困難加權(quán)數(shù)出對象點總數(shù)。然后再乘上一個“去重用比例”算出新對象點 NOPNew Object Points。最后除以一個生產(chǎn)率參數(shù) PROD就是工作量PM NOP / PRODPROD 取值范圍大致在 4 到 50 之間取決于開發(fā)者的經(jīng)驗和開發(fā)環(huán)境的成熟度。新手團隊可能只有 4 到 7資深團隊配合成熟的組件庫可以到 25 到 50。舉個例子一個數(shù)據(jù)錄入原型數(shù)出來大概 200 個對象點給一個熟手團隊按 PROD 25 算工作量就是 200 / 25 8 人月左右十分鐘就能給出一個量級判斷。這個模型精度確實一般但勝在便宜適合做“方向盤級”的決策。2.2 早期設(shè)計模型需求有方向、架構(gòu)還沒定型項目正式立項、需求大體方向定了但架構(gòu)還沒評審這時候用早期設(shè)計模型。它支持用功能點或未調(diào)整的代碼行來估算規(guī)模成本驅(qū)動因子也從后架構(gòu)模型的十七個壓縮成了七個RCPX產(chǎn)品可靠性與復(fù)雜度、RUSE復(fù)用性、PDIF平臺難度、PERS人員能力、PREX人員經(jīng)驗、FCIL設(shè)施條件、SCED進度約束。為什么只有七個因為信息不夠你根本沒法精確區(qū)分“數(shù)據(jù)庫大小”和“產(chǎn)品復(fù)雜度”對成本的影響硬拆成十七個因子反而制造虛假精度。把相關(guān)性高的因子合并是對現(xiàn)階段信息量的誠實回應(yīng)。這個階段算出來的結(jié)果通常是一個“區(qū)間”而不是一個“點”我一般會拿它來做立項預(yù)算和人力規(guī)劃的初步依據(jù)。2.3 后架構(gòu)模型架構(gòu)落地后的精細核算這是三種子模型里最常用、也最需要認真對待的一個。架構(gòu)已經(jīng)評審?fù)昴K劃分、接口、關(guān)鍵設(shè)計都有了這時用千行源碼KSLOC或功能點作為規(guī)模用完整的十七個成本驅(qū)動因子去精算。我通常在兩個時間點必須跑一次后架構(gòu)模型一個是詳細設(shè)計完成、開發(fā)啟動之前作為內(nèi)部排期基線另一個是投標階段需求說明書比較完整時作為對外報價的技術(shù)依據(jù)。這個模型篩出來的結(jié)果我也不建議當成一個單點數(shù)字對外承諾而是配合敏感性分析給出一組“最可能 上下限”這樣對外匯報有底氣對內(nèi)排期有彈性。架構(gòu)都定了還估不準那問題往往不在模型而在規(guī)模估算和因子評級這些輸入環(huán)節(jié)。2.4 階段切換不是一刀切實際項目里很少有人說“我們現(xiàn)在不做早期設(shè)計了進入后架構(gòu)”。我的習慣是滾動估算需求澄清一次就更新一次規(guī)模架構(gòu)評審一次就把早期設(shè)計的七因子替換成后架構(gòu)的十七因子。模型的輸出始終是個活文檔而不是立項時寫完就鎖死的死數(shù)字。每次刷新其實都是在強迫團隊重新審視需求變化和風險這個附加價值往往比估算數(shù)字本身還重要。3. 核心公式拆解規(guī)模因子和成本驅(qū)動因子才是發(fā)動機三種子模型的骨架是同一套公式區(qū)別只在于規(guī)?？趶胶统杀掘?qū)動因子的數(shù)量。理解了公式你就能理解整個模型的設(shè)計意圖不理解你就只能當一個“公式填表員”數(shù)字錯了都不知道錯在哪兒。3.1 主公式PM、Size、指數(shù)、EM 的關(guān)系后架構(gòu)模型和早期設(shè)計模型都基于下面這個式子PM A × Size^E × ∏EM_i其中PM 是工作量單位人月A 是校準常數(shù)模型默認給 2.94這是提出者用當年大量項目數(shù)據(jù)擬合出來的基線Size 是規(guī)模后架構(gòu)模型用 KSLOCE 是規(guī)模指數(shù)它不是固定的 1.0而是由五個規(guī)模因子算出來的∏EM_i 是所有選定的成本驅(qū)動因子的連乘。這里有個新手最容易忽略的點Size 頭上的指數(shù) E 不是常量。E 越大說明同樣的規(guī)模增長會帶來更大的工作量增長。這背后是軟件工程里一個真實規(guī)律——項目越大溝通成本、集成成本、返工成本都呈超線性增長10 個模塊和 20 個模塊的溝通復(fù)雜度差得不是一倍是好幾倍。3.2 五個規(guī)模因子決定指數(shù)的區(qū)間E 的計算式是E B 0.01 × ΣSF_j其中 B 取 0.91SF 是五個規(guī)模因子各自的評分值。五個因子分別是 PREC項目先例性、FLEX開發(fā)靈活性、RESL架構(gòu)與風險解決、TEAM團隊凝聚力、PMAT過程成熟度。每個因子分六級評分從 Very Low 到 Extra High對應(yīng)數(shù)值如下表規(guī)模因子Very LowLowNominalHighVery HighExtra HighPREC 先例性6.204.963.722.481.240.00FLEX 開發(fā)靈活性5.074.053.042.031.010.00RESL 架構(gòu)與風險解決7.075.654.242.831.410.00TEAM 團隊凝聚力5.484.383.292.191.100.00PMAT 過程成熟度7.806.244.683.121.560.00打分邏輯也很好理解先例性越高、架構(gòu)風險解決得越好、團隊越默契、過程越成熟評分值越小指數(shù) E 就越低。最理想情況下五個值全取 0E 0.91規(guī)模增長帶來的工作量增長接近線性最差情況下五個值全取最大E 約等于 1.23規(guī)模翻倍工作量要翻接近 2.3 倍。這就是模型對“混亂大項目”最直白的懲罰。3.3 十七個成本驅(qū)動因子后架構(gòu)模型的主戰(zhàn)場后架構(gòu)模型把成本驅(qū)動因子分成四組總共十七個每個因子評六級對應(yīng)一個乘法系數(shù)Effort MultiplierEM。EM 大于 1 表示這個因素把工作量放大小于 1 表示有利因素把工作量縮小。下面這張表是我常用的速查表分組因子含義常見取值區(qū)間產(chǎn)品RELY要求的軟件可靠性0.82 ~ 1.26產(chǎn)品DATA數(shù)據(jù)庫規(guī)模0.90 ~ 1.28產(chǎn)品CPLX產(chǎn)品復(fù)雜度0.73 ~ 1.74產(chǎn)品RUSE要求的可復(fù)用性0.91 ~ 1.36產(chǎn)品DOCU文檔要求0.81 ~ 1.23平臺TIME執(zhí)行時間約束1.00 ~ 1.63平臺STOR主存約束1.00 ~ 1.46平臺PVOL平臺易變性0.87 ~ 1.30人員ACAP分析師能力1.42 ~ 0.71人員PCAP程序員能力1.34 ~ 0.73人員PCON人員連續(xù)性1.29 ~ 0.81人員APEX應(yīng)用經(jīng)驗1.22 ~ 0.81人員PLEX平臺經(jīng)驗1.19 ~ 0.85人員LTEX語言與工具經(jīng)驗1.20 ~ 0.84項目TOOL軟件工具使用1.17 ~ 0.78項目SITE多點開發(fā)1.22 ~ 0.80項目SCED進度約束1.43 ~ 1.00注意 ACAP 這類人員因子數(shù)值方向是反的能力越高 EM 越小比如 ACAP 評到 Very High 時 EM 只有 0.71等于給工作量打七折。這組因子的連乘可以輕松讓最終結(jié)果差出兩三倍所以評級必須認真不能全拍 Nominal。3.4 早期設(shè)計模型為什么只需要七個因子早期設(shè)計模型的七個因子本質(zhì)是把十七個因子按相關(guān)性合并后的結(jié)果RCPX 合并了 RELY、DATA、CPLX 和 DOCUPDIF 合并了 TIME、STOR 和 PVOLPERS 合并了六個人員因子FCIL 合并了 TOOL 和 SITE再單獨留一個 RUSE 和一個 SCED。這樣在信息不完整時打分更穩(wěn)不會因為硬拆出十七個因子而制造虛假精度。這背后是一個工程原則估算的精度應(yīng)當匹配信息的完備度。信息不足時強行細分打分全是猜結(jié)果反而不如合并后粗評可靠。所以階段越早參數(shù)越少不是模型偷懶而是它在替你規(guī)避“虛假精確”的陷阱。3.5 從工作量到日歷工期有了 PM 還不夠還得算日歷工期。COCOMO II 的工期公式是TDEV C × PM^F其中 C 默認 3.67F D 0.2 × (E - B)D 默認 0.28。平均人力約等于 PM / TDEV。這里有個關(guān)鍵點如果老板要求壓縮工期不能直接拿 TDEV 數(shù)值除以 2因為 SCED 因子會在工作量公式里起作用——強行壓工期工作量反而會上升。這是模型里我最欣賞的一個設(shè)計它內(nèi)置了對“趕工幻覺”的警告你以為壓縮時間能省錢其實是在燒更多的人力成本。4. 一次完整的估算實操從定場景到出結(jié)果理論講完下面我?guī)Т蠹易咭槐橥暾墓浪懔鞒?。為了能完全?fù)現(xiàn)我會用一個虛構(gòu)的內(nèi)網(wǎng)管理系統(tǒng)項目做例子規(guī)模按 20 KSLOC 算。你照著走一遍就能把整套流程跑通。4.1 第一步明確估算場景選擇子模型先問三個問題需求到什么程度了架構(gòu)定了嗎這個估算給誰用如果只是立項前的量級判斷用應(yīng)用組裝模型或早期設(shè)計模型如果是要排開發(fā)基線或?qū)ν鈭髢r用后架構(gòu)模型。我們的例子假定已經(jīng)完成架構(gòu)評審所以選后架構(gòu)模型。這一步別跳過選錯模型是整個估算里最傷筋動骨的錯誤后面再精細都白搭。4.2 第二步把需求翻譯成規(guī)模規(guī)模是估算里最影響結(jié)果的輸入。后架構(gòu)模型里規(guī)模指新開發(fā)的代碼量單位 KSLOC。怎么估一般用三種辦法交叉驗證一是類比參考歷史項目每千行的規(guī)模二是分解把系統(tǒng)拆成模塊逐個估再匯總?cè)侨c估算每個模塊給出樂觀值、最可能值、悲觀值按 (O 4M P) / 6 求期望這個公式也叫 PERT 加權(quán)。注意幾個口徑坑注釋和空行通常不計入有效源碼行自動生成的代碼要單獨說明一般不計入或打很低折扣復(fù)用代碼不是零成本改造工作量按當量規(guī)模折算。比如從開源組件里拿來的代碼如果只改 10%就該按改造工作量折算而不是把整段代碼都算成你的開發(fā)規(guī)模。我們估下來這個系統(tǒng)新代碼 20 KSLOC復(fù)用和改造部分折算后等價規(guī)模仍按 20 KSLOC 處理。4.3 第三步逐項評級這一步是估算精度的心臟。建議拉上技術(shù)負責人、一線開發(fā)、測試負責人一起打分背靠背評完再統(tǒng)一討論避免“一個人說了算”。我自己會準備一張評定表每個因子都寫下評級理由哪怕是“參考了上次項目的數(shù)據(jù)庫復(fù)雜度”這種一句話理由都比直接填數(shù)字強。為方便理解我們這個例子的評分設(shè)定如下五個規(guī)模因子分別取 Nominal、High、Nominal、High、Low對應(yīng)數(shù)值 3.72、2.03、4.24、2.19、6.24合計 18.42十七個成本驅(qū)動因子里可靠性、數(shù)據(jù)庫規(guī)模、文檔要求偏高平臺約束寬松人員能力和經(jīng)驗中上工具使用較好。具體評級不必糾結(jié)重點是走通流程每個評級都要有依據(jù)依據(jù)越硬結(jié)果越可信。4.4 第四步代入公式算給你看先算指數(shù) EE 0.91 0.01 × 18.42 1.0942再算規(guī)模的冪20^1.0942 ≈ 26.5然后連乘十七個 EM。這一步最容易漏乘我建議在電子表格里用 SUM 和 PRODUCT 函數(shù)自動算避免手疊。假設(shè)各因子評級代入后連乘等于 0.645——含義是這些“有利因素”整體把基準工作量壓掉了約 35%。最后代入主公式PM 2.94 × 26.5 × 0.645 ≈ 50.2 人月再算工期F 0.28 0.2 × (1.0942 - 0.91) 0.3168TDEV 3.67 × 50.2^0.3168 ≈ 3.67 × 3.47 ≈ 12.7 個月平均人力 ≈ 50.2 / 12.7 ≈ 4 人也就是說按這個屬性畫像大概需要 4 到 5 人左右的團隊干一年出頭。如果你心里先入為主覺得“20 千行三個月搞定”現(xiàn)在這個數(shù)字可以幫你冷靜一下。這不代表模型絕對正確但至少它把“20 千行需要多少成本”這件事從主觀感覺變成了可討論的公式推演。4.5 第五步結(jié)果解讀與敏感性分析我不建議直接把 50.2 人月當作最終答案。更實際的做法是對幾個不確定因子做敏感性分析比如把 ACAP 從 High 降到 Nominal工作量可能漲十幾個百分點把 CPLX 從 Nominal 提到 High整體要再多一成。把最優(yōu)、最可能的幾種組合都算一遍得到一個大致的區(qū)間比如 42 到 72 人月再結(jié)合需求和風險定最終基線。敏感性分析最大的作用是暴露“哪些信息不確定會怎樣影響結(jié)論”。如果某個因子稍微動一下結(jié)果就天差地別那說明當前最大的風險就在那兒應(yīng)該優(yōu)先去把信息補齊而不是糾結(jié)估算數(shù)字本身。我見過太多人拿著模型算出來的單點數(shù)字去跟老板匯報結(jié)果被一個不確定因子打得措手不及。5. 常見問題與排查技巧實錄這部分是我用過幾年之后攢下來的實戰(zhàn)心得踩過的坑都在這兒。模型本身不復(fù)雜真正復(fù)雜的永遠是輸入端的各種“人性陷阱”和“口徑陷阱”。5.1 算出來工作量“離譜”先查這三處第一處是規(guī)?？趶?。最常見的錯誤是拿整個倉庫的代碼量直接當 KSLOC把第三方依賴、自動生成代碼、測試代碼全算進去了。我見過有人把實際 8 KSLOC 的改動量算成 50 KSLOC結(jié)果估算翻了近十倍。第二處是 EM 連乘漏項或者把 EM 相加了。必須是連乘少乘一個 0.85 的因子整體就差 15%十幾個因子下來誤差能到兩三倍。第三處是單位問題有人把 20 KSLOC 填成 20000 KSLOC指數(shù)一拉數(shù)字直接崩壞。還有一個隱蔽坑指數(shù) E 忘了按規(guī)模因子算直接拿 1.0 以外的某個“印象值”硬填。E 每差 0.1在 50 KSLOC 規(guī)模上就是 15% 左右的誤差所以五個規(guī)模因子的評級也要認真對待不能默認取中間。5.2 評級全是“Nominal”等于沒評我見過最典型的偷懶是所有因子全選 Nominal。這樣做不是錯而是白白丟掉了模型最大的價值——把團隊對項目的共識變成量化參數(shù)。我的做法是每個因子至少寫一條客觀依據(jù)比如“接口文檔要求達到對外發(fā)布級別DOCU 評 High”“核心鏈路延遲要求 200 毫秒以內(nèi)TIME 必須考慮”。寫不出來就去查資料、去訪談而不是直接跳過。評級還有一個技巧把“和上一次項目相比”作為錨點。上次項目數(shù)據(jù)庫復(fù)雜度高這次差不多DATA 就參考上次的評級上次團隊凝聚力差導(dǎo)致返工多這次換了組織形式TEAM 就可以向上調(diào)一檔。有歷史參照物比憑空打分穩(wěn)得多。5.3 新人團隊、外包團隊、遠程團隊怎么擺參數(shù)如果團隊里一半是剛畢業(yè)的新人ACAP 和 PCAP 別客氣直接往 Low 甚至 Very Low 偏人員流動大PCON 往 Low 偏遠程多點協(xié)作、溝通鏈路長SITE 和 TEAM 都不會好看。這些參數(shù)調(diào)完之后工作量常常會讓人肉疼但這也是模型的誠實之處團隊現(xiàn)狀差成本就是高。與其把參數(shù)美化來討老板開心不如把真實成本擺出來推動團隊改善現(xiàn)狀。我實際遇到過項目因為把 ACAP 從 Low 調(diào)成 Nominal整體工作量被壓了兩成最后開發(fā)階段瘋狂返工成本全找補回來還倒貼。參數(shù)美化一時爽項目復(fù)盤火葬場這句話真不是段子。5.4 手算還是上工具我自己的習慣是拿電子表格搭一個模板把 KSLOC、SF、EM 放進去公式鏈自動算 PM 和 TDEV再配一個小的腳本做敏感性分析批量跑。市面上也有不少商業(yè)成本估算工具優(yōu)勢是內(nèi)置了完整的校準參數(shù)和歷史數(shù)據(jù)庫適合大規(guī)模組織統(tǒng)一口徑。但如果你只是中小團隊電子表格完全夠用關(guān)鍵是保證公式正確、參數(shù)可追溯。這里分享一個模板設(shè)計思路把五個規(guī)模因子和十七個成本驅(qū)動因子分別做成兩縱列一列填評級、一列填對應(yīng)數(shù)值然后用 PRODUCT 函數(shù)自動連乘 EM用公式引用 SF 合計去算 E。這樣每次改評級結(jié)果自動刷新做敏感性分析時就特別順手。6. 我實際用下來的幾點體會用了幾年 COCOMO II我最深的感受是它改變的不是估算方式而是團隊討論估算的方式。以前評審會里吵的是“我覺得要三個月”“我覺得一個月就行”現(xiàn)在吵的是“RELY 憑什么評 High”“CPLX 是不是低估了”。爭論聚焦在可驗證的參數(shù)上反而更容易達成共識也更容易暴露需求理解的盲區(qū)。這是我一開始完全沒想到的收獲。另外一個很實用的建議是拿歷史項目做回測。把自己做過的兩三個項目翻出來把規(guī)模和評級填進模型看看算出來的人月跟實際差多少。這個校準過程比任何理論都管用——你會發(fā)現(xiàn)自己的團隊到底偏快還是偏慢、哪些評級總是過于樂觀。把常數(shù) A 的 2.94 調(diào)成自己團隊的校準值之后模型才真正變成了“你的工具”而不是“別人的公式”。最后說個小技巧每次估算完把評級表和計算結(jié)果存成一份文檔項目結(jié)束之后回頭對賬。堅持幾個項目你就有了屬于自己的估算基準那時候你拍出來的“感覺”也會比大多數(shù)人準得多。這也是我把這些寫出來的原因——估算能力是攢出來的不是天上掉下來的。模型給你骨架歷次項目數(shù)據(jù)給你血肉兩者合起來才是一套真正能用的成本估算體系。