敏捷实践记录 - SkipBo 项目

游戏开发

一、指导原则

1. 信息：信息在项目组内要有一条清晰的流向线路，并且这条线路要流经需要知晓的相关人员，且流向线路不应该是网状的
2. 时间：策划先行，QA 断后，甘特排期，实时追踪，责任到人，灵活调整
3. 工程：主干开发，主干测试，分支回归；需求单隶属版本明确，版本管理提交规范化，按需合单，冷热分离

二、一个完整的 Sprint 周期

下面以一个完整的 sprint 周期（两周）为例，记录下目前我认为的一个团队各个工种都可能比较舒适的模式。

1. Review Day 前的 5 个工作日

策划团队准备 Stroy 和文档

策划团队在此期间，要准备好下一个 Sprint 需要做的功能的 Story 单和文档。

对 Story 的要求：策划只需按完整大功能/模块的粒度开 Stroy，无需自行拆分
对文档的要求：策划准备的文档应该是已经和美术、制作人确定过的，7-8 成已经明确好的

在文档基本确定之后，再找程序讨论与确认文档的可行性或替代方案。

1. 程序对文档只提出小细节的修改：此时程序要给策划初步确认开发的所需时间
2. 出现以下问题需要重新一起讨论解决方案或者重新准备文档：
   
   1. 复杂度过高导致开发时间上不能被策划接受
   2. 技术上难以实现或者需要大量的技术调研/学习时间
   3. 文档出现了逻辑上的大漏洞

程序和策划如果核对文档比较顺利，就可以一起过一下 Story，程序需要为策划做的：

1. 程序可以按照自己的思路对大粒度的 Story 进行合理的分隔（一般一个 Story 战线最好不超过 4-5 个工作日）
2. 同时在对文档已经充分了解的基础上对各个 Story 进行一个粗略的估时。

策划对程序的估时进行记录，并与 PM 共享程序估时的信息。

经过以上流程，信息已经在团队内（除了 QA）进行了有效的流动。

制作人、策划、PM

制作人、策划、PM 在得到程序给出的初步的估时后，要对 Story 进行一个优先级的排序，并分析团队各成员分配任务工时的合理性，实行多退少补的机制。

2. Review 会

RD 工作一：进行 Sprint 验收

验收分为以下流程：

1. 工作成果展示
2. 团队一起试玩（重点体验版本工作的部分）
3. 体验优化项、Bug 反馈收集

RD 工作二：进行团队 Review

1. 检查与回顾以往历史遗留问题解决的进度
2. 团队成员抛出当下这个周期内团队存在的问题，并讨论解决的实践方案

RD 工作三：PM 粗略告知团队下个 Sprint 的工作内容（Story）

1. PM 过一遍 Story 列表，让大家对接下来 Sprint 的工作全貌有个认知
2. 强调优先级
3. 梳理各个需求之间的依赖关系

3. Sprint Start Day

Sprint Start Day 需要由策划来主导对功能/模块的逐个需求评审，评审会的参会人员需要有策划、PM、负责对应功能的程序（前后端）、QA。

需求评审的主要内容是策划再向相关的人员介绍一遍文档，重点是 QA 理解文档，提出问题，并查漏补缺。

4. Sprint Start 的前两天内

QA 与 分支

一般情况，由于开发时间紧，一个 Sprint 的工作时间可能刚好只够把功能开发完，所以新 Sprint 开启的前两天 QA 还是在测试上个 Sprint 和功能或者进行回归。

待 QA 在新 Sprint 开始后的 2 天左右将上个 Sprint 的功能全部测完，再进行分支的合并。

程序

程序在此阶段要对 Story 进行 SubTask 的拆分，拆分的粒度由程序来主导，PM 来监督。建议 SubTask 的粒度以 [2,4,8] 小时为主，避免出现 2d/16h 以上的单子。

程序在此阶段的注意项

新 Sprint 前面 QA 测试的几天，程序可以照常在主干开发新功能，但是要求 美术、策划、程序在 SVN 的提交必须有所属的 JIRA 单，严格按照提交规范。且提交不能出现以下情况：

1. 随意填写或不填提交注释，不按规范走
2. 归属于不同版本周期的不能合并提交
3. 修改的是 A 功能，但用非 A 功能的单子提交

且一般 JIRA 单的标题在建单时也需要有所属版本周期的信息。例如：【圣诞】【程序】圣诞活动卡片掉落机制开发、【SDK强更】【程序】接入 TC 广告 SDK，其中【圣诞】、【SDK强更】就作为一个版本的识别 Tag。当然，版本的识别标志可以团队自行制定规范。

虽然只是在这里强调了注意项，但是平时的 SVN 提交也务必要符合上面的要求。不然会给冷热分离更新、合分支带来非常多的麻烦。

PM 的甘特排期

PM 在程序拆完单子后就要对 Sprint 进行甘特图排期，比较好的实践是让程序自行去拉甘特图，程序调好后 PM 再与程序进行核对、讨论、调整。

5. Sprint 开发周期内

此阶段就是一个正常的开发周期了，此阶段要遵循以下原则：

1. 最小化交付：不等到整个大功能做完才交给 QA 测试，按照拆 SubTask 的思路进行逐步交付/每日交付，防止 QA 干等、测试时间不足情况的出现
2. 敏捷循环：每天/每两天都有新内容进包，美术、策划及时体验包，提出反馈和优化意见（开发 -> 反馈 -> 迭代 的敏捷循环）

6. Review 前

一般在验收会议之前的前一天或前数小时，主程就要确认并发布禁止提交新内容的通知，开始打验收包。

打包后，如没有卡死、卡流程等恶性的 Bug 就不返工打包，只由 QA 开 Bug 单，放在验收会后修缮。