简介这份CMMI模型V2.0中文完整版PDF面向项目管理从业者、过程改进负责人及准备CMMI评估的团队系统呈现能力成熟度模型集成的最佳实践与实施路线。内容围绕过程域、目标与实践展开涵盖项目管理、工程、服务及供应商管理等视图并说明从初始级到优化级的成熟度进阶逻辑适合用作体系搭建、内训参考和评估前查漏补缺。资源包共1个PDF文件约19.27MB中文完整版便于直接检索与打印研读。目前已有4777人学习说明其在CMMI学习与项目管理实践中具有较高参考价值。读者可从中获得模型结构、实践域组织方式、高成熟度实现要点及持续改进框架理解如何将标准要求映射到组织流程并为过程规范编写、内部评审和CMMI导入提供可复用的知识底稿。1. 从一份 CMMI V2.0 中文完整版 PDF 开始别通读先建索引很多团队第一次接触 CMMI是在被要求做过程改进、或者准备内部评估的时候临时拿到一份几百页的 CMMI V2.0 中文完整版 PDF翻开目录就卡住了二十来个实践域、五个等级、开发/服务/供应商三套视图全挤在一份文档里。我见过有人从第一页开始逐字读读到第三章就放弃也见过有人直接把实践条目当文档模板硬给项目组加了三倍表格两个月后没人再打开。这份 PDF 的正确打开方式不是通读是当字典查——它是 CMMI 教程和 CMMI 文档规范的上游底稿项目管理里那些说不清的“该留什么证据”答案都在实践条目的措辞里。下面按我实际拆过的顺序写结构怎么切、实践怎么翻译成差距台账、怎么接进敏捷迭代、哪些坑会翻车。2. 拆开模型骨架实践域、等级和视图的三层索引表2.1 目录页就是最好的索引先抄一张实践域总表这份 PDF 的目录信息量极大它把每个实践域的中文名、英文全称、缩写、以及该实践域下按等级排列的条目页码全部列了出来。绝大多数人跳过目录直接翻正文结果在几百页里迷路。我的习惯是先花半小时把目录里能确认的实践域抄成一张表放在团队共享文档最上面后面所有讨论都用缩写指代沟通成本立刻降一半。从目录里能确认的实践域大致是这些缩写中文名日常最常被谁用到CAR原因分析和解决质量、复盘主持人CM配置管理配置管理员、研发CONT连续性运维、风险管理DAR决策分析和解决技术决策者、架构EST估算项目经理、技术负责人GOV治理管理层II实施基础条件管理层、PMOIRP事件处理和预防运维、服务台MPM管理性能与度量管理层、PMOMC监视与控制项目经理OT组织级培训技术管理、HRPR同行评审技术评审组织者PLAN策划项目经理PAD过程资产开发过程改进岗PCM过程管理过程改进岗、管理层PQA过程质量保证QAPI产品集成集成、构建RDM需求开发和管理产品、需求分析RSK风险与机会管理项目经理SDM服务交付管理服务交付负责人这张表的价值不在“全”而在“可检索”。后面任何人问“我们评审老走过场怎么办”你能三秒内定位到 PR 实践域而不是翻半小时目录。抄表的时候注意一点中文译名在不同版本里会有细微差异比如“估算”有的地方译成“估计”抄的时候以你手上这份 PDF 的目录用词为准别自己统一否则团队拿着两种叫法对不上号。表建完再补一列“当前状态”用三个值没有、有但不留痕、有且留痕。这一列是后面做差距分析的起点别省。2.2 视图与等级同一份 PDF 里为什么要分三套看法很多人以为 CMMI 是一套通用流程其实模型内部是按业务场景切视图的。这份文档的变更历史里写得很清楚2.1 版在 2.0 基线之上增加了服务和供应商管理视图的内容。也就是说同一份 PDF 里开发型团队、服务交付型团队、以及大量依赖外部供应商的团队各自该看的那部分实践是不一样的。开发视图关心的是从需求到交付的完整链路RDM、PI、PR 这些实践域的权重高服务视图关心的是服务级别、事件响应和连续性IRP、SDM、CONT 是主线供应商管理视图则把“外部依赖怎么管”单拎出来。实际做改进时先判断自己属于哪一类或者哪几类叠加再决定哪些实践域的条目要逐条对哪些只需扫一眼。等级这一层更容易被误解。实践域内部的条目是按能力等级标注的1 级是“这事得有人做”2 级是“这事得有管理动作、有跟踪”3 级是“这事得在组织层面标准化”4 级引入量化管理5 级是持续优化。而成熟度等级是把一组实践域打包后的整体判定两者不是一回事。血泪经验是不要拿“我们要过 L3”这句话直接去翻 L3 的条目。正确顺序是先确认 L2 对应的实践域集合你有没有真的跑起来因为 L2 那批实践域是地基很多团队 L3 条目背得滚瓜烂熟回头一看 CM 的基线从来没打过MC 的偏差跟踪全靠口头这种结构到了评估现场是撑不住的。具体哪个成熟度等级覆盖哪些实践域PDF 里有对应的覆盖表以那张表为准别凭印象。2.3 单个实践条目的四段式读法打开任意一个实践域比如 EST你会看到一套固定结构。我的读法是四段第一步读目的段。每个实践域开头都有一段简短的目的说明一两句话讲清楚这个实践域存在的理由。这段话是判断“我们做的动作是不是同一件事”的标尺跳过它直接看实践条目很容易把手段当目的。第二步读价值说明。这一段讲的是做好这个实践域能带来什么通常写成几条。它的实际用途是给你做内部动员时的说辞——你跟业务方讲“模型要求”没人理你你讲“估算不准导致排期反复返工”对方立刻坐下来听。第三步看实践组标题。实践域内的条目不是平铺的会分成几个实践组组标题本身就是一个动作短语。先把组标题连起来读一遍你就能得到这个实践域的骨架。以 EST 为例组标题连起来读大致就是“先建立估算的依据再形成并记录估算然后随着情况变化更新估算”这条线逻辑很顺。第四步才逐条读实践。读的时候做一件事把每条实践改写成一句以动词开头的中文主语写“我们”句子控制在二十字以内。比如原文那种“建立并维护估算依据”的表述改写成“我们把估算依据写下来并定期更新”。改写完的句子才是能贴到看板上的东西原文那种长句贴上去没人看得懂。提示实践条目后面常跟着“信息项”或示例工作产品那只是举例不是强制清单。把这部分当参考别当交付物目录否则一个实践域能给你变出十几份表格。3. 把实践条目翻译成差距台账以 EST 和 PLAN 两个实践域为例3.1 台账只留五个字段多一个都会烂尾把 PDF 转成能执行的东西中间那个载体就是差距台账。我试过七八个版本最后稳定下来的只有五列字段填什么常见错误实践编号直接用 PDF 里的编号如 EST 2.1自己重编后面全对不上我们现在的做法一句话描述真实动作写成“应该怎么做”自欺欺人证据能拿出来给人看的东西写“大家都知道”等于没证据差距动作一个可执行的动作写成“完善流程”这种空话责任人具体到人写到部门就没人认领第三列是整张表的生死线。所谓证据指的是任何一个局外人能在十分钟内验证的东西一份带时间戳的文件、一个系统里的记录、一次有纪要的会议。写“团队都清楚”这种答案评估现场一句追问就露馅。还有一条纪律台账不是一次填完的。我一般先花两天把 L2 那批实践域的条目全部过一遍只填前三列差距动作和责任人在第二轮评审时补。一次性填满的台账八成是闭门造车编出来的。3.2 用脚本把 PDF 拆成可检索的条目清单几百页的 PDF靠人工翻页抄条目太低效。常见做法是先把 PDF 转成文本再按实践域缩写切分生成一份待核对的清单。我一般用下面这个脚本跑完得到一份 CSV后面在表格里逐行填台账。from pypdf import PdfReader import re import csv # 参数说明 # SRC 是这份中文完整版 PDF 的路径放在脚本同目录下最省事 # OUT 是输出清单文件名建议每次跑用日期区分方便回溯 SRC CMMI模型V2.0_中文完整版.pdf OUT cmmi_pa_index.csv # 目录里能确认的实践域缩写遇到没收录的自行往字典里加 PA { CAR: 原因分析和解决, CM: 配置管理, CONT: 连续性, DAR: 决策分析和解决, EST: 估算, GOV: 治理, II: 实施基础条件, IRP: 事件处理和预防, MPM: 管理性能与度量, MC: 监视与控制, OT: 组织级培训, PR: 同行评审, PLAN: 策划, PAD: 过程资产开发, PCM: 过程管理, PQA: 过程质量保证, PI: 产品集成, RDM: 需求开发和管理, RSK: 风险与机会管理, SDM: 服务交付管理, } reader PdfReader(SRC) # extract_text 对扫描版 PDF 会返回空遇到空页直接跳过不算异常 pages [p.extract_text() or for p in reader.pages] full_text \n.join(pages) # 按“缩写 空格 中文名”这种标题行做切分锚点 # 锚点不追求百分之百准目的是给出粗略位置后面人工核对 pattern re.compile( r(%s)\s*[(]?\s*[\u4e00-\u9fa5、]{2,20} % |.join(PA.keys()) ) rows [] for match in pattern.finditer(full_text): abbr match.group(1) # 锚点前后各截 200 字足够人工判断这条是不是真的章节标题 snippet full_text[match.start():match.start() 200].replace(\n, ) rows.append({ 缩写: abbr, 中文名: PA.get(abbr, ), 上下文片段: snippet, 字符位置: match.start(), }) # 同一缩写会命中多次按字符位置排序后人工剔除误命中 rows.sort(keylambda r: r[字符位置]) with open(OUT, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[缩写, 中文名, 上下文片段, 字符位置]) writer.writeheader() writer.writerows(rows) print(f共命中 {len(rows)} 条输出到 {OUT})几个参数上的讲究。encodingutf-8-sig是为了让表格软件打开 CSV 时中文不乱码少了这个参数你会看到一堆问号。锚点正则里限制中文名长度 2 到 20 字是为了减少把正文里随口提到的缩写也命中进来。字符位置这一列不是给机器用的是给你的——按位置排序后误命中会集中堆在正文段落附近一眼就能剔掉。至于为什么用 pypdf理由很实际它纯 Python、不用装外部程序、对中文文本层支持够用。如果这份 PDF 是扫描件、抽不出文本层那就别折腾脚本了老老实实按目录页码人工翻或者先用 OCR 工具过一遍再跑。翻车最多的情况就是拿扫描件跑脚本跑了十分钟得到一堆空字符串还以为脚本写错了。清单跑出来只是半成品必须人工过一遍。我的做法是把 CSV 导进表格加一列“是否章节标题”人工打勾勾完再按缩比分表每个实践域一张子表后面填台账就在子表里填。3.3 EST 和 PLAN 的拆解示范从条目到动作拿 EST 走一遍完整流程你就知道这套方法怎么落地。打开 EST 章节先读目的段你会明白这个实践域解决的是“排期凭感觉”的问题。再看实践组骨架大致是建立估算的依据、形成估算、随着信息变化更新估算。然后逐条读改写成动词开头的短句填进台账前三列。举个例子如果某条实践讲的是“记录估算的依据和假设”那台账里就这么写现状列填“我们估算靠技术负责人拍脑袋依据在聊天记录里”证据列填“上三个项目的估算邮件实际值与估算值没有对比表”差距动作列填“建一张估算依据表每个迭代填一行”责任人写具体的人名。PLAN 的拆解同理但有个额外注意点PLAN 和 EST 的条目会互相引用比如策划里会提到“依据估算结果制定计划”。做台账时不要在两个实践域里重复建设同一个动作否则你会得到两份表格、两个责任人、两套说法。我的处理办法是在 PLAN 的台账里写“见 EST 台账第 X 行”用引用代替复制减少维护量。做完这两个实践域你会得到一个很朴素的结论所谓过程改进八成的工作量是把“已经做了但没留下东西”的动作补上记录而不是新增动作。这个认知能帮你挡掉大量形式主义需求。3.4 L2 起步阶段的最小实践域集合很多团队的问题不是不会做是想一次做完。二十个实践域同时铺开三个月后全线烂尾。我的建议是先圈一个最小集合跑通一轮再加。起步集合的判断标准很实用挑那些“缺了它其他实践域根本没法做”的。按这个标准CM、PLAN、EST、MC、RDM 这五个基本构成闭环——需求进来估算排期计划落地执行跟踪配置管住版本。RSK 和 PQA 可以作为第二批因为它们依附于前五个才有内容。GOV 和 II 这两块偏管理层通常要等前面有了实际数据管理层才愿意坐下来谈。圈定集合后把 PDF 里这些实践域对应等级的条目全部抄进台账其他实践域先不看。忍住。看到后面章节觉得“这个我们也该做”的时候记到待办清单里别当场加进本期范围。这个自制力决定了项目能不能收尾。4. 接进敏捷迭代CMMI 2.0 实践域与日常仪式的映射方法4.1 仪式不改改的是每个仪式的产出物最常见的对抗思路是“上了 CMMI 就要加文档加了文档敏捷就死了”。实际情况恰恰相反这份模型里的很多实践条目描述的正是敏捷团队已经在做的事只是没留痕、没形成稳定节奏。我一般用一张映射表把两套语言对齐让团队意识到不是新增仪式是给现有仪式补产出现有迭代活动对应的实践域该活动应留下的东西迭代计划会PLAN、EST、RSK迭代目标、估算依据、风险条目每日站会MC进度偏差、阻塞项、需要升级的问题迭代评审RDM、PI需求覆盖确认、集成结果迭代回顾CAR根因分析结论、改进项及责任人版本发布CM基线标识、发布内容清单需求澄清RDM需求变更记录、影响分析这张表贴出去以后团队的抵触会明显下降因为它证明了大部分动作是现成的只是产出物散落在聊天记录和口头约定里。补的动作是把产出物收拢到一个固定位置而不是新建一套流程。有个细节值得说映射表的每一行都要指定“落在哪个工具里”。写“记录在文档中”等于没指定两周后一定找不到。写“记录在迭代看板的固定字段里”才是可执行的。工具选型不重要重要的是唯一入口。4.2 MPM 给出的不是 KPI 清单是度量体系怎么搭很多人翻到 MPM 就想找“该定哪几个指标”翻完失望因为里面没有现成指标表。它讲的是度量这件事本身的结构度量要服务于业务目标从目标往下拆到过程再从过程拆到项目级的数据。按这个结构我的做法是先问三个问题再决定采什么数。第一个问题这个季度业务上最想改善的一件事是什么比如交付周期太长。第二个问题哪个过程环节最影响这件事比如需求变更频繁导致返工。第三个问题这个环节现在有没有数据没有的话最小可采集的字段是什么。三个问题答完度量项自然就出来了而且每个都能追溯到业务目标。反过来先定一堆指标再找用途最后一定变成填表比赛数据没人看采集的人怨声载道。这是我在几个团队里反复见到的翻车路径。还有一条度量项的个数要克制。一个十人左右的团队同时跟踪的度量项超过五个基本就没人认真看了。宁可少两个也要保证每个都有人定期解读。4.3 文档瘦身哪些必须留痕哪些可以合并中文完整版 PDF 里实践条目下面常跟着一串示例工作产品容易让人误以为每个都要产出一份独立文档。实际做的时候要分两类处理。必须独立留痕的是那些事后无法重建的信息基线标识、评审结论、估算依据与假设、变更记录、根因分析结论。这些东西的特点是当时不记一周后就只能靠回忆回忆出来的东西经不起追问。可以合并的是过程性记录会议纪要、进度更新、任务分配。这些完全可以收进迭代看板或周报的一个字段里不必另起文档。合并的判断标准也很简单如果这条信息在别的记录里已经能推导出来就不要单独建。我踩过的一个坑是给每个实践条目配一份模板最后整理出四十多份表格团队直接罢工。后来砍到八份反而执行得住了。所谓 CMMI 文档规范重点在“证据能对上”不在“文档数量够多”。5. 避坑拿这份 PDF 做过程改进时最容易翻车的五件事5.1 把实践条目当文档模板一条配一份表现象改进启动两周产出四十多份模板项目组开始消极抵抗两周后模板全部躺平。原因把“实践”理解成“交付物”。实践描述的是一个能力状态达到这个状态可能有十种做法出一份文档只是其中最重的一种。照抄条目字面意思去设计表单等于用最贵的方式满足要求。解决每条实践先问“用现有哪个产出物能证明”能证明就不新建。实在没有的优先考虑在看板字段、提交记录、自动化流水线日志里补而不是新建文档。台账里加一列“证据载体”写清楚落在哪个系统这一列能挡掉八成的无效文档。5.2 跳过 L2 直接冲高等级现象团队把主要精力放在组织级标准化的条目上结果项目层面的基础动作全是空的内部预评估时被逐条追问返工两个月。原因高等级的条目读起来更“高级”也更容易写成一页纸的漂亮方案低等级的条目琐碎、涉及具体执行做起来累。人性会往轻松的方向走。解决先做一次 L2 覆盖的实践域自检确认每个实践域都有可验证的证据再往上走。自检不通过就别急着谈更高等级。这条没有捷径地基不牢上面盖什么都会塌。5.3 评估前突击补证据现象预评估前一个月全组加班补记录文件日期集中在同一周访谈时说法对不上反而暴露了问题。原因把过程改进当成一次性验收。补出来的证据在时间维度上是断裂的任何有经验的评审者看一眼文件创建时间和修改记录就能判断。解决证据是过程的副产品不是可以后补的材料。真到了时间紧张的时候宁可缩小范围、只做实打实跑过的几个实践域也不要把没做的写成做了。少而真远好过多而假。5.4 把示例工作产品当成强制清单现象团队为了凑齐某项实践下面列出的所有示例产出物额外做了三份没人看的分析报告占用了两周工时。原因没注意区分模型里的规范性内容和信息性内容。实践条目本身是“要达成什么”后面跟的示例只是“可以参考长什么样”。解决读条目时先看这段话是不是以“示例”“例如”开头是的话直接跳过。判断某个产出物要不要做用 5.3 里那个标准——事后能不能重建。不能重建的才值得单独立文档。5.5 中英文术语混用内部沟通各说各话现象会上有人说“配置管理”有人说 CM有人说“版本控制”讨论半小时才发现说的是三件事写台账时同一实践域出现两种译名检索不到。原因这份 PDF 是中文版但缩写、英文全称、中文译名同时在用团队没有统一约定。解决在实践域总表旁边加一列“统一叫法”约定内部一律用缩写加中文名的形式比如“CM 配置管理”第一次出现写全后面统一用缩写。台账、看板、周报全部沿用同一套叫法。这个动作花不了半小时能省掉后面无数次会议上的对齐。6. 评估前自检一周跑完一次轻量差距分析的四个动作真到了要检验成果的时候不必等外部评估自己先跑一轮轻量自检成本低、信息量大。我一般按四个动作走一周内能出结论。第一个动作是抽样不要全查。从每个实践域挑两到三条最核心的条目覆盖到台账里标记为“有但不留痕”的那些这些是风险最高的位置。第二个动作是倒查随机挑一个最近交付的版本从代码提交记录倒推到需求条目看这条链路每一环的证据是否都在、时间戳是否连续。第三个动作是访谈找两位没参与台账填写的一线同学问三个问题你这个迭代的估算依据是什么、变更走哪里、评审结论记在哪。答不上来的地方就是缺口。第四个动作是对表把抽样和访谈的发现填回台账只更新“证据”和“差距动作”两列别改其他字段避免台账越改越乱。自检结果用一张简单的表收口就够了实践域抽查条目数证据齐全数缺口描述补齐所需动作CM32基线标识只在发布邮件里在构建流水线里打标签MC31偏差跟踪靠口头看板加偏差字段并每周复盘EST22无无这张表比几十页的自评报告有用得多因为它每一行都指向一个具体动作。最后说个习惯。早些年我也觉得自检是走过场直到有一次预评估前一周做倒查发现某个版本的集成记录和发布记录对不上追下去是流水线配置漂移导致的那批产物的来源根本说不清。从那以后我每次启动改进项目第一周必做一次倒查不管有没有人要求把它当成后悔药提前吃掉。希望帮到你。本文还有配套的精品资源点击获取