CMMI V2.0改善软件开发质量案例

CMMI V2.0模型比以前1.3版本简化，更适合用于敏捷迭代项目。这经验分享分3部分：

1. 项目概述 - 背景与目标，主要事件时序
2. 工具/方法+培训+评估 --- 针对问题的原因分析与改进措施
3. 总结

1、项目概述

背景

我们的客户公司是IT软件企业，员工超过8,000，其中八成以上都与研发相关。
为了可以实际帮助企业提升，我们结合了量化敏捷开发与CMMI V2.0模型，对开发团队进行为期9个月的培训、辅导与评估服务：我们客户的客户群对软件产品的质量要求特别高，市场压力也很大，需要尽快依据新的市场需求1-2周就发版，所以他们希望CMMI能带来帮助。

管理层对改进的期望

管理层对过程改进的支持很重要，因此必须在开始就让他们了解和参与。启动前我们和事业部、部门经理交流，了解他们对过程改进的期望，同时解读我们能够给他们带来的好处——帮助加强管理。而且在项目执行过程中，每完成一阶段，便向客户方高层汇报进展和收获，让他们知道CMMI不只针对技术/软件开发， 更重视对公司带来什么价值。

制定计划 - 确保有足够（内部）资源参与

基线与预测模型是CMMI高成熟度的关键要素，需要有足够数据，才能够开始统计分析。
这次评估都挑选敏捷快速迭代项目，两周左右就能够收集到一轮数据。三个月一个项目就可以贡献六轮数据， 五个项目差不多可以产生30组数据，比传统瀑布式开发快多了。
评估项目启动初期就定好全年的计划，里程碑包括预评与正评的计划时间，以把握好项目的节奏。
除了我们老师的投入外，公司也要安排专门的人来负责这个项目，例如刚才说的定期数据收集、数据分析就需要公司内部人员负责。V2.0注重评估前的策划与准备，所以一开始的总计划与人员安排是否到位很关键。要项目组把学到的东西用于项目中，除了给予充足的时间外，项目组各方面的能力是否充分也很重要。

从启动到正式评估

做完模型培训与需求/估算方法的培训后，便要参与评估的所有项目，按学到的方法立马用于项目中。 每月都有一到两次的现场辅导，解决项目组实际遇到的问题。

并最终评估还需要看每个项目的具体证据，所以也要求项目组在我们提供的Wiki服务器上写故事。利用截图加上描述，说明如何满足每一条模型的实践。

正式评估之前进行预评估，每个过程都抽看两个项目， 覆盖所有参评项目。 项目组依据评估的发现， 继续改进，最终做正式评估。

根据美国要求，V 2.0正式评估的项目是随机抽样，正是如此，本来在预评估最优秀的项目组都没有被抽到，所以公司的过程改进小组在正式评估前，也花精力辅导参评项目如何准备，抽样的好处可以让本来参与度不高的项目也不得不多参与，从中获得改进。

项目经理与大家分享/汇报

客户完成了CMMI V2.0的5级评估后，举办项目团队评估后总结会，安排了其中的3个项目团队汇报他们在过去半年，如何利用所学到的方法达到CMMI5级评估要求。 非常高兴地看到他们已经掌握了我们老师所培训的技能——利用模板从需求自动计算功能点，然后从功能点估算出项目工作量、测试用例数，再利用CCI（后面会详细说明)小工具衡量代码质量，并且预估最终的缺陷密度等。
3位项目经理每人都针对以上内容发表了的1小时的演讲，分享项目团队如何把学到的东西用于项目中，配合度量数据，取得具体的质量提升，并且达到CMMI V2.0的5级评估要求。

这些项目经理都非常忙，每天可能工作到晚上十点/十一点；如果没有CMMI五级评估驱动，很难在短短几个月时间内达到这效果。 其他项目组也因为听到试点项目有改进效果，虽然年底很忙也专门抽空过来听。
过程改进要有效，离不开3个方面的相互配合：培训+评估+自动化工具。

  

下面我们针对培训、 根因分析、工具、评估的作用详细说明：

2、工具/方法+培训+评估

简化功能点让项目间可比

没有度量，便没有管理。
虽然公司一直很注重产品质量和客户的满意度，每年都做调查，并用度量统计数据来监控，但缺乏项目规模大小的衡量标准，导致不少部门/项目组对衡量项目质量的KPI 有争议。
也因缺乏规模的衡量，导致对编码效率和质量都没有客观的度量标准。
90年代大部分项目还是采用瀑布式开发，现在是反过来，大部分是敏捷开发；那年代还是主要用代码行数(LOC)来估算规模，现在因每个迭代都两周左右，因周期短，可利用简化功能点估算规模。
问：“我们有些指标用故事点作为分母（规模），用故事点来估算也可以吗？”
我说：“故事点只是每个项目组自己规定，无法与其他项目作比较。”
所以我们首先辅导项目组如何简单用模板写需求，然后自动从需求文档（使用固定格式）来估算功能点数。（见附1）

 

