在过去的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方法。
排序的功能清单
- 非常重要，是实现快速迭代的主要输入；
- 清单里的功能应该兼顾市场需求、公司需求、产品自身需求；
- 需要定期进行整理，按照功能价值进行排序；
- 清单内的功能，高优先级的应该进行细化，大的功能点应该进行拆分；
- 定期邀请所有团队成员，进行功能点梳理。
新版本计划会议、新版本策划案
- 每个迭代必定需要进行一次这样的会议；
- 团队所有成员参与，决定版本的内容，明确工作的方向；
- 就关键技术问题和工作量，能够达成一致，确保迭代能按时完成；
- 新版本策划案，作为每次迭代的书面产物，用来指导后续工作的开始。
迭代周期
- 保证稳定的迭代节奏，2~4周为宜；
- 功能点细化后，尽早开发，尽早交付，尽早测试；
- 进行每日站会，保证信息透明、职责清晰，及早发现可能影响迭代的潜在问题。
可交付的新版本
- 尽快上线，收集反馈，指导下一次迭代的进行；
- 进行迭代的评审和回顾，学习和提高自身快速迭代的能力。
写在最后
一直保持着紧绷的神经，进行了一年多的更新，有欣喜的时候，也犯过错误，总体感觉是越走越顺。僵尸项目这种以4周为一个周期的快速迭代，已经慢慢成为了一个习惯，可以最大程度上保证团队每一个人都清晰的知道，自己应该做什么，应该什么时候做。
当团队成熟度提高、自动化集成环境完善后，迭代周期可以进一步缩短。对于周期很短、内容很小的更新，尽量应该通过热更新去做。否则频繁的版本更新，对玩家不是一件好事。
参考资料
[1] 在游戏产品中使用敏捷方法
[2] A successful Git branching model
[3] 僵尸榨汁机-版本记录
[4] 这样的工作流程让网易在14个月修复2000个bug
