写点什么

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

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

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

关注

评论

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

Gartner最新报告:低代码应用开发平台在国内的发展

明道云

并购增资或将有望启动东软越通新动能?

E科讯

MySQL使用ReplicationConnection导致的连接失效分析与解决

转转技术团队

MySQL JDBC Java’ 数据库·

等保备案是什么意思?应该去哪里办理备案?

行云管家

等保 等级保护 等保备案 等级测评

【二级等保】过二级等保用哪个堡垒机品牌好?

行云管家

网络安全 堡垒机 等级保护 二级等保 等保安全

如何让销售管理更高效?

优秀

销售管理

Go 语言使用 MySQL 的常见故障分析和应对方法

百度Geek说

Go MySQL

CRMEB知识付费如何二开阿里云短信功能

CRMEB

数据中台稳定性的“四高” | StartDT Tech Lab 18

奇点云

数据库 大数据 数据中台 云原生

如何解决 Iterative 半监督训练 在 ASR 训练中难以落地的问题丨RTC Dev Meetup

声网

RTC Dev Meetup 生态专栏 语音处理

首次曝光!唯一全域最高等级背后的阿里云云原生安全全景图

阿里巴巴云原生

阿里云 云原生 安全 可信云

技术分享| WVP+ZLMediaKit实现摄像头GB28181推流播放

anyRTC开发者

音视频 推流 摄像头 GB28181 播放

Selenium Edge的IE模式

IT蜗壳-Tango

IT蜗壳教学 6月月更

进销存软件排行榜前十名!

优秀

进销存管理系统 进销存系统

Vone新闻 | 旺链科技赋能众享链网自组织管理,打造企业级联盟DAO

旺链科技

区块链 产业区块链 DAO 自组织协作

大数据培训 | Flink如何监控恶意登录

@零度

大数据

直播间源码在开发前期必须做的工作及开发步骤

开源直播系统源码

软件开发 直播源码

腾讯的技术牛人们,是如何完成全面上云这件事儿的?

科技热闻

如何用 Redis 实现一个分布式锁

Ayue、

redis 分布式锁

大数据培训 | 电商用户行为分析之订单支付实时监控

@零度

大数据 flink

基于Vite+React构建在线Excel

葡萄城技术团队

SpreadJS vite

基因检测,如何帮助患者对抗疾病?

阿里云弹性计算

高性能计算 生命科学 EHPC 基因检测

想学习eTS开发?教你开发一款IQ-EQ测试应用

HarmonyOS开发者

HarmonyOS

navicat定时任务无效

源字节1号

冷板式、浸没式、喷淋式液冷散热能否引领高性能计算发展?

GPU算力

用OBS做直播推流简易教程

boshi

直播 OBS

得物多活架构设计之路由服务设计

得物技术

架构 高可用 架构设计 双活 路由

Wallys/DR6018-S/ 802.11AX MU-MIMO OFDMA / 2* GE PORTS/WIFI 6e / BAND DUAL CONCURRENT

wallys-wifi6

web前端培训redux的理解与应用

@零度

前端开发

图解OneFlow的学习率调整策略

OneFlow

前沿技术 学习率 调整策略

再突破!阿里云进入Gartner云AI开发者服务挑战者象限

阿里云大数据AI技术

人工智能 机器学习 AI开发软件

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