如何找出DevOps具体改进内容？

假定你是一个软件开发团队的负责人，你的老板找你聊天儿，让你想想办法，把开发速度再弄得快一点，或者把上线质量再搞得好一点。你充满信心充满干劲儿地答应下来。那回去咋办？凭直觉，或者凭最近管理上遇到的事情，或者灵光乍现想出几个改进点？还是根据最近看的几篇文章分析下团队是不是也能做类似改进？要么，组织团队成员一起唠唠，集思广益？

都不错。然而你怎么保证，你找到的待改进事项，就是抓住了团队当下最要紧的事情？你怎么保证，没有遗漏其它一些重要内容？

你需要一种系统全面的方法!

假定你带领的团队负责软件研发效能工具平台，这个团队从市面上挑选和引入好用的开发工具并部署运维，必要时搞点定制开发、搞点工具间的集成、甚至搞点自研工具，总之目标是服务好本公司数百名软件开发人员。现在要考虑今后一两年要建设点儿啥，重点投入哪些事项。

这时候，你怎么分析和确定团队的工作计划？你怎么保证，你做的计划抓住了当下最要紧的事情？你怎么保证，没有遗漏其它一些重要内容？

你需要一种系统全面的方法!

假定你是负责软件开发过程改进的专职人员，别人称呼你或者你自称敏捷教练、工程教练、DevOps教练。当然，你可以拿着Scrum这个锤子到处找钉子砸，或者拿着极限编程这一套锤子到处找钉子砸，或者持续集成、持续交付、精益看板、TDD、微服务、云原生……

然而更理想的情况是，用系统的方法，对你进驻的团队有一个全面的了解和全面的分析，梳理出它在软件开发过程方面应该做哪些改进，以及轻重缓急。然后再从你的工具箱里拿出匹配的合适工具，叮叮当当。

你需要一种系统全面的方法。需要有一种类似对人进行体检的方法，对一个开发团队进行全方位多层次的梳理，根据所处业务领域、当前采用的技术栈、当前使用的工具、流程和方法等实际情况，找出当前问题最突出，最值得改进的那些地方，甚至制定中长期的改进方案，一步一步扎扎实实弄。

— 1 —

沿价值流梳理

要想系统全面地进行梳理，首先需要沿价值流梳理。DevOps主要聚焦于软件交付过程，也就是从写完一行代码，到这行代码发布上线的过程。从流程角度，典型的软件交付过程大致经历了三个层级：

• 第一个层级，代码改动累积并最终提交：从在一行代码上做了一点改动开始，改动不断累积的同时不断进行质量上验证，直到把累积起来的改动提交到服务器端的代码库。

• 第二个层级，特性改动累积并最终提交：从特性分支上收到代码改动提交开始，这个特性上的代码改动提交不断累积的同时不断进行质量上的验证，直到把完整实现的特性提交集成。

• 第三个层级，集成并最终发布：从集成分支上收到特性改动提交开始，特性改动提交不断累积的同时不断进行质量上的验证，直到把这些特性发布上线。

而上述每个层级，又都可以分为先后两个部分，先是在不断地累积代码改动的同时，持续地验证质量；然后等改动都完成后，进行最后的质量验证，验证通过就意味着这个层级的完成。

梳理分析以上3x2共6个阶段发生了哪些活动，看它发生的时机、发生的频率是否合理，看有没有遗漏的活动，是沿价值流梳理主要关注的内容。

— 2 —

按不同活动梳理

流程包括很多活动，而某种活动又可能在流程中多次运行，甚至出现在流程的不同位置和阶段。以构建这个活动为例，开发人员本地要构建、代码改动提交到服务器端代码库的特性分支可能会触发构建、创建合并请求可能会触发构建、集成发布分支上的每次提交也有可能触发构建。

在考察软件交付过程做得怎么样的时候，我们既要考察软件交付全过程的流程编排是否合理，也要考察流程中每个活动做得怎么样。前者重点看流程本身：何时做什么、是否合理、是不是自动化地串接起来等等。而我们考察每个活动的时候，是要聚焦在这个活动：方法对不对、有没有效果、执行得快不快等等。

那么，具体有哪些活动呢？这些活动的类型其实不少，如果平铺下来，可能有疏漏，也不好记。我们把这些事情大概分分类。

先不考虑测试相关的活动。即便是开发人员写出了完美的源代码，无需测试，那么从写出了源代码到发布上线，也仍然需要经过一系列活动。这包括源代码和构建相关的：源代码版本控制、构建、构建环境管理、制品管理，也包括部署运行相关的：部署、运行环境管理、配置参数管理、数据存储结构管理。

然后考虑测试相关的活动。这包括静态测试：代码评审、代码扫描、制品分析，也包括动态测试：单元测试、自动化接口测试、人工UI测试、自动化UI测试、非功能测试、生产环境测试。

— 3 —

按各个关注角度梳理

不论是分析一个流程阶段，还是分析一个具体的活动，我们都需要从不同的关注角度去梳理。我们大体上有这些关注角度：

• 执行时机。考察某个活动的时候，首先要看什么时候执行它。比如，什么时候构建？什么时候部署？什么时候执行自动化接口测试？执行时机，是第一类要考察的内容。

• 执行效果。这个活动开展了，那到底有用没有啊？有多大收益啊？比如搞单元测试，那发现了问题没有啊？是不是仍然有很多问题遗漏啊？

• 执行效率。怎么才能让总体过程更有效率呢？除了减少等待外，提高每项活动本身的执行效率，让它更快、成本更低。

• 问题处理效率。这是指出现问题后多久能够把它修理好。不仅是线上的问题要尽快修，集成、测试过程中的问题也要尽快修，不然导致流程阻塞，甚至因为质量问题影响继续开发和测试。问题拖延越久，损失越大。

• 避免引入问题。软件交付过程的主要工作是查找出编写代码时引入的问题，软件交付过程本身就尽量不要再引入新的问题了。

以上几项，其实是关注角度的类别。每个类别下，再细分为若干个关注角度。限于篇幅，这里就不展开了。

如果您觉得读着不过瘾，可以来“K+全球软件研发行业创新峰会”（上海，11.19-20），听一听我的《全面摸排确定DevOps改进项的系统性方法》主题演讲，届时将更详细地介绍这种全面梳理的方法。敬请期待！

本届“K+全球软件研发行业创新峰会”旨在发现全球软件研发领域的创新工程和杰出团队，整合国际前沿技术实践，构建行业案例研究智库，通过软件研发技术的创新融合，帮助中国企业成功进行数字化转型与升级。秉承“开放×连接×预见”的主题，大会包含工程创新、管理创新、产品创新、技术创新和效能创新五大分论坛。

并且形成了数字化转型、产品创新、运营和增长、云原生、DevOps创新、质量创新、微服务、高并发架构、智能金融、应用性能优化、工具的革命等十几个专场。特邀近百位全球软件领域的技术领袖与一线实战专家，融合主题演讲、互动研讨、案例分享、实战演练等多种形式，共同探讨软件领域的前沿发展、最佳实践和创新应用，打造大师智慧+实践干货的技术盛宴。

董越老师所在的效能创新分论坛最新议题出炉啦~干货满满，也许你只需要花半小时的时间，就能走完别人几年的历程。更多效能创新分论坛议题，我们一起来看：