组织成熟度：影响生产力的“大象”

内容来源：本文选自《工程效能十日谈》第20章

• 不成熟、无纪律的开发实践会严重影响到生产力。

• 在组织的开发实践中进行逐步的改进，可以极大地提高生产力。·

组织的软件开发环境成熟度会影响开发人员及团队的生产力，所以，组织属性的度量应纳入成本、进度和质量的估算考虑中。

过程成熟度框架在过去30年中不断发展，但基本结构一直保持不变。

缺失开发流程的组织，压力驱动下的项目经常依赖于开发人员没日没夜地努力工作来满足荒谬的时间表，在项目承诺和基线不稳定状态下，开发人员疲于奔命、犯错误并且几乎没有时间纠正错误。 

尽管大多数项目中，项目经理或团队负责人在项目计划和管理控制中定义项目开发过程和工作环境，并且通过建立基线和变更控制流程来管理需求变更和项目交付物。但是，当发生不可避免的需求或项目变化时，每个项目需采取必要措施，重新制定计划做出承诺。当高层管理人员或客户提出无法实现的期望时，管理人员和团队负责人会说“不”或通过外交方式来商讨变更和可实现的承诺。 

标准化流程和度量一旦在项目中实施，项目就可以使用更精细化的流程和措施来管理整个开发周期中的过程实践及产品质量。CMM 4级通过精细化度量分析，指导持续改进过程性能，预测可能发生的问题并尽早采取措施进行调整，以减少项目产出的偏差，提升项目绩效。标准开发流程为其他生产力的提高（例如组件重用和精益实践）也奠定了基础。

流程通过持续优化即使发挥出了全部的功能，也可能无法达到竞争环境或苛刻要求下所要求达到的生产力和质量水平。因此，组织必须识别和评估相关创新技术、流程和文化等方面的实践，持续提升生产力和质量成果，超越现有绩效水平。

理论上，敏捷方法在迭代冲刺开始时通过冻结一定数量的故事来解决CMM 一级中的承诺问题，即：新的故事只能在后续迭代计划中增加。所以，当市场或业务部门要求在迭代过程中增加新的故事时，开发人员会产生抱怨并感到不安。这些在迭代内的额外工作增加会引发同样的返工进度压力，这种压力也困扰着低成熟度瀑布项目。

Scrum方法的联合创始人苏瑟兰(Jeff Sutherland)说，他所拜访的企业中有多达70%在执行Scrum。他们说：“我们正在做Scrum，但我们不做日常构建，我们不做日常站会，我们不做……”正如他所观察到的，他们显然没有在做Scrum。当一个组织的开发团队严格执行时，Scrum以及其他敏捷或DevOps可以提供具有CMMI三级特点的标准化流程好处。

但是，当敏捷方法缺乏纪律性时，开发团队将面临CMMI 1级的典型问题，即：基线和承诺不受控制。而且，凑合执行的开发实践会降低他们的生产力。

2015年，美国住房市场的抵押贷款提供商房利美(Fannie Mae)在其整个IT组织中发起了一次纪律严明的敏捷-DevOps转型。转型包括以短周期迭代替代传统瀑布式流程，安装具有持续集成和分析能力的DevOps工具链。采用自动化功能点法[插图]每单位时间内交付功能点数度量生产力，并对其进行跟踪监控，评估实践效果。

在整个组织范围实施转型后，房利美发现，应用程序中的缺陷密度通常都降低了30%～48%。生产力提升的影响转化通过整理多轮迭代数据进行了统计分析，这些迭代的总持续时间和投入与瀑布的发布周期（基线）基本相当，当团队转为短周期迭代开发方法时，最初的迭代通常情况下效率相对会较低，但连续多个迭代结果数据综合与瀑布基线相比，生产力平均提高了28%。

虽然开发方法会随着时间而发展，但许多影响效率的问题在几代人之间都是相似的。所以，稳定-标准化-优化-创新的成熟度进化模型提供了一种提高生产力的方法，而这种方法同样适用于敏捷DevOps转型实施。

乔梁老师开课啦~视频课程《持续部署实战解析（NodeJS版）》， 限时特价！

（扫码订阅）