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

导语

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

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

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

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

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

研发困境 

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

 能够看到，产品、前端 、后台、测试属于不一样的职能部门。这是一个很是广泛的组织形式——职能型组织。

在这样的组织形式中，一般会存在如下问题：

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

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

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

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

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

经过跟团队的沟通，咱们发现团队同窗其实已经或多或少地意识到了这些问题，而且他们也作了一些改进的尝试，可是由于各类缘由没有继续下去，致使团队如今对改变没有什么信心。

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

 要解决问题，必须让你们可以站在全局的视角来分析现状，从而找到核心问题。所以，咱们经过可视化物理板以及站会，把研发团队的工做进行了可视化。

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

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

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

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

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

 同时咱们发现，在项目初始阶段，几乎全部的需求在同一时期投入到了开发中；大约在中期时，有不少任务慢慢地移到了自测阶段，但并无需求能够移到待测试阶段；直到临近发版前1-2天，大部份需求才一块儿移到了待测试。整个过程当中，测试同窗除了了解当前准备开始的工做以及准备测试用例外，一直在等待测试工做中。以下图所示。

为何测试同窗天天都在等待接受新的工做需求，但总没有需求能够提测呢？在离发版的前1天，研发才提测。对测试来讲，测试时间很紧迫，验证出来的bug也来不及修，这就会形成上线后仍然须要有一周时间来修复bug。

 经过可视化物理板，研发团队很快明白了测试瓶颈的缘由——咱们是否是能够尽快让测试参与工做呢？

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

如何让测试尽快参与工做呢？咱们发现，需求之因此没法进行测试，是由于需求的各个子任务与其余需求之间的子任务相互依赖形成的，多个需求之间耦合在一块儿，相互等待。其结果就是，全部需求都得一块儿开发完成才能测试。为何它们会耦合在一块儿呢？

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

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

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

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

什么是有效的需求拆分呢？需求拆分完以后，它必须仍是需求，它必需要：

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

要作到有效的需求拆分，须要：

1.澄清目标：需求相关方要共同理解需求的背景，为何要作需求的缘由；

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

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

咱们能够从一个具体的例子来了解整个拆分的过程。

需求描述：组件商业化

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

若是咱们按照上面描述的方法进行拆分的话，应该：

（1）澄清目标

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

（2）列出上下文及用户使用场景

（3）列出用户操做及操做步骤

（4）按用户端到端的使用拆分为4个需求：

• 组件成功接入到产品，能在产品上展现；
• 用户能经过产品查看已经接入的组件；
• 用户能使用组件功能，能根据使用数据提示已使用金额；
• 用户如已欠费，没法使用组件功能。

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

在整个拆分的过程，实际上是需求从目标出发，逐层澄清分析的过程，需求拆分并不直接产生价值，产生价值的是需求分析自己，而需求拆分是需求分析的副产品。

当需求拆分完成以后，如何让需求顺畅流动起来，持续开发呢？

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

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

（1）明确需求准入规则

进入开发就绪前，必须进行需求拆分，而且明确验收标准，不然不能进入开发。每一个需求拆分后的工做量大小不该超过1周，对应需求的每一个任务工做量不该超过1天。

（2）先后职能拉通，任务左右对齐

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

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

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

迭代 3 ：构建测试环境，恢复端到端持续测试

要作到持续测试，须要与之相匹配的测试环境。咱们发现测试环境主要存在如下这些问题：

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

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

3.1 提升优先级，修复环境，让环境可用

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

3.2 创建团队环境约定，保证环境持续可用

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

部署后测试环境有问题的，测试须要判断是属于新提交代码提交致使的仍是自己环境的问题，作到准肯定位，新提交代码致使的，由代码合入人修复，自己环境问题指定对应人员修复。

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

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

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

3.4 研发流程规则工具化

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

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

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

当有了可用的测试环境以后，整个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.软件质量也获得提高

从图中所示，因为需求的拆分、环境的稳定、让每一个需求能够提早测试创造了有利的条件，测试时间更充分，缺陷在测试期间暴露得更多，所以遗留到线上的缺陷也就下降。

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

最后

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

本文做者：云效鼓励师

阅读原文

本文为云栖社区原创内容，未经容许不得转载。