写点什么

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

  • 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:001761
用户头像

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

关注

评论

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

火山引擎DataLeap:助力PICO落地数据流程规范,提升开发效率

字节跳动数据平台

数据中台 数据治理 数据安全 数据研发 企业号 8 月 PK 榜

MySQL切换字符集引发的思考(一)

石小天

MySQL 数据库 运维

R 语言入门与介绍

timerring

R 语言

Presto 设计与实现(三):依赖注入框架 Guice

冰心的小屋

guice presto 依赖注入 presto 设计与实现

VuePress 数学公式支持

ReturnTmp

2023上海国际智慧物业展览会|城博会

AIOTE智博会

城博会 智慧物业博览会

“龙蜥社区系统运维MeetUp”乘云数字议题分享

乘云数字DataBuff

BSN“五、十、百”工程实施半年成果丰硕,助力数字化转型和高质量发展

BSN研习社

《知识图谱互联互通白皮书》正式发布,合合信息携手电子标准院共同推动技术规范化发展

合合技术团队

人工智能 知识图谱

Flink 数据集成服务在小红书的降本增效实践

Apache Flink

大数据 flink 实时计算

React请求机制优化思路 | 京东云技术团队

京东科技开发者

React 前端性能 企业号 8 月 PK 榜 react18 请求机制

银行科技外包存风险,金融机构如何做好软件供应链安全管理?

网安云

软件安全 供应商管理 软件供应链安全 金融业

微信小程序:跨端开发框架的繁荣发展之路

没有用户名丶

OLED屏幕,LED,AMOLED哪个更好?

Dylan

LED 显示器 LED显示屏

SpringBoot3集成Kafka

Java kafka 架构 springboot SpringBoot3

基于 Easysearch kNN 搭建即时图片搜索服务

极限实验室

KNN 向量检索 图像搜索 easysearch

MATLAB R2023a 激活for Mac附安装教程

胖墩儿不胖y

Mac软件 数据分析软件 好用的数据管理

通宵加班设计的储能板不能用?厚铜PCB设计这个问题一定要注意

华秋电子

储能

鸿蒙生态星河璀璨| 先行者李洋全力以赴,拥抱星辰大海

最新动态

OpenTiny Vue 组件库实现主题配置和UX交互规范自定义

OpenTiny社区

开源 Vue 前端 组件库

直播系统源码协议探索篇(二):网络套接字协议WebSocket

山东布谷科技

软件开发 websocket 源码搭建 直播系统源码 网络套接字协议

坚持梦想,心向光明

何元

ARTS 打卡计划 个人感悟

【华秋推荐】无线充电的原理与解决方案

华秋电子

无线充电

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