拼体力,从来都只是弱者的游戏

点击 笔记侠 关注   回复“ 1 ”领取 120张思维导图 大礼包

内容来源 2019年4月20日,在人民邮电出版社主办的《持续交付2.0》新书分享会上,国际持续交付领域专家,持续交付2.0方法创始人乔梁,进行了以“持续交付2.0”为主题的精彩分享。笔记侠作为合作方,经主办方和讲者审阅授权发布。

讲者   | 乔梁    今日笔记达人   | 花七

封面设计&责编  子墨

第    4233 篇深度好文:5827 字 | 8 分钟阅读

活动笔记•组织管理

本文优质度:★★ ★+     口感:椰枣

笔记君说:

越专业,越卓越。很多时候,我们以为的离我们很远或者不相关的事物,其实无时无刻不在影响着我们的工作、学习、生活。

今天,就和笔记君一起走进今天的文章,了解一下总在无形影响我们的“持续交付”吧。

以下,尽情享用~

《持续交付2.0》是我过去十多年产品研发管理的经验总结,是我对“持续交付体系”的认识,它不但包括软件基础设施建设,还包括组织管理和软件架构方面的内容,其中,持续交付双环模型是全书的框架。

一、持续交付1.0和DevOps

(一组过程、方法与系统的统称)

1.持续交付1.0

传统的企业应用软件项目,发布周期时间一般都比较长。项目都是从完整的需求收集开始,经过瀑布模式开发以后,将软件部署到生产环境下。

此时,对于软件开发团队来说,一个版本就结束了。这是大多数传统软件公司的开发模式。

也就是说,软件项目团队仅负责从代码提交到发布这个阶段。而对于互联网公司,还要扩展到“产品监控”这个节点。这样就形成了一个闭环,这个闭环也是一个迭代开发的过程。

我把这一个环叫做持续交付1.0,关注的就是从代码提交开始,一直到能够保证它能够正常在生产环境运行。

它更强调的是快速把代码放到生产线上,让用户能用到。这也是目前DevOps聚焦推动的一件事。

2.DevOps (一组过程、方法与系统的统称)

讨论“持续交付”,就不得不提一下“DevOps”。DevOps术语是由当时在传统软件项目上工作的咨询师 Patrick DeBois提出的,它是一组过程、方法与系统的统称,用于促进开发 (应用程序/软件工程) 、技术运营和质量保障 (QA) 部门之间的沟通、协作与整合。

案例1:Flickr网站

DevOps的引爆点实际上是2009年。十年前有个互联网图片分享社交网站,叫Flickr,有点像现在手机端的Instagram。

2009年,Flickr的一个开发工程师和一个运维工程师在Velocity大会 (一个国际著名软件技术大会) 上做了一个分享,题目是《Flickr每天部署10次》,通过开发团队与运维团队紧密合作,使用尽可能相同的软件与工具,达到高质量快速部署。在这之前,整个软件行业普遍认为这是不可能的。

