2天时间,聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情
写点什么

从持续交付中获得商业优势

  • 2015-11-24
  • 本文字数:2180 字

    阅读完需:约 7 分钟

Gojko Adzic Agile Tour London 2015 上发表了主旨演讲,关于“如何将持续交付转变成商业竞争优势”。InfoQ 采访了 Adzic,主要关于向持续交付要效益、Gojko 的三条持续交付规则、可能出现的问题和风险、以及在持续交付中使用多版本控制。

InfoQ:您谈论了企业如何才能从持续交付中获得效益。您能给出一些案例吗?

Adzic:我觉得企业正从持续交付中获得利益,比如降低发布的技术风险,和加快产品上市时间,但是他们可以从持续交付中获得更多的效益——通过从技术角度解锁持续交付的关键问题和解锁一些非常有趣的商业优势,从而使解决方案更加有效。例如,通过整理车辆的持续交付管道,Tesla(汽车制造商)能够比竞争对手更加便宜地处理产品缺陷和召回缺陷产品(参考 Tesla’s over-the-air fix: Best example yet of the internet of things? )。

此外,人们很少考虑持续交付对产品体验中非技术部分的影响——比如市场营销和用户期望。例如,当在 MindMup 工作时,我们使用持续交付从发布中消除可能导致意外发生的因素(take away the drama),让事情发展顺利并可预测。但是,消除意外因素的同时我们也远离了令人兴奋的事情。几乎不可能让媒体报道一连串持续的小改进——因为没有一个单一的更新具备报道的新闻价值。

同样,没有软件版本和主要更新,客户往往会感受到更多的权益。每年一个版本,用户往往会付费升级。当换成一连串持续的小改进时,用户则希望永远免费试用新产品。许多移动应用开发人员一直被这个问题困扰着,几乎不可能让现有客户为了一个重要更新付费,但是仅仅开发和发布免费产品并不能带来很大的商业意义。

InfoQ:您提出了 Gojko**** 的三条持续交付规则。它们是什么?

Adzic:与一套严肃的规则相比,更多的是类似 Asimov 著名的机器人三定律的文字游戏,我试图捕捉团队在技术因素之外对持续交付管道产生误解的三个关键问题。技术因素已经被现有的实践和文献覆盖并解决,但是迈出更大的一步,看看一连串的小改变是如何把技术之外的事情搞糟的也非常的有趣。

持续交付可能不会……

  • 使用户混乱
  • 中断用户的工作或会议
  • 扰乱或者阻止营销活动

InfoQ:您在演讲中提到持续交付中可能会有一些问题和风险。一个可能是提高效率可能会伤害客户。您能给出一些案例吗?

Adzic:当有一连串持续的更新时,许多团队不会考虑在整个更新过程中会对客户的会议和工作产生什么影响。我看到过团队要求他们的客户在繁忙的工作日注销并重新登录,仅仅是因为软件有一个新的版本发布,人们彻底被新增的 UI/UX 混乱了。对于较大的改变,很容易在整个产品中保持 UX 的一致性。但是对于一连串的小改变,常常是在较长时间内更新和发布产品的一部分,所以用户常常必须处理不一致性。这方面的一个案例是,Paypal 去年实施的“新的业务面板”。我的公司在 Paypal 账户有两种货币余额,某天早上我登录上去后,总余额让我以为账户上少了数千英镑。我花了一个小时,试图弄明白是否其他人获得了账户访问权限并转走这笔钱,或者我被骗了,但是我没有找到任何明显的错误。实际上,这笔钱还在那儿——有人重新设计了面板,使其只显示一种货币,我认为应该为多货币客户推迟这种设计。这不是我想要的最佳客户体验,但是我可以理解他们为什么那么做。同时,在新的业务面板准备好之前,不应该强迫客户使用新的业务面板。

InfoQ:您还提到,通过交付小的功能增量,你不再有大的发布版本可以向你的客户推销。对此,你有什么解决方案?

Adzic:我现在的想法是解耦部署和发布。在我们行业中,部署和发布常常被看成一件事,但是一个是发布代码到产品的技术事件,另一个是让客户可用的市场事件。通过解耦这两件事情,我们可以从中获利,将意外因素从部署中消除,同时仍然保持其具有新闻报道价值,从而产品特征可以发布出去,制造最大的营销卖点。

这是一个需要解决的困难的技术难题,尤其是因为部署软件的一些版本需要对某些人开放访问,从而对其验证和确认,但是它也需要对外面大多数用户是隐藏的,从而制造营销热点。

InfoQ:在您的演讲中你说“没有多版本控制的持续交付是不负责任的”。您能否解释一下?您能解释一下为什么?

