企业官网建设流程全解析

简介：CMMI 3.0软件工程规范文档是面向软件过程改进团队、QA人员、项目管理者和研发管理者的系统性参考，围绕商业目标驱动、过程固化与高层参与等核心思想，帮助各类组织建立和改进软件工程过程。压缩包内为1份PDF文档，约5.17MB，图文结合地梳理了CMMI从v1.3到v2.0的模型演化，涵盖初始级、已管理级、已定义级、定量管理级和优化级五个等级的具体目标与实践，GG/GP通用目标与通用实践，以及v2.0中20个实践域与v1.3过程域的详细映射对照。已有1415人学习下载。文档针对v2.0在商业目标驱动、性能报告评估、随机抽样检查、高层经理参与等重大变化作了重点说明，并列出估算、监控、治理、实施基础设施等实践域的意图与价值。对于需要系统理解CMMI 3.0框架、准备模型评估或推动组织级过程改进的读者，这份文档能提供清晰的参考索引和落地要点，适合作为案头资料反复查阅。

1. CMMI 3.0 不是升级包，是换了一套体系：我为什么劝团队重做过程定义

某团队拿着旧版过程域清单去做 CMMI 3.0 差距评估，第一轮就被评审员问住：他们厚厚的体系文件里通篇写着"过程域"，可 3.0 的评估模型里只有"能力域"和"实践"，术语对不上，证据自然也无从谈起。这件事让我意识到，CMMI 3.0 软件工程规范文档不是 2.0 的修订补丁，而是把原来按流程切分的多个过程域，重组成按业务价值域组织的能力域结构，让敏捷、DevOps、网络安全这些本来就该存在的做法，第一次在模型里有了明确位置。这篇文章要讲清楚 3.0 的骨架长什么样、从旧版迁移时差距清单到底怎么做，以及那些不看评估规则就永远踩不中的坑。适合正在准备 3.0 评估、或想把手头过程体系真正用起来的研发与质量负责人。

2. 从过程域到能力域：看懂 3.0 的骨架再动手，不然连文件目录都建错

我第一次打开 3.0 的能力域清单时，第一反应是和旧版做一一对应，结果发现根本对应不上。旧版按需求、设计、测试、配置这样的流程切分，3.0 按"工程与开发""项目管理""质量"这样的价值域切分，切法不同，意味着你组织文件、分配责任人、设计证据的方式全部要变。

2.1 视图决定评估范围：先选开发视图还是服务视图

3.0 引入了"视图（View）"的概念，用来替代旧版里"模型族"的割裂感。旧版开发、服务、采购各是一套模型，一个团队如果既做产品又做交付运维，就要同时维护两套体系，非常痛苦。3.0 的做法是：一个组织可以选定一个主视图，再按业务补充叠加其他视图的实践，不用再被迫二选一。

我一般会建议：主业务是产品研发的，先锁定开发视图，再评估自己是否需要补服务视图的实践组。最容易犯的错是为了显得业务覆盖面广，一下子选四个视图，结果评估范围翻倍，每条实践都要有两三个项目的证据，团队直接被拖垮。视图选的不是荣誉，是你要接受评估的实践范围，范围越大，证据负担越重。

2.2 能力域与实践组：新版最核心的二维结构

在 3.0 里，"能力域（Capability Area）"取代了旧版的"过程域（Process Area）"。它不再按流程步骤组织，而是按组织要达成的能力目标组织。开发视图下常见的能力域包括工程与开发、项目管理、质量、过程管理、支持、基础设施六类，每一类下面再挂若干实践组，实践组里才是真正被评估的最小单元——实践（Practice）。

这个结构对落地最大的影响是：评定的最小粒度变小了。旧版评一个过程域，要看一组实践的综合表现；3.0 评的是单条实践，覆盖还是没覆盖，证据够不够，一目了然。以前靠"整体感觉还行"蒙混过去的环节，现在很容易被单拎出来查证。所以建文件目录时，我不建议再按旧版的 22 个过程域建 22 个文件夹，而是按"能力域 → 实践组 → 实践"三层结构建，后面做差距清单时能直接对齐。

