阿里云效平台 关注 云效

阿里敏捷实践| 4个迭代,从批量交付向持续交付转型

  1. 云栖社区>
  2. 阿里云效平台>
  3. 博客>
  4. 正文

阿里敏捷实践| 4个迭代,从批量交付向持续交付转型

云效鼓励师 2018-10-11 19:03:10 浏览1243 评论0

摘要: 忙不完的事情,解不完的bug,每次发版都得集体熬个大通宵,干得多,结果还不好。你是否正处在这样的漩涡之中?本文将用4个迭代,带领你的团队走出困境。

导语


忙不完的事情,解不完的bug,每次发版都得集体熬个大通宵。干得多,结果还不好。阿里内部某研发团队就正处在这样的漩涡之中。


在这样的背景下,阿里云效敏捷教练团队受邀,和该研发团队一起,通过4个迭代的持续改进,研发效率和质量取得了显著提升:

  • ·       大幅缩短了需求开发时间,从一个月变为一周;
  • ·       从无可用测试环境到具有稳定的测试环境
  • ·       从无自动化测试用例到50%的模块实现测试自动化
  • ·       从手工部署到自动化部署

 

这一切是如何做到的呢?阿里云效敏捷教练蔡春华将在本文为你一一道来。


阅读本文大概需要10min,建议收藏细读。

 

研发困境 

 

首先我们了解了该团队的组织结构以及各人员的工作内容。如下图所示。

87218fa3c9588b4ef6827c3d45a5ec557d072b5f

 可以看到,产品、前端 、后台、测试属于不同的职能部门。这是一个非常普遍的组织形式——职能型组织。

在这样的组织形式中,通常会存在以下问题:

  • ·       工作之间相互依赖,彼此等待;
  • ·       职能团队之间的目标不一致;
  • ·       需求变动沟通不及时;
  • ·       工作完成标准不一致。

 

其次,集中批量集成发布,时间紧、效率低。团队的迭代周期一般是一个月,需求从准备开发到待测试的周期是4周,测试时间要花掉1天,发布一般都安排在周五晚上,大约第二天天亮才能发完,整个发布过程完全靠工程师手工完成。我们发现测试和发布的时间相对集中,时间紧,而且是完全手工操作,出错的可能性很高。

 最后,测试守护薄弱,无法做到有信心发布。因为产品需要发布到公共云,目前集团没有相应的工具可以帮助公共云的发布;并且,产品的构建部署过程均无工具支持,需要手工打包和部署。在测试守护方面,有一些遗留的单元测试,但是这些单元测试根本就无法运行起来;而集成测试的运行的用例数基本为零,虽然有同学努力在加新的用例,但目前这些用例还无法运行,整个测试守护过程非常薄弱。

 这么多的问题,该从哪里入手解决呢?下面分享一下我们的4个迭代措施。


迭代 1 :可视化研发工作,寻找问题的关键点


通过跟团队的沟通,我们发现团队同学其实已经或多或少地意识到了这些问题,并且他们也做了一些改进的尝试,但是因为各种原因没有继续下去,导致团队现在对改变没有什么信心。

在这样的情况下,需要在尽量少改变团队现状的情况下,去取得一个比较好的效果。

 要解决问题,必须让大家能够站在全局的视角来分析现状,从而找到核心问题。因此,我们通过可视化物理板以及站会,把研发团队的工作进行了可视化。

1.1 利用可视化物理板与站会,透明团队工作

初期的可视化板,主要是展现出团队当前迭代要做的工作以及每天出现的问题。过程中对物理板的规则并未做太多约束,主要起到可视化的作用。这样一方面降低了可视化工作的门槛,让大家愿意使用,另一方面,能把大家最真实的工作状况给反映出来,如下图所示:

 

761103544d39456a0a065e9e298b81a6da2cb361

 

物理板展示的同时,配置了每日固定站会,时间控制15分钟,要求产品、前端、后端开发、测试一起参与。每人轮流对所有人透明每天完成的工作、接下来要完成的工作、遇到的问题。

1.2 通过可视化物理板,暴露团队的测试瓶颈

