《Scrum敏捷游戏开发》读书笔记

第一章：业界状态

游戏行业三大危机：创作保守，内容缩水，加班繁重

 

第二章：敏捷开发

大型游戏项目特点：开发过程中容易产生‘新增特性’，任务复杂度高>评估准确性低，demo阶段不确定性高。------ 变化多

瀑布模式难以应付大型项目‘变化多’的特点，且难以在计划阶段就明确游戏产品多核心乐趣。

敏捷模式拥抱变化，每一次迭代都更明确游戏所需的核心乐趣，这意味着敏捷模式制作游戏将会降低返工（成本）或以降低质量来维持原计划的风险。

敏捷特征：敏捷宣言

 

第三章：Scrum模式

Scrum主要由PB和SB组成，在jira中PB直接叫backlog，SB直接叫sprint。

SB以一个阶段小产品为目标在PB中抽取PBI，由PO确定。

PO负责scrum团队每个sprint中抽取的PBI的优先级排序，确保ROI,确保整个团队目标一致。

SM负责协助团队建设（包括评审会等），减少工作中的障碍，指导团队成员Scrum原则，协调团队内部沟通及团队与外部（相关方等）的沟通。

 

第四章：Sprint

典型sprint流程应该在sprint会议前举行优先级会议，先确定当前冲刺目标，再确定抽取PBI的优先级，并将选取的PBI拆分或者合并成合适大小的PBI。

sprint计划会需要将暂定抽取的PBI（史诗/用户故事）分解成任务，并估算故事点以及确定CoS（满意条件）。

评审会：相关方参与

回顾会：停止，开始，持续；confluence中默认为‘需要做的更好的（停止)', '做的好的（持续)', '要改进的行动（开始)'.

燃尽图：以故事点为计量燃尽图可以反应sprint速率,在sprint中途就可以预估，时间到而未燃尽需要删除部分PBI或者加班，或者重置sprint。

Scrum流程：需求梳理会，PO梳理PB（按需召开） ——> 故事研讨会+sprint优先级会议和计划会（优先级会议排优先级，确定潜在sprint目标，以及合并或分解PBI） ——> 站会 ——> 评审会 ——> 回顾会

研讨会：写故事，团队共同讨论

计划会：拆子任务，估时，认领

评审会：showcase展示，相关方意见

回顾会：检查，总结

 

第五章：User Story

用户故事目的是让所有人都理解这个故事的目标。

用户故事优先级排序的时候需要在统一标准下评估。

故事应该遵循INVEST原则：

Independent独立的

Negotiable可商讨的

Valuable有价值的

Estimable可估算的

Sized appropriately大小合适的

Testable可测试的

完成字段可以配置词典

 

第六章：敏捷计划

敏捷计划是小而短贯穿整个项目，分阶段制定。

敏捷模式会根据实际情况以迭代和变更的方式做计划。

敏捷计划的制定会以优先高价值的交付，可控（时间，成本）为标准。

发布计划：每个发布都应该是一个可交付的产品（可玩的游戏），一个发布中包含多个sprint，类似瀑布模式里的里程碑。

 

第七章：游戏项目管理

kanban模式（精益）与scrum模式（敏捷）同级，侧重流程控制（可视化），优化流程减少资源（时间，人力等）浪费（精益理念）。

Jira上可创建两种面板，一种是Scrum面板（敏捷面板）一种是kanban面板（精益面板）。

共享资源类（依赖）岗位可以单独成立团队，可为这类团队按精益理念使用kanban，理想情况下应为各独立团队制作符合其工作内容的专属kanban流程，需要通过个人时间窗计算循环时间，再对比步骤花费时间，然后配给人员或者设置缓冲等方法使流程平滑，进度可估。

游戏项目管理模式可以混合，如scrum和kanban结合，或者原型阶段敏捷>制作阶段瀑布.

 

第八章：团队

团队应具备的属性：有共同愿景和目标，共同承担责任，重点在于自我管理和自我组织。

规模化Scrum团队可以组建SoS（Scrum of Scrums）。

小团队类型：

特性团队（针对一类交付任务，LeSS体系推荐），功能团队（针对共用功能，通常为底层基础功能），制作团队（内容创作团队），公共结构团队（支持服务团队），工具团队（制作工具的支持服务团队）资源成团队（内部外包），集成团队（大型特性团队）组件团队（业务线团队）

SoS中小团队sprint可以同步也可以不同步，同步的好处在于评审功能更完整。

SoS中可以为同样职能的队员组建非正式社区，社区可以快速有效的交流信息沟通。

 

第九章：迭代

迭代是增量开发的过程，Scrum中每一次sprint可以算一次迭代，迭代开销主要来自变更。

当前各团队不影响其他分支的单独sprint可以看作是个人迭代（更新），对其他分支有影响需要上传主线变更共有资源的sprint可以看作是版本迭代（做版本）。

版本迭代（1.1，1.2，1.3之类）和发布（1.0，2.0等）不同，版本迭代是一个阶段性的增量开发过程，发布是一个里程碑（准交付产品，可玩的游戏）。

 

