张传波（网名：Fireball，大大大火球）

CMMI2.0与1.3在组织形式区别很大，很多PA和之前的不太一样了，而且PA在2.0中叫实践域，1.3中叫过程域。不过其实核心内容没有大的变化，只是相关内容的位置进行了调整，部分描述进行了优化。目前是过渡阶段，2.0和1.3都可以评估，但截止日期之后就只适用2.0了。1.3评估的截止日期是2020年9月，但因为疫情的原因不知道会不会有所调整。下面是基于CMMI2.0的持续改进计划，供参考：对该计划感兴趣，欢迎与我联系，谢谢！...

好像很少听说某公司评估CMMI不通过的情况，似乎通过率很高，甚至100%，这其中有什么玄机吗？

评估简单的说就是用一定的办法判断是否达到了CMMI的要求。那怎样才能判断呢？这就是“SCAMPI A”评估办法，晕不？我们将通过一个吃饭的简单例子来理解这个评估方法。

聪明的人在出现问题的时候，除了解决问题外，都会想到如何避免问题以后再次发生，避免的办法可能是从过程或者技术两个方面入手，从根本杜绝问题的发生。问题分析是很常见的，为什么在5级的时候才有这样的要求呢？难道2、3级的企业，甚至是没有级别的企业，就不会做问题分析并防止问题再次发生吗？其实5级的这个CAR没有这么简单……

组织革新与部署(Organizational Innovation and Deployment)，在CMMI1.3中，OID已经改名为OPM（Organiational Performance Management，组织性能管理）

5级的企业，是如何做到“持续改进”呢？其实一个软件企业，要提高生产力，有3方面途径：1)改进过程，使现有的过程更强更有效。2)引入新技术，提高生产力。3)对工作出出现的问题进行原因分析，避免以后再次出现。

这五个问题相当经典而且比较深，需要做过CMMI4、5级的朋友才能看懂这些问题。希望本文对正在实践CMMI4、5级的朋友有帮助，也欢迎你来围观一下，不过本文对于无基础的朋友来说有点难喔。

2级到5级，直接跟项目管理有关的PA有好几个，它们是怎样的关系呢？

OPP是对组织级提出要求的，组织要根据公司的商业目标、企业的实际情况，选择要进行性能分析、量化管理的子过程，制定组织的质量和过程方面的量化的目标，建立基线和模型。这些量化的目标、基线、模型，要用于进行项目管理。具体内容见QPM。

定量项目管理与一般的量化管理很不同，不是在项目管理过程中用到数据，就算是定量项目管理。定量项目管理要求过程是稳定的，过程要稳定，需要满足很多条件，企业的过程要做到稳定，要付出很多努力。

2、3级已经对软件开发的方方面有了详细的指引，4级还会有什么更高的要求呢？4级叫定量管理，那什么叫定量管理？微软的MSF达到CMMI几级水平呢？是不是所有企业都适合做CMMI4级呢？

决策分析就是根据一定的选择标准，在一些候选方案中选出合适的方案。一般来说，经过决策分析后得出来的决策，科学性更高，实施该方案成功概率会比较高。但实施决策分析本身的成本也比较高，一般我们只在重大问题采取决策分析的办法，例如：大家购买房子就需要决策分析一下了，但今晚去哪里吃饭，恐怕就不需要决策分析一下了。

3级出现了3个以O开头的PA：OPF、OPD、OT。O就是Organizational（组织的）的第一个字母，在2级的时候还没有见到一个O开头的PA，3级就出现了3个，4级还会有1个，5级也会有1个。虽然只有3个PA是O开头的，但不代表其它PA与组织级没有关系，其实到了3级全部PA都包含对组织级的要求，大家会发现大部分PA的SG1其实都是针对组织级的要求的。本文将会让你进一步理解CMMI2级和3级的区别。

软件研发是高难度的技术活和团队协作活，几乎所有的项目都不可能在项目开始之前就具备完成该项目所需要的技能，所以培训、特别是组织级别的有计划有前瞻性的培训就显得很重要了。

