《术以载道——软件过程改进实践指南》—第1章1.4节CMMI实施的难点与对策

本节书摘来自异步社区《术以载道——软件过程改进实践指南》一书中的第1章1.4节CMMI实施的难点与对策，作者任甲林,更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.4 CMMI实施的难点与对策
1.4.1 CMMI 2级的难点
其实这个问题本没有答案，因为不同的企业难点是不同的。对于某些企业来讲，可能没有什么难点。譬如，某企业只想拿到一个评估证书，而不考虑改进效果。我是基于企业里最常见的难点泛泛谈之。尽管CMMI 2级是最基本的等级，如果真想将CMMI 2级做好，其实还是不容易的，通常情况下的难点如下。

（1） 做一个切实可行的计划

任务要识别得比较全面，估算的工作量比较合理，人员的安排不能超负荷、不能窝工、进度安排紧凑而不失弹性。

（2） 实时掌握项目动态，发现问题，解决问题

如果项目经理是技术人员出身，往往不喜欢实时管理项目中每个任务的进展，总是阶段性地去检查，发现问题比较滞后。
如果项目经理缺乏技术背景，监督进展时往往浮于表面，没有深入实际判断是否任务真的进展顺利。
（3）需求变更的影响分析要全面而完备

需求变更时要：

分析对设计、编码、测试用例的影响。
分析对规模、工作量、进度、成本的影响。
分析对客户、开发人员、测试人员、管理人员等的影响。
分析需求变更的相关风险。
（4）需求文档化

需求文档化是需求变更的基础，如果需求不全面、不正确、不详细则在后续的过程中变更的次数会比较频繁。如果需求没有文档，沟通时我们会这样讲：“传说，需求是这样的……”。基于传说中的需求时是不可能让客户顺利验收的。而要做到前面说到的全面、正确、详细，则可能需要加强需求获取、需求描述、需求评审的工作。

（5）收集真实的、有用的度量数据，并得出管理结论

度量数据不在于多，而在于“精”。所谓“精”的含义是指：数据要准，数据要有用，数据要反馈在管理实践中。

用数据说话，用数据说真话。首先要保证数据的正确性与及时性，其次要能够通过这些数据分析出结论，并体现在后续的管理措施中。数据的真实性是很多企业面临的难题，数据不真实，数据的实用性也就无从谈起了。
度量数据的需求来源是管理的需要。从客户、高层经理、项目经理一直到具体的开发人员，各个层次、各个角度的人员都有自己感兴趣的数据，要基于这些人的实际数据需求去度量数据，要自顶而下地基于目标建立度量数据，不要度量无需求的数据。
有的数据要对其进行分析，得出管理结论并定义相关的管理措施，以充分发挥数据的作用。否则，该数据就失去了存在的价值。
（6）建立开发人员实施配置管理的工作习惯

工作产品要及时入库。
工作产品的变更要符合流程，要保留历史痕迹，可回溯。
（7） QA要严格、细致地对项目的活动与工作产品进行检查

在QA方面最常见的问题如下。

检查不全面，有的工作产品或活动没有检查。
检查不细致，不能及时发现产品与流程的不符合问题。
1.4.2 CMMI 2级难点之对策
CMMI 2级难点及对策参见表1-9。

1．建立WBS分解的方法指南，训练项目经理如何进行任务分解，充分识别项目范围。

很多项目经理即使接受了PMP的专业培训，仍然没有掌握WBS分解的方法，正如很多人拿到了驾照不会开车一样，缺乏实际训练。在实施CMMI 2级时，组织级应该定义出WBS分解的方法指南、模板，供项目经理参考，并对项目经理建立的WBS进行多次评审，训练其分解的技能。

2．建立组织级的估算方法指南，教会项目经理如何做估算，为项目的工作量、工期、质量的平衡提供依据。

