持续交付——不仅仅是技术

在实施持续交付的时候，很容易陷入到技术方面。对发布流程中的每一步进行客观地观察和度量之后，我们会发现其中一些阻碍发布的非技术因素，成为流程中的瓶颈。因此，我们需要确保沟通方式有效，同时所有成员能够真正地协作。

关键要点

• 人和人之间的沟通问题可能会推迟发布周期数小时甚至数天。

• 将系统可视化，以查看问题和瓶颈所在。

• 学会客观观察，注意是否存在你的偏见和主观观点。

• 使用系统使用中产生的数据来集中改进工作流程。

• Toyota Kata 确实有助于流程改进。

和许多组织一样，我们也正走在持续交付的路上。这个过程中有许多工作要做，这都是些众所周知的工作，例如构建自动化测试和部署管道。然而，我们发现还有一些使发布流程没有那么顺畅的其他因素。只是当时还不知道产生这些问题的确切原因。

我开始观察我们的发布流程，并做了记录。客观地观察了发布流程中的每个阶段，让我能够度量发布流程。例如，流程中的每个阶段耗时以及它们的实现方式是自动的还是手动的，不同角色的 人员数量，和在什么时间点我们会发现阻塞发布的问题。一旦有了足够的数据，我们就可以开始分析和寻找瓶颈，这些瓶颈将成为最急需解决的问题。

在观察时务必确保是客观的，不能让主观判断和偏见掩盖实际发生或未发生的事情。客观观察是一项值得锻炼的技巧，它是Gemba和实验的基础，在尝试改进我们的流程和系统时非常有价值。

为何专注于改善我们的发布流程？

原因非常简单：我们的发布流程不够顺畅和平滑，也没能达到期望的频率，这都影响到了我们的交付能力。虽然当时我的角色是在跨职能团队担任探索式测试人员（Exploratory Tester），但我一直对改进我们的系统很感兴趣。因此参与到改进我们的发布流程是一个很自然的步骤。

和技术专家一起共事的好处是他们尊重数据和事实，并且都非常热衷于让事情变得更好。因为我收集了大量数据，反映了实际的问题，因此我们能够专注于解决实际的问题，而不是基于各种假设。例如，数据显示实际部署到准生产（Staging）环境的套件数量远小于预期，因此我们需要解决部署到该环境时遇到的问题，以降低部署难度。

稳定发布——不是所有功能都必须发布

哪些功能点真的很重要而需要发布呢，讨论它是非常困难的事情。当我们在选择本周待发布版本的最后一分钟，每次总会有“最紧急的”变更被加进来，并且提交的团队都能为这些变更提出一堆必须发布的理由。当时我们有差不多 8 个团队，因此这对我们来说是个大问题。这种在发布前延迟选择待发布版本带来的连锁反应，既一些需求需要很匆忙的上线，有时候会影响发布质量。本质上来说，这个问题的根源来自于每周只能发布一次的限制，除非我们能够做出改变，否则每周仍然会遇到这样的压力。

我开始问类似这样的问题：“为什么这个需求必须在这个版本中发布？”，“如果不发布这个需求会有什么问题？”或者“这个需求能等到下个发布周期发布吗？”。类似这样的话题很难聊下去，因为当我问出这些问题的时候，对团队来说我已经成为阻碍他们变更的障碍。事实上，当我们在试图提高发布频率的时候和对方说变更得等到下周才能发布是有悖常理的。这时候的核心要务是确保发布稳定。

通过对上述问题的讨论，我们意识到一些变更一点都不紧急，因此不用匆忙上线。这样做带来的整体效果是发布更加顺畅，修复线上 bug 的补丁更少了。显然对我们的压力也更小了，让我们能够专注于提高发布频率。

使用数据来识别瓶颈和改变习惯

改变习惯非常难。习惯是人们下意识的行为，因此必须努力停止旧习惯，并使用新习惯取而代之。公布我们发布环节数据并突出其中的问题，能够增加这些问题的可接受程度和修复意愿。

我们尝试了一些方法来帮助养成好习惯。例如，由于发布环节参与人之间的主要沟通方式是电子邮件，使得我们会有小时级别的延迟。对于发送者来说，当邮件发出，消息传达出去，任务就完成了。但是，在接收者阅读并理解邮件内容之前，事实上并没有沟通任何消息。如果接收者在开会，或者一天只查看一到两次邮件（这是一个好习惯！），那么当他们看见邮件的时候已经过去几个小时了。引用我的朋友 Rob Lambert（@Rob_Lambert）的话，“沟通内容需要到达听众的耳朵里”。

为了改变使用邮件这个习惯，我们引入了一段时间物理交接。我们买了一块好莱坞场记板（clacker board），在上面写上待发布版本号，然后像接力棒一样逐个交接。如果我接到了这个场记板，那么我知道现在整个发布流程都在等待我的工作。实际在做的就是应该要做的事情会让人很有成就感。同时这个方式也让参与者感受到了发布是手头最重要的事情。

使用场记板还有一个目的：让参与者面对面的交流，增进相互了解，并逐渐有团队感。这个过程很花哨，也很搞笑。但是它完成了使命，它让我们消除了因为沟通不畅导致的流程阻塞，让所有人像一个团队那样工作，并帮助我们养成了更好的沟通习惯。

