Osheep

时光不回头,当下最重要。

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

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

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

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

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

僵尸榨汁机-版本记录

快速迭代

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

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

01 单次迭代过程

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

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

单次迭代过程

迭代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个迭代版本上。工作切换越多,效率越低,出错可能性就越高。

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

滚动进行中的迭代

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

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

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

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


版本和分支管理

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

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

01 单个分支管理

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

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

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

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

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

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

单个分支管理

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应当从项目层面进行管理,分支上有且只能有紧急问题的改动。

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

多个分支管理

03 版本和分支管理要点

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

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

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

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

04 和海外并行开发的困难

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

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

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

版本合并的风险

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


敏捷方法的应用

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

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

敏捷方法Scrum

排序的功能清单

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

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

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

迭代周期

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

可交付的新版本

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

写在最后

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

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


参考资料

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

点赞

发表评论

电子邮件地址不会被公开。