每次发版都搞到晚上11点，我们能不能……

“ 将四持原则，融入到你的日常工作中，你将不会被「琐事」缠身。”

在《持续交付 2.0》一书中，提到改善软件交付能力的「四持原则」。

它们分别是：

坚「持」少做，

「持」续分解；

坚「持」反馈，

「持」续改善。

如果在工作中，能够践行这个「四持原则」，那么，下面的场景就基本不会发生。

1

场景复现

如果你能真的身处软件研发的一线，你应该经常在晨会上听到项目经理或技术负责人在软件发版的前几天，会像念咒语一样，重复着类似的话：

• 星期二：周四要发一个新版本。请大家今天下班前自己检查一下各项准备工作。明天早上晨会同步一下进度。

• 星期三：明天要发新版本。今天大家各自同步一下各自的准备情况，看看有哪些风险点。

• 星期四：我们照旧在晚上七点发版本。昨天晚上我又和 xx 对了一下现在的项目情况，还有一个风险点，今天晨会后再确认一下。大家都准备一下，下午早点吃饭，晚上七点发版。希望一切顺利。

此时，有人问：

「能不能改在下午三点呀？

这样不用搞到那么晚。

前几次，每次都要搞到晚上十一点多，还不一定能搞完。」

2

持续改善

嗯，

问这个问题的同学，多半还是个爱思考的同学，他至少想改变现状。

「提问」是一个很好的学习方式。没有「提问」，那么就无法「改善」。

当然，它只是「持续改善」的第一步。

每个人第一次提出的问题并不一定是一个之前没有解决过（或试图解决）的问题。

而对于问题的提出者来说，却是一个「新」的问题。

此时，应该有人来给他解答该问题。可以是通过口头沟通，也可以通过指出已整理好的「文档资产」所在位置与链接。

不过，他直接给出的了一个解决方案，用以解决「每次发版都要搞到很晚」这个问题。

对，没错，在某些情况下，夜间部署可能是一个天经地义的事情。

注意，只是可能，并不是绝对……

即便是夜间部署，也不必所有人都留下，看着整个发布版本过程吧……

如果有人能够意识到问题，这里应该有人提问。

「为什么每次发版，都要这么多人，花这么长时间，搞到这么晚呢？」

3

持续分解

与

坚持反馈

上面的场景正是在之前两篇文章中提到的项目。文章链接如下：

1. 如何通过累计流图，发掘更深的项目管理风险（PART TWO）

2. 新团队，刚接触持续交付实践，遇到这种状况，怎么办？

虽然这个项目遵守了“持续分解”的原则，将项目需求分解成很多个小的需求，迭代周期是两周。

然而，项目管理中，并没有很好地执行「坚持反馈」的原则。

项目原来的约定是：

每两天，向测试环境部署一次，

每星期，向预生产环境部署一次。

由于上面两篇文章提到的问题，使得多个子团队都无法完成这一约定。即使能够进行部署，也多次因为质量原因，导致在对应环境上无法开展正常的验证工作。

造成这种状态的原因有多个：

• 因为开发人员并没有自己的开发测试环境，能够很方便地进行开发自测，所以，测试环境经常成为开发人员的调试环境。

• 并没有太多的自动化功能测试，单元测试也很少。所以，每个开发人员依赖于这个测试环境，进行功能调试。
  

• 这个测试环境是几个子团队的共用测试环境，而各子团队之间也有一些需求互相依赖，也需要在这个测试环境上联调。

• ……

反馈的第一时间并不是当任务在角色之间交接之时，而是每个人的每次行动之时。也就是微反馈。只有通过微反馈回路，才能让开发人员效率最大化。

然而，在国内当前软件工程环境中，这种微反馈回路的建设需要一个较长的周期才能建设完成，尤其是对于那些老旧的遗留系统，可能需要更多的改造任务。

3

技术高管

无法正确地衡量

公司实际的能力水平

Forrester 的报告称，DevOps正在加速技术发展，但组织往往高估了自身的进步速度。该报告还指出，与从事基层工作的人相比，高管更容易高估组织的进步速度。

所以，需要准确地衡量DevOps能力，并将结果传达给领导者，这样，他们就可以使用这些结果来做决策，并准确传达其改善组织技术状况的策略。

4

提出正确的问题

针对开篇提到的场景，一个重要的问题是：

「为什么每次发版都需要这么长时间？」

只有问对了问题，才能解决好问题～

盲目开始行动，都是浪费。