一、伟大的团队
-
追求共同的愿景和目标
-
团队成员的技能相互补足
-
开放和安全的沟通
-
共同决策、共同责任和义务
-
在一起很开心
-
交付价值
-
实现共同的承诺
二、团队的Scrum方法
1. 跨领域的团队
各部门专业之间无法同步优先级导致对游戏认知的延迟
2. 自我管理
大型团队的沟通问题
5~9个跨职能领域开发者 组成 小型团队
进行Sprint
3. 自我组织
团队自己选择他们的成员
自组织考虑的问题：
① 发布目标和最初发布计划是什么？
② 需要哪些专业领域和技能？
③ 发布目标的优先级是什么？
④ 团队成员之间有默契吗？
4. 团队规模
推荐7~9人
5. 领导力
着重于引导和辅导
-
设计和计划：和专业团队一起
-
资源分配：领导预估，Sprint来定义
-
任务创建和管理：团队自己管理，领导在计划会上帮助提升任务识别、预估能力
-
评审和引导：定期评审
-
指导工作：帮助提高生产力
三、游戏团队和协作
1. 特性团队
开发游戏核心功能 的 团队
一个特性团队应该拥有制作玩法所需的所有人
2. 功能团队
大多由同一专业职能的开发者组成
做一些高级别、跨职能的工作会导致不适合游戏
通常只做底层或基础构建方面的工作
3. 制作团队
制作阶段的跨职能团队
有特性团队发展而来
动态成员，保持资源制作的稳定流程
4. 公共结构团队（shared infrastructure，SI）
提供许多游戏都要用的共享的支持服务
引擎组、音频组等
这些团队的实践：
-
SI需要自己的Backlog和PO
-
客户团队计划会明确优先级，带上SI
-
SI应将 支持 作为产能的一部分
-
SI可以借成员给另一团队 一个Sprint的时间，但需先说明
-
SI PO应处于管理层，如CTO。以便对优先级冲突作判断
-
SI支持一个或多个已发行游戏
5. 工具团队
支持多个团队
客户是使用常用工具集和流程的用户
6. 资源池团队
“内包”团队
支持团队的工作，为大量美术资源提供支持
7. 集成团队
大型项目 共同目标 非常有挑战性
集成各个特性团队目标为统一玩法
结构与特性团队相似
四、缩放和分布式Scrum
大型团队的问题：
-
100人项目效率 ≠ 1个人效率 × 100
-
100人团队有4950个可能的交流渠道（n × (n - 1) / 2）
1. Scrum of Scrums会议（SoS）
（1）不需每日召开
（2）目的是解决问题
（3）问题是不同的
* 自从上次会议，团队做了什么？
* 团队下一步做什么？
* 团队遇到了什么障碍？
* 团队可能对其他团队造成什么影响？
2. PO层级
3. 统一的Sprint日期
好处：
* 团队可交换成员
* 鼓励对游戏做综合评审：跨团队
* 否则首席PO分身乏术
4. 实践社区
多团队中 相同只能特性专家分散，沟通不足
每个社区自定碰头时间
做好分享
5. 避免依赖性
A团队和B团队依赖专家1
- 发布计划会议
确定所需人员，调整有冲突故事的优先级
- 前瞻计划会议
计划变更 → 需要定期开前瞻计划会议
协调冲突和人员变动