Organizational Process Definition,简称OPD，就是一个组织如何进行知识管理的问题了。知识可以包括两类，非技术类和技术类，非技术类包括：标准过程、规章制度、流程、项目管理经验、度量数据等等，技术类包括：设计、代码库、重用组件等。组织除了要对知识进行分类外，还需要建立知识的收集、分析、存储、使用的策略及具体可操作的办法等。

要做这个PA，组织要成立EPG（Engineer Process Group）专门负责过程改进的工作。这个组是整个公司过程改进的动力源头、策划中心、执行中心、培训中心。很多公司的过程改进没有做好，很大部分的原因是EPG的成员没有选择好。EPG成员绝对不能清一色都是“理论派”，没有具体项目经验的。

集成项目管理（IPM）是2级的项目计划（PP）与项目计划跟踪与控制（PMC）的“升级版”，而4级的定量项目管理（QPM）又是集成项目管理的（IPM）的“升级版”。3级与2级最大区别之一就是上升到组织级，项目管理也是一样，项目需要利用组织资产库定义项目自己的过程，考虑各种计划的集成。这是“集成”的其中一层意思，“集成”另外一层意思就是，要协调和管理好项目开展过程中各相关关系人。

有这样的说法：项目管理其实就是风险管理，把风险管理好了，项目也就管理好了。可见风险管理是多么重要啊！CMMI2级的PP这个PA的SP2.2提到要识别风险，但这里的要求还是处于项目级别层次的。3级中的RSKM，已经把风险管理上升到组织层面，组织级需要对风险进行分类、定义风险的属性、制定风险的管理策略等。

验证强调的是在开发过程中对工作产品进行检查，尽早发现问题。而确认强调的是，在真实的使用环境中，确保软件能达到预期的效果。开发环境与真实环境是不可避免存在差异的，为了有效地避免在开发环境中没有问题，但一到真实环境就出现问题的情况，确认的工作是非常重要的。

验证就是按照既定的标准，检查工作产品是否符合要求。工作产品可能是文档也可能是软件本身。而检查的办法一般是同行评审或者是软件测试。那什么是同行评审呢？比方说：A君是做软件设计的，B君也是做软件设计的，A君写了一份设计文档，让B君这个同行（因为大家都是做设计的）来给给意见，这样就使同行评审。同行评审的目的就是让有同样工作经验和技能的人来评审自己的工作产品，发现尽量多的问题。验证这个PA其目的是希望软件企业在软件开发整个过程中，做好相应的检查工作，把尽量问题发现前面，保证了项目的可控性，降低开发的成本。

什么是产品集成？简单的说就是把组成产品的所有软件组件组装起来，使之运行在目标环境上，产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。系统越复杂，集成就显得越发重要。微软的每日构建，极限开发中的持续集成，都是对产品集成的基本原则，其基本道理就是随时保证组成最终产品接口一致，能顺畅运行，能随时拿得出可运行的版本。

不知道您的工作中，在设计方面是否有这样的一些问题：1)无设计文档；2)有设计文档，但形同虚设；3)设计时没有考虑可以重用以前项目或者第三方的代码或组件；4)没有用需求来驱动设计；5)设计没有考虑多过一个的方案；6)没有考虑清楚设计的原则和标准；7)设计的弹性不够、架构落后？；8)代码与设计脱节？；9)代码到处是炸弹或地雷……

要理解好本PA，需要先理解清楚以下几个关键的概念：1)客户需求(Customer Requirements)；2)产品需求(Product Requirements)；3)产品组件需求(Product Component Requirements)。我们经常抱怨客户的需求在变，其实80%的原因是没有把握住客户需求，其实客户经常变的是产品需求或者是产品组件需求，客户需求是很少变的，就是因为我们没有把握住客户到底想要什么、需要什么，导致我们认为客户太难“服侍”了。只有把握住客户真正的需求，我们才能抓住根本，万变