物理板与每日站会,很清晰地展现了当前迭代需要完成的工作,团队在需要完成的目标基本上达成一致。并且在每日站会的过程中,因为每日不断需要沟通的需求,团队能及时调整并更明确研发流程规划。

 同时我们发现,在项目初始阶段,几乎所有的需求在同一时期投入到了开发中;大约在中期时,有很多任务慢慢地移到了自测阶段,但并没有需求可以移到待测试阶段;直到临近发版前1-2天,大部份需求才一起移到了待测试。整个过程中,测试同学除了了解当前准备开始的工作以及准备测试用例外,一直在等待测试工作中。如下图所示。

 44d154b71f4a5ad0c3984239e7173b8583fcf080

为什么测试同学每天都在等待接受新的工作需求,但总没有需求可以提测呢?在离发版的前1天,研发才提测。对测试来说,测试时间很紧迫,验证出来的bug也来不及修,这就会造成上线后仍然需要有一周时间来修复bug。

 通过可视化物理板,研发团队很快明白了测试瓶颈的原因——我们是不是可以尽快让测试参与工作呢?


迭代 2 :合理拆分需求,让需求变小、独立、可测试


如何让测试尽快参与工作呢?我们发现,需求之所以无法进行测试,是因为需求的各个子任务与其他需求之间的子任务相互依赖造成的,多个需求之间耦合在一起,相互等待。其结果就是,所有需求都得一起开发完成才能测试。为什么它们会耦合在一起呢?

 我们发现,当前的需求拆分方式是以组件或模块来进行拆分的。例如,一个需求,首先从实现的角度,把它按模块拆分成多个需求,对模块的实现,再对该模块需求拆分成若干个任务。

 但是,从测试的角度来看,需求应该是端到端可测的,这样拆分出来的模块需求不能独立测试,它仅局限在这个模块的范围。

 那么如何有效地来拆分需求呢?

 2.1 从业务目标出发,由外而内逐步拆分需求

什么是有效的需求拆分呢?需求拆分完之后,它必须还是需求,它必须要:

  • ·       足够小:这样才能做到可持续交付;
  • ·       端到端:这样才能保证交付有意义的价值;
  • ·       独立性:便于持续集成和灵活安排;
  • ·       整体性:拆分完仍能看到整体的结构。

 

要做到有效的需求拆分,需要:

1.澄清目标:需求相关方要共同理解需求的背景,为什么要做需求的原因;

2.梳理需求上下文及用户的使用场景;

3.列出用户操作及操作步骤。

我们可以从一个具体的例子来了解整个拆分的过程。

需求描述:组件商业化

需求背景:某组件需要接入到E产品,以按量计费的形式提供服务,并通过阿里云统一按流量收费;组件接入到E产品后,用户通过访问产品页面开通/暂停/使用组件

如果我们按照上面描述的方法进行拆分的话,应该:

(1)澄清目标

组件要从免费的形式转变为按量计费的形式。组件要用统一的接入方式;用户在产品页面上可以看到已经接入的组件,在页面上开通/暂停组件,产生的费用,通过阿里云来进行计费并反馈给用户。当用户欠费时,该组件直接暂停使用,提示用户进行缴费。

(2)列出上下文及用户使用场景

 

1b90ccb53d3f959f0046fa9e8e27b9f2e31bee5f

系统上下文

 

 

7ea85d6ae5d3167c7baa510df71fcad6403dca61

用户使用场景(用例)

 

(3)列出用户操作及操作步骤

 7f852d4a6f72a24bdcbe4130a246a3164ad9e94c

(4)按用户端到端的使用拆分为4个需求:

  • ·       组件成功接入到产品,能在产品上展示;
  • ·       用户能通过产品查看已经接入的组件;
  • ·       用户能使用组件功能,能根据使用数据提示已使用金额;
  • ·       用户如已欠费,无法使用组件功能。


其中,组件成功接入到产品需要依赖组件方技术改造,也是后续几个需求的依赖,因此这个需求为其他需求的依赖,需要最高优先级需求。

在整个拆分的过程,其实是需求从目标出发,逐层澄清分析的过程,需求拆分并不直接产生价值,产生价值的是需求分析本身,而需求拆分是需求分析的副产品。

当需求拆分完成之后,如何让需求顺畅流动起来,持续开发呢?

2.2 完善看板规则,前后职能拉通,任务左右对齐

需求除了是交付的单元,同样也是沟通的载体。在整个端到端的交付过程中,经过有效拆分的需求,可以更便捷地进行协作,与此同时,看板的设计也需要做出相应的调整。

(1)明确需求准入规则

