移动App双周版本迭代实战--转载备用

对于移动互联网产品来说，迭代的速度就是生命。我创业时做移动App时是一周一版，而现在是2周1版。相比起小公司，大公司迭代时间虽长，却更为不易，因为大公司流程更多，参与人数更多，需求更多，实现这样的快速迭代存在许多挑战，也有一定风险，管理者控制起来更困难。

那我们应该如何来实现2周1版的快速迭代呢？

这是最开始我构思的版本迭代流程图：

后来修改成这样：

我们来梳理一下，在2周1个版本的迭代开发中，有哪些最佳实践呢？

        关于项目管理

2周的迭代时间是非常赶的，基本只能cover开发加测试的时间，所以需要尽量把版本的准备工作提前，以保证开发的时间。其中包括MRD、UE和后台接口，后台可定义假接口便于前台提前开发，最后再进行联调。

在整个流程中，项目第一个版本最开始的Kickoff会议很重要，这能帮助我们更好的了解团队里的人员和职责，提高后继沟通效率。后面就可以走标准的MRD Review、制定版本计划、开发、定期Review和例行通报的流程。

UE和开发时间可部分并行，只需先定义好交互，RD就可以进行开发工作。

        关于需求

需求优先级必须排序，哪些是一定保证完成的，哪些是最好能有的，哪些是能有最好。来不及完成的需求再汇总到下一个版本的需求中。

关于需求变更。时间和需求变更有时候是不可调和的矛盾。提测后我们“尽量”不提交新的需求或者更改需求，新需求在下个版本添加。因为迭代速度较快，新需求最晚都会在2周后的新版本中得到实现，所以这个问题能较好控制。

        关于开发

基于主干开发，提前划分好功能模块。否则代码合并是要命的事情。

划分好代码的架构和模块，每个功能模块拆分的粒度足够细。这可以解决几个问题：

1）  投入更多人力时可以提高开发效率。

2）  减少模块之间的耦合度，防止并行开发时出现的相互代码干扰。

经常遇到功能较大，开发完成时间可能需要超过1周，这个时候应该如何处理？

1）  设计产品时尽量拆分功能为更细的粒度。

2）  不能拆分的，如果功能入口能简单屏蔽，开发不影响其他代码结构的，可以多个版本开发完成，在中间的版本通过屏蔽入口或者代码解决。

3）  基于底层或者大量功能的改动影响范围太大，需要大量开发和测试时间，应当适当调整版本计划或延期。

需要频繁更新的内容用WebView方式展现。

        关于沟通

整个流程中，信息的透明和通畅非常重要，需要有一个统一的需求和进度管理工具。

明确的项目进度表很重要，这可以让项目团队成员信息透明，减少沟通死角。无论是通过立会+Web展示，还是用实体的白板，都是可以采用的方式。

明确的项目进度表

在项目后期，每日项目组所有成员立会是必须的，这样做有很多优点，例如解决沟通问题，同步进度，统一最后的目标。

        关于测试和质量控制

要考虑到Android、iOS两个版本同时提测对测试工程师人手的压力，测试人手足够时可并行开发，这样便于两个平台的研发相互之间对产品需求、技术实现方式等进行讨论和交流。

我们采用多级测试和发布流程来减小质量风险。测试可分为自测、QA测试、内部测试、用户测试等级别，配合较专业的错误收集工具，能解决绝大部分缺陷。再加上灰度发布策略，质量能够得到最大的保障。

发布一定要有Check List，保证每一个步骤和流程都要校验和到位，例如SVN Tag、版本号、数据统计、线上接口地址等等。

        还有…

在人力足够的时候，可以考虑两条产品功能线，两条线做一些相互耦合性不高的功能（例如一条线做常规功能，一条线做创新功能），这样能把时间利用到极致，迭代速度提升到最快。

版权声明：本文为博主原创文章，未经博主允许不得转载。