第十章：敏捷技术

不确定性导致变更成本高，约后期改动越大，敏捷则可以在发现问题的初期尽量解决减少变更成本。

敏捷不应该做太多预想却不是当前切实的需求，构建需求只要考虑当前需要的功能，不要考虑太多未来可能会添加的功能。

敏捷中应该尽量减少BUG fix债务，QA发现错误后，如果和当前sprint相关并小到可以修复应该加入到当前sprint中作为一个任务，如果不会影响到当前sprint，则可以放在PB中作为一个用户故事。

 

第十一章：敏捷美术&音频

美术人员通常不纳入跨职能业务线，但也可以有部分人员加入业务线，然后以社团的形式非正式交流。

美术人员和跨职能的业务线之间容易产生理解偏差，需要双方增进了解。

音频人员工作大多在收尾阶段，为了避免启动阶段的时间浪费，可以采取合作生产的模式，音频人员也可以同步业务线开展工作，在不需要进行音频制作的时候可以旁听其他业务线的工作内容，以及辅助一些相关性的工作。

 

第十二章：敏捷设计

游戏行业设计岗大多数是策划，所以策划作为PO会更合适，策划作为PO也更容易把握共同愿景。

用户故事债务积攒到一定程度需要集成方式清楚债务（将多个类似的零件故事组成一个故事）。

基于集合的设计可以在短时间内找到最好的解决方案：取技术可能性，美术可能性，设计可能行的交集作为一个方案。

 

第十三章：敏捷QA&制作

QA的数量取决于需要。前期可以共用，后期最好可以做到每个业务线都有专属QA。

QA在Scrum中应该贯穿整个项目而不是集中在发布前测试，因为Scrum每个sprint都具有潜在可交付成果。

QA应该具有玩家视角，需要在版本测试阶段进行体验测试。

错误数据库：将识别的错误收入一个错误数据库，在后期（发布阶段）维护的时候每个业务线可以将需要修复的bug提出加入到PB排序后加入当前SB。

制作人也适合SM和PO。

 

第十四章：Scrum的神话与挑战

Scrum并未适用所有团队或个人。

Scrum崇拜问题：强行依照Scrum流程而拒绝变化是伪Scrum。

Scrum并非没有计划，迭代也是有序的迭代。

Scrum会议表面上占据很多时间，但实际上有效的会议可以降低风险或提前发现问题，最终等于提高效率。

Scrum并非解决问题的框架，更大的作用是提前暴露问题。

Scrum应该注重工作增加的价值而不是工作中完成的任务。

 

第十五章：开发商和发行商

发行商和第三方开发商之间的信任危机，合同间往往会隐瞒缺陷，需要建立信任，可以采用敏捷合同的方式。

第一方开发商也存在与发行商之间的矛盾，第一方需要降低发行商的干预程度，可以让发行商有限地参与到开发过程，如双PO模式（发行商PO和开发商PO）。

敏捷合同的核心有两点：1、优先创造价值更高的目标；2、尽量减少债务，避免推迟还债。

敏捷前期制作阶段可以采用阶段性评审（两个绿灯）：

1、概念绿灯：发行商评审完游戏项目的概念，计划和原型后决定是否可以进入研发阶段；

2、生产绿灯：发行商在评审完玩法和和资源的计划安排后决定是否可以进入制作阶段。

阶段性评审可以让团队更加注重游戏品质而非计划。

 

第十六章：启动Scrum

Scrum可以划分成三个阶段：学徒阶段，熟练阶段，大师阶段。

学徒阶段的团队成员在进行Sprint的时候更多的是当作一个小型瀑布模式去执行，对Sprint的目标（价值）不够关心，对任务完成度较为关心。一个版本的多个Sprint直到最后一个或几个Sprint才开始测试调优，因此容易产生债务积压。且学徒阶段的团队站会容易变成汇报会议，注意不可使用工具代替站会。

熟练阶段的团队需要注意集中办公环境，一个是安排相同职能相同团队的人员坐在一起，另一个尽可能取消隔断（常见互联网类型），还需要根据实际工作内容安排方位（如程序需要在安静的区域），在Sprint上要避免固化：在Sprint中包含过多“未完成”的任务，需要修改“完成”的定义。团队会关注游戏的好玩程度，这会带来：后期工作任务可能不会增加多少，但是价值增加却会很多。

大师阶段的团队能够自我组织并持续改进，这样的团队的共同点有：归属感，领导力，核心专家，团队合作，培养性的工作室文化。该阶段团队队Scrum本质有深刻认识，有更适合团队本身的定制化流程，不再被Scrum常规流程框架束缚。

推广Scrum：

第一步组建桥头堡团队：先选取部分意向高队人组成团体使用Scrum，取得成果后分三种方式推广：

1、分裂种子式：将桥头堡团队每个成员作为种子组建新团队；

2、分裂重构式：将桥头堡团队对半分再分别补充人员组成新团队；

3、全面部署式：依照桥头堡团队成功的模式全面推广。