简介这是一份聚焦CMMI 3.0的软件工程规范文档面向软件过程改进人员、项目经理、质量保证工程师及研发管理者用于理解并落地CMMI模型。文档系统梳理了五个成熟度等级——初始级、已管理级、已定义级、定量管理级、优化级——的各自目标与实践要求同时整理了CMMI 2.0到3.0的重大变化包括以商业目标驱动改进、通过性能数据衡量效果、强化高层经理参与、强调执行层真正按流程办事以及采用随机抽样评估确保过程固化等。资源为单个PDF文件大小约5.17MB目前已有1415人学习。通过阅读该规范文档读者可快速掌握CMMI的等级框架、通用目标GG与通用实践GP的核心要点明确不同级别下组织应达到的过程能力为制定过程改进路线图及后续落地实践提供直接参考是一份实用的组织级过程改进基础资料。1. CMMI 3.0 软件工程规范文档先弄清它到底是什么前年帮某公司的研发中心做内部过程评估一进会议室就看见桌上三摞装订好的文档每摞七八厘米厚。负责人说这是我们迭代了两年的 CMMI 3.0 软件工程规范文档。可我刚翻到项目策划那一章就意识到这次评估大概率要翻车——文档很完整但里面规定的活动和团队实际干活的方式完全是两张皮。标题里的 3.0严格说并不是 CMMI 模型本身的版本号当前模型基准是 CMMI 2.0所谓 3.0是组织内部把过程资产迭代过三轮之后自己的版本叫法。这套体系到底该长什么样怎么从零搭起来怎么让项目组真的去用以及评估时怎么证明它不是纸面文章。下面的内容就围绕这四件事展开。2. 为什么需要一套规范文档模型基准、文档分层与颗粒度选型2.1 CMMI 2.0 是模型基准3.0 是你们自己的文档版本先把最容易被绕晕的概念摆正。CMMI 官方模型目前最新的主流版本是 2.0它把早先 1.3 时代的 22 个过程域重构为按实践域组织的结构。实践域的描述方式从“你要建立哪些文档”变成“你要做到什么程度、用什么证据证明做到了”这个转变很关键。很多团队做体系文档时还在按 1.3 的思路写一堆表单结果文档数量上去了评估专家却问不到点子上。反过来说2.0 对证据的要求更看重真实工作产物而不是专门为评估做出来的模板。所以CMMI 3.0 软件工程规范文档这个叫法在行业里通常是组织内部过程资产的版本命名。对外说“我们是 CMMI 3.0”如果对方是内行他真正想听的是你们基于哪个模型视图、覆盖了哪些实践域、文档体系分了几层、最近一次评估或内部检查是什么时候。这些才是规范文档的身份证。还要想清楚一个问题规范文档到底是给谁用的。我接触过不少团队把过程文档当成给评估专家看的作品措辞讲究、图表精美唯独项目组自己不看。正确做法是把文档分成两种消费者一类是项目组成员他们要的是“我今天开工会、做估算、提交代码之前该拿哪个模板、走哪条审批”一类是评估人员和过程改进组他们要的是“你说你按流程做了证据在哪里”。能同时满足这两类消费者的文档体系才是合格的规范文档。判断文档体系好不好可以先看两个小场景。场景一新入职的项目经理第一天上班想知道项目计划要写到什么程度是去问旁边同事还是打开文档目录找十分钟就能找到答案场景二评估专家问“你对估算结果做过偏差分析吗”项目经理能不能在半小时内找到当时的估算表和实际工时记录这两个场景能通关体系就基本立住了。2.2 规范文档体系拆成四层方针、过程、指南、模板大多数成熟组织的文档体系是四层结构这个分层不是咨询公司发明的而是被多年的评估实践逼出来的。顶层是方针一般只有两三页讲清楚公司对软件过程的基本承诺、质量底线和发布权限边界比如“未经评审的代码不得合入主干”“里程碑评审不通过不得进入下一阶段”。方针的特点是稳定一年动不了几次由公司层面签发。第二层是过程描述一项活动从输入到输出的完整链路谁发起、谁执行、谁评审、谁批准输入是什么、输出是什么、卡点在哪个环节。过程文档建议按业务场景组织比如“从立项到交付的端到端主流程”“需求变更处理流程”“缺陷修复流程”而不是按 CMMI 实践域一个个写否则项目组根本对不上号。第三层是指南回答“具体怎么做”的问题例如代码评审的检查要点、估算用什么方法、测试用例设计从哪些场景切入。指南可以带个性允许不同团队有不同做法。最底下是模板与检查单这是项目组日常接触最多的一层也是后续维护工作量最大的一层。模板的价值是统一交付物格式检查单的价值是把过程要求翻译成可勾选的行动项。四层之间的引用关系要清晰过程文档里提到某份模板就要写到具体编号模板表头要标注它对应的过程文档版本。我见过最混乱的体系就是过程文档说“见附录模板”但附录里根本没有项目组只能自己猜着做。分层清楚的好处是改一层不用动另外三层。提示四层文档之间禁止互相复制大段内容。过程文档引用指南和模板时写编号不写全文。改一层不会牵动另外三层体系才能低成本维护。这套四层结构与 CMMI 2.0 的证据链天然匹配。评估专家看证据时先由过程文档告诉他组织定义了什么事情再由指南告诉他事情的标准做法最后由模板和检查单展示实际执行留痕。三层源文件加一层执行记录恰好构成一条完整的证据链。如果少了指南层项目组会把同一个任务做出七八种样子如果少了模板层过程文档再漂亮也只能停留在概念层面。2.3 文档颗粒度怎么定按团队规模而不是按咨询模板我见过的最常见翻车是团队拿着某咨询公司的模板直接套。那种模板是为几百人规模的组织设计的一个技术文档目录能列出六十多个条目。一个三五十人的研发部门照单全收结果就是过程文档没人维护模板没人填最后整个体系变成摆设。颗粒度的第一原则是文档体系的总维护成本必须小于它带来的节约。我给团队的参考量级如下具体可用下表做一个简单的定位判断| 团队规模 | 过程文档数量 | 模板数量 | 编写周期 | 维护责任 | | 20人以下 | 5-8份 | 10-15份 | 2个月成稿 | 技术负责人兼QA | | 20-100人 | 8-12份 | 15-25份 | 3-4个月成稿 | 专职QA或EPG小组 | | 100人以上 | 12-18份 | 25-40份 | 6个月成稿 | EPG主导加各过程Owner |这里的数字不是标准答案但量级可以参考。团队越小越应该把精力放在模板和检查单上而不是过程文档的长篇大论团队越大才越需要过程文档来串联不同角色之间的协作关系。判断颗粒度是否合适有一个简单标准让一个不熟悉你们体系的新员工拿到文档后能独立完成一次标准的迭代不需要到处找人问“这到底什么意思”。如果他还需要反复确认说明不是人笨是文档没写到该写的粒度。还有一类颗粒度陷阱是把敏捷团队硬套瀑布式过程文档。CMMI 2.0 和敏捷并不冲突规范文档里完全可以写“需求以用户故事形式维护在迭代看板上每个故事须包含验收标准由产品负责人在迭代评审时确认”。关键不是流程形态而是责任、输入输出和证据有没有定义清楚。这个原则在后面的落地章节还会用到。3. 搭建 CMMI 3.0 规范文档体系目录结构、编写顺序与模板设计3.1 文档树与文件清单一份可以直接改的目录结构规范文档首先要有一个明确的所有者我习惯用五类目录来组织方针治理、过程资产、指南手册、模板检查单、度量分析。目录不是按 CMMI 实践域建的而是按“项目组找东西的路径”建的。项目组找东西时不会说“我要找实践域 PP”他会说“我要找项目计划模板”或者“我要看需求变更流程”。所以目录的第一层应该是业务场景第二层才是 CMMI 实践域映射。给你一份我常用的文件清单直接可以套用改造。技术开发类的最小集合我一般控制在 30 份以内超过这个数就说明文档已经开始失控。| 编号 | 目录 | 核心文件 | 维护角色 | | 01 | 方针与治理 | 质量方针、过程改进方针、角色职责定义 | 管理层签发 | | 02 | 项目立项与计划 | 立项评估流程、项目计划模板、估算指南 | 项目经理 | | 03 | 需求与设计 | 需求管理流程、需求跟踪矩阵模板、设计评审检查单 | 需求分析/架构师 | | 04 | 开发与测试 | 编码规范、代码评审指南、测试策略模板、缺陷管理流程 | 开发/测试负责人 | | 05 | 交付与运维 | 发布审批流程、上线检查单、问题响应流程 | 交付经理 | | 06 | 支持与管理 | 配置管理计划模板、质量保证检查单、培训计划模板 | QA/配置管理员 | | 07 | 度量与分析 | 度量指标定义、数据分析报告模板、过程改进建议库 | EPG |这个清单的好处是每个目录都有明确的使用者维护角色和文件清单一一对应。很多团队文档失控就是因为没有角色认领没有人对“这份文档一年前就该更新了”负责。3.2 编写顺序先写主线过程再补管理与改进类新搭体系时不要按 CMMI 模型从第一个实践域写到最后一个。那样写出来的东西是给专家看的不是给项目组用的。我的习惯是先写能支撑“一个项目从立项到发版跑完整条链路”的最小过程集。这个过程集通常由四篇组成项目策划与监控、需求管理、设计开发与测试验证、发布与结项。把这条主线写通了项目组就已经可以有流程用了。主线完成后再补支持类过程配置管理、质量保证、决策分析、培训管理。这类过程的特点是跨项目它们本身不产生业务价值但保证主线过程稳定运行。最后才写过程改进类比如过程资产管理和原因分析。原因很简单过程改进类文档描述的是“如何改进过程”在体系还没有被使用之前改进对象都不存在写出来也是空转。每个过程的编写有一个顺序套路我自己总结成四步。第一步定义边界这个过程的起止点在哪里输入什么、输出什么。第二步定义角色谁做、谁审、谁批准、谁备案一个角色对应一段职责。第三步定义活动流用文字或表格列出活动顺序卡点位置要特别标注。第四步定义证据每个关键活动对应什么产出物产出物挂哪个模板编号归档到哪里。四步走完一份过程文档的基本盘就有了。先不追求完美写出来能跑比写出来好看重要得多。这一步对熟手也适用老团队改造已有文档时常用手法是把原来的几十份文档按这四步重构凡是回答不了第四步“证据是什么”的章节优先砍掉或重写。3.3 模板与检查单控制在 30 分钟能填完模板是最容易被高估的东西。很多团队花大力气设计了十几个字段的模板结果项目组填一次要两个小时填完再也没人看。我设计模板有一条硬标准一个模板的正常填写时间不能超过 30 分钟超过 30 分钟填写时间的模板必须拆成多份或者删掉部分字段。这条标准要在模板评审会上直接说否则需求方永远觉得“再加一个字段也不多”。项目计划模板是最典型的重灾区。一份可用的项目计划模板结构上只需要九个部分项目目标与范围、交付物、估算与规模、进度计划、资源分配、风险登记、干系人与沟通、质量目标、度量项。每个部分用表格或简短段落避免大段文字。例如估算部分就是一个三列表格模块名称、估算人天、估算依据。三列就够了不要加“置信区间”“上下限”这种专家才用的字段。检查单的设计更讲究它要把过程文档里的要求翻译成可勾选的动作。比如“里程碑评审检查单”可以这样写| 序号 | 检查项 | 对应依据 | 结论 | | 1 | 项目计划已更新到当前版本并在配置库归档 | 项目策划过程 4.2 | 通过/不通过 | | 2 | 需求跟踪矩阵与最新需求基线一致 | 需求管理过程 5.1 | 通过/不通过 | | 3 | 本轮缺陷关闭率达到 95% 以上 | 缺陷管理指南 3.2 | 通过/不通过 | | 4 | 风险清单已评审高风险项有明确责任人 | 项目监控过程 4.4 | 通过/不通过 | | 5 | 配置审计报告已提交质量保证负责人 | 配置管理过程 6.3 | 通过/不通过 |检查单最好不要超过二十项。超过二十项评审会议就会变成念检查单失去评审本身的意义。另外检查单里的“对应依据”列是关键它把模板和过程文档连接起来评估时专家顺着这一列就能找到证据链。3.4 度量定义先于指标采集五个常用过程指标的口径度量是规范文档里最容易写成摆设的部分因为定义指标不解决数据从哪来的问题。我的经验是度量项宁少勿多先定义采集方式再谈分析方法。一个刚开始建体系的团队五个指标足够了。五个指标的推荐口径和采集时点如下表| 指标 | 计算口径 | 采集时点 | 责任角色 | | 进度偏差率 | (实际完成日期-计划日期)/计划周期 | 每次里程碑评审前 | 项目经理 | | 需求变更率 | 本期变更需求数/基线需求总数 | 每次迭代结束 | 需求负责人 | | 缺陷密度 | 严重缺陷数/千行代码或功能点数 | 测试阶段结束 | 测试负责人 | | 评审有效性 | 评审发现缺陷数/测试阶段发现缺陷数 | 版本发版后一周 | QA | | 交付周期 | 从立项到首次发版的实际天数 | 项目结项时 | 项目经理 |每个指标定义时必须写清楚三件事数据从哪里拿比如缺陷数从缺陷管理工具导出谁负责填填到哪里。只要有一项说不清楚这个指标就会被项目组用最省事的方式造假填上去最后分析出一个毫无意义的结果。指标分析报告以季度为周期就好月度报告在小型团队里只制造焦虑不产生改进。过程改进组拿到季度数据后真正的动作是找一两个偏差最明显的项目做根因分析而不是把报告做得越来越精美。4. 从零落地 CMMI 3.0 规范文档差距分析、裁剪规则与试点三步走4.1 差距分析用一张过程域对照表找出真实缺口规范文档落地第一步不是写文档而是做差距分析。差距分析的目的不是证明你们一无所有而是把“当前怎么做”和“目标怎么做”之间的缺口量化出来。如果团队还没有成熟的文档体系这一步会同时产出两份东西一份现状描述一份待建清单。我常用的差距分析表结构如下每一行对应一个过程域或关键实践。如果团队还习惯 CMMI 1.3 的过程域缩写可以直接用 PP、PMC、REQM 这些代号来做初步映射后面再对齐到 2.0 的实践域。| 过程域 | 现状描述 | 目标要求 | 差距等级 | 建设动作 | | 项目策划 | 项目经理口头排期无估算记录 | 输出项目计划模板并评审 | 高 | 先建项目计划模板 | | 需求管理 | 需求变更靠群通知无基线 | 建立需求基线并维护跟踪矩阵 | 高 | 建需求管理流程 | | 配置管理 | 代码库有分支交付物随意命名 | 明确基线策略和归档规则 | 中 | 建配置管理计划模板 | | 质量保证 | 无独立QA测试自己审自己 | 设置QA角色并执行过程检查 | 中 | 定义QA检查单 | | 决策分析 | 技术选型拍脑袋 | 重大选型走正式评审 | 低 | 写决策分析指南 |差距等级建议只分高中低三档。高表示可能会直接导致项目失控必须在一个月内补上中表示有风险但短期可控低表示有操作但缺记录。等级分类越简单梳理速度越快。一次差距分析会议控制在半天以内让一线项目经理和开发负责人参与由QA记录管理层最后确认优先级。不要让咨询顾问自己关在屋里打分那样写出来的差距分析永远完美也永远不被认领。4.2 裁剪规则哪些必须留哪些可以裁一套规范文档如果对所有项目一刀切必然被小型或敏捷项目组抵制。所以裁剪规则不是可选的加分项而是让体系活下去的必要机制。裁剪的维度我一般看四个项目类型新产品研发、定制交付、运维支持、内部工具、项目规模人天估算范围、团队人数、风险等级是否涉及合规审计或外部金额合同。一个可裁剪的参数表示例如下| 裁剪维度 | 简化条件 | 可裁剪内容 | 必须保留内容 | | 项目类型 | 运维支持类 | 设计评审流程可简化 | 问题响应、发布审批 | | 项目规模 | 小于 60 人天 | 里程碑评审合并为结项评审 | 需求确认、代码评审 | | 团队人数 | 小于 5 人 | 独立QA改为交叉评审 | 配置管理、核心评审 | | 风险等级 | 无外部合规要求 | 决策分析流程可不走 | 需求基线、变更控制 |裁剪规则里要特别区分“可简化”和“可裁掉”。可简化意味着步骤还在但可以合并或降低评审层级可裁掉意味着该实践域不适用。评估专家最不喜欢看到的是无理由整块裁剪所以项目裁剪时必须保留一份裁剪记录写明裁掉了哪个实践域的哪个活动为什么裁依据是什么。QA 在项目启动时要核对这份记录没有裁剪记录的项目直接退回。这个动作本身就是证据链的一部分。注意裁剪记录必须在项目启动时完成而不是在评估前补。补出来的裁剪记录经不起追问访谈时项目经理三句话就露馅。4.3 试点推广选对项目比选对流程更重要体系写完不能直接全量推广选试点项目是决定成败的关键一步。我挑试点项目有三条标准第一项目周期在三到六个月之间太短看不出效果太长等不起反馈第二项目业务重要但不属于救火状态救火项目只会把新流程当成绊脚石第三项目经理愿意配合而不是被指派来配合。三条缺一不可尤其是第三条一个抵触的项目经理足以让试点数据全面失真。试点期间要做三件事。第一试点启动会由管理层站台说明试点目的、时间边界和考核方式明确试点不等于秋后算账。第二QA 每周和项目经理过一遍新流程的使用情况收集卡点这个频率很关键每周太密每两周太松。第三试点中期做一次快速内部访谈找两位开发、一位测试、一位产品每人二十分钟只问三个问题哪份文档你确实用了、哪份文档你压根没打开、哪一步流程你最想改。访谈记录直接进下一轮文档修订清单。试点结束时必须产出一份试点复盘报告分三类输出必须修改的问题、建议推广的经验、暂时不加的功能。复盘报告批准后体系文档发布 3.0 正式版或者 3.1 修订版同时安排全员培训。培训不要讲概念拿试点项目当案例讲把项目从立项到发布的全程走一遍展示每一步对应哪份文档、哪张模板。这种讲法新手也能跟上熟手还能现场提裁剪问题。全部完成后再谈推广推广节奏建议每季度扩一个团队而不是一个月铺完全公司。5. CMMI 3.0 规范文档落地避坑5 个踩过的坑与排查顺序5.1 坑一文档写成教科书评审专家一眼看出没跑过真实项目现象过程文档里定义了一套理想流程比如“每周三召开项目例会由 PMO 发布风险周报”但项目组实际根本没有 PMO 这个角色。专家访谈时只要问一句“你们的风险周报长什么样”现场就露馅。原因通常是执笔者是 QA 或外部顾问没有真实跑过项目写出来的内容来自咨询模板。解决每份过程文档的第一执笔人必须是在职的项目经理或研发负责人QA 只做格式统一和交叉检查。写完第一稿就看一件事文档里提到的每个角色是不是组织架构里真实存在的如果不存在要么改文档要么先补角色。5.2 坑二模板字段太多项目组填一次就想放弃现象模板发布第一周项目组全都用旧版凑合填新模板无人问津模板评审会开了三次还没通过。原因模板设计时把十年内可能用到的字段全部堆上去了没有人站在填表人的角度审核。解决按 30 分钟标准重做把模板拆成必填、可选、免填三组。必填字段真正支撑过程评审可选字段给有需要的团队用免填字段比如版本号、编制日期做到自动生成。模板发布前找两个不是作者的项目组成员试填一遍试填超时就当场删字段。这一步是最容易出效果的改完模板项目组的抵触情绪立减一半。5.3 坑三裁剪规则写了没人执行评估时被打成弱项现象裁剪参数表写在体系文档第二卷里项目启动时没有任何环节提醒项目经理去查结果所有项目都按最重的流程走评估专家发现实际执行和裁剪声明不符。原因裁剪规则是文档没有转化为流程的强制步骤。解决把裁剪记录做成项目启动检查单的第一项QA 在立项评审时点检。项目经理填裁剪记录的时间限定在十五分钟内模板里预设常见项目类型的推荐裁剪方案项目经理只需要确认或说明不同之处。裁剪记录每季度汇总一次EPG 从里面发现哪些流程确实不适合团队再反过来调过程文档形成闭环。5.4 坑四度量数据没人填指标体系空转几个月现象度量表挂在项目计划模板里但项目结项时很多字段是空的。分析报告出来了过程改进组自己都说不清数据准不准。原因指标定义没写清楚采集时点项目组不知道由谁填、在哪一步填。解决把采集动作绑进已有流程。比如缺陷密度要求测试阶段结束时统计就把它写进测试阶段评审检查单评审通过之前必须附上统计表。数据采集动作如果不绑在流程节点上靠自觉一定失败。还要定期抽查数据质量拿两个项目的两次版本做数据一致性比对偏差大的直接找当事项目经理核对第一次口头提醒第二次写进质量月报。5.5 坑五3.0 发布了项目组还在用 2.1 的旧模板现象体系文档最新版已经更新到 3.0但项目计划模板实际打开还是 2.1 的格式新旧混用评审时文档编号对不上。原因文档发布和配置资产更新没有联动项目经理面前有两条获取模板的路径旧路径没关。解决发布 3.0 时同时做三件事配置管理系统里的模板库整体切换旧模板归档为只读项目启动检查单里直接链接最新模板编号。同时加一条硬性要求任何模板版本升级配置管理员要在发布后一周内检查在跑项目中引用的模板编号发现旧版直接回退并通报。这一条应当写进配置管理过程里作为例行配置审计的一部分。6. 验证规范文档有没有用评估访谈与文档版本管理的技巧6.1 用评估访谈验证文档和实际是否一致规范文档好不好用可以按 SCAMPI 的思路做一次内部验证文档怎么说、现场怎么答、记录怎么证明。挑三个角色项目经理、开发、QA各访谈二十分钟。问法有个技巧别说“请讲一下你们的流程”而是“上周那次版本演示前你做了什么”让他当场打开项目目录找到对应的模板和签字记录。如果他开始泛泛讲流程十有八九是在背文档。我第一次做这种访谈就被上了一课项目经理讲得头头是道问他变更确认单在哪翻了五分钟网盘没找到最后承认变更其实是口头确认的。内部验证按季度做一次每次半天覆盖三个项目就够。6.2 把规范文档当产品做版本管理规范文档一旦发布就是需要长期维护的产品。我习惯小修订随时发版本号升 3.1、3.2大修订半年到一年一次升 4.0 合并所有变更。每份模板页脚放三行版本号、修订日期、修订说明。配置管理员把文档库纳入配置管理后旧版本全部归档只读避免出现正文引用 3.0、实际打开是 2.1 的情况。三年下来我最大的教训是规范文档的敌人从来不是不完美而是完美。第一版可以只覆盖主线流程但文档里写的每一句话都必须是团队真实会做的。如果你正准备建 CMMI 3.0 软件工程规范文档我建议从一张差距分析表和一份项目计划模板开始别从厚厚的过程文档开始。希望帮到你。本文还有配套的精品资源点击获取