3级的几个重要特点：1)明确规定了需求开发、设计、编码、测试、集成等软件开发各过程的要求。2)对项目管理提出了更高的要求，要利用组织级的数据来管理项目。3)出现了专门针对组织级的PA，要求有专门的组织来负责过程改进的工作。4)提供了一个做出最佳决策的指导，而这个方法可以用于软件工程，也可以用于组织级过程改进。

度量工作有很多学问，所有的度量工作，都需要回答这些问题：1.度量的目的是什么？2.谁来做这个度量？3.什么时候做这个度量？4.如何做这个度量？5.怎样记录度量的数据？记录到哪里？6.谁会使用这些数据？7.如何分析这些数据？8.谁来分析这些数据？9.分析的结果如何使用？

有人可能会说，过程就算是错的，也需要执行，在执行中持续改进。这个观点在某些情况下是不对的，要看过程错的程度。如果过程错到根本无法执行，这样强硬执行的话，肯定吃力不讨好。在刚建立过程的时候，不宜太死，可以适当宽松，另外应该鼓励项目组定义自己的做法，然后QA就按照项目组自已定义的做法来监督执行。通过不断的积累，就可以建立比较完善的过程。

做软件开发的，不免要购买一些软硬件。软件可能是中间件、控件、插件、组件等，硬件可能是一些服务器、PDA、单片机等。只要稍微复杂的项目，都不可避免的会有采购的问题，就算目前没有采购，以后也会不可避免。另外也有可能把项目的一部分外包给第三方来做。作为一个想改进过程的企业，是不应该规避这个问题的。采购的软硬件或者是外包，都会从根本上影响项目的成本、进度和质量，采购和外包可以认为是风险最大的活动之一。

配置管理就是用了一些什么工具，建立了什么基线，成立了什么变更控制委员会，对所有的变更进行严格的控制吗？这样项目组将会苦不堪言，调整一下计划都需要提什么变更申请，修改什么设计文档也要经过一番审批，天啊，配置管理就是这样的吗？我们并不是为了配置管理而管理，配置管理是对软件生产过程中的各类工作产品进行管理的办法，要做这个工作之前，应该先理清楚到底会有什么工作产品，这些工作产品的依赖关系是怎样的，哪些是重要的工作产品，不同的工作产品需要什么层次的管理。

由“感知级”到“经验级”，再到“可预测级”、“持续优化级”这个过程是不可跨越的，不同级别的“用数据管理过程”，都是由商业目标驱动的，只是不同级别所达到的量化管理程度不一样。那为什么要“用数据管理过程”呢？如果有一个非量化管理的办法，成本更低，并且能更有效地达到目的，那我们当然就采用那个办法，而不会片面地追求“用数据管理过程”了。所有想“用数据管理过程”的人士，都应该认真思考这个问题，并考虑哪种层次的量化管理级别适合您的商业目标。

麦当劳的薯条不少人都吃过，味道很好，而且每家麦当劳的薯条味道很一致。麦当劳是如何做到的呢？我们分析一下生产过程，我们发现薯条从原材料开始，到后续加工，油炸的时间，薯条炸出来后多少分钟没有售出，就销毁，整个过程都有严格的控制，而且很多地方是量化控制，时间甚至精确到秒。严格的过程控制，保证了薯条能高质量地稳定地产出。全球的麦当劳，都用同一的严格过程来管理，所以保证了全球的麦当劳的食品都是高质量的而且是高度一致的。从另外一个角度说，只要麦当劳按照既定的过程来生产食物，就可以“预测”出最终食物的情况，麦当劳将对最终

进行初级量化管理的时候，企业通过实际的参数值，来“感觉”项目的状况，当积累足够多数据的时候，管理者可能会找出项目间的一些共同的数据特点，如可以统计出“平均值”、“最大值”、“最小值”，这些数据，可以描述组织整体的性能。当数据积累比较多的时候，组织级的经验数据可以用来管理以后的项目，例如可以用组织的平均值做为量化管理的要求。这个时候，就达到了中级量化管理水平了。

