[关闭]
@yangfch3 2021-02-05T09:17:09.000000Z 字数 2208 阅读 908

敏捷实践记录 - 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 单,放在验收会后修缮。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注