🎯 什麼情境該想到我
當你發現「以前這樣做都好好的，怎麼這次專案一變大就整個垮掉」——工作量、錯誤、開會時間全都比你想的多很多，而且多的比例還各不相同的時候。
核心觀念：規模不是線性放大的。程式長度變 10 倍，工作量、建構、整合測試、錯誤各自以完全不同的倍率成長，所以小專案的做法直接搬到大專案會失敗。
「雖然最終軟體的大小是所預期的 10 倍，並不意味著也需花費 10 倍的工作量，而可能是 20 倍的工作量。而且，20 倍的工作量並不意味著 20 倍的建構，也可能是 12 倍的建構和 40 倍的系統整合和測試。你也將可能獲得不僅是 10 倍的錯誤，而是 15 倍的錯誤。」（p.351）
⚙️ 怎麼用
第 0 步：先定位你在哪一格
書給了兩張分布表。先確認你的專案「典型不典型」，再決定要不要沿用直覺。
用人數定位（p.351）
| 專案組人數 | 專案所占百分比 |
|---|---|
| 1～3 | 50％ |
| 4～8 | 33％ |
| 8～12 | 6％ |
| 12～20 | 5％ |
| 20～50 | 3％ |
| 50＋ | 2％ |
用程式長度定位（p.352）——「大的專案往往使用更多的程式設計師」
| 程式長度（以程式碼長度計算） | 程式設計師所占百分比 |
|---|---|
| 2k | 5～10％ |
| 2k～16k | 5～10％ |
| 16k～64k | 10～20％ |
| 64k～512k | 30～40％ |
| 512k＋ | 30～40％ |
判準：一半的專案是 1–3 人。如果你的經驗都來自這一格，你對「大專案」的所有直覺都要重新校正。
第 1 步：查倍率——別用同一個係數放大所有活動
| 規模變化 | 建構 | 系統整合與測試 | 計劃 | 錯誤 | 總工作量 |
|---|---|---|---|---|---|
| 大 2 倍（p.353） | 2 : 1 | 4 : 1 | — | 多於 2 倍（p.356） | — |
| 大 10 倍（p.351） | 12 倍 | 40 倍 | — | 15 倍 | 可能 20 倍 |
| 大 10 倍（p.353） | 12 倍 | 40 倍（整合測試量） | 100 倍 | — | — |
「建構之所以隨著專案的增大而變弱，是因為建構的各種活動——詳細設計、除錯、編碼單元測試——是線性增長，而其它各種活動則是按乘冪的關係增長的。」（p.353）
會隨專案增大而工作量增大的其它活動（p.353–354）：計劃、管理、交流、需求開發、系統功能設計、介面設計和描述、總體結構、整合、錯誤消除、系統測試、文件生成。
判準：你的估算是不是只算了建構？ 如果是，你就漏掉了成長最快的那一整排。
第 2 步：查建構佔比——決定你的估算會偏掉多少
| 專案規模 | 建構佔開發活動時間 | 原文（p.353） |
|---|---|---|
| 小專案 | 80％ | 「建構是最為突出的活動」 |
| 中專案 | — | 「建構仍然是主導性的活動，但是所佔比例下降了 50％」 |
| 很大的專案 | — | 「結構、整合、系統測試和建構所占時間比例大致相等」 |
對應的估算誤差（p.356），這是最可據以決策的一組數字：
| 你的做法 | 結果 |
|---|---|
| 用自己寫 2K 行的經驗估一個 2K 行的程式 | 所估時間僅為實際所需時間的 80％ |
| 沒有考慮各種非建構活動所費時間 | 實際所花時間比估計的多 25％ |
| 用自己 2K 的建構經驗評估 32K 程式 | 所估時間僅為實際需要的 50％ |
| 用過去的編程經驗評估「建構一個系統產品」 | 可能低估近 10 倍 |
| 不理解產品其它工作的重要性 | 估計錯誤數可增加 3 倍或更多 |
第 3 步：查「你做的到底是什麼東西」——不是只有行數在決定規模
「並不只是程式碼行數和參加人數對專案的大小有影響。一個更微妙的影響是軟體的品質和複雜性。」（p.356）
| 產物型態 | 定義（p.356） | 代價 |
|---|---|---|
| 程式 | 由使用者自行開發的單一程式 | 1 倍 |
| 產品 | 為了讓其它人而不僅是使用者自己使用；交付前深入除錯、被文檔化、可能被其它人維護 | 程式開發代價的 3 倍 |
| 系統 | 要求一群程式設計師相互協作開發；需開發各不同部分之間的介面以便有機整合 | 單一程式的 3 倍 |
| 系統產品 | 加裝產品外殼（使用者介面），並將系統各部分整合起來 | 單一程式的 9 倍 |
判準：你答應的是「一個程式」還是「一個系統產品」？ 兩者差 9 倍，而這是「導致估計錯誤最為常見的原因」（p.356）。
第 4 步：查該用多少正規性——規模決定形式化程度
書用「專案正規性明細表」（表 21-1，p.354–355）：對 12 個因素各評 1–5 分，總分落在 12–60 之間。
12 個因素：初始要求、通用性、操作跨度、範圍和對象的修改、設備複雜性、人事安排、開發代價、關鍵性、對程式修改的平均反應時間、對資料輸入的平均反應時間、程式語言、軟體開發中的合作性。
其中兩個因素直接錨定規模：
| 評分 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| 人事安排 | 1－2 | 3－5 | 5－10 | 10－18 | 18 以上 |
| 開發代價 | 3－15k | 15－70k | 70－200k | 200－500k | 大於 500k |
「得 12 分意味著對專案的要求是輕微的，且對其正規性要求很少。得 60 分意味著專案要求很高，且對結構的規定也很多。……在軟體開發中，專案越正規，你就越需付出更多的工作量。」（p.355）
文件建議（表 21-2，p.355）——查到分數就查到該產出的文件層級：
| 正規評分 | 建議文件 |
|---|---|
| 12－15 | 使用者指南和小程式文件 |
| 15－26 | 低級文件以及操作使用手冊、維修手冊、測試計劃、管理計劃、結構配置計劃 |
| 24－38 | 低級文件加功能描述、品質確保計劃 |
| 36－50 | 低級文件以及系統和子系統描述、測試分析報表 |
| 48－60 | 低級文件以及程式描述 |
（區間重疊為原書表格所載，照錄。）
寫文件的理由不是為了那份文件本身：
「你編寫配置管理計劃並不是為了運行有關程式，而只是強迫自己能向其它人解釋。……如果你自己感到要編寫一般的文件，這就有點不對頭了。」（p.355）
第 5 步：算溝通成本——這是規模稅裡最容易被忽略的一項
「如果只有你一人開發專案，對專案成功或失敗影響最大的正是你自己。如果你所在專案開發組有 25 人，你也可能仍發揮最大作用，但更可能是大家各有一份功勞，整個集體對專案的成功或失敗有更大的影響。」（p.352）
交流途徑的成長（p.352）：
| 程式設計師人數 | 交流途徑 |
|---|---|
| 2 | 1 |
| 3 | 3 |
| 4 | 6 |
| 5 | 10 |
| 10 | 45 |
| 50＋ | 至少 1200 |
「交流途徑越多，你放在交流上的時間越多，也就越容易出現錯誤。大的專案要求採用一定的方法以簡化交流方法，以對其作一定程度的限制。」（p.352）
對策（p.353）：規範化交流方法——「不是讓 50 個人按各種可能方式相互間進行交流，而是讓 50 個人都閱讀和編寫文件，有些是文字的，而有些則是圖形的，有些是列印在紙上的，或是表格形式的。」
方法（method）的使用也隨規模改變（p.354）：「對小系統，方法往往是偶然的和本能的。對大專案，方法往往是精確和仔細計劃的。」
不論專案大小都有價值的做法（p.354）：結構化編碼、其它程式設計師對邏輯和程式碼的檢查、聯機開發系統、高階語言的使用。
第 6 步：預期錯誤密度與生產率會往哪邊掉
錯誤來源的組成隨規模變（p.356）
| 專案規模 | 建構錯誤佔整個錯誤 |
|---|---|
| 一些小專案 | 75％（「方法對程式碼品質影響不大，對程式品質影響最大的是個人編寫程式的技巧」） |
| 大專案 | 50％（「較大專案需要更多的分析和設計，所以此類活動中發生錯誤的機會相應也大一些」） |
| 一些很大的專案（500,000 行） | 75％以上 |
錯誤密度（表 21-3，p.357，出自 Jones 1977）
| 專案大小（程式碼行數） | 每 1000 行程式碼所發生錯誤數 |
|---|---|
| 小於 2k | 0－25 |
| 2k－16k | 0－40 |
| 16k－64k | 0.5－50 |
| 64k－512k | 2－70 |
| 512k 或更多 ※ | 4－100 |
※ 原書此列印作「52k 或更多」，依相鄰級距推斷應為 512k。
結論（p.357）：「大專案出現錯誤數是小專案的 4 倍多」；「對超過一定大小的專案，不能編寫出沒有錯誤的程式碼，錯誤總可以潛入，而不管採用什麼方法預防錯誤。」
生產率（表 21-4，p.358，出自 Jones 1977）
| 專案大小（程式碼行數） | 每月程式碼行數 |
|---|---|
| 小於 2k | 333－2000 |
| 2k－16k | 200－1250 |
| 16k－64k | 125－1000 |
| 64k－512k | 67－500 |
| 512k 或更多 | 36－250 |
結論（p.358）：「最小專案的生產率是最大專案的 10 倍。即使從某一中等專案轉移到另一中等專案——如從千行程式碼的專案轉到 9 千行程式碼的專案——生產率也可降低一半。」
另外（p.357）：對於小專案（200 行或更小），對生產率影響最大的是單個程式設計師的技巧；隨著專案增大，開發組人數和組織對生產率影響迅速增大。Boehm 和 Gray 曾說過，較少人數的開發組的效率比人數較多的高 39％。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 不要把不同段落的倍率混用。 p.351 是「軟體最終長度是預期的 10 倍」這個情境（工作量 20 倍／建構 12 倍／系統整合與測試 40 倍／錯誤 15 倍）；p.353 是「一個專案是另一個的 10 倍大」這個比較（建構 12 倍／計劃 100 倍／整合測試 40 倍）。前者談的是同一專案膨脹，後者談的是兩個專案相比。
- 表 21-3、21-4 的數字有它的前提。 書自己就說了：「以上數據只是來自一些特定專案，你實際所出現的錯誤數可能和以上數據略有出入」（p.357）；生產率「實際上是由人員的素質、程式語言、方法、產品複雜性、編程環境、工具支持和其它許多因素所決定的，所以可能表 21-4 的數據並不能直接用於你的編程環境，你可視具體情況而定」（p.357）。當方向感用，不要當承諾。
- 反向也成立：大專案的做法搬到小專案同樣是錯的。 「如果你已習慣開發中等專案，你可以利用你的經驗進行一次小專案開發」（p.351）——正規性要跟著往下調，不是往上抄。「正規的方法並不令人高興。如果誤用了，往往會引起麻煩」（p.354）。
- 表 21-1、21-2 的正規性尺度帶有軍方採購色彩（因素含「操作跨度：廣泛地適用於各軍事部門」、「關鍵性：國家防務」），書明講軍方是最大用戶與最大研究贊助者之一（p.354）。當作一種「規模→形式化」的量表使用，別逐項照搬。
- 本書為 1993 年第一版，度量單位以程式碼行數為主。
🔗 相關工具
- 工具-建構的先決條件——同書。規模越大，先決條件（需求、架構）沒做好的代價越高；本卡的「分析和結構錯誤在大專案佔比上升」（p.356）正是那張卡的成本論證。
- 工具-估算的藝術——互補。那張卡講「怎麼估」（三點估算、範圍與信心度、估算 ≠ 承諾）；這張卡講「估之前要先知道自己在哪一格」，特別是 p.356 那組系統性低估係數（80％／50％／低估近 10 倍）——先用本卡校正基準，再用那張卡包裝成可溝通的區間。
- 回連 程式碼大全
📌 本章小結（p.358 原文四點）
- 在一些小專案中的活動並不能想當然地用於大專案中，你應仔細計劃它們。隨著專案增大，建構作用減弱。
- 隨著專案的增大，交流方法應簡化。各種方法的使用應因時而異。
- 在相同條件下，大專案的生產率比小專案低一些。
- 在相同條件下，大專案的每行錯誤數比小專案的每行錯誤數多。