有很多软件企业在项目过程中，须提交一些进度报告、总结报告，报告中可能会有进度情况、成本情况的一些数据。收集这些数据的目标也十分明确，就是想了解项目的进度、成本情况，并与计划的情况进行比较，采取必要的措施。这是不是已经达到了“感知”级别的量化管理呢？

六西格玛被网络炒作得太厉害了，我一直没有能找到一篇能通俗说明六西格玛基本原理的文章。我们公司通过了CMMI5级了，但我还不时会遇到推销六西格玛培训的事情，这些推销者可能不知道要过CMMI4级，不精通六西格玛是不行的。

软件开发人员加班是家常便饭的事情，曾听说了一个朋友近一个月连续加班，日夜颠倒，没有周末，过着“暗无天日”的生活。我曾经问过另一个朋友他所在公司如何控制项目的进度成本的，他们公司非常“黑”，每隔一段时间公布一次加班龙虎榜，看谁加班最少，搞到他们不好意思不加班。通过不断的加班来保证进度了，通过加班不给加班费来控制成本，软件开发变成了“人间煎熬”。如何才能有效地度量项目的进度与成本呢？如何少加班最好不加班，就能按期并在预算内完成项目呢？

我们为什么要进行软件规模度量呢？目的无非是：1. 作为报价或者决策的依据。2. 安排具体的项目进度。3. 可以作为组织的生产力数据，可以有很多用途，如：各项目间横向比较，供以后项目参考等。基于不同的目标，我会为大家分享不同的实用度量方法。

公司的效益指标的度量是任何公司都可以做的，而且应该是第一时间就要做的度量，并且要持续地做的。公司所做的任何工作，市场活动、过程改进工作、度量工作等等，最终目的还是为了提高效益指数！而度量公司的效益指标，其实一点都不难！大多数软件公司都会有一套管理缺陷的系统，我们应该如何把缺陷度量做得更好呢？我们需要目标驱动地把度量工作做好，首先有两个最基本的要求：1.缺陷被准确的记录和跟踪。2.客观地依据缺陷状况对软件发布进行决策。

这年头IT界流行“用数据管理过程”、“用数字说话”，软件度量成为热点话题！一方面一堆专家在“哗众取宠”，而另外一方面企业在推行软件度量的实践中遇到了各式各样的问题，软件度量在软件企业中的实施效果不甚理想。一个软件企业应该从何做起度量工作呢？这是本系列文章的第1篇：度量陷阱及什么是度量？如果有人给你一个度量任务，要求你度量水的温度，你会怎样做？你会不会马上想到用温度计？不好意思，如果是这样，你就落入了度量的其中一个陷阱了。你应该先问，为什么要度量水的温度？不同的目的，做法是不一样的。

曾经有朋友跟我提起，他们公司突然有人关注我了，我自然很开心了,看来我名声在外了，哈哈！但我的朋友说，他是这样关注的：“他怎么还在那个公司？他们不是过了5级了吗？我们公司过了级后，EPG（Engineering Process Group，工程过程小组，负责过程改进的小组）已经没有存在必要了，都炒掉了，他们还没有炒掉？” 我真是要吐血而亡了！CMMI难道在国内就是这个鬼样的吗？公司是这样经营的吗？

人是会死的，需求是会变的。相信大家都经历了很多需求变更的痛苦，项目被拖延，成本高涨，十有七八是需求管理没有做好导致的。有哪一些需求管理方面的常见问题呢，这里列举一下：1.因为项目进度赶等原因，在很多需求还没有明确情况下，便开始开发的工作。2.开始客户只能提出模糊的需求，客户喜欢先让你做个东西给他看，然后他才可能逐渐提出真正的需求，而需求调研人员，对此没有什么好的处理办法。3.客户以种种

计划不是用来看的，是用来执行的。PP讲述了如何做计划，PMC讲述的就是如何跟踪计划的执行并在实际情况偏离计划时采取纠正行动。我们先看看SG1，SG1讲述的是如何根据计划来跟踪计划的执行问题。SG1: Actual performance and progress of the project are monitored against the project plan.中文大意是：根据