《敏捷无敌之DevOps时代》读后感

背景：

2020年基于我司业务形态，我开始实行敏捷项目管理。以敏捷为道，Scrum为法，迭代为术，禅道作器，大张旗鼓的搞了2年敏捷开发。随着时间推移，问题出现在2022年，当时我们已经完全按照Scrum的模式在运作着10个项目，以及项目团队。我们基于禅道提炼了如：任务准期率、任务准交率、计划偏差率等指标。但是其中一项指标成了我们10个团队的核心痛点，即：需求交付周期。我们在2022年年底复盘的时候发现全年下来，需求交付的平均周期为40天，也就意味着一个需求从登记到禅道到关闭的平均周期是40天。这是我们无法接受的，也是业务部门（内部甲方）无法接受的。

问题出在我们的发布与迭代是强关联的，我们的迭代是2周一次，然后一个迭代就发布一次，也就是说一个需求在理论上最快发布周期是21天(3周)，这里说的是理论值如下图：

除非刚好，提出需求的那天正好是迭代开启的头一天，那样可以做到14天，但是那种情况太极限了。另外也不是刚刚提出需求，下个迭代就可以安排开发。所以普遍性来说，算上排期，一个需求平均交付周期在这种模式下最快就只能做到21天。

但是，不可接受的事情是我们10支项目团队，平均需求交付周期是40天，甚至比21天还要多2周。一个经典的案例是用户需求增加一个Excel导入导出的功能，问我们要多久。我们开发人员评估的工时是2小时，但是客户问我们什么时候能用上，我们回答却是2周以后。用户不理解，我们也不理解。至此，如何将迭代与发布脱钩，就成了我研究的课题。

摆在我们面前的有两条路线可以选择一条是SAFe，一条是DevOps。 由于我们在2020~2022年期间先后取得了Scrum Master 和 PMI-ACP的认证。所以思维定式上会去靠拢SAFe， 完全实行SAFe对人员的要求很高，转型也很痛苦。因此，我只采用了SAFe中的“发布火车”这一重点实践。 固定每周2、4 为发布周期。 在试行2个月后，研发人员抱怨声音越来越大，抱怨的主要原因是开发人员根本跟不上。其实这里所谓的跟不上，经过我后面的调研不是指开发能力不行，而是对代码没有基于需求做主分支管理。至此，我开始研究另外一条路线：DevOps 。

写在前面：实施DevOps两个月之后，我将需求平均交付周期从原来的40天，成功的缩短到了23天，并且后续任然有信心降低到15天内。

---

正文：

我入手的第一本书籍是《DevOps实践指南》。说实话，这本书把我整的有点懵逼。书中讲了很多运维人员和开发人员的实操案例。虽然我本身具备10年的.Net开发经验，但是我现在本职工作是项目经理，这对我来说并没有解决我的核心痛点。也可能是我们目的性太强，造成了我耐不住性子去读这本书。不过，这本书在我小白阶段的时候，至少跟我说清楚了什么是：DevOps？

早期在百度搜索DevOps，多数解释就是：开发运维一体化，打通开发与运维之间的部门墙之类的。其实，这只是狭义的DevOps的理解。通过潜伏到各种微信群中，听到各种大佬对DevOps的解释，有的说是工具链，有的说是是流水线，有的说是实现自动化，有的说是实现CI/CD（持续集成/持续部署）。

这种浑浑噩噩的阶段，直到读完《DevOps实践指南》才慢慢好转，那么究竟什么是DevOps?

我认为现在最好的定义是：研发效能。 特别是这个“效能”，不是研发效率，效率指的是团队的产能，速度。 而效能是这个“能”字是指的：赋能。 这样才解释清楚，在广义的DevOps是怎么适配到IT的研发场景。紧接着问题又来了，怎么个赋能法才叫DevOps？还是没说清楚什么是DevOps？我们先把这个问题先放一下，先来回答另外一个问题：什么是敏捷？

其实，在我入门敏捷的时候，也具有同样的困惑，什么是敏捷？是Scrum？是Xp？还是水晶？ 后来明白了，符合敏捷宣言的都是敏捷。

再回到前面那个问题，什么是DevOps ？如何为研发效率赋能？是否也有类似敏捷宣言这样更具体的解释，答案是有的《DevOps实践指南》给出了DevOps 三大原则： 流动、反馈、持续学习。 简单来说符合 流动、反馈、持续学习的就是DevOps，并且DevOps自身也在不断进化更新。

可是，还是有点抽象。这个持续学习还好理解，无论是理论指导实践，还是实践完善理论，持续学习始终是向上的攀升的正确途径。

那么剩下的两个问题：

1，流动是什么？

2，反馈是什么？

带着这两个问题我又分别入手了《价值流动》、《敏捷无敌之DevOps时代》这两本书。

关于《价值流动》我之前写过另外一篇读后感，这里不做赘述，总之该书解释清楚了流动的是啥，如下图：

	描述	交付物
特性	为推动业务结果而增加的新价值；对客户可见	新的业务价值
缺陷	为修复影响客户体验的质量问题	质量
风险	致力于解决安全、隐私和合规风险	安全、治理、合规
债务	软件架构和运维架构的改进	消除未来交付的障碍

到这里我的问题更多了，前面我们要解决的问题是如何将迭代与发布脱钩？ 如何将需求交付周期从40天降下来？我们通常认为的需求就是上表中的特性，这里一看不但需求对应的特性没有 透明化，另外的缺陷、风险 和债务也是不透明的。但是总而言之，一句话：当前我是看不见需求的流动， 这也就解释了为什么我潜伏微信群的时候，有大神解释DevOps 就是流水线，流动的东西就是上面的四大流动项。

