从DevOps到研发效能管理不要期望自动化来解决工程域的缺陷

　　在前面谈DevOps的文章中，我更多的都是从CI/CD持续集成和交付，自动化测试，基于Scrum敏捷研发管理的思路在谈。或者进一步探讨如何与微服务，容器云融合，构建完整的云原生解决方案。
　　而现在基于开源工具链整合的DevOps支撑平台，当前市场主流的叫法已经是研发效能管理平台，即希望通过DevOps工具实施来提升整个研发效能。
　　所以今天准备写篇文章来进一步谈下DevOps和研发效能平台的关系。
　　研发效能和敏捷之间的矛盾
　　首先看下什么是研发效能，简单总结就是多块好省。
　　用最少的钱，最少的研发资源投入，在最短的时间开发出一个高质量的软件系统。既满足了生产率高，又满足了高质量的要求。
　　那么可以想象下你在开发这个软件的时候一定会用最稳定和成熟的技术，最简单的框架来进行开发，如果软件系统小往往是微服务拆分都不要做，一个人完成往往效率才是最高的，极大的减少了沟通和协同成本。
　　因此在这种情况下敏捷性的需求往往并不会作为重点去考虑。
　　而敏捷往往考虑的是如何适应变化，如何保留软件系统架构的可扩展性，这个扩展性既包括了IT基础设施资源的扩展性，也包括了软件代码本身的扩展能力。同时敏捷还需要考虑对后续软件变更的友好性，能够适应后续变更的快速迭代。
　　当你去考虑这些内容的时候，实际可以看到研发效能本身是降低的。但是敏捷和扩展性需求往往又是必要条件。也正是这个原因，我们需要在研发效能和敏捷之间达到一种均衡，同时充分利用敏捷和精益的思想，减少浪费，减少等待时间，减少返工。
　　DevOps能够解决什么问题？
　　原来我谈到过，如果一个小业务系统，也没有分微服务。那么对这个业务系统进行编译，构建，打包部署的时间完全是可控的。也就是即使没有采用任何CI/CD工具，或者DevOps平台，这块的时间完全可控，不会成为整个流水线作业瓶颈。
　　而在实施IT架构转型和微服务化后，你会发现传统单体已经拆分为多个微服务模块，而且还需要部署和托管到容器上运行，这个时候CI/CD持续集成和部署的工作量急剧增加。那么将这些工作通过流水线自动化完成就是必然。
　　所以DevOps首先解决的是整个集成和交付过程的自动化过程。通过该过程将开发人员从常规的构建，打包，部署等工作中解脱出来。
　　那么整个研发生命周期，本身包括了需求，设计，编码，测试，部署各个工程领域。而这些工程域里面最可能进一步自动化的只有测试，所以DevOps当前成熟度模型中也将自动化测试，QA/QC的安全检查，代码静态检查全部纳入。希望先将测试内容自动化掉。
　　减少浪费和等待时间。
　　一个是减少上游朝下游的工件交付时间等待，一个就是减少各个岗位角色之间的无效沟通。传统研发协同中，有些沟通是无效的。比如测试人员会去问开发者，这个功能开发完成没有，是否可以测试的？这些都是无效的沟通。
　　这些无效沟通我们也希望通过敏捷研发管理工具和DevOps过程协同来解决。各个岗位角色你只需要关注你的看板，关注todoList，有你要处理的任务自然在看板就能看到。这种自动化协同可以大大降低沟通成本。
　　从过程域到工程域的改进
　　研发效能的提升实际包括了过程支撑域和工程域，比如前面谈到的自动化CI/CD，敏捷研发属于过程域的内容。而对于需求，设计，编码，测试则属于工程域的内容。
　　虽然测试工作部分可以自动化。但是大量工程领域的工作实际无法自动化完成。
　　因此DevOps虽然有助于研发效能提升，但是真正研发效能提升的核心并不在于DevOps，而在于研发团队工程域研发技能提升。
　　比如需求开发技能，架构设计技能，编码技能等。
　　研发效能提升要减少浪费，减少返工，那么对于每一个阶段工件输出的质量就必须高标准，高要求，尽量因此把事情做对，而不是大量返工去修复，形成坏质量成本。
　　比如一个IT架构微服务化改造，你一开始整个微服务划分就不合理，API接口设计不合理，那么导致的将是后续开发，集成复杂度成倍增加。这个时候即使你用再好的自动化集成工具也没法避免你架构阶段犯的错误。整个研发效能也无法提升。
　　因此研发效能的根本还是需求-设计-编码这条工程线的效能和质量提升。
　　需求先要和用户描述清楚，沟通确认清楚，建设后续的需求变更。架构设计要把握好新技术和团队技能之间的平衡，做好模块划分和接口设计。编码要加强编码技能提升，编码规范化培训等。
　　这些才是研发效能之根本。
　　即使在早期我们实施Scrum敏捷研发过程改进的时候，一般最多也就是一天部署构建一次，2周发布一次版本，紧急变更也需要1周时间发布。
　　但是在DevOps推广实施过程中，我们往往在宣传通过CI/CD自动化，我们可以做到随时随地的编译构建和部署交付，这个频度可以足够端，甚至也看到有些团队真正的是每1,2个小时就在做一次完整的CI/CD和部署流程。
　　当看到这里的时候，我个人感觉是DevOps一些敏捷和自动化思想被滥用了。
　　也就是说研发效能提升，你在治标而不是治本，由于你需求分析不完善，架构设计考虑不周，导致了后续频繁地变更，而这些频繁紧急变更本身需要快速自动化的持续集成交付。看起来DevOps工具实施好像帮你解决了问题，但是问题本质是在你本身工程域的质量出现大问题，你不是去解决工程域质量，而是希望加快构建发布频率来解决问题，这个本身就是一个错误的做法。
　　包括对于远行科技我们自己的云原生和DevOps解决方案，我始终在强调在工具链支撑平台上面，更加重要的是敏捷研发实践。但是这个实践本身也仅仅可以解决过程支撑层面的问题，并没有解决核心的工程域问题。
　　即如何去提升整个研发团队的技能和能力。
　　有两个工厂同样生产一种笔记本电脑，都有各自自动化的生产流水线，但是A工厂本身原材料质量就好，流水线相关的工艺路线设计也合理，各个流水线之间干扰也少，最终自动化检验和人工抽验过程也设计完善。但是B工厂以上所有内容都没有做。
　　那么同样两个工厂，同样都有自动化的流水线，最终生产出来的产品质量差异巨大。你不能说是流水线和机床本身又问题，而是应该考虑你的过程问题，你的工程域能力问题。
　　所以我再修正下我原来的一个观点，即：
　　DevOps的推进不是简单的应用一套支撑平台或工具，而是一个覆盖项目管理，过程域，工程域三者的最佳实践。工程域往往比过程和项目管理域更加重要。