2016-02-03
当前位置: ㊣苏云田博客 > 产品运营 > 文章正文

移动App双周版本迭代实战

0

对于移动互联网产品来说,迭代的速度就是生命。我创业时做移动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、版本号、数据统计、线上接口地址等等。
还有…
在人力足够的时候,可以考虑两条产品功能线,两条线做一些相互耦合性不高的功能(例如一条线做常规功能,一条线做创新功能),这样能把时间利用到极致,迭代速度提升到最快。

Post a Comment

您的昵称 *

您的邮箱 *

您的网站