2.3 能力等级与成熟度等级：两个容易混的判定标准

3.0 里有两套等级，能力等级针对单个能力域或实践组，成熟度等级针对整个组织。能力等级描述的是某条能力域做得有多深：从 0 级"未完成"到 3 级"已定义"，部分场景还会延伸到 4 级"量化管理"和 5 级"优化"。成熟度等级则沿用 1 到 5 的整体框架，但不再像旧版那样强制要求所有过程域都达到某一等级，而是看一个"目标能力域清单"。

最常见的误用，是团队盯着"我们要过 ML3"，却不知道 ML3 对应的是一组具体能力域，每个能力域都要达到 CL3。有人把 ML2 当成"所有实践都做到 CL2"，结果把预算摊到几十条实践上，最后每条都是半吊子，评级反而失败。我建议先把目标拆清楚：例如"开发视图下，工程与开发、项目管理、质量、支持四个能力域达到 CL3"，再按这个清单分配资源。

3. 从旧版迁移到 3.0：实践映射表与评估差距清单怎么做

把旧版体系搬到 3.0，最忌讳的是直接改文件封面。3.0 的实践编号和证据粒度都和旧版不同，需要先做一次系统的映射清点，再生成可执行的差距清单。

3.1 旧实践到新实践的映射：先清点再动刀

拿到旧版的过程域清单后，我会按以下四步走：先建立新旧概念对照关系，再为每条旧实践标记变化类型，然后输出映射表，最后用映射表拆工作量。映射表至少要包含旧实践名称、旧所属过程域、新能力域、新实践标题、变化类型、备注说明。以需求管理为例，旧版"需求开发"与"需求管理"两个过程域的内容，在 3.0 里会被合并进工程与开发能力域下的需求相关实践组，变化类型就是"合并"。

这里的关键动作是"清点"而不是"理解"。我曾见过一个团队用三个月时间讨论新旧理念差异，最后连哪些实践消失了都没列出来。做映射表时，不要凭记忆写，把旧版清单逐条过一遍，每条都要落到新能力域的某个实践上，落不进去的单独标出，再判断是删除还是合并。这一步是做给评估组看的证明——证明你的体系是按 3.0 重新组织的，而不是旧版换了封面。

3.2 设计自己的差距清单：用电子表格就能落地

差距清单不需要专门买工具，一个电子表格足够，但字段设计要贴合 3.0 的实践结构。我常用的字段有：视图、能力域、实践组、实践编号、实践标题、目标等级、当前状态、证据链接、责任人、计划完成时间、验证结果。当前状态这列建议只保留三个值：未启动、部分覆盖、已覆盖，不要搞出"基本完成"这种模糊态，否则统计时没法量化。

差距清单做成后，我会让每个实践指定一个责任人，并在证据链接里填写实际路径，而不是写"见过程文件第 X 章"。评估组抽检时，顺着链接点进去就能看到产物，这才是有效证据。这个习惯能省掉大量评估前的补证据时间，算是我做过这么多改进项目后的后悔药：越早把证据路径固化，评估前越不用加班。

3.3 每条实践写"证据要求"：让评估不再靠答辩

3.0 评估里，证据分为直接证据与确认信息两类。直接证据指实际工作产物，比如需求规格说明、评审记录、测试报告、配置基线记录；确认信息指访谈对象的口头确认和操作演示。很多团队把所有精力压在 PPT 式汇报材料上，结果评审员来现场看系统、看记录，材料反而没人翻。我的原则是：每条实践至少准备一份直接证据、一个能讲清证据的访谈对象。

判断证据质量，我只看四点：可追溯——能从需求追溯到代码；可重现——按记录操作能重建产物；时效匹配——证据时间在评估周期内；有人能讲清——负责这条实践的人不照稿子也能讲明白。最后一点最容易翻车，后面避坑章会细说。

