@yangfch3
2021-02-05T17:17:09.000000Z
字数 2208
阅读 1108
游戏开发
下面以一个完整的 sprint 周期(两周)为例,记录下目前我认为的一个团队各个工种都可能比较舒适的模式。
策划团队在此期间,要准备好下一个 Sprint 需要做的功能的 Story 单和文档。
对 Story 的要求:策划只需按完整大功能/模块的粒度开 Stroy,无需自行拆分
对文档的要求:策划准备的文档应该是已经和美术、制作人确定过的,7-8 成已经明确好的
在文档基本确定之后,再找程序讨论与确认文档的可行性或替代方案。
程序和策划如果核对文档比较顺利,就可以一起过一下 Story,程序需要为策划做的:
策划对程序的估时进行记录,并与 PM 共享程序估时的信息。
经过以上流程,信息已经在团队内(除了 QA)进行了有效的流动。
制作人、策划、PM 在得到程序给出的初步的估时后,要对 Story 进行一个优先级的排序,并分析团队各成员分配任务工时的合理性,实行多退少补的机制。
RD 工作一:进行 Sprint 验收
验收分为以下流程:
RD 工作二:进行团队 Review
RD 工作三:PM 粗略告知团队下个 Sprint 的工作内容(Story)
Sprint Start Day 需要由策划来主导对功能/模块的逐个需求评审,评审会的参会人员需要有策划、PM、负责对应功能的程序(前后端)、QA。
需求评审的主要内容是策划再向相关的人员介绍一遍文档,重点是 QA 理解文档,提出问题,并查漏补缺。
一般情况,由于开发时间紧,一个 Sprint 的工作时间可能刚好只够把功能开发完,所以新 Sprint 开启的前两天 QA 还是在测试上个 Sprint 和功能或者进行回归。
待 QA 在新 Sprint 开始后的 2 天左右将上个 Sprint 的功能全部测完,再进行分支的合并。
程序在此阶段要对 Story 进行 SubTask 的拆分,拆分的粒度由程序来主导,PM 来监督。建议 SubTask 的粒度以 [2,4,8]
小时为主,避免出现 2d/16h
以上的单子。
新 Sprint 前面 QA 测试的几天,程序可以照常在主干开发新功能,但是要求 美术、策划、程序在 SVN 的提交必须有所属的 JIRA 单,严格按照提交规范。且提交不能出现以下情况:
且一般 JIRA 单的标题在建单时也需要有所属版本周期的信息。例如:【圣诞】【程序】圣诞活动卡片掉落机制开发
、【SDK强更】【程序】接入 TC 广告 SDK
,其中【圣诞】
、【SDK强更】
就作为一个版本的识别 Tag
。当然,版本的识别标志可以团队自行制定规范。
虽然只是在这里强调了注意项,但是平时的 SVN 提交也务必要符合上面的要求。不然会给冷热分离更新、合分支带来非常多的麻烦。
PM 在程序拆完单子后就要对 Sprint 进行甘特图排期,比较好的实践是让程序自行去拉甘特图,程序调好后 PM 再与程序进行核对、讨论、调整。
此阶段就是一个正常的开发周期了,此阶段要遵循以下原则:
一般在验收会议之前的前一天或前数小时,主程就要确认并发布禁止提交新内容的通知,开始打验收包。
打包后,如没有卡死、卡流程等恶性的 Bug 就不返工打包,只由 QA 开 Bug 单,放在验收会后修缮。