总的来说，致力于将低效习惯改成更有效的习惯，需要通过一些富有创造性且有趣的方式，让大家能够参与进来。习惯堆叠是另一种好方法，它的方式是将新的习惯放到另一个已经存在的好习惯之上。如果想了解更多，我非常推荐 Helen Lisowski（@HelenLisowski）的“好习惯的力量（Power of Good (Agile) Habits）”研讨会。

尝试使用 Toyota Improvement Kata

当我刚开始以改进发布流程的视角来观察它的时候，我并不知道Toyota Improvement Kata。幸运的是我和非常有经验的敏捷专家、精益和系统思想家一起共事，因此我很快就学习了它。事实证明，我工作的整个过程都是符合 Toyota Kata 的，包括观察、收集数据和分析，最终找到下一步实验的重点。

Toyota Kata 是关于运用科学的思维方式来理解我们的问题，对接下来会发生事件的思考和基于现在已经发生的事件来调整后续步骤。它主要有四个步骤：

步骤一：

制定方向、挑战和目标。对于我们来说就是按需发布。这不意味着我们在每分钟都有发布，而是我们能够以平滑流畅的方式按照自己的节奏发布。

步骤二：

了解当前状态和条件。这就是我们收集和分析数据的来源。我们有一个电子表格形式的价值流图（Value Stream Map）。

步骤三：

建立下一个目标条件，既我们的第一个里程碑。通常从当前条件直接到最终目标跳跃太大，否则我们早就完成了。为了取得进展，确定一个更容易实现的中间目标是有帮助的。对于我们来说，这个目标是发布周期从 4.5 天降低到 2 天。

步骤四：

确定并进行实验，以达到目标条件。这时候数据分析再次入场。数据会显示我们最大的问题域和阻塞的地方。我将这种阻塞定义成停滞时间：期间不会发生任何事情，我们能做的只是等待下一个流程发生。我们将第一个实验重点放在消除或者减少这些阻塞。

使用 Improvement Kata 的方式进行思考，帮助我们确定下一步我们想要做出的改变，最终让我们改变了现有习惯，或者将一些人工步骤自动化。例如，前文提到的使用场记板来改善沟通，就源于 Improvement Kata 设计的实验。

另一个基于 Improvement Kata 做出改变的例子，是在测试阶段将绿色构建套件自动化。这个步骤看上去本来就应该自动执行（事实上也是这样），但当时的情况是，我们认为绿色构建总是失败，会耽误部署到预发布环境，因此被作为一个手动流程。收集的客观数据展示了当前状态（步骤二），实际情况是我们基本上没有部署过绿色构建套件！由于是一个手动流程，它经常因为人为遗忘或者被其他事情分心而忽略。将该步骤自动化部署成为了下一个行动（步骤四）。

从非技术层面改进发布带来的收益

最明显的收益是缩短了发布周期。原先的发布周期是 4.5 天，因此我们一周只能发布一次。在进行了一些尝试，和将一些交付流水线自动化之后，我们将整个周期缩短了一半，如果加把劲我们可以在 1 天内发布。

其他一些重要收益包括：

• 更好的沟通和工作关系。

• 自动部署测试环境，这样团队可以快速完成用户故事的测试，以降低用户故事和反馈的周期。

• 改善了我们糟糕的自动化测试。

• 将持续集成的投入从 6-8 人执行 2 天，降低到 1 人执行 30 分钟。

• 减少修复逃逸缺陷的补丁。

一些经验教训

以下是我学到的一些内容：

1. 拥有展示当前模式和趋势的数据很重要。因为它们能够真实的表露问题，并显示我们做出的改进亦或视情况不做改变。

2. 在试图说服管理层给项目投入时间和资源时，客观数据收集和分析非常有用。这些图表非常强大！

3. 虽然持续交付的工作主要集中在技术和管道自动化方面，但人的因素对发布周期也会产生很大的影响。一定要找到瓶颈所在。

4. 虽然开放式办公室和参与到发布流程中的同事交流比较方便，但并不意味着他们有着良好地沟通和协作。

5. 一个人的好点子是有限的！向同事寻求帮助，让他们参与进来（感谢 Gemma Lewington 提出的好莱坞场记板主意）。

在持续交付过程中很容易找到技术相关问题，但是容易只关注技术。毕竟，这也是大部分建议和技能开发资源关注的点。技术问题很明显，也应该要解决。但是，请关注整个发布流程。根据自己在管道自动化流程中的位置和这个流程的耗时，可能会发现隐藏在发布流程中的其他非技术因素。了解整个发布流程中的每一个步骤，找到瓶颈和阻塞点，确保沟通方式有效，所有相关方都能够一起有效的协作。

关于作者

Sylvia MacDonald 职业生涯开始时是一名开发工程师，然后成为了软件测试工程师，现在是 NewVoiceMedia 的工程经理。她深入研究了如零售客户服务和蒙特梭利教育（Montessori education）等其他领域。她热衷于提高质量，帮助团队了解业务敏捷，并通过发现问题并帮助消除问题来改善工作流程。MacDonald 主持并组织了 Reading Tester Gathering Meetup 小组。想要了解关于作者的更多情况，可以查看她的LinkedIn、@Sylvia_MacD和一些会议演讲。

查看英文原文： Continuous Delivery - It’s Not All About Tech!