进入开发就绪前,必须进行需求拆分,并且明确验收标准,否则不能进入开发。每个需求拆分后的工作量大小不应超过1周,对应需求的每个任务工作量不应超过1天。

(2)前后职能拉通,任务左右对齐

通过看板,呈现需求端到端的交付过程,各职能以需求顺畅流动为共同目标,从需求层面拉通各职能之间的协作。同样,在需求的开发阶段,分解成不同的任务列,同一需求的各任务被安排在同一泳道(行)上,做到任务在需求层面的对齐。如下图所示。

 8c0d6f8f050956df13467e1df16702cc4788d610

 采用新实践的团队,需求做到了有效拆分,提前一周完成了所有需求的开发以及测试验证工作,上线后缺陷比以往显著减少。而未做改变的团队,在发布前一天,仍然有代码未合并。

合理的需求拆分,使得持续测试成为可能。现在由于测试工作变得日常化,基本上迭代开始一周后就有需求进入提测,而这时,却没有一个与线上相一致的测试环境。那么环境就成为了当前团队的一个重要瓶颈。


迭代 3 :构建测试环境,恢复端到端持续测试


要做到持续测试,需要与之相匹配的测试环境。我们发现测试环境主要存在以下这些问题:

  • ·       测试环境中,服务组件之间的依赖多,准备一套环境让这些组件全部跑通不容易;
  • ·       某些外部依赖无法搭建线下环境;
  • ·       整个构建部署全由研发手动操作,缺少环境监控的有效手段;
  • ·       测试环境服务器部在售卖区,与阿里内部不能互通访问。

 

问题很多,但解决的方法只有一个,即首先必须修复环境,让环境可用;其次,需要保证环境持续可用;最后,让集成测试的流程自动化,让规则自动化。


3.1 提高优先级,修复环境,让环境可用

我们发现,环境的问题并不是技术上不可行,而是在研发过程中,环境修复缺少足够的优先级,不能得到足够的投入。当环境问题已经影响到持续测试后,我们在看板中设一个泳道(下图中的青岛VIP),由测试同学把当前测试环境中的问题在这个泳道展现出来,并作为最高优先级由研发同学来修复。并且在站会时,首先去关注环境是否可用。

8f182f348c2aa20a45c865df45adec9c4e683c50

3.2 建立团队环境约定,保证环境持续可用

测试环境由测试同学来守护,做到有效监控、及时反馈、快速恢复(环境坏了要及时知道,知道了要及时将问题抛出来,大家进行修复)。在工具暂时还未支撑时:由开发打完包后,测试同学到固定的地方去取包进行部署,并做基础环境是否可用验证。考虑到验证的时间成本,先添加了一个端到端的用例来进行验证。待一个跑通并且持续稳定的前提下,再增加下一个用例。

部署后测试环境有问题的,测试需要判断是属于新提交代码提交导致的还是本身环境的问题,做到准确定位,新提交代码导致的,由代码合入人修复,本身环境问题指定对应人员修复。

整个环境管理的十六字规则就是:有效监控、及时反馈、准确定位、快速恢复。而这一切得到落地,一是测试的同学负责了环境的守护,二是团队有足够的优先级来响应环境的问题。

3.3 有效利用云效自定义流水线,实现构建部署测试全自动化

为了让环境持续可用,整个流程可以不再依靠人力的管控,团队决定接入阿里一站式研发平台——云效来打通整个发布过程。因此,研发团队与云效团队一起,打通了从云效到售卖区的整个部署流程,形成一个从代码提交、构建、部署、测试和发布的完整流水线,该方案对后续上云的团队也可以借鉴。有了这样的测试环境和流水线,我们从新增一个完整端到端的测试用例开始,逐步完善测试自动化。

3.4 研发流程规则工具化

经过前面几个迭代的改进,团队尝到了改进带来的好处,PD、测试及TL都要求其他研发团队也按照该研发模式进行协作。另外,如果其他团队仍然按照以前的模式进行工作的话,测试环境的稳定性也会难于维系,因此,整个大团队统一切换到新的研发模式中。