3.4 试运行两周看信号：哪些实践落地是假动作

差距清单做完不是终点，我会挑 1 到 2 个能力域先试运行两周，再对照信号判断真落地还是假动作。四个典型信号：一是风险清单两周没有任何新增或关闭，说明风险管理是静态台账；二是所有评审记录清一色"通过"，且缺陷数为零，说明评审走过场；三是度量数据照常收集，但从不见有人在项目例会上引用，说明测量是应付；四是变更记录多但配置基线从不更新，说明变更管理脱节。

信号背后几乎都是同一个原因：实践只写了文件，没进入工作习惯。解决方式不是补文件，而是把实践要求嵌进日常活动。比如风险清单必须在迭代计划会上逐条过，评审记录必须关联具体缺陷单，基线更新必须绑定发布流水线。试运行期间发现假动作是好事，因为还没到正式评估，改起来成本低；怕的是档案做得漂漂亮亮，试运行一开就全露馅。

4. 把 3.0 融进研发流程：敏捷团队与瀑布团队的两种搭法

CMMI 3.0 的一个明显变化是不再规定你必须用瀑布流程，而是允许你在既有的开发模式下，把实践嵌入现有活动。敏捷和瀑布都可以合规，关键是实践证据出现在哪里。

4.1 敏捷团队：把实践挂进迭代而非挂在文档

对敏捷团队，我的建议是别为 CMMI 单独造一套流程文档，而是把实践挂到迭代里。例如工程与开发能力域的"需求定义与分析"，对应的落地动作是每个用户故事必须有验收标准和回访记录；项目管理能力域的"计划工作"，对应的是每个迭代开始时的计划会议输出；质量能力域的"同行评审"，对应的是代码评审和关键用户故事的验收评审。

这里的关键是"追踪性"：评估组看迭代板时，要能顺着板上的卡片找到对应的实践和证据。所以我一般会在迭代计划里单独加一列"实践标签"，例如某张卡片带上"PRM-计划工作"的标记，这样评审员抽查任何一张卡，都能快速定位到实践。这个做法成本极低，但对评估抽检的友好度提升非常明显。

4.2 瀑布团队：里程碑评审与质量数据采集

瀑布团队落地 3.0 时，最自然的载体是里程碑评审。需求评审对应工程与开发能力域，设计评审对应技术实现实践组，测试评审对应质量能力域。每个里程碑的输出检查单，直接就是该能力域的实践证据。我通常会建议把检查单做成统一的模板，每个里程碑一份，评审会上逐条打勾，这样证据自然沉淀，不用事后补。

瀑布团队还有一个要点是质量数据采集。CMMI 3.0 的质量能力域要求你不仅做测试，还要分析过程质量。建议至少采集缺陷密度、评审有效性、需求稳定性、返工工作量四类指标，每月形成趋势，用作项目例会里的改进依据。这套数据既是质量能力域的证据，也能让团队看到过程改进的实际效果。

4.3 配置管理与基础设施：最容易引入安全实践的入口

配置管理在 3.0 里被放进了支持能力域，但与基础设施能力域紧密相关。落地时，最有效的做法是建立统一的构建与发布基线检查单，让配置管理、构建环境、依赖安全这些实践共用一套证据。

我把基础设施单独挑出来讲，是因为很多团队在 3.0 里把网络安全相关的实践忽略了，觉得那是信息安全部门的事。实际上，依赖扫描记录、构建环境权限审计、生产回滚演练，都是基础设施能力域可以直接用的证据。把这些要求和研发日常结合起来，不用额外造一套安全流程，就能补上这块覆盖。

5. CMMI 3.0 落地避坑：五个真实踩坑案例

以下是过去几年里我见过最多、也最容易在正式评估中翻车的五个坑，每条都按现象、原因、解决方式拆开讲。

5.1 沿用旧版术语写文件，评估组不认账

