【连载6】如何进行快速迭代?

96
卫亮
0.1 2017.05.22 21:34* 字数 3726

< 上一篇 | 连载目录 | 下一篇 >
我和《僵尸榨汁机》的故事,连载(6)

在过去的2016年中,僵尸项目进行了13次iOS功能更新,10次bugfix的更新,另外还有4次百度版本、3次Google Play版本的发布,总计一年进行正式发布高达30次!(具体可以参考:僵尸榨汁机-版本记录

能够支撑一年中这么多次的更新,这背后是我们成熟稳定的快速迭代方式、对版本和分支管理的深刻理解、和对敏捷方法合理的运用。

僵尸榨汁机-版本记录

快速迭代

对于快速迭代,除了要求功能尽可能小和独立、能够快得起来之外,很重要一点是保持节奏感(Cadence)。对于一个需要长期快速迭代的项目,这种节奏感就好像是跑110米栏时,在栏间踩对了步点,一次次轻松跨过栏杆。反观也有不少时候,我们都会过于要求“快”,但是一次次打到栏杆,结果事与愿违。

真正的快速迭代,一定是建立在稳定的节奏感上的。每一个团队成员,都应该很清晰的知道,自己工作的内容和时间节点,不管交付内容是如何变化的。

01 单次迭代过程

在僵尸项目中,我们保持了4个星期为一个标准的迭代周期,进行大版本的更新。对于单次迭代N,可以从下图中看到它的具体过程。

单次迭代过程

迭代N:主要时间节点

  • 第1周初,项目正式启动,开始代码开发和美术制作过程;
  • 第2周末,进行首个内部版本交付,开始进行功能测试;
  • 第4周初,要求功能开发结束,进行系统测试和回归测试;
  • 第4周末,提交经过测试的新版本,进行苹果审核;
  • 第5周中,经过苹果审核后,新版本正式上线。

策划:主要工作和时间节点

  • 前一个迭代上线之后,就进行玩家反馈收集和运营数据分析;
  • 迭代N开始前1周,开始准备新策划案,并邀请美术和程序评审;
  • 迭代N开始前,新策划案应该准备就绪;
  • 第2周末,收到首个版本后,开心验收测试;
  • 第4周末,结束验收测试,协助程序提交版本审核;
  • 第5周中,上线新版本和相关活动。
    (因为团队较小,这里说的策划会涵盖策划、运营、测试的工作)

美术:主要工作和时间节点

  • 第1周,开始美术制作。之前应当已经评审过新策划案;
  • 第3周末,所有美术素材分批提供完毕;
  • 第4周,进行美术的验收测试。

程序:主要工作和时间节点

  • 第1周,开始程序开发。之前应当已经评审过新策划案;
  • 第2周末,提供首个内部测试版本,可以使用代图,侧重在功能逻辑实现;
  • 第4周初,开发结束,提供相关版本,美术资源已做整合;
  • 第4周末,bugfix结束,提交最终的软件版本;
  • 第5周,预留一部分时间,应对上线后的问题,和可能的紧急更新。

02 滚动进行中的迭代

那么在迭代滚动进行当中,迭代版本、策划、美术、程序的工作是会有一定叠加的。对于工作安排,最重要的2点:

1. 尽量减少迭代版本重叠的时间,尽量保证一段时间内只有一个关注点;
2. 每个人同时最多只能工作在2个迭代版本上。工作切换越多,效率越低,出错可能性就越高。

滚动进行中的迭代

迭代N
迭代版本提交审核后,由于审核和版本上线需要一定周期,实际已进入下一个迭代版本的开发,两个版本工作会有一定重叠。

策划
这里策划定义的工作内容较广,时间跨度会较长,所以策划往往需要同时工作在2个迭代版本上,但是避免出现3个版本的情况。

美术
美术相对是最轻松,基本上只要关注当前开发的版本就可以了。

程序
程序也是基本上只要关注当前开发的版本。除非在新上线版本出现问题的情况下,才需要工作到之前的版本上。


版本和分支管理

对于大型研发项目、或海外合作开发项目,可能会存在大量并行开发的内容,这种情况下需要建立合理的分支进行版本管理。对于分支(branch),需要按照项目的时间节点,进行feature和bug的管理,才能够更好的实现快速迭代。

切记一点,并不是任意时刻增加越多的内容就越好!

01 单个分支管理

对于一次迭代,可以分这样几个关键时间节点:

1. 创建分支
创建版本分支,进行配置管理,随后进入开发阶段,进行功能开发和提交。如果使用敏捷方法,可以提交一个功能,测试一个功能,提高开发效率,所以过程中还会有bugfix的提交。

2. 功能冻结(完成)
这个时间节点标志着所有功能的完成,后续应当进入全面测试和bugfix阶段。这时候如果有新的功能需求提出来,理论上应该放到后续迭代中,而不应该继续进行开发提交,否则会影响当前迭代的进入和这次发布的质量。

3. Bug冻结
这个时间节点意味着主要测试已经完成,质量已经达到了要求,原则上不应该在未经允许下提交任何改动。可能会有bug还没有修复,这时候应当由项目负责人进行严格审查,是否需要这些改动,任何"nice to have"的改动都应当被拒绝。只有严重影响游戏功能的bug才可以提交,放入这次迭代中。需要引起重视的事:任何改动,包括bugfix,都会带来新的bug!

4. 版本发布
这个时间节点意味着所有测试工作和bugfix已经结束,软件版本可以进行发布。发布之后,在当前版本打上标签,可以进入到下一个迭代的开发之中。

单个分支管理

02 多个分支管理

这里参考[2]中GIT的示例,进行简单说明。

1. 分支分类
feature branches: 功能开发分支,可以按照功能和Release分成多条分支
develop: 用于集成当前Release所有开发的功能
release branches: 待发布分支,功能开发已结束,主要进行bugfix
hotfixes: 用于修复紧急问题的分支
master: 主分支,用于进行正式发布。

2. 功能开发
需要开发新功能时,从develop branch拉出feature branch,在feature branch上进行开发,开发测试完成后,再merge回develop branch。如果分支开发时间持续较长,定期需要进行Rebase,以免最后merge回去的时候冲突太多。在develop branch上,应该不断的进行功能的集成测试,使得develop branch始终是一个稳定可以运行的版本

3. 版本发布
功能都完成后,从develop branch merge到release branch,进入发布准备过程。在release branch上,只进行bugfix,不再增加任何新的功能。当bugfix结束之后,再从release branch merge到master branch,然后再master branch上打上标签,进行发布。另外,在release branch上的所有bugfix,需要反向merge到develop branch,保持两个branch内容的一致。

4. 紧急问题处理
如果在正式版本上发现紧急问题,需要立即修复的,应当从master branch上拉出hotfix分支,在hotfix分支上修复测试后,再merge到master branch上进行发布。另外hotfix的内容,需要再merge到develop branch和release branch(这点图中没有展示)。应该注意的是,hotfix branch应当从项目层面进行管理,分支上有且只能有紧急问题的改动。

多个分支管理

03 版本和分支管理要点

1. 尽可能少,尽可能晚
保持分支的数量尽可能少,多一个大分支,工作量起码增加30%以上。如果一定要开分支,那么尽可能晚的去开分支,减少无谓merge的工作量。

2. 保证主分支稳定
保证主分支的质量尽可能稳定,修改在bug分支、开发分支(或本地版本)上进行,经过验证后才能够提交到主分支上。主分支按周或者更短频率提供可测试的软件版本。如果能通过自动化测试来保证这一点就最好了。

3. 代码及时同步
大的开发分支需要定期和主分支进行同步(rebase),避免后期提交时的大量代码冲突。一些重要的改动,如hotfix,需要尽快安排进行merge。养成定期提交代码的习惯,代码提交量越小,越容易及时发现和定位问题。

4. 分支规划和管理
对于大型团队,需要有专人进行分支的规划和管理,制定对应的软件配置管理(SCM)方案。所有团队成员,可以在SCM定义的范围内,最简单和快速的进行开发,并不一定需要去理解所有分支规划。

04 和海外并行开发的困难

1. 学习成本
短时间内需要了解程序整体,特别如果是在代码可维护性较差的情况下,最后交付产品的质量,很大程度取决于对于代码的熟悉程度。

2. 版本合并
改动内容较多之后,进行版本合并成本非常高。这个类似前文说的,在develop branch和feature branch之前要进行rebase,太长时间没有做的话,代码上会有非常多的冲突,造成代码难以整合。另外,很多新的功能,可能需要二次开发,来适应之前的本地化修改,成本非常巨大。

版本合并的风险

3. 同步更新
为了赶全球同步更新,往往需要提前在海外版本半成品基础上,先开始merge,再多次merge直到最终版本。过程中由于新功能不稳定,可能导致代码来回反复,需要投入较多成本。并且最终留给集成和测试的时间非常少,一旦海外版本交付时间延误,或者交付质量较低,我方风险会很大。


敏捷方法的应用

曾经在在游戏产品中使用敏捷方法一文中,描述过对于敏捷方法在游戏产品开发中的应用和想法。这里对快速迭代中的注意点,再进行详细描述。下图展示了敏捷方法中的Scrum方法。

敏捷方法Scrum

排序的功能清单

  • 非常重要,是实现快速迭代的主要输入;
  • 清单里的功能应该兼顾市场需求、公司需求、产品自身需求;
  • 需要定期进行整理,按照功能价值进行排序;
  • 清单内的功能,高优先级的应该进行细化,大的功能点应该进行拆分;
  • 定期邀请所有团队成员,进行功能点梳理。

新版本计划会议、新版本策划案

  • 每个迭代必定需要进行一次这样的会议;
  • 团队所有成员参与,决定版本的内容,明确工作的方向;
  • 就关键技术问题和工作量,能够达成一致,确保迭代能按时完成;
  • 新版本策划案,作为每次迭代的书面产物,用来指导后续工作的开始。

迭代周期

  • 保证稳定的迭代节奏,2~4周为宜;
  • 功能点细化后,尽早开发,尽早交付,尽早测试;
  • 进行每日站会,保证信息透明、职责清晰,及早发现可能影响迭代的潜在问题。

可交付的新版本

  • 尽快上线,收集反馈,指导下一次迭代的进行;
  • 进行迭代的评审和回顾,学习和提高自身快速迭代的能力。

写在最后

一直保持着紧绷的神经,进行了一年多的更新,有欣喜的时候,也犯过错误,总体感觉是越走越顺。僵尸项目这种以4周为一个周期的快速迭代,已经慢慢成为了一个习惯,可以最大程度上保证团队每一个人都清晰的知道,自己应该做什么,应该什么时候做。

当团队成熟度提高、自动化集成环境完善后,迭代周期可以进一步缩短。对于周期很短、内容很小的更新,尽量应该通过热更新去做。否则频繁的版本更新,对玩家不是一件好事。


参考资料

[1] 在游戏产品中使用敏捷方法
[2] A successful Git branching model
[3] 僵尸榨汁机-版本记录
[4] 这样的工作流程让网易在14个月修复2000个bug