上面解释清楚了什么是流动，以及流动的是什么。那么转换成为行动任务就是，打造一套体系让流水线，实现可视化、透明化。这让我们想起了考ACP的时候的 “价值流图” 有异曲同工之妙。

就像木桶定理一样，决定一个木桶能装多少水，取决于那么短板。 无论是特性、缺陷、风险、还是债务。对应的是四条处理流程（流水线），而将这个流程以进行可视化，就能发现过程中的短板，并加以改善。根据我浅薄的理解，我悟到这里，算是对“流动”有了一个较为具体的认知。

那么反馈又是什么？ 基于我对敏捷的认知，反馈就是以最小可行产品实现快速上线，获得用户反馈，并立即优化调整。通过阅读《敏捷无敌之DevOps时代》之后，我有新的理解。通过各种工具建设对 观测指标 进行提炼，对各项指标进行治理形成反馈，并利用这些反馈进行改进和优化，从而形成犹如PDCA的正向循环。

所以，这里又说明白了为什么我潜伏在微信群中，大佬说DevOps是 工具链。

说到工具链，不得不说我们潜伏微信群时候，大佬的另外一个解释：自动化。前面讲的基于四大流动项，可以打造四条流水线。那么流水线除了做价值流图分析过程短板以及等待浪费以外，还可以针对流程本身进行提速。 这里我们可以简单的映射一下现实生活中的工厂，手动流水线 和 自动化流水线。

至于怎么自动化，说来也简单。就是把重复劳动的事情交给机器去做，现实生活中的流水线不也是这样的吗？这里对于解决了哪些重复劳动不做篇幅（PS.前期在B站一搜DevOps，老是出来一堆工具的实操教程，一直给我整的挺懵逼。）

这里再回头说一下，发布与迭代怎么脱钩，通过我对这些DevOps工具的了解，接触到了CI/CD。

　　CI (Continuous Integration)：持续集成。它涉及将开发人员的代码频繁地集成到共享存储库中，并使用自动化构建和测试工具对代码进行验证。

　　CD (Continuous Delivery/Continuous Deployment)：持续交付/持续部署。它涉及自动化地构建、测试和部署应用程序以实现快速且可靠的交付。

本身，CI/CD 概念并不复杂，为什么我们前面用发布火车团队反应这么大呢？ 前文中也有描述，没有基于需求创建分支这是其一，创建分支缺乏管理，无法有效的实施持续集成、持续部署这是其二。

通过建设CI/CD，基于需求创建分支，配合工具使用。做好的功能通过测试，就发布。不再等到迭代结束再发布，一下子就把需求交付与迭代脱钩了，我们的交付周期也很快的从40天降低到了30天内。

写到这里，我再提炼几个关键词： 流动、反馈、持续学习、透明化、可视化、自动化、工具链、流水线，CI/CD。

到这里，还不是DevOps建设的全貌，接下来就要大刀阔斧的动起来了~！

---

感悟：

前面已经讲过，由于在团队内部实行“发布火车”，造成的团队各种抱怨。为了达成共识，这次我选择了外来和尚念经。由于市场上也有不少的成熟的DevOps解决方案，我先后组织了4场“解决方案供应商" 线上交流会，让团队对DevOps有了一致的认知，也成功勾起了大家对组织改善的意愿。

这里我规划了三条建设路线同步进行：

其一，是工具链。包括：禅道18.0、GitLab、SonarQube、Jenkins、Selenium、Jmeter、K8s、Docker、Zabbix、WebFunny

其二，是流程与规范，包括：项目管理流程、需求管理流程、缺陷管理流程、敏捷运作机制、禅道使用规范、.Net编码规范、JAVA编码规范、GtiLab使用规范、持续集成规范、持续部署规范、测试管理规范、制品管理规范、服务器监督管理规范、应用系统监督管理规范。

其三，是过程性指标与结果性指标。包括：需求总数、需求从登记到设计周期、需求从设计到评审周期、需求从开发到提测周期、需求从测试到发布周期、代码提交次数、部署频率、部署成功率 等指标。

紧接着趁热打铁，直接把DevOps转型当做项目来做，发起了对DevOps的立项：

项目背景：

数字运营中心是敏捷型交付组织，具有边设计边生产边实施、用户需求多且变更频繁、软件使用过程中需要快速响应等组织特性。随着部门业务量的倍速增长，管理复杂度不断增加，同时需要更精细化的观测指标进行管控，产品设计、项目管理、软件开发、质量测试等过程缺乏规范性，尤其对细节管理需要实现过程与结果透明化，需要一套适合自己的面向企业服务的软件生产管理体系与工具，同时拉通各个职能角色，使软件生产业务数据透明可视；缩短需求生产周期，降低开发成本，进而实现开发运维一体化，提升管理效率。

项目目标：

目标1：需求平均交付周期从40天降低至25天。

目标2：需求按期交付率从90%提升至95%。

目标3：人均需求交付数从1.5提升至1.8。

目标4：软件发布一次成功率实现透明化，并提升至80%

项目收益：

投入180人天，获得约14人编制的产能，计算如下：

数字运营中心以70人为基准，当前月度人均交付需求数为1.5。 通过建设DevOps研发效能体系，预计产能提升至月度人均交付需求1.8。

通过计算可知：

当前产能：70*1.5=105

目标产能：70*1.8=126

提升产能：126-105=21

释放同等人力：21/1.5=14人，以人均薪资1万元计算，约每月降本14万元，全年降本168万。

项目蓝图：

成果：

再回到一开始的问题，我们通过建设蓝图里的一系列工具，成功实现了基于需求做代码版本的主分支管理，实现了一周2发布的频次。自此也完成了发布与迭代脱钩，虽然目前DevOps研发效能这个项目还没有完全结束。但是我们已经成功实现了交付周期从原来40天缩短到了23天。大致成果如下图：