估算是帮助项目经理进行能力平衡的手段。通过估算工作量、工期、成本等可以平衡能力需求与实际可提供的能力之间的差别，即使不能满足也要知道差别有多大，这种差别是否可以通过加班、加人、裁剪需求等来弥补，不能糊里糊涂地做项目，即使死，也要死地明白。在项目组需要进行估算的时机主要有3个时间点。

（1）需求不明确，需要给客户报价或项目立项时。

（2）需求明确，需要制定项目的开发计划时。

（3）在开发或维护过程中，需求发生变更，需要变更项目计划或给客户承诺变更的完成时间时。

在不同的时机，不同的输入条件下，对于不同类型的任务采用的估算方法不同，不能一概而论。因此项目经理要灵活掌握，组织级要给出明确的指南。

3．教会项目经理使用Project排进度表，合理安排进度，优化资源投入。

排进度表时要定义出任务之间的先后顺序关系，然后识别关键路径，想办法减少关键路径的长度，然后安排资源，再识别出关键链，减少关键链的长度，合理安排缓冲的时间，这样才能保证项目在比较短的时间内完成。如果进度安排不合理，会造成人为地拉长，有人忙工期，有人闲。借助于项目管理的工具可以帮助项目经理识别关键路径，减少安排计划的工作量。万事预则立，不预则废。

建立WBS、项目估算、排进度表是项目经理制定计划的三项基本技能。

4．建立组织级风险库，教会项目经理如何识别风险、管理风险，培养风险意识。

很多项目经理不重视风险的管理，缺少风险管理的意识，这就导致了在项目初期一些可能发生的负面影响没有被识别出来，没有采取预防措施，坏消息没有尽早暴露出来，最终导致项目的延期、质量不过关等。风险列表、风险分类识别、头脑风暴法、阶段驱动法、任务驱动法等是常见的识别风险的方法，简单易行。识别出了风险，无论是否可以解决，都能够帮助项目组成员、项目组的上级领导、客户等清楚地了解项目的状态，即使发生了最坏的结果，相关人员也能够谅解。

5．建立计划评审检查单，计划评审流程，保证计划的合理性与一致性。

计划的好坏可以通过计划评审活动进行检验，通过计划评审可以在各利益相关者之间沟通计划的内容，识别出计划中的缺陷，同时也起到了培训和教育的目的，帮助项目经理提升项目策划的能力，尤其是对于管理刚刚起步的公司，尤其需要注重项目计划评审。

6．建立组织级每日站立会议制度，实时跟踪项目进展。

在CMMI中并没有要求一定要做每日站立会议，这是在敏捷方法中的一条实践，但是该实践简单易行，而且卓有成效，值得推广。通过每日站立会议可以及时了解每位项目组成员的工作进展，沟通项目的状态，同时也起到了建立团队文化的作用。

7．建立周例会的制度，定期评价项目状态。

如果导入了每日站立会议，未必需要开项目组内的周例会。

应该同客户每周至少沟通一次，应该同项目组的主管每周至少沟通一次。

通过周例会的形式建立一种正式的沟通渠道，使利益相关者全面了解项目的状态，发现问题，沟通问题的解决方法。

8．建立经验教训总结制度，固化管理经验教训。

在里程碑达到时、项目结束时，项目组要总结经验教训，组织级EPG固化经验教训。一般每个月或每2个月就应该总结一次经验教训，最长周期不能超过每3个月。固化经验教训是稳步提升管理水平的一个有效措施，是减少推广阻力的有效措施。

9．建立跟踪项目进展、生产率的度量体系，量化了解项目状态。

通过项目进展的度量可以标识项目完成的百分比，能够对项目的进度有一个总体的、量化的了解，以跟踪项目的进展，帮助项目经理管理进度风险。生产率的度量可以为项目的工作量估算、进度估算提供一个参考。这2个度量数据是最基本的项目管理的度量数据。

10．建立瀑布与迭代生命周期模型，根据不同项目的类型分而治之。

