|
|
51CTO旗下网站
|
|
移动端
创建专栏

如何在2周内交付85%以上需求?阿里工程师这么做

在 什么是真正的敏捷开发?文章里,我们讲述了什么是真正意义的敏捷开发,如何去衡量。今天,阿里资深技术专家何勉老师,继续带领我们探索,如何以流动效率为抓手,提升持续交付的能力。

作者:何勉|2018-11-02 15:53

在 什么是真正的敏捷开发?文章里,我们讲述了什么是真正意义的敏捷开发,如何去衡量。今天,阿里资深技术专家何勉老师,继续带领我们探索,如何以流动效率为抓手,提升持续交付的能力。

提升持续交付能力

最近我们在阿里内部做团队效能改进时,提出了称之为“2-1-1”的愿景,得到了不少部门的认可。什么是211呢?“2”指的是交付周期2周——85%以上的需求可以在2周内交付;第一个“1”指的是开发周期1周——85%以上的需求可以在1周内开发完成;第二个“1”指的是发布前置时间1小时——提交代码后可以在1小时内完成发布。

今天,很多团队离“211”还是有距离的,特别是这个“2”,它涉及到整个组织各职能,和部门的协调一致,紧密协作。一小时的发布前置时间,则需要持续交付流水线,产品架构体系和自动化测试、部署等有力保障。达成“211”并不容易,但它体现了组织提升持续交付和快速响应能力的目标,树立了持续改进的方向,因此我们才把它作为愿景。

注:以上理念也将落地到研发工具云效(阿里内部叫Aone),从交付流程、交付结果、交付质量等数据也可在云效的度量功能中查看。

问题是我们如何才能达成这一目标呢?让我们先看一幅漫画。

这是一个酒吧,路灯下醉汉在找什么东西,很长时间过去了,警察一直看着他,终于忍不住走上前,问道:“你在找啥?”醉汉说:“找我的钥匙。”警察看了一下钥匙好像不在这,就问:“钥匙是丢在这吗?”醉汉说:“不是。”警察奇怪地问道:“那你为什么在这找?”醉汉回答道:“只有这儿能看到啊 。”

钥匙(key)英文也有关键的意思。光照亮的地方却不是关键所在。我讲这个故事,是为了说明研发中一个常见的问题——在光照亮的地方,而不是关键所在的地方寻找答案,当然不会有结果。那研发过程的关键所在究竟在哪里呢?

《The Principles of product development flow》一书的作者Don指出:“在产品开发中,问题的关键几乎从来不是停滞的资源,而是停滞的需求。”这是什么意思呢?产品开发的最终目的是交付价值,那我们就必须让价值交付的过程顺畅起来,也就是让价值流动顺畅起来。计划、管理、协调活动,以及资源的配置等等,都应该服务于价值的流动。价值流动是目的,资源忙起来不是。

现实中我们更多关注资源是否停滞,人是否闲着,但真正的问题并不在这儿。真正的问题是需求的停滞,需求在各个阶段的积压——如分析阶段、测试阶段、发布阶段等等。需求不能顺畅流动才是真正的问题所在,也就是我们所说的关键所在。

为什么我们往往对需求的积压很少关注?因为它很难看到,不是光照亮的地方。我们很难觉察(至少很难即时察觉)需求的停滞、积压和返工,而那才是改进价值交付的关键所在。

要改进端到端的流程,我们必须看到价值端到端的流动过程,在哪里出现了积压和停滞。为此,改进的第一步,就是要让光照亮关键所在——可视化端到端的价值流动过程,基于价值流发现流动过程中的问题。

看一个例子,它是来自某个产品团队看板。看板中蓝色卡片的是需求。让光照亮关键所在,就是要让需求流动的端到端过程可视化。需求从“选择”开始,所谓选择是指从众多的市场机会中选择这些需求开始开发。选择之后是流程中的其他阶段,比如需求的设计、开发、测试、验收等,直至发布,这是一个端到端的过程。

我们单独看“开发中”这个阶段,在这里需求被分解成为任务——图中黄色纸条。任务与其所属于的需求处于同一行中,我们把这样的行称为泳道。泳道的首列(蓝色纸条)是需求,下属任务(黄色卡片)按模块组织在一起,如前端、后端或其他依赖的外部模块,其中任务的最后一列代表完成状态,所有任务完成后,需求进入下一阶段——待测试。

端到端可视化需求的流动过程,从需求被选择开始,直到发布结束。这让我们能即时看到问题,如:需求是否顺畅流动,是否发生了停滞和积压,是否有瓶颈。这就是所谓:光照亮了问题所在。