Adzic:能够运行不同组件的多个版本是一个很好的解决方案,或者是我上文列出的问题——将部署软件的一些版本对用户的一个子集可见,但是其他用户看的却是不同的版本。我说的不是网络重新路由或者功能切换——而是一种系统性解决方案,多种版本可以并行运行,而不会中断。如果解决了这个问题,就没有必要中断会议或者忙于部署——人们可以继续使用当前版本,直到会议结束。同时也可能可以逐步发布产品——在 Paypal 面板案例中,他们可以向拥有一个货币账户的用户发布面板,并解决整个 UX 一致性 / 迭代的问题。这同样允许将部署从发布中解耦。这就是为什么多版本作为一个架构概念如此强大的原因。

与此同时,多版本开辟了一些惊人的业务功能,比如高风险或实验性功能的温和 / 逐步发布;基于 1% 的活跃用户运行产品试验,从而证明高昂的假设;对高端用户提供预览版;紧急修复和比以前更廉价地预防问题;围绕营销事件而不是技术部署能力运行营销活动。

InfoQ:对于那些希望有效应用持续交付的组织,您有没有什么建议?

Adzic:除了技术, 你可以思索的更广泛一点。持续交付开辟了一些惊人的商业机会,如果处理得当,就不仅仅是一个技术解决方案。

查看英文原文 Getting Business Advantage from Continuous Delivery

2015-11-24 18:001879
用户头像

发布了 92 篇内容, 共 31.7 次阅读, 收获喜欢 4 次。

关注

评论

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

如何读IPO招股说明书(2)到哪儿下载招股书?

赵新龙

IPO 上市 招股说明书

像产品设计一样思考、像程序运行一样执行

水色

ZGC都出来了,你还不懂G1?

大白给小白讲故事

G1 JVM

OpenCV 在 Android 上的应用

fengzhizi715

android OpenCV 计算机视觉

迷茫时,想想能为这个世界做些什么就好了

霍太稳@极客邦科技

身心健康 个人成长 团队协作

祝这些不要脸的王八蛋同行家里着火

二爷

“WHY-HOW-WHAT”这个被誉为伟大的领袖如何激励行动的黄金圈法则,非常值得大家学一学!

数列科技杨德华

思维方式

“IPO上市扒层皮”,以阿里巴巴为例看看公开了什么 | 如何读IPO招股书(3-a)

赵新龙

阿里巴巴 IPO 招股说明书

回"疫"录(4):见证历史

小天同学

疫情 回忆录 现实纪录 纪实

如何避免把中台变成外包团队

松花皮蛋me

数据中台

判断链表是否有环

Kenn

算法 链表 双指针 Brent

vSphere 7融合Kubernetes,构建现代化应用的平台

亨利笔记

Kubernetes 容器 云原生 k8s vSphere

“消灭你,与你无关”——阿里巴巴的风险 | 旧文重发

赵新龙

阿里巴巴 风险 蒋凡 IPO

Nginx学习

陈雷雷

nginx

曾国藩的人生“六戒”

霍太稳@极客邦科技

身心健康 个人成长 心理学

演讲的秘诀

伯薇

个人成长 演讲 追求极致 完美主义

Golang 真的好用吗?

极客时间

编程语言 Go 语言

Harbor和Dragonfly双剑合璧 打造容器镜像运维新模式

亨利笔记

容器 k8s Harbor dragonfly 镜像

死磕Java并发编程(4):happens-before是什么?JMM最最核心的概念,看完你就懂了

Seven七哥

Java Java并发 happens-before JMM

二叉树的先序中序后序递归实现

Kenn

算法 递归

JCJC错别字检测JS接口新增CORS跨域支持

田春峰-JCJC错别字检测

哪儿有真实靠谱的数据,说谎话必须负责的那种?| IPO招股说明书(1)

赵新龙

阿里巴巴 IPO 旷视科技 数据

程序员陪娃漫画系列——吃饭

孙苏勇

程序员 生活 陪伴 漫画

不知不觉,写了10000字了

小天同学

写作 个人感想 思辨

“IPO上市扒层皮”,以阿里巴巴为例看看公开了什么 | 如何读IPO招股书(3-b)

赵新龙

阿里巴巴 IPO 招股说明书

我们是时候降低对完全自动驾驶的期望了

赵钰莹

自动驾驶 AI

浅谈行业软件

孙苏勇

软件 思考 转型

二叉树先序中序后序的非递归实现

Kenn

算法

批注MYSQL开发规范,助你了解其背后的“道”

三石

数据库规范 规范背后的原理 白话规范

我不是怕表错态,而是怕我会不自觉地捍卫它

池建强

个人成长

运维 Harbor 镜像仓库的法宝:Operator

亨利笔记

Kubernetes 容器 k8s Harbor operator

从持续交付中获得商业优势_DevOps & 平台工程_Ben Linders_InfoQ精选文章