1988 - CMM 能力成熟度模型：流程決定結果#
案件摘要#
1988 年，Watts Humphrey 在卡內基美隆大學軟體工程研究所（SEI）發表《Characterizing the Software Process》， 提出軟體成熟度五級模型，隨後成為 CMM（Capability Maturity Model）。 這是一樁國防部出資的辦案：找出一套方法，在簽約之前就判斷承包商做不做得好。 核心線索只有一句話——在混亂的流程下，結果全靠個人英雄；唯有流程可重複，成果才可預測。 CMM 把「軟體品質」從玄學變成階梯：一級一級往上爬，每級削掉一塊不可預測性。
前因 -- 為什麼會有這個案子#
- 國防部的爛帳：1980 年代美國國防部（DoD）軟體專案普遍超支、延期、品質失控，但採購時只能看履歷與報價，無從判斷哪家承包商「有能力把軟體做對」。
- SEI 成立（1984）：國防部委託 CMU 設立軟體工程研究所，Humphrey（前 IBM 高層，OS/360 的老戰友）被點名主持流程計畫。
- 品管界的先例：Deming、Juran 在製造業的統計品管（SPC）早已證明——過程決定結果，把製程管好，良率自然高。這套思想能否搬到軟體？
- 關鍵推理：製造業的品質靠機器一致，軟體的品質靠「人＋流程」一致。Humphrey 的推理是：與其事後驗收抓蟲，不如事先評估承包商的流程成熟度——成熟度高的組織，專案時程與成本的估計偏差小、缺點密度低。評估的依據是一條階梯：
\[ \text{可預測性} \propto \text{流程紀律}:\quad 1\,\text{級} \to 2\,\text{級可重複} \to 3\,\text{級標準化} \to 4\,\text{級可量化} \to 5\,\text{級持續改進} \]
- 評估方法：SEI 以成熟度問卷（Maturity Questionnaire）＋現場訪談打分，問卷只答「是/否」，涵蓋需求管理、專案計畫、品保、組態管理等關鍵流程領域——答不上來的，就是流程不存在的證據。
1987–88 年 SEI 先以問卷試測，1988 年正式提出五級框架，1991 年 CMM 1.0 問世。
線索與推理 -- 數學式、程式、理論#
1. 案件現場：五級成熟度#
| 級別 | 名稱 | 特徵 | 典型症狀 |
|---|---|---|---|
| 1 | Initial（初始） | 混亂、靠英雄 | 成敗全看個人，同公司兩案天差地遠 |
| 2 | Repeatable（可重複） | 基本專案管理 | 需求、計畫、組態、品保成文，成功經驗可複製 |
| 3 | Defined（已定義） | 全組織標準流程 | 有標準程序、培訓、同儕審查 |
| 4 | Managed（已管理） | 量化管理 | 收集度量，用統計手法控制品質與產能 |
| 5 | Optimizing（最優化） | 持續改進 | 缺點預防、流程創新、持續收斂 |
關鍵在 2 級：只有當一個組織能把上一次的成功經驗「重複」到下一個專案，它才第一次脫離混亂。1 級組織的成功是擲骰子，2 級組織的成功是紀律。
各級的關鍵流程領域（KPA，CMM 1.0 的正式結構）：
| 級別 | 關鍵流程領域（KPA） |
|---|---|
| 2 | 需求管理、軟體專案計畫、追蹤與監督、分包管理、品質保證、組態管理 |
| 3 | 組織流程焦點、組織流程定義、培訓、整合式軟體管理、產品工程、組間協調、同儕審查 |
| 4 | 量化流程管理、軟體品質管理 |
| 5 | 缺點預防、技術變更管理、流程變更管理 |
每一級 KPA 共通的是「政策 → 程序 → 驗證」三件套：組織要有成文政策（承諾）、執行程序（能力）、以及確認程序真的被執行的稽核（度量）——KPA 不是清單，而是流程存在的證據鏈。
2. 數學線索：從英雄到紀律的方差分解#
1 級組織的專案結果可建模為「個人表現 + 隨機噪音」： \(T = \mu + \epsilon\) ，其中 \(\epsilon\) 的方差 \(\sigma^2\) 巨大（成敗全看抽到哪個英雄）。每升一級，就是從分佈裡削掉一塊方差：
\[ \text{2 級：削掉「專案管理」的方差} \quad\to\quad \text{3 級：削掉「流程不一致」的方差} \quad\to\quad \text{4 級：用度量控制剩餘方差} \]
3. 數學線索：成熟度與可預測性#
Humphrey 的核心主張可以寫成估算偏差的分佈：成熟度等級 \(L\) 越高，實際工期 \(T\) 對估算 \(\hat{T}\) 的相對偏差分佈越集中：
\[ \sigma_L < \sigma_{L-1},\qquad \text{偏差} = \frac{|T - \hat{T}|}{\hat{T}} \]
實證線索（SEI 與後續研究一致指出）：低成熟度組織的估算偏差常達 100% 以上且方向隨機；高成熟度組織偏差收斂到兩成以內。另有一條品質相關：缺點密度（defects/KLOC）與成熟度等級呈負相關——流程紀律越好，殘留缺點越少。
4. 第 4 級：量化管理與控制圖#
第 4 級的精神直接繼承 Deming 的統計製程管制（SPC）：對流程指標（生產力、缺點率）畫控制圖，
\[ \text{UCL} = \bar{x} + 3\sigma,\qquad \text{LCL} = \bar{x} - 3\sigma \]
- 指標落在控制線內 → 流程穩定（in statistical control），結果可預測。
- 指標越線或連續同側漂移 → 流程失控，先找特殊原因（special cause）再談改進。
- 這把「軟體專案做不完」從玄學變成統計學：你無法預測不穩定的流程，也無法改進沒有度量的流程。
5. 第 5 級與 CMMI（2000s）#
- 第 5 級：不只控制，還主動預防缺點（defect prevention）與改進流程本身——每個專案結束都要問「下次哪裡可以更好」，並把答案制度化。
- CMMI（2000 年代）：SEI 把軟體 CMM、系統工程 CMM、整合產品開發 CMM 等多套模型整合為 CMMI（Capability Maturity Model Integration），2002 年 CMMI 1.1 上市，分階段式（staged）與連續式（continuous）兩種表述。2010 年代的 CMMI 2.0 持續簡化，至今仍是大型組織與國防供應鏈的評估標準。
- SPICE（ISO 15504）：國際標準組織參考 CMM 制定的流程評估標準（後演进為 ISO/IEC 33001 系列），把 CMM 思想推向國際。
6. Agile 派的批評：官僚化 versus 紀律#
- 批評聲浪（2000 年代 Agile 陣營）：CMM 評審鼓勵「寫文件給評審看」，組織為過等級而過等級，產生大量不產生價值的流程文書。
- 高成熟度不等於敏捷：5 級組織也可能慢得要死——成熟度衡量的是可預測，不是快速。
- 反向對話（Humphrey 與後繼者）：紀律與敏捷不對立——TDD、CI、回顧會議其實就是 2 級的「可重複」與 5 級的「持續改進」用敏捷語言重寫一遍。兩派後來在 CMMI 2.0 與 Agile Scale-up 等框架中握手。
7. Python 實作：專案估算偏差模擬#
import random
def simulate_estimates(level, n=10000):
"""模擬不同成熟度等級的專案估算偏差分佈。
低級：偏差大且隨機；高級：偏差小且集中。"""
if level == 1: mean, sigma = 0.10, 1.00
elif level == 2: mean, sigma = 0.05, 0.50
elif level == 3: mean, sigma = 0.00, 0.30
elif level == 4: mean, sigma = 0.00, 0.20
else: mean, sigma = 0.00, 0.15
devs = [abs(random.gauss(mean, sigma)) for _ in range(n)]
over = sum(1 for _ in range(n) if random.gauss(mean, sigma) > 0) / n
return sum(devs) / n, max(devs), over
random.seed(1988)
print(f"{'級':>2} {'平均偏差':>8} {'最大偏差':>8} {'超支機率':>8}")
for lvl in range(1, 6):
avg, worst, over = simulate_estimates(lvl)
print(f"{lvl:>2} {avg:>7.0%} {worst:>7.0%} {over:>7.0%}")
# 級 平均偏差 最大偏差 超支機率
# 1 79% 411% 54% ← 1 級：平均偏差八成，近半數超支
# 2 40% 198% 54% ← 2 級：成功可重複，但仍有暴衝
# 3 24% 124% 51%
# 4 16% 80% 50% ← 4 級：控制圖把偏差壓進 3σ
# 5 12% 56% 49% ← 5 級：持續改進持續收斂
結案 -- 後果與影響#
結案要點#
- 政府採購的能力評估標準：美國國防部及後續各國政府把 CMM/CMMI 等級寫進標案門檻，承包商為接單而投入流程改善。
- 流程工程學科的誕生：軟體流程改善（SPI）自成學科，評審師、諮詢業、培訓產業鏈成形。
- CMMI 至今仍用於大型組織：國防、汽車、金融等高可靠產業的供應鏈評估仍以 CMMI 為基準，CMMI 2.0（2018）持續演进。
- Agile 與 CMM 的對話：從互斥到互補——敏捷提供了「快速回饋」的實務，CMM 提供「可預測性」的度量骨架；Scrum 的回顧會議本質上就是 5 級的持續改進。
- 度量文化的深遠影響：「無法度量就無法管理」（You can't manage what you can't measure）成為軟體管理圈的通用格言，也引出後續 Goodhart 定律式的反思。
- 對個人式方法的反證：CMM 證明「流程資產」獨立於個人存在——英雄離職後，高成熟度組織仍能交付；這也為後來的知識管理與 DevOps 平台化鋪路。
案件年表#
| 年份 | 事件 |
|---|---|
| 1984 | SEI 成立，國防部委託軟體流程研究 |
| 1987 | SEI 成熟度問卷試測，五級框架成形 |
| 1988 | "Characterizing the Software Process" 發表 |
| 1989 | 《Managing the Software Process》出版 |
| 1991 | CMM 1.0 正式問世 |
| 2002 | CMMI 1.1 整合多套模型上市 |
| 2018 | CMMI 2.0 簡化框架，與敏捷對話 |
關鍵人物與文獻#
- Watts Humphrey（前 IBM 高層、SEI 流程計畫主持人）：CMM 之父；《Managing the Software Process》(Addison-Wesley, 1989)、"Characterizing the Software Process" (IEEE Software, 1988)。
- W. Edwards Deming：《Out of the Crisis》, 1986——統計品管思想，CMM 第 4 級的理論源頭。
- Mark Paulk 等（SEI）："Capability Maturity Model for Software, Version 1.1" (IEEE Software, 1993)——CMM 1.0 的正式文件。
- SEI, Capability Maturity Model Integration (CMMI), Version 1.1, 2002；CMMI Institute, CMMI 2.0, 2018。
- ISO/IEC 15504（SPICE）與 ISO/IEC 33001 系列：流程評估的國際標準。