2010年,我查了一下Flickr网站的公开资料 (http://code.flickr.com) ,该公司在当时的发布次数如图所示,一周内部署54次,这54次里包含了23个工程师的636次代码变更。

案例2:Etsy公司

Etsy的公司 (国外电商网站,模式类似淘宝) ,2010年时,主要卖手工制品,像手工制作的钱包、皮夹等。

2010年,该公司启动持续交付之旅,截止到2012年,每天可部署50多次。如果按每天工作8小时,相当于15分钟就会有一次部署,如下图所示。

所有人向同一个代码仓库提交代码变更。每次提交代码变更后,立即进行自动化构建和测试 (需要15分钟左右) 。只要自动化测试通过,代码就会部署到生产环境上。即便是现在,在国内也是比较罕见的工作方式。

案例3:领英公司

2016年,领英有3000名工程师,从图中,大家可以看到IOS、安卓和Web网站的发布次数。Web端、API、IOS、安卓提交代码变更的次数总计一周905次。

为什么会有这样的工作方式呢?

在2016年之前,他们曾经做过一个设想,这个设想就是每年发布12次,为了达成这个目标,做了完美的时间规划。即:前3周进行开发工作,在第三周的星期四开发完成,可以创建发布分支,并交接给测试团队进行测试。

经过四天的测试之后,到第四个星期的星期三就可以发布了。发布后交给运维工程师。此时开发团队可以启动下一个版本的开发。国内的很多公司直到现在也是采用这种规划方式的。

然而,实际情况并没有像规划上面那样真正的发生过。现实状态是:前3周仍旧是在开发阶段,到了要转测的时候,由于期限已到,为了达到时间点,开发人员匆忙提交代码 (很可能是半成品)

创立发布分支,测试人员进行手工测试,结果会发现很多缺陷。更可怕的是,到了最后时刻,还有一个新功能要添加到这个版本发布。

开发人员经常说:“马上就好,只是一点点改动,放到这个版本里就可以了,肯定没有问题”。结果一测试,发现还有缺陷,只好延迟发布,然后再测试,又发现问题。来来回回又用了一周时间,这个版本才能发布。

保守一点估计,我认为,现在国内软件公司中,仍旧有50%左右的公司处于这种状况,但对于领英来说,他们认为,这是无法忍受的。

第一 ,开发人员不能忍受,因为加班太严重,压力太大。

第二 ,产品经理不能忍受。因为他们希望能够更多地尝试新的想法,更快得到真实的用户反馈数据。

第三 ,管理者也不满意,因为没有办法调动资源,所有资源一直在救火。人员压力大,离职率就高,团队就很不稳定

所以,2015年的时候,领英启动了一个项目,叫“航海家”。这个项目对整个领英产品做了改造,同时也希望变换一种产品研发工作方式。于是,制定了一个目标:3×3×3。

第一个3是指 :每周Beta (测试) 发布3次 (周一、周三、周五) ,将新版本推送给外部测试用户。如何实现这一目标呢?通过实现第二个3来完成这一目标。

第二个3是要求 :每天发布3个Alpha版本 (上午11点、下午1点和4点) ,即每天都有三个内部版本,给公司内部人员体验。其目的是让内部人员更快更早地拿到新增的功能进行体验。那么,又如何实现这一目标呢?

第三个3 是从开发人员提交代码到能够拿到一个试用版 (Alpha版本) 给内部人员进行体验,这个时间长度为3个小时。

这个时间包括代码提交后,code review (代码评审,指在软件开发过程中,通过对源代码进行系统性检查的过程) ,经过静态扫描、构建发布包、单元测试、界面测试、场景测试,然后是Alpha发布。

下图是团队的工作流水线。

3.DevOps的文化与工具

我认为DevOps运动最重要的是文化与工具。文化里包括:数据验证文化、快速反馈文化、工程质量文化。工具构建时需要考虑的因素是:员工自服务、让机器等待、流程自动化。

思考的方向是自上而下,要做到数据验证文化,就必须有快速反馈文化;要有快速反馈文化,就必须有工程质量文化。

▲ 长按图片分享给需要的人

所以顺序很重要, 你思考的方向是从上到下的,但是,行动方向应该是自下而上的

工具部分也是一样。什么是员工自助化?就是当一个团队成员要完成他自己一项工作时,不需要其他人的协助。

比如说,当开发人员想发布版本时,要找测试人员测试、运维人员审批。假如,我能够自助完成这些审批流程背后的各类要求的话,我就不需要找很多人,这样,所有人都节省时间。

二、持续交付2.0之双环模型

1.持续交付2.0

持续交付2.0的起点是业务价值探索,而非软件需求,强调业务问题的完整闭环。

也就是说,所有的起点都是从想法 (问题) 出发,设定目标,分析洞察,找出尽可能多的解决方法,然后开发上线、数据评测,得到数据之后,决定是发布还是下架,然后再次快速迭代。

持续交付2.0的双环模型强调的是从问题出发,所有的事情都应该从问自己下面的问题开始。问题是什么,目标是什么,有多少种方案,如何从这些备选方案中选择。这部分才是真真正正我们需要首先思考的问题。

持续交付1.0和DevOps的落地通常都聚焦在从需求开始,而不是从产品想法开始,我们都在努力地把我们的需求变成软件,发布给用户,但是并没有真正形成完全闭环。

我并不是说后面这个验证环不重要,恰恰相反,我认为非常重要,但是其更多的是在讨论如何正确的做事。

亚马逊的贝佐斯和Facebook的扎克伯格,他们所坚信的产品理念是“一万次实验法则”。这两句话真正体现硅谷互联网公司产品的研发理念。

我认为,只有在先进的研发理念指导下,才能够设计出先进的产品研发模式。为了支撑先进的产品研发模式,就必须重新定义这个流程模式中各环节的输入和输出,以及职责与参与者和决策机制。

这样,才能知道每个环节应该做什么事情,要做到什么标准,以及如何达成这些标准。

当我们提出问题时,事实上我们是在问:

客户在哪儿?

他遇到了哪些问题?

现在他们是怎么解决这些问题的?

为什么你会认为你的解决方案比现在的解决方案优秀?

无论进军2C领域,还是2B领域,你都逃不开这几个问题。所有的问题都会有一些解决方案,你的方案到底差距在哪里?

当你自己在头脑中谋划出这些问题后,下一步是回答类似下面的问题:

如何衡量你找到了你想要的这些客户?

如何衡量你的方案特别优秀?

这就是在定义明确的目标,即:找到问题后,再去找到衡量问题是否被解决的标尺,怎么看你达到了你的目标。如果这两个问题清楚了,才会有下一步的问题:

到底有多少种途径找到我的目标客户?

他的问题有多少种解决方案?

这些解决方案的投入和产出到底是如何评估的?

正如《这就是OKR》一书的作者约翰道尔所说:“解决一个业务问题,一定并不只有一种方案。”

事实上,人们经常会沉迷于自己想到的解决方案,因为解决方案是我们自己想到的,像自己的孩子一样。谁会说自己的孩子不好呢?

科学探索环节就是为了破除心中的障碍,一定要考虑问题到底有多少种解决方案。如果你认真地回答前两个环节的问题后,你能找到比你现有的解决方案还要好的解决方案。

在“共创”这个节点,你可能找到了10个、20个,甚至50种解决方案。那么,如何决策哪些方案应该实施呢?此时,“精炼”环节就十分重要了。

我为很多产品研发团队提供咨询时,总会去提到一个问题:你现在遇到最大的困难是什么?基本上会得到三个固定 回答:

第一,我们需求太多。

第二,我们人手不够。

第三,我们这个软件系统特别复杂。

试想一下这三个答案有没有解决办法?……不用想了……大部分情况下,这三个问题都不是真正需要解决的问题,它们只是结果或者表象,而不是问题。

▲ 长按图片分享给需要的人

如果一个产品没有很多很多的需求,说明这个产品已经快死掉了。

任何一个组织都不会雇佣超过它认为的最大员工数。另外,也没有哪个负责人会说自己负责的系统是简单的。

想要解决上面的问题,最重要的就是“精炼”环节。从众多可能的解决方案中选择其中一部分,进行快速验证。

快速验证则是后面环节要解决的问题,通常来说是只要以正确的方式做事情,你就能够做到快速,但前面更多的是科学分析和探讨如何选择正确的事情来做。

这两个环是相辅相成的。如果快速验证环的成本足够低、足够快,就可以在相同的时间内做出更多次的科学探索。

如果科学探索环产出的解决方案是一个能够快速实现的方案,也会令快速验证环的反馈时间更短。

假如探索环产生的解决方案就是个巨无霸,也会导致后面的快速验证运行很慢,导致结果反馈周期较长。

就像我们有一份搬砖的工作。如果在科学探索环里,确定的是“一块砖”,那就很容易在快速验证上完成了。

但如果是“一整吨砖”,你的快速验证环的运用很难比“一块砖”时更轻盈。

▲ 长按图片分享给需要的人

正如腾讯公司副总裁曾宇所说:

敏捷,就是极致地缩短每一次尝试、反馈和决策的时间

对技术来说:更厚的积累;

对组织来说:是更小的团队和更合理的研发运营模式;

对个人来说:是更强的工程技术素养。

2.持续交付2.0的两个关键点

精益思想 系统思考 是持续交付2.0的指导思想与落地工具。精益思想的核心是“消除一切浪费”。软件产品的生产浪费在哪里呢?就是那些无用功能、等待、工作项的移交、库存、软件缺陷等。

我们的日常活动有两种类型。一是增值活动,二是浪费。在“浪费”这个类型中,又可分为“必要的浪费”和“不必要的浪费”。我经常问大家:“测试是不是浪费?”很多人认为不是。

然而,从客户价值出发,“测试活动”就是一种浪费,但对于企业来说,它是有价值的活动。所以它应该被归到“必要的浪费”这一类。项目管理也是一样。

我们要消除所有不必要的浪费,同时,尽可能减少必要的浪费。如果你秉持消除一切浪费的思想,你就可以从另外一个视角审视当前的软件开发流程和生产流程。

当年,我与同事去某公司做持续集成实践的指导时,客户会问:“为什么我们应该快速地修复失败的构建?我们的发布时间还在两个月以后呢……”

因为在持续集成实践中要求,如果你的某一次构建失败了,是不允许其他人提交新代码的,因为此时再提交新代码,构建也会失败。并不能发挥持续集成的快速反馈作用。

如果修复构建所用的时间长,就会累积很多未提交代码,而潜在问题的可能性和数量就会增加,而这可能就会导致下一次构建失败的可能性变大。修复就会花费更长的时间。这就形成了一个渐进增强环了。

在这个渐进增强环中,你唯一能够有所行动的点就是在“快速修复”这里,其它节点都只是结果,可以观察,但无法采取行动。

修复的方式有两种 :一是再次提交代码,把问题修复,二是把引起问题的代码删除,这也是最快的修复方法。

3.持续交付2.0里面的四大基本工作原则

① 坚持少做

为什么要坚持少做呢?大家刚开始就会纠结这一点。

比如“我为什么要坚持少做?我有100个人为什么还要坚持少做?”其实他的意思是说“我有100个人,怎么能只做一点点事情呢?”

▲ 长按图片分享给需要的人

事实上,持续交付2.0中所强调的“坚持少做”,并不是说100个人做一点点事情,而是说 当你在想到底哪一件事情对你最重要的时候,你才能够真正思考要投入多少资源把它完成

任何人都想把他想到的所有事情做完,但你永远有做不完的事情 (需求) ,永远有事情在等着你。

所以,作为一个管理者,唯一要思考的就是怎么少做。只有坚持这一个观点,才能发现真正重要的东西。

② 持续分解任务

想要“少做”,就必须将大问题持续分解成多个小问题,在其中找到那几个真正最重要的问题,把它们挑出来,然后去做。

而在做的过程中,因为问题比较小,所以也能够得到快速反馈,从而验证自己最初所定义的问题是否正确。

例如,我们在开发软件需求的过程中,可能某个大需求需要做5天,那是否意味着你要在五天之后全部做完,才提交代码变更呢?

显然不行,因为你没有和其他人的工作成果 (他们的代码) 进行集成,你就没有得到真实的反馈。

所以,对软件开发工程师来说,也要将这个需求分成很多次的少量代码提交,快速验证每行代码是否正确,是否影响到别人的工作了。

这也是精益思想中所强调的,做好每一个环节的质量管理,避免在后期发现问题,带来更大的浪费。

③ 坚持快速反馈

如何支撑软件的快速交付与快速反馈呢?当然是加快交付频率,获取更多的机会将功能及时发布到生产环境中,但是在保障软件质量的前提下。一旦频率提高,就不用过分在意功能完成了多少。

这种方式会让工程师很高兴,因为他们不需要在版本发布前加班,火急火燎赶进度。产品经理也很高兴,因为他不需要再等一个月才把自己设计的功能发出去。

▲ 长按图片分享给需要的人

所以,事实上他的产品研发理念改变了整个的研发模式和思考模式,即: 只有高频短周期发布,才有很多机会可以试错

并且,对于大团队来说,尽量减少没有必要的沟通,可以减少很多浪费。

④ 持续不断改善

“持续不断的改善“这一点来自于丰田管理。 任何时候、任何地方你都可以改善。

没有人能够一下子立即消除所有的浪费,它是一个漫长过程,甚至可以说,无法消除所有的浪费。

但是,我们必须学习,如果识别这些浪费,并在下一个目标里程中,将消除这些浪费做为正式目标。从而不断提升能力,消除它们,这也就相应增加了更多的增值活动时间。

持续交付2.0本身关注的是端到端的业务协作,并不仅仅是产品开发、测试和运维,还要与市场、业务联动。

持续交付2.0应该成为企业的组织能力,应该具有可持续性。这一点是我特别要强调的一点。

▲ 长按图片分享给需要的人

可持续性并不是每周冲刺加班,那样很难具有可持续性。因为 最开始可以拼体力,但一段时间之后, 只拼体力就无法做到可持续了

我再次强调的是,我们要能够提供真正的业务价值,这个才是目标。

4.持续交付七巧板

我将持续交付2.0中的工作分成三个大领域 (基础设施、组织管理和软件架构) ,其中基础设施又细分了五个子领域。

并用“七巧板”这个传统玩具做隐喻。即:每一个企业都要根据自己的目标和实际情况,拼出自己不同阶段的不同解决方案。

每个企业的解决方案都有差异,但前提是你要找到你的方向和目标。每个企业都可以去学习别人,但决不能照搬别人。

你可以在这个七巧板中通过不同的组合,挑选任意一个模块,不断改进,甚至改变很多模块,走出自己的路。

*文章为作者独立观点, 不代表笔记侠立场。

笔记侠好课推荐

如果好看,点击“在看”哦~

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章