HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

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

作者:Sylvia MacDonald

  • 2019-02-27
  • 本文字数:3868 字

    阅读完需:约 13 分钟

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

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

关键要点

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

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

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

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

  • 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!


2019-02-27 08:0011767

评论

发布
暂无评论
发现更多内容

如何使用 NFTScan NFT API 在 Polygon 网络上开发 Web3 应用

NFT Research

NFT NFT\ NFTScan nft工具 API 接口

浙大材料学院高性能存储实践,加速 AI 新材料科研创新

焱融科技

Mac电脑版红巨星粒子插件 Red Giant Trapcode Suite激活中文版

mac大玩家j

Mac软件 红巨星粒子插件 视觉效果插件

实用PCB拼版攻略,您的拼版合理吗?

华秋电子

拼板

YRCloudFile V7.0.0发布| 新增 EC 数据冗余保护功能

焱融科技

软件项目验收计划书

金陵老街

飞码LowCode前端技术:如何便捷配置出页面 | 京东云技术团队

京东科技开发者

前端 低代码 低代码平台 企业号11月PK榜

TiDB x 北京银行丨新一代分布式数据库的探索与实践

TiDB 社区干货传送门

实践案例

【TiDB 社区智慧合集】史上最全的 158篇 TiDB 用户实践合集来啦!千万不要错过!

TiDB 社区干货传送门

混音师必备软件:iZotope Ozone 11激活最新

胖墩儿不胖y

Mac软件 音频处理工具 母带处理软件

活动回顾|OpenTiny 参与线下大会:共创开源未来,助力低代码技术创新

OpenTiny社区

开源 前端 低代码 UI组件库

TiDB故障处理之让人迷惑的Region is Unavailable

TiDB 社区干货传送门

集群管理 故障排查/诊断 扩/缩容

自动化API测试工具ReadyAPI新增业务历史记录功能

龙智—DevSecOps解决方案

ReadyAPI

QCN9074 QCN9024|DR9074E Compatible with DR4019 Platform OpenWrt

wallyslilly

QCN9074 QCN9024

混合云场景下基于 Fluid 的焱融高效存储方案

焱融科技

Windows、Linux 和 Mac:操作系统之间的比较

小齐写代码

OpenTiny Vue 3.11.0 发布:增加富文本、ColorPicker等4个新组件,迎来了贡献者大爆发!

OpenTiny社区

开源 TinyVue 前端组件库

TiDB基础运维操作汇总

TiDB 社区干货传送门

管理与运维 故障排查/诊断 6.x 实践

新形势下芯片研发如何实现数智化转型,革“芯”未来?龙智即将携手Perforce及Atlassian亮相ICCAD 2023

龙智—DevSecOps解决方案

ICCAD

JAVA 调用Open AI 接口生成图片url并直接在浏览器上响应显示

风清扬

openai 图片生成 AI绘画 ChatGPT chatgpt api

我们该如何规划自己的职业生涯?

老张

职业规划 职场成长

Node.js 中 HTML 解析的终极指南:探索各种方法

Liam

JavaScript node.js html 前端 Web

焱融全闪 | 高算力时代下的国产存储之光

焱融科技

趋势:国产数据库发展的五个一体化

科技热闻

生信领域|焱融存储为极智基因打造高性能生物医学平台

焱融科技

KiCon Asia 2023 深圳

华秋电子

KiCon

大模型在代码缺陷检测领域的应用实践

百度Geek说

知识图谱 大模型 企业号11月PK榜

ATC汽车电子与软件技术周:汽车行业客户使用静态代码扫描工具的案例与建议

龙智—DevSecOps解决方案

ACT

KaiwuDB 内核解析 - SQL 查询的生命周期

KaiwuDB

数据库 sql查询 生命周期 KaiwuDB

支付宝代扣接口签约的各种问题排查(建议收藏)

盐焗代码虾

支付宝 代扣

剑指pulsar之数据写入流程

少年游侠客

消息队列 pulsar 写数据

持续交付——不仅仅是技术_文化 & 方法_InfoQ精选文章