在企业内一般都会含有瀑布与迭代两种生命周期模型。瀑布模型适合于需求稳定的小项目，迭代模型适合于需求不稳定的项目。瀑布模型管理比较简单，相对而言迭代模型管理稍微复杂一些。通过定义生命周期模型可以帮助项目经理设计总体的项目管理思路，将大的复杂的项目划分为小的易于管理的阶段或迭代，以降低管理的复杂度。

11．实施SCRUM敏捷的项目管理方法。

在实施CMMI 2级时可以导入Scrum方法，Scrum方法是敏捷项目管理方法，在该方法中定义了4个活动、3个角色、3个工作产品、2个度量元，这个方法简单易行，作为一种项目管理的解决方案，适合于CMMI 2级的企业导入。在实施Scrum时，需要将Scrum的方法在组织内流程化、制度化。

12．培养QA人员，使其成为项目组的过程管理导师。

实施CMMI 2级的企业，首先要有QA人员，通过QA人员监督过程标准的实施，维护公司的质量文化。QA人员首先应该是进行指导，而不仅仅是监督。在项目初期，QA对项目组的管理策略、管理过程、项目计划提供指导，帮助项目组进行合理的管理设计，在项目执行过程中进行纠偏。

13．导入版本管理工具，建立配置管理的机制，控制变更、保持完整性和、一致性。

通过导入SVN、Git、VSS、CC等配置工具将公司的文档、代码等管理起来，能够回溯到任何一个历史的版本，能够确保资料的完整性，这是最基本的管理要求。通过变更控制过程确保文档之间的一致性。

14．需求文档化，建立需求变更的控制机制，减少“根源性”错误，控制渐变的需求。

管理需求变更的前提是需求文档化。需求文档化看似简单，却是很多公司难以做到的。

无论需求是如何获取的，无论需求是如何描述的，需求的变更都要经过客户和开发人员的沟通，都要评估需求变更的影响范围，经过利益相关者的评审，而不是随意变更，所有的变更都应该文档化。

上述的14条实践要求项目组在项目管理中投入基本的工作量，以建立基本的项目管理方法。

1.4.4 CMMI 3级的难点
（1） 需求、设计、代码、测试用例的质量比较差

需求描述不全面、不详细。
设计中错误比较多，遗漏比较多。
设计与实现脱节，实现人员不看设计文档。
代码中隐藏的缺陷比较多，代码的可维护性比较差，其他开发人员难以读懂代码。
测试用例数量太少，对需求、设计的覆盖率比较低。
（2）同行评审无法快速发现问题

缺少同行专家参与评审。
同行专家没有足够的时间准备评审。
（3） 单元测试与代码走查推行不下去

开发人员不愿意改变工作习惯，没有意识到单元测试与代码走查的作用，不愿意做单元测试与代码走查。
项目的工期太紧，无法在单元测试与代码走查投入足够的工作量。
（4） 没有足够多的时间做系统测试

项目组留给系统测试的时间很短，系统没有经过充分的测试就交付给客户。
系统测试不充分，正常、异常、边界情况没有完全测试到。
（5）对组织级的体系裁剪不当

项目组不知道如何根据自己的实际情况裁剪体系，机械执行体系，EPG也没有提供实际的指导。
（6）组织没有建立持续改进的体系

虽然有专人负责过程改进工作，但是经验教训的收集与整理、典型案例的整理、组织级度量数据的分析、新体系的部署、过程改进点的识别没有制度化、经常化，没有在组织级建立持续改进的文化。

1.4.5 CMMI 4级的难点
（1）目标驱动建立过程性能基线与过程性能模型

为什么要建立过程性能模型呢？要通过过程性能模型预测目标的达成，因此应建立过程性能模型与目标之间的映射关系。为什么要建立过程过程性能基线呢？过程性能基线刻画了历史的过程性能的变动范围，目标是基于历史的过程性能确定的。我们需要基于组织的商务目标确定组织的和项目的质量与过程性能目标。基于目标确定应该建立哪些过程性能模型，应该建立哪些过程性能基线，应该收集哪些度量数据。很多组织没有建立符合SMART原则的目标，过程性能基线和过程性能目标也没有和目标紧密相关。

