移动团队交叉双迭代的敏捷实践

浏览数：22 / 时间：2015年06月11日

再快点！再多干点！

在这个移动互联网的时代，作为移动开发团队，对“快”这个字看得尤其重要。不仅仅是移动开发团队，其实每个开发团队都在注重团队效率，具体而言，就是关心开发效率和产出。管理者经常会发出这样的提问：还能更快的上线吗？还能增加每个迭代的产出吗？

影响团队效率的因素很多，且往往是综合作用的结果，仅针对更快速的产品上线和增加每个迭代的产出这两个问题，我们尝试对团队正在执行的敏捷迭代过程进行改进，即使用交叉的双迭代模型进行软件开发。

环环相扣的链条

先简述一下我们在传统迭代上的基本情况。

我们的团队是一个Android客户端开发团队，团队角色有产品经理、交互设计师、视觉设计师、开发工程师、测试工程师。各个角色的职责不再赘述。从迭代启动会开始，至交付可上线版本为止，定义为一个迭代，通常的周期是3周。在这个3周的迭代周期当中，前半段以新功能开发为主，后半段以优化和Bug修复为主，通过频繁的开发、测试直至产出可上线版本。

随着产品的快速发展，我们的发布速度还需要进一步提高，理想情况是缩短到每2周能有一个上线版本。当然，不能因为时间短了就减少产出数量，还是要保持每个上线版本有足够多的新功能带给用户。也就是说我们既要减少上线间隔，又要保持以前的产能。

带着这样一个“又想马儿跑，又想马儿不吃草”的挑战，我们需要找出此前迭代中影响这两个因素的问题，然后再尝试进行针对性的调整。

在这样一个十多个人的团队中，我们注意到沟通成本是非常高的，客户端产品的快速变化需要信息在各角色之间共享和互通，并且形成一致的理解。站会同步的更多是昨天完成的情况和今天将要进行的工作，但今天工作中的细节仍然占据了大量的沟通时间。即使在开发工程师内部，也会由于接口变化、联调、代码检查等花费很多时间。如何有效的减少沟通，此前其实已经采取了一些措施，比如消息群、邮件组、提倡面对面沟通等。但还是常常能听到各角色抱怨“白天净说话了，只能晚上加班”的话，这样不仅消耗了迭代时间，也对产出有负面影响。

降低沟通成本的方法之一是拆分团队，将大团队变小，减少沟通的参与者，这样是可以提高开发效率的，能够做到花同样多的时间产出更多的代码。

另一方面，如果为了每2周上线一个版本而将迭代周期缩短到2周，人少了，时间短了，就会在产出上有降低的问题。为了保证产出，在人少了的同时如果把迭代周期延长为4周，就可以做更多的开发工作。如果我们再让两个小组交叉2周，就可以保证每2周有一个交付版本。

通过前文的分析，我们形成了如图1所示的交叉双迭代模型。

图 1交叉双迭代模型

我们将一个开发团队分为两个小组A和B，A组先启动进行为期4周的一个迭代，即图中的一个Sprint。在迭代进行到一半的时候B组再启动为期4周的迭代，每个组各自做迭代内容的开发，形成交叉的双迭代节奏。这样从宏观上看，产品由每个小组交替发布，发布的周期是2周，每个小组的迭代周期由原来的3周延长到4周。随着时间的推移，重复这个迭代过程。

方法总比问题多

经过这样的迭代调整，从模型上看虽然满足了版本更快上线并且包含更多功能的需求，但在实际实施过程中，我们也遇到了很多问题。

首先就是代码管理的问题。由于两个团队都在做开发，最大的风险就来自于代码合并。对此，我们分析之前迭代中的特点发现，大量代码往往在迭代的前半段时间里产生，到后半段往往更多的是少量的修改。因此，我们采用了主干开发分支上线的方式进行管理。即启动迭代的团队使用主干开发，当开发过半时，另一团队将完成上线的代码合并到主干，合并后当前团队从主干拉出分支进行分支开发和上线，让出主干给即将启动下一迭代的团队。如图2所示，B组启动时在主干开发，当A组完成上线后将代码合并到主干，此时B组将合并后的代码开出分支用于迭代后半段的开发和上线工作，A组启动新的迭代并占用主干继续开发。如此交替使用主干开发，分支上线。

图 2代码管理示意

在使用SVN的时候我们一直采用这一方式进行代码管理，换用GIT以后由于分支的成本更低，我们变化了一些管理方式，此处可以根据实际情况进行调整。

另一个问题就是效果，采用这个模型到底效果如何。代码质量是否有所提高？产能是否有所提高？如图3所示，我们用每1000行变化代码产生的bug数量即千行bug数来衡量开发质量，即图3中蓝色的柱形图。通过对比前后几个迭代，可以看到千行bug数是有所下降的，我们把这个归因于开发工程师有更多的时间关注到代码质量当中。再看红色的Story数的变化，我们用每迭代完成的Story数量表示产能，从前后的对比可以看到，Story数量有所提升，我们把这归因于迭代周期延长后可以开发更多功能。当然，Story数量受到产品经理拆分对需求的拆分粒度以及人员变化的影响，但是从实施以后多个迭代的产出来看，至少没让产能减少。

图 3交驻双迭代实施前后的效果

还有对需求的理解一致性问题。现实情况当中，很多bug和无用功来源于对需求的理解不一致，在使用两个团队以后，也依然存在跨迭代也就是跨团队的需求。所以需求评审会是要全部成员参加的，一定程序上可以保证长期的需求有一致性的理解，每个人都要为需求承担责任。我们也用这一方式来解决设计方案一致性的问题。当然，仅这一项措施并不能完全保证这一点，我们也在不断探索。

另外站会的组织也是个问题。我们尝试过两个小组各自开站会，也尝试过合在一起开站会，最后我们采用的是分另开站会但是各角色的负责人同时参加两个站会的方案。一方面保证站会在沟通上的作用和效果，另一方面对跨小组的工作由负责人进行判断和统一协调。

其他的问题还有很多，比如某个迭代遗留的bug怎么办？小组如何分？小组成员是否允许动态调整？这些都需要根据具体情况加以处理，本文就不一一解答了。

这不是银弹

当然，任何模型都有适用的条件，也有不适用的情况，该模型也同样存在一些不足。例如迭代周期延长不利于快速响应变化，对人员素质和能力要求较高，每个人的工作量都更加饱满，代码合并会产生新的bug，bug要跨团队维护，交付时间相互影响等。因此，是否采用还需要仔细斟酌，本文也是抛砖引玉，不是说这个模型就是好的，一切都要从团队的具体情况出发，剪裁出适合团队的过程模型才是我们最终追求的目标。