除此之外,我们还要保障价值流动的过程质量,把交付质量内建到开发过程中,而不是依赖最后环节的测试。为了做到内建质量,我们需要明确定义需求流动的标准,上图显示了需求进入开发环节要满足的输入标准,在这个例子中,它被定义为:

1)需求的用户使用流程和验收规则清晰定义;

2)依赖方能够被识别;

3)大的需求拆分成在两周以内或者一周以内的小需求,等等。

我们还可以定义其它阶段的规则,如开发输出(也就是转测试)的规则。这也是照亮关键所在一部分。

照亮关键所在,看到需求端到端流动的过程,以及流动中的问题和瓶颈是第一步。更关键是看到问题后要怎样做?以可视化端到端的价值流动为基础,我们希望价值能够顺畅流动,从左到右,不要发生停滞和积压。如何做到呢?让我们再看一个故事。

图中这位叫潘季驯,他是明朝治理黄河的水利专家,被称为“千古治黄第一人”,我们今天要讲的就是他治理黄河的故事。治黄河难,难在泥沙不断淤积。清淤是治理黄河的传统办法,问题是清了又会淤,年复一年。大批的河工聚集,又为造反提供条件,元朝的覆灭就与之关系甚大。不治则生灵涂炭,治则劳民伤财,这是摆在历代统治者面前的两难决定,明朝也不例外。

嘉靖到万历年间潘季驯四次临危受命治理黄河,取得前所未有的成效,并总结了切实可行的方略,其中最为重要的思想就是“束水攻沙”。什么是“束水攻沙”呢?潘季驯在治理黄河时既没有蛮力清淤,也不是一味地加高、加宽河堤。他反其道而行,收窄河堤——在大堤(称为遥堤)内再修筑一道更窄的堤(称为缕堤),遥堤用以防溃,缕堤用以束水。河堤收窄了,水流的速度就会加快,将沉积的泥沙带走,这就是所谓"束水攻沙"。

“束水攻沙”与产品开发有什么关系呢?“束水”加快了水的流速,也带走了泥沙。对应的,产品开发中我们也要限制并行需求的数量,同样是为了缩短需求从开始到完成的平均交付周期——加快流速,并即时发现和处理交付过程中的问题——带走泥沙。我们来看具体的例子。

在上图中,泳道数约束了并行需求的数目。并行需求减少,需求流动的速度随之加快,从而缩短开发和交付周期。更重要的是,限制并行能更快暴露问题。有限泳道中的需求发生阻塞,很容易被发现。团队必须尽快解决阻塞的问题,才能开始新的需求。而即时解决问题又促进了价值的顺畅流动。

基于端到端的价值流,团队可以更好地管理价值流动。以站会为例,团队在站会上,会去审视需求的状态。这里面有两个策略,一种是从左向右审视,还有一个从右往左审视,大家认为哪个合适?对,大家都说从右往左。为什么呢?因为我们应该聚焦于完成而不是开始,我们应该聚焦于尽快地交付,比如测试中的需求是不是有缺陷,并优先解决这些缺陷,好让需求尽快上线;开发中的需求,有没有阻碍,并即时解决这些阻碍,完成它们。只有这样,新的等待开发的需求才能够开始。

站会的核心是通过审视价值流动,关注需求流动中的缺陷、阻碍、停滞、等待和瓶颈,即时发现和解决这些问题,促进需求更流畅流动。站会只是一个例子,围绕看板的其他活动,比如说度量数据分析和改进行动的制定,都是为了促进价值流动,而价值的顺畅流动是响应能力、质量和效率的保障。

(此电子看板截图来自阿里云云效)

上面举例用的都是物理看板,是为了让大家更有体感。现在绝大部分团队,不管是阿里云,技术中台还是闲鱼,用的都是云效电子看板。经过持续的优化,电子看板操作体验已经与物理看板接近。并且具备物理看板不具备的优势,比如:前面讲到的数据度量都可以自动生成,这对于发现问题和改进很有意义,还有就是与其他系统如文档和发布工具的无缝集成。这是优酷电子看板的截图。

看板帮助团队暴露问题,具体的改进行动还是要落实到不同方面的。我们可以用湖水岩石效应来描述这一过程。这是一个湖,湖里有一些石头。湖水比较深时,石头都隐藏在湖面之下,但其影响是在的;当湖面降低,石头就会渐次暴露出来。

在产品开发中,石头暗喻的是问题,而湖水的深度暗喻交付周期长短(或并行需求的数目)。当需求的交付周期长时,问题被隐藏,我们看到的是平整的水面。只有水位降低,问题才会暴露。