（2）过程性能模型的建立与应用

过程性能模型建立上游过程与下游过程之间的量化关系，或者建立了过程的输入与输出之间的量化关系。过程性能模型表达的不是确定型的函数关系，而是统计关系或概率关系。应该根据目标确定建立哪些过程性能模型。在现实中关于过程性能模型常见的问题如下。

已建立的过程性能模型缺少历史数据。
已有的历史数据无法确定过程性能模型的成立。
过程性能模型的预测效果太差，预测结果对项目组的实际活动缺少指导意义。
项目经理不知道如何使用过程性能模型。
（3）统计过程控制技术的使用

统计过程控制技术应用于软件领域是有争议的。有的专家认为，在软件公司中对于某一个项目而言，可以重复的活动或过程很少，可以采集的数据点很少，难以证明过程的稳定性。因此，对于统计过程控制技术在软件项目中如何应用，采用哪种具体的技术需要仔细甄别，并注意应用正确的SPC技术。

（4）预防措施的选择与制定

从哪些现象入手进行分析？如何通过现象发现本质？如何通过量化的数据证明分析结论的正确性？如何通过量化的数据证明措施的有效性？这些问题的回答需要分析问题制定预防措施的人员具备应用统计学的基本知识，熟悉方差分析、假设检验、回归分析等手段。

（5）度量数据的支持

软件企业的管理达到CMMI 4级是管理水平的一个质变。依赖于度量数据可以实现开发过程的SPC，可以预测过程的性能，可以控制过程目标的达成。此时的管理水平和传统硬件生产企业的管理水平近似相同，适合于重复生产型制造流程的各种手段都可以在这种创新型开发流程中得到使用。真正做到了数字说话的程度，而数字的准确性、结果的可预测性取决于管理流程的可重复性、稳定性。但是大部分企业在度量体系的构造、度量体系的执行、度量数据的分析上存在大量的问题，并导致数据没有用途、数据不准、数据无法分析出结论等现象。

1.4.6 为什么难以达到高成熟度
很多朋友认为CMMI4～5级难做的原因是度量做得不好，我认为那只是表象，最根本的原因还是过程不稳定，2～3级的过程就没有做好。过程不稳定，反映在数据上就不稳定，MA可以做得很好，但是MA的结果可能没有管理的参考价值，建立的模型就没有意义。比如：

我们可以很准确地度量身高、体重、年龄、每天的饭量、每天饭食里葡萄糖的含量、智商。我们希望建一个模型来预测智商，假如根据上述信息建立了一个模型：

智商=f（身高，体重，饭量，年龄，葡萄糖摄入量）。

假如这个模型有统计意义，各x和y之间有因果关系，但是将你的信息输入到这个模型中，预测出来你的智商在60～140之间，你认为这个模型有实际的作用吗？不用量化预测我们凭经验都能认为你的智商基本上是在这个区间内，所以这样的量化预测有啥意义？假如模型能够预测你的智商在91到103之间，那我们认为这个模型还是很有意义的。为什么呢？因为预测得比较准确，变动的范围很窄，凭经验不能预测得那么准。可惜的是，现实中很多公司的过程性能模型预测出来都是在60～140之间，所以模型没有实际意义。根本原因在哪里呢？不是数据不准确，不是建模的方法不对，而是过程本身就不稳定，基于不稳定过程的输出数据进行建模，进行预测，预测的结果也不稳定。

正如你是一个业余射击选手，我们建一个模型预测本次打靶你能打几环，预测的结果就难有意义，业余选手的过程不稳定，难以预测。如果你是一个职业选手，我们建一个模型预测本次打靶你能打几环，就会比较准确，职业选手的过程稳定，就好预测。

这便是高成熟度级难做的本质原因！2、3级过程稳定了，高成熟度自然好做！

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。

分享