大团队的汇入,我们发现需要对原来的规则和模式做一些调整,才能适应大团队的运作,因此,我们将团队的研发过程规则进行了细化,补充和明确了完成标准和提测标准等。如下图所示。

 49448ffacb6f635185f1100157427d95f87c1ddf

 研发流程并非一成不变,应该是一个不断演进调整的过程。规则调整由团队共同商议决定,尤其对于就绪、待测试、待发布几个关键状态的规则定义显得尤为重要,这是因为就绪规则是要控住入口,明确需求是否合理拆分;待测试规则是为了确定提测前是否做过自测,以保证不要一上去就把测试环境给弄趴下了;待发布是要保证发布质量。

当有了可用的测试环境之后,整个CI/CD的流水线打通,并且能够跑通30+自动化用例,该迭代准时发布,开发到测试的时间也缩短为1周。

似乎所有的问题得到了解决,但是,这个时候我们发现每一次部署都会block测试环境120分钟以上,如此长时间的block是什么原因导致的呢?有没有有效的方法可以解决?

 

迭代 4 :环境稳定并持续可用


测试环境被block120min以上,影响了每一次的验证工作。针对所有block的问题进行分析,发现问题有以下几类:

  • ·       新提交代码产生的问题,
  • ·       历史bug导致的
  • ·       测试环境本身未搭建好
  • ·       暂时无法判断原因的

 

分析原因主要是背后的理念,是先开始重要呢?还是先完成重要?我们从两方面进行了改进:

4.1 明确优先级以及需求owner意识

目标是更早的交付价值。每个需求提交应该更早的去验证、集成,再去做下一个需求。 

4.2 bug的修复流程

快速排查问题:

  • ·       测试环境问题,测试同学先做基本的排查;
  • ·       在云效发布工具上更多的展示发布单的反馈状态与信息,帮助排查;

缺陷消灭:

  • ·       新Feature引入的bug,研发同学默认高优先级解决,以加速单个需求的快速流转;
  • ·       整理一份当前测试环境功能点的Feature列表及其对应的Owner;
  • ·       遗留历史bug,版本owner组织review一遍,判断影响,影响度不大,修复成本高的,产品进行排期;

提前预防:

  • ·       提测前自动触发轻量级版本的自动化测试;
  • ·       代码强制codereview,代码合到测试分支的前提是自动化测试用例通过。

第四个迭代结束,测试环境已经明显不再有block的现象;团队研发流程也比较顺畅,迭代中也解决了异地站会同步问题。并且自动化测试用例已经覆盖主要核心业务。经团队评估,团队有能力在白天发布,发布熬夜已经不是团队的困扰了。

 

总结


通过4个迭代,研发团队达到了很多0到1的效果。从不被看好到大家都更有信心成为更高效的研发团队,最主要的原因是:大家能在同一高度来看到团队共同的问题,每次选择一个当前最迫切最重要的问题来改进,不贪多。

4个迭代后,通过数据我们来看整体的改进效果:

1.自动化测试释放人力的变化

以前每轮回归测试,需要7个开发*4小时的手动测试,通过自动化用例的添加,在回归测试人力上已经释放了2个研发人力。

2.研发周期时长明显缩短

从团队开始开发到提测从原来的4周缩短到了1周;测试的时间更充分了;限制了提测最后时间点,需求的发布时间也更充分,再没有通宵发布的情形。

3.软件质量也得到提升

从图中所示,由于需求的拆分、环境的稳定、让每个需求可以提前测试创造了有利的条件,测试时间更充分,缺陷在测试期间暴露得更多,因此遗留到线上的缺陷也就降低。

研发流程并非一成不变,应该是一个不断演进调整的过程。规则调整由团队共同商议决定,尤其对于就绪、待测试、待发布几个关键状态的规则定义显得尤为重要,这是因为就绪规则是要控住入口,明确需求是否合理拆分;待测试规则是为了确定提测前是否做过自测,以保证不要一上去就把测试环境给弄趴下了;待发布是要保证发布质量。

86467d88141977b0d5a1500e7eedc5c790aee08c


最后

4个迭代只是改进的开始,未来,仍然有许多的问题需要团队持续改进。但是,只要路走对了,就不怕远。

作者介绍:

蔡春华(花名古茹),阿里云效团队敏捷教练,阿里百年技术讲师,曾支持阿里安全、阿里中台等多个阿里事业部敏捷转型。

这是彩蛋的分割线

评论区说出你所在团队在研发协同中遇到的问题,你将得到云效敏捷教练的亲自回复~


【云栖快讯】阿里云栖开发者沙龙(Java技术专场)火热来袭!快来报名参与吧!  详情请点击

网友评论