应用了DevOps就是研发效能管理，没有这么简单

对于DevOps支撑平台当前业界主流的一个说法叫研发效能管理平台，从这个叫法上也可以看到是将敏捷研发管理和CI/CD集成的一个基础能力平台。

而这个平台的目标就是希望提升研发效能。

这个就容易给大家造成一个误解，应用了DevOps就能够彻底了提升研发效能。但是实际的问题并没有这么简单。也又回到了常说的思维技能和工具方法之间的关系上面。

任何工具层面的内容都仅仅是一种效率提升手段，真正的效能提升重点仍然应该是在研发过程管理能力和开发人员能力培养上面。

当前的研发管理工具，CI/CD支撑工具更多的是将已有的研发过程管理思想进行固化和自动化，不管是偏重的CMMI方法论还是当前主流的Scrum敏捷方法论，工具的目标都是将这些方法论里面涉及到的研发项目管理，需求管理，配置管理，QA和QC，发布和运维等管理内容进一步的固化和自动化掉，让研发人员重心真正专注到核心业务需求实现上面。

因此在早期的CMMI过程实施过程中，其实核心目标也是提升研发管理效能，CMMI的核心思路你可以理解为通过MA度量过程持续的采集数据和分析数据，形成相关的估算基准，同时有形成组织级的过程能力基线。

那么到了DevOps阶段一个大的转变就是通过Scrum敏捷研发和CI/CD支撑过程工具的实施，将软件研发生命周期中辅助性工作全部自动化掉，同时还自动的采集各种研发性能基准数据，并基于数据分析进行研发过程持续改进。

其体现的两个重点即：过程数据自动采集+短周期快速迭代改进。

也就是DevOps实现整个自动化流水线并不是重点，如果是个人或小团队，你可能通过Jekins，GitOps等可以快速的实现这么一个自动化交付流水线。

真正的重点反而是整个研发过程和CI/CD是如何集成的，同时通过这种集成来完成关键度量数据的采集和分析，这个分析最终的目标是不断的改进最终的软件交付质量和交付效率。

这个点对于实施DevOps的相当重要。

由于DevOps自动化流水线可以实现高频率的自动化运行，包括做到按代码变动实时自动化触发，这就导致很多企业在使用的时候每天都不停的再集成构建，不断的再进行新增和变更功能的发布和交付。

• 需求有变化了无所谓，反正修改后自动化再发布一次。
• 有Bug了无所谓，修复后构建交付一次
• 需求和版本规划无所谓，不需要提前规划
• 软件产品不断的发布，不断的打补丁修复

我上面谈到的几点往往在各类互联网SaaS应用很常见，一些应用可能每天都在发布新版本，随时都在修复Bug。但是企业类的应用开发不应该如此，任何企业内IT应用即使再业务敏捷也没有到当天提的需求当天就需要马上发布的紧急程度。

我说这点的重点还是想表面，即使研发过程自动化了，对于基于需求驱动的整个研发过程管理规范流程，基于需求的版本规划，迭代计划，计划监控执行等工作仍然相当重要。任何一个软件项目的持续交付和发布，仍然要有产品规划，有版本规划和短周期迭代计划。

要做到这点类似PMS研发项目管理平台，基于Scrum的研发协同平台和DevOps里面的CI/CD持续集成和部署能力的集成和融合就相当重要。做DevOps实践研发过程管理+CI/CD这两个点必须具备，对于自动化测试反而不是说一开始必须具备的内容。

简单来说就是：

不要通过DevOps过程和工具的使用，自动化技术来掩盖你研发过程管理不规范，研发人员技能不足的问题，DevOps本身思想也不是为这两个事情服务的。DevOps的实施最终目标是辅助你去改进你的研发过程和研发能力，如何辅助？就是不断的提供相关的参考数据给你，让你去分析并制定行动计划。

举例来说

当你通过DevOps过程度量数据发现了CI/CD过程相当频繁，那么就要分析原因，究竟是需求频繁变动导致的，还是说开发人员开发完成功能Bug太多导致的，还是说设计阶段有些关键的架构和接口设计不清楚导致的。

这些东西必须要搞清楚，是需求的问题就要去提升需求分析和需求开发能力，是开发的人员就需要提升开发人员技能，是架构设计过程缺失就需要重新规划哪些必须在开发前完成并进行架构评审确认后才能够进入编码阶段。

所有上面的问题点都不是应用了DevOps工具链能够解决的，DevOps只是采集了数据辅助你去分析和改进，符合当前数字化下主流的数据驱动业务运作，数据驱动改进的思路。

对于DevOps下的度量管理，后面再专门写一篇文章进行详细说明。