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

导语

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

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

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

这一切是如何做到的呢？阿里云效敏捷教练蔡春华将在本文为你一一道来。
阅读本文大概需要10min,建议收藏细读。

 

研发困境 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

1.2