用功能点做规模估算的另一好处是能够让软件开发可以客观进行内部报价:软件开发最大的成本是人力，但如果只依据实际所花工时计算,客户或公司销售会嫌贵，认为是你们开发生产率低才要花这么多工时。 如果按照软件需求，算出功能点来结算就没有这争议。

辅导+学习平台

• 不少领导层认为培训浪费资源——很多时候培训虽然令学员学到一些知识，但是往往没有在项目中真正用起来，很快就会被遗忘。针对这些问题，我们老师在开头就对大家进行集中培训（2天），教授如何用新方法（功能点等）写需求，指导大家在项目中使用。大概3周后，再到现场辅导，解答他们在使用过程中出现的问题，这样经过2-3轮后，项目组基本都能掌握所学到的知识。
• 因为项目组人数较多，不一定全都有空参加现场的培训课，我们把一些主要的内容录制下来，放在Wiki服务器，让他们可以随时观看。Wiki服务器除了提供参考资料，培训教材，培训视频等资源外，更重要是让项目组就可以在平台上分享故事，除了为评估做准备，也方便公司累积过程经验。

利用数据与根本原因分析改善软件质量

单靠统计数据本身是不会带来提升。人与机器不同，如定期收到反馈，并觉得可以影响到结果，便会有动力改进。
所以重要的是辅导项目组进行每轮冲刺/迭代后的回顾，利用统计数据找出根本原因，制定针对性的改进措施。

用功能点作为分母，各项目每个迭代都可收集缺陷密度（系统缺陷数/功能点数），可以项目与项目之间做比较。
项目经理既可以看到自己项目的表现，也可以和其它项目进行比较。
组织级可以建立公司缺陷基线（标杆），以便进行跨项目的根本原因分析与改进。
尤其是客户公司现状是业务扩张迅速，开发员工有限，很多面对客户的项目的开发人员水平难以保证， 影响项目质量。
例如，我们收集了两轮数据，发现某项目系统测试与验收的缺陷特别多。 于是我们和整个项目团队一起复盘，希望找出系统测试发现的缺陷主要来自那些过程。 发现绝大部分都是编码的问题，其次是对需求的误解：
我与咨询老师一起看了项目部分代码，发现很多问题 —— 例如：重复代码、不良分支 、方法/类很长等等。而且这项目的代码消耗率（代码行数 / 功能点数）也特别高。
我们便教他们应如何避免这些代码问题， 并建议开发人员尽力重写有问题的代码——代码重构。

问：可否不做代码重构？ 答：重构是用于减少“技术债务”，降低日后因需求变更导致本来可避免的返工。例如有时编程人员为了省事，通过拷贝代码来实现新功能，导致多处重复代码，这样会导致当后面要做任何修改的话，都要同时修改好几个地方。 若代码重构好，就不会出现这种烂代码，后面要增加功能就简单多了。

不同的编程人员经验/能力不同，开发出来的编码差异很大。 同样一个功能，好的代码设计，日后变更/增加功能应很方便，但不良代码就不然。
经过这样的改进后，后面迭代的系统缺陷率有明显改善，初步验证两者是相关。
但每次都靠人工来评审代码工作量很大，于是老师写了自动检测代码的小程序（CCI代码混沌指数）（详见附2），帮助统计这些代码问题的数量 ，公司过程改进组将之进行推广，我们老师除了现场培训外，也录了培训视频和提供使用说明文件，告诉团队写代码的注意事项，避免出现这些不良代码。

改进措施

要求各项目除了SONAR 扫描外，也要做CCI代码检测。
辅导过程改进组与项目经理更新代码规范与评审检查单，要求收编码人员也必须要把这些总体的问题改好。
经过几轮迭代之后，系统缺陷密度有显著下降：

这就验证了CCI 指数，确实跟缺陷密度有显著相关性。
收集了几轮项目数据后，我们开始发掘项目的系统测试缺陷密度与什么可控因子相关？发现CCI系数跟代码的质量相关。

归一化缺陷密度:依据迭代测试密度（测试用例数/功能点）把缺陷密度调整到测试密度=1.2 水平，以便项目间可比。
一个缺陷如果是在系统测试时才暴露，可能要花上几个人天才能修复好，但如果这个缺陷在前期设计编码阶段已经被发现，大多数半个小时一个小时就改好，所以我们利用了CCI检查便可以预先暴露代码的缺陷，减少后面的返工，也同时提升了生产率。

从事后回顾到事前预测