现象：团队体系文件里的"过程域（PA）"满篇都是，评估时评审员指着一份文件问：这条实践在 3.0 模型里编号是什么？对应哪个能力域？没人答得上来，评审直接中断。原因：迁移时只改了文件封面，内容还是旧版结构，实践粒度和新模型对不上。解决：正式评审前做一次全局术语替换，把所有"过程域、特定实践、通用实践"字样改为"能力域、实践组、实践"，并且按能力域重新组织文件目录。别小看这个动作，评估员看的是模型对齐度，术语错了等于证据无效。

5.2 只改组织级文件，项目级不落地，抽检全灭

现象：组织级过程文件写得很完整，但抽取三个项目做评估时，项目里找不到对应记录，评审员认为体系是一纸空文。原因：改进小组把精力集中在写文件上，项目只是拿到了模板，没真正执行。解决：选定一个真实的中型项目作为贯标试点，组织级文件先在这个项目上跑通，再横向推广。确保每个实践在试点项目里都有对应的工作产物和操作记录，组织级文件才有支撑。

5.3 把质量与测试混为一谈，能力评分崩掉

现象：团队把所有质量实践的证据都指向测试用例与测试报告档，评估组问质量保证怎么做、同行评审怎么组织时，拿不出独立证据。原因：质量能力域里包含了质量保证、同行评审、测试等多个实践组，测试只覆盖其中一部分，把测试当作质量的全部，必然有一批实践覆盖不到。解决：把质量能力域下的实践组拆开逐条看，测试对应验证类实践，质量保证单独建检查记录，同行评审单独建评审记录。证据分开存放，互不替代。

5.4 用成熟度等级倒推能力等级，目标设错

现象：团队宣称目标"ML3"，于是所有实践组都按 CL3 的标准去做，工作量爆炸，半年后什么都没做完。原因：ML3 并不要求所有能力域都到 CL3，而是目标能力域清单里列出的能力域达标即可，非目标域只要有基础覆盖就行。解决：先拿评估模型的目标清单，圈定本次评级真正需要达标的几个能力域，再集中资源逐条做深，其他能力域先保持 CL1 或 CL2，留到后续持续改进。通过拆解，把评级目标落到能力域级别再动手分配人力。

5.5 证据全是汇报 PPT，现场访谈翻车

现象：证据库里全是总结式 PPT，评审员问一线工程师"你实际操作里怎么提变更"，工程师支支吾吾答不出来。原因：证据被做成了宣传材料，而不是操作佐证。解决：每条实践的证据以可追溯的操作为主，例如版本库的提交记录、评审系统里的缺陷单、项目管理工具里的状态流转。访谈前让证据责任人自己过一遍实际操作流程，确保能脱离 PPT 讲清执行细节。血泪经验是：PPT 能过初审，访谈才是终审。

6. 进阶：用能力画像代替证书式改进，半年后你会感谢这个习惯

评估通过之后，差距清单别丢，把它升级成一张"能力画像"评分表，每半年滚动更新一次。画像是这样一张表：以能力域为行，以实践组为列，用满足、部分满足、不满足三档标注每个格子的状态，再额外加一列"薄弱环节概述"和"下一周期改进动作"。

能力画像和评级报告最大的区别，是它不回答"你过了几级"，而是回答"你的工程能力在哪几个格子上是空的"。过级是结果，画像才是下一次改进的输入。我见过不少团队，评估通过那天把差距清单删了，第二年复评时发现能力不但没提升，还因为人员流动倒退了。后来我养成一个习惯：每半年拉着研发负责人过一遍画像，每次只挑两个最薄的实践组集中补，比年底突击补一年的漏洞有效得多。

这个习惯坚持一年，你再回头看，会发现团队的能力短板不再是黑匣子，哪条实践是真落后、哪条只是证据没留，都清清楚楚。CMMI 3.0 这套规范文档真正值得投入的地方，不是那一张等级证书，而是让你每隔半年能用同一套尺子量一次自己。希望帮到你。

本文还有配套的精品资源，点击获取