以某个中间件团队的效能改进过程为例。他们原先采用小瀑布的模式,没有持续集成和有效自动化,以月度为周期交付产品,需求在月初集中开始,在月底集中转测试和发布,对外交付质量和效率一直不让人满意,内部的协作也有很多问题,每次发布都异常痛苦,延期的情况时有发生,但大家对问题根源和解决方案却各执一词。

在精益和敏捷开发实施过程中,我们首先做的是可视化价值流动,并以此为基础逐步减小并行需求的数目,力求需求的持续流动——持续小批量的输入、开发、转测试和交付。在减小批量的过程中,问题逐渐暴露。

在这个案例中,为了做到小批量的流动,首先暴露的是需求分析和拆分的问题,也就是如何将需求拆分成可以独立测试、验证和交付的小的单元。通过引入“实例化需求”(一种需求澄清、分析和拆分的方法)等方法,这一问题得到了解决,开发和测试移交的批量明显减小了。

很快新的问题又出现了,测试环境或移交给测试的版本总是不可用,需求还是不能顺畅流动,这时持续交付流水线的建设的重要性就凸显出来。当然持续交付流水线的建设也并不是一步实现的,一开始我们只是打通了管道,并引入了最基本的自动验证,保证测试随时都有一个可用的环境和版本可用。接下来才是自动化对关键功能的覆盖。在其后组织协调沟通,技术架构等问题也渐次暴露。

过程中,我们感受到最大的好处是,尽管解决问题的过程还是比较痛苦,但我们可以集中精力一个时间解决一个被暴露的真实问题,而解决它们也会带来立即可感知的受益,这大大提升了团队持续投入解决问题的动力。

这个团队,多年未能解决的问题,在短短三、四个月内被一一解决,在没有投入额外资源的情况下,研发效能得到根本改善,质量、响应能力都有了质的提升。我对此也深有感触——研发效能改进实践的技术难度,并不比我们平时做的业务系统难。但为什么总是得不到实施呢?这个团队有做对了什么。

这里面的根本问题不是能力问题,也不是意识和态度问题。更重要的是:要让团队看见问题,并且提供合适的路径,一个时间解决一个问题,并且解决问题后要能看到立即的想过。

核心有两个:

第一:“看见”,它的关键是看见系统,看见价值的端到端流动,以此为基础看到问题和改进机会;

第二:“路径”,它的关键是小步快走,但每一步都要有可感知的成果。

图中岩石的高低,从概念上反映了随着并行的降低,问题逐渐暴露的大致顺序。对不同的团队,问题和次序会不同。但相同的是,通过水位的降低,问题被渐次暴露和解决,产品交付的响应能力、效率和质量也会得到提升。我们的目标并不是要把水位降到最低,而是要发现问题,让需求能以较小的粒度顺畅流动,实现顺畅和高质量和持续的交付价值。

总结一下持续交付实践。它关注从需求到开发、测试直至部署和运维这些环节。它的目标可以总结为两个:

第一:让价值顺畅流动,这个我们已经讲了很多。之前讲的实践都能促进价值的顺畅流动,如:看板、反馈改进这些管理实践,故事地图、验收测试驱动开发这类技术实践。

第二:让流动过程更加高效,这个我们前面没有强调。补充一下,其核心是让团队成员只需要关注带来真正价值的业务逻辑,而不需要在其他工作上花费过多时间。

我们看看除了业务逻辑,团队还会被那些工作影响?又如何减少这些工作?这里我们列举了其中的一些:

可靠的交付流水线:让团队不用担心验证和部署的环境,步骤及流程。

容器技术(如Docker):让团队不必过多考虑构建分发及运行环境的问题。

Kubernetes:让团队不用过多考虑容器应用的部署、运行、扩缩容等工作。

Sevice Mesh:让团队不用过多考虑分布式服务的通信。

Severless:让团队不用过多考虑服务器的实体资源。

持续交付价值的能力是互联网时代研发效能的核心。我们介绍了提升持续交付能力的度量,以及以流动效率为抓手提升持续交付能力的实践和路径。

问题是,建立了持续交付能力就可以保证业务的成功吗?显然不是。持续交付能力是快速交付价值、获取反馈并灵活调整的基础。我们还必须以把持续交付能力转化为有效的业务创新,带来真正的业务成功。

【本文为51CTO专栏作者“阿里巴巴官方技术”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

【编辑推荐】

  1. 数据安全在交付中的思考
  2. 企业安全团队中的“灰帽子”
  3. 高效安全团队的7个习惯
  4. 如何提升团队的研发效率?阿里工程师这么做
  5. Apache Flink靠什么征服阿里工程师?
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