虽然公司一直收集很多度量数据，但全都是度量最终结果，缺乏过程中可控因子的度量。
在评估总结时，我便利用归一化缺陷密度与CCI指数的关系向管理层解释度量可控因子的重要性：“以往我们只是衡量最后的结果，所以项目组只知道产品质量不行，但不知道如何改进，从那方面入手。CCI便是可控因子的实例，让开发人员知道代码有毛病，重视代码重构，不用等到系统测试被发现缺陷才知道。有了可控因子与结果的关系，便可以靠控制过程中的可控因素来预估结果，这也是CMMI很重要的概念。”
客户表示赞同，并把CCI纳入为项目质量KPI。

CMMI评估的作用

改变习惯很难很难。
我在总结会上听3位项目经理自豪地分享他们的收获——按学到的方法确实达到CMMI 5级水平，便体会到CMMI评估与培训确实可促进团队改进。
要顺利通过CMMI评估，项目组不仅需要提供数据，也需要参加访谈，把项目的故事讲出来。
为了确保项目组没有误解，我们在wiki服务器上，除了提供模型、Q&A问答、视频外，也要求每个项目组按模型的每一条实践，写出是如何在项目组体现。 让项目组不仅仅知道要怎么做，也了解为什么。
因Wiki服务器是个交互平台，公司每个人都可以随时访问，所以评估组和我可以随时了解到他们对CMMI实践的理解是否有错误。

3、总结

CMMI 过程改进的成功要素：
1.时间 如果公司希望借用CMMI确实做到一些具体的改进，因为要足够的时间来累积数据，整个项目时间不能太短，比如小于6个月就很难达到改进效果。
2.计划 一开始就要做好计划，企业要有过程改进组人员的投入，包括负责度量与分析。而且还要有合适的工具，单靠手工很难收集真正的项目数据。
3.方法 培训不仅仅是教CMMI模型，更重要是有一些具体的方法、模板、工具，可以让项目组立马用起来。项目实战辅导很关键，听得懂并不一定会用，老师的实战辅导才能真正将方法落地。
4.使用功能点估算项目规模使项目间可比 直接从需求估算功能点数，让不同项目的度量数据可比，不然无法建立公司基线。
5.预测模型 不仅衡量结果，也要度量过程中的可控因子。例如扫描代码，尽早暴露问题，不用等到系统测试才发现缺陷，减少返工。
6.工具与平台 尽量用工具取代人手工作，除了上面的扫描工具，我们还提供了从需求计算功能点数的模板工具等。
平台（如Wiki）方便团队做分享。
7.高层的支持 高层与事业部领导的支持非常重要，可以想象如果他们不认同这些对企业长远的帮助，很难要求他们投入这么多人力资源在这个项目中。 如果领导不关心，很可能评估过后便回复到改进前的状态，不能持续。

及时沟通也很重要 相关干系人之间的沟通举足轻重，例如培训后技术团队有疑问，最好的方式是直接在群里和老师沟通，而不是都要经主管转达。 所有干系人都要定期监控项目进展，有任何问题，要及时交流沟通，避免延误。 例如某个项目，培训后过了好几周时间都没有收集到数据，老师与相关干系人多次远程沟通，了解原因是测试人员不足，导致无法完成收集迭代数据，大家讨论出解决办法，后面便恢复正常。

 

附1:我们如何帮助公司做量化敏捷开发

针对很多敏捷方法都缺乏度量的弱点，我们三年前已经开始推动量化敏捷一体化方案： 从需求开始，估算功能点数，工作量，策划，看板，测试等，配合标准课程与模板，让项目可以：

• 把需求/策划/编码/看板监控/测试 都“打通“
• 利用简单模板记录各项目每冲刺的度量数据
• 而且自动生成度量，让公司/项目组可实时知道快速/持续交付，质量保证的状况
• 也建基线，预测模型，满足 CMMI V2.0 5级要求

利用模板，从需求估算功能点数：

技术管理（编码水平，早期缺陷预防)

1. 利用“编码有效率”追踪编码的整体技术水平趋势
2. 使用交叉验证保证信息的正确性

技术管理（缺陷密度，测试覆盖率)

1. 利用“每功能点缺陷密度”度量缺陷率的趋势
2. 利用“每功能点测试用例数”交叉验证

附2:CCI代码混沌指数

“与Sonar等静态扫描工具关注语法细节不同的是,CCI代码混沌指数聚焦于代码的宏观结构化问题,可以通过降低CCI数值,提升软件可维护性和质量。”
CCI 指数主要度量不良代码的一些常见问题，如：

• OverLengthClassIndex 超长类指数
• BadBranchIndex 不良分支指数

CCI目的：以上问题都在Martin FOWLER 的经典书《代码重构(Refactoring)》中第3章"Bad smells in Code"有详细说明 ，但很多编码人员不注意或不觉得是问题。
CCI相当于用了更通俗易懂的方法来改善这本书提到的问题。首先让他们意识到代码里哪个地方烂，不需要说这种烂叫什么专业术语，而要求他们直接想办法把它干掉就好了。