去年下半年，有幸领导了一场目前全球规模最大的CMMI 2.0试点评估。按2.0评估方法草案从头到尾过了一遍，对如何做真正有价值的CMMI评估有了新的认识和体会。评估结束后也给研究院提交了一份详细的反馈及2.0评估方法改进建议，这里把评估心得重新整理和大家做个分享。
试点评估回顾
2017年初，招行总行信息技术部希望年底前完成CMMI开发模型的三级评估。由于我当初主导他们第一次的三级评估，后面去也陆续做过一些培训和咨询，所以对他们的情况还算了解，以为就是一个通常形式的复评。
勇于创新、关注客户体验的招商银行
初步沟通以后，才发现招行这次是放大招。负责IT的招行行长对本次复评的期望值是：不刻意做评估准备，覆盖所有项目，通过评估找出软件开发中的风险隐患，给出一个客观评价，并为后续改进提出可操作的指导建议。这信息技术部一年大大小小有好几百个项目，内部的评估准备工作量更是大的可怕，就算我和评估小组天天泡在招行里，年底完成这样一个评估可能性基本是零。
用SCAMPI A 1.3方法评估，满足行长要求实属不易，虽然我貌似有些思路，但实际可操性并不好。五月初，我参加研究院的年会，分享了天网模型实践。恰好研究院也在收集CMMI 2.0评估方法的反馈，听了2.0团队Alex的介绍后，我觉得新的方法和招行的需求太合拍了，其随机选样的核心做法可以解决评估范围超大的问题。而其鼓励不刻意准备，避免花瓶项目评估的要求正是行长要的东西。
会议休息时，我和Alex就2.0的一些做法做了深入探讨，提到招行不走寻常路的评估需求，而研究院恰好也在寻找大规模组织的2.0试点评估，简直一拍即合啊！当天我和招行同事联系上，他们毫不犹豫同意做一次2.0评估试点。直到今天我还是很佩服招行的勇气，不刻意准备，将自己所有团队的开发过程展示给研究院，还真不是谁都敢做的。
我建议招行把100%项目覆盖，改成100%团队覆盖，最终范围包含了近百个团队。组织级则重点检查招行近几年在精益看板、敏捷、DevOps等方面的改进实践。长话短说，我们六月底建立了评估组，七月完成了2.0方法培训及一些内部准备（本次评估没有使用PIID表），八月制定了四个mini team的详细工作计划以及整个team的大计划。研究院随机（据说是MIT专家帮助写的程序）从所提交的近百个项目中选了一些参评项目，以及对应的过程域，在此基础上，我们又根据不同项目类别的特点，选择了剩余项目的过程域。
评估现场阶段到11月中结束，一共历时3个月。在这个期间各miniteam分几次去深圳和杭州，根据所分配的项目及对应的过程域，直接在项目使用的服务器上看文档并和团队的过程执行者沟通。在这个过程中，记录下潜在的问题，优秀实践及一些可操作的建议。
整个评估团队在11月中一起完成了现场的最后阶段工作，后面和研究院就试点情况做了充分的沟通，并提交了比较全面的对2.0评估方法的反馈。评估一个月后，又向负责IT的行长和CTO做了全面汇报，还算完美的完成了试点评估。
新的评估方法的改进点
- 随机将小部分过程域（实践域）和参评项目对应，让大规模全覆盖评估变得可行。之前我评估最多的项目是15个。
- 新的方法避免了之前常见的花瓶项目评估，减少了大量低价值的评估“准备”工作，可以让Sponsor全面、准确的了解组织开发过程中的问题、机会、有效实践，公司大佬会对评估结果更有信心。
- 在评估过程中紧紧抓住实践的意图目的（Intent）和组织场景结合，让评估组和访谈人员有了共同语言易于沟通，便于识别出问题的根因，使得建议更有针对性。
- Mini team在和项目组沟通时，做弱项问题的确认，这有助于评估组理解问题的背景，给出更有价值的建议，同时有助于被评估组织对改进的认知。
- 新的评估方法和2.0模型价值驱动的原则高度一致，应用得当可以更好地完成高价值的评估。
2.0评估方法的一些不足
- 随机为选中的参评项目选择过程域（实践域），会导致一些不合理的匹配。如对某类项目来讲，一些不重要的过程域会被选中，而真正重要的可能会被忽略。
- 由于每个项目只对应少数几个过程域，这就有可能对所发现弱项的根因分析造成困难。因为很有可能弱项体现在一个地方（实践域），而造成的原因在另一个地方（未被选中的实践域）。在试点评估中，我们要求分析弱项根因时不受所选模型范围的限制。
- 新的评估方法需要评估组更多的去“发现”而不是去“确认”，这就要求其成员具备必要的能力：如真正理解实践的意图，真正理解被评估组织的具体特点，具备模型之外的工程、管理、改进等技能。这些要求在草案中不够明确。
一些改进建议 （研究院下半年才会发布2.0的评估方法，他们会继续收集改进意见）
- 根据评估规模，采取不同的随机取样方法，使之更加合理合法。
- 在确定评估组成员条件时，也许可以明确mini team的最低要求。
- 根据每个Subgroup中的项目特点，确定实践域的最大范围，据此随机选择。
- 允许被评估组织在收到研究院确定的评估范围后，根据情况做些合理调整，提高针对性及评估价值。
- 给出操作性强的Benchmark/Sustainment评估指南，平衡好“评估准备”和“随机抽查”。
- 改进Performance Report的形式，支持各类不同的组织。
虽然招行这个案例不具备广泛的代表性，但不论从使用CMMI改进过程、引入新的开发模式，还是做有价值的评估，它给中国软件组织如何将CMMI应用价值最大化提供了一些宝贵经验。随着2.0时代的到来，让我们把评估从仅仅关注级别，转向为被评估组织后续几年的过程能力提升提供一个清晰的、可操作、适用的改进路径图。让CMMI评估给组织带来了真正的价值！
推荐阅读
1. 列车飞驰，键盘狂敲 （“知行合一：价值驱动的敏捷和精益开发”介绍）
2. 揭开CMMI2.0的面纱
3. CMMI三十年
4. CMMI 2.0开发模型培训的四个变化
