Scrum在游戏开发实践中的若干问题

Scrum在游戏开发实践中的若干问题

1．  前言

Scrum是一种迭代增量的敏捷开发方法，能快速响应变化的需求，比较适合游戏开发项目管理。但是Scrum并不是一种流程管理方法，需要使用者结合自己的生产需要，与自己的流程整合。

在和公司的同事一起应用Scrum的多年时间里，对如何正确应用Scrum有过分歧和争论，经历了最初的Scrum教条化和Scrum-But，后来认识到Scrum与流程之间的关系，以及到后来阅读了Clinton Kenth的《采用Scrum开展敏捷游戏开发》，对Scrum的认识逐步加深。《采用Scrum开展敏捷游戏开发》一书是作者实践经验的总结，整合了Scrum与游戏开发流程，并提出了一些新的概念，让Scrum和游戏开发流程更好地结合。

在本篇文章，我将以问-答的形式来介绍Scrum实践中应该注意的若干问题。

2．  如何认识Scrum与开发流程

Scrum定义了Sprint周期，以及Sprint周期中需要完成一系列事件。如果没有真正理解Scrum，Scrum的这个周期性被看作是一套“流程”，很容易让使用者与开发流程混淆。再加上敏捷开发轻设计的思路，导致整个项目开发没有清晰的思路，没有总体的规划，每个参与者都有自己的想法（自下而上），各自为政，各说各话。

我们应该认识到Scrum其实是一个流程控制，项目定义的里程碑是开发流程。

我们把一个项目分成几个阶段，每个阶段都有一定的目标。我们再把这些阶段分成一个或几个Sprint，在这个小的Sprint周期里，完成一个阶段的一部分目标。Scrum通过帮助我们控制这一个个小的周期，从而帮助我们管理项目。

下面的“Scrum周期与项目Milestone之间的差异”，更加明确地阐述Scrum与项目开发流程之间的关系，以及我们该如何改进Scrum。

3．Scrum周期与项目Milestone之间的差异

大家知道，Scrum是以Sprint为迭代周期的。Sprint的长度，实践者可以根据项目的情况自己定义，一般在2~4周。如果Sprint长度定义太短，那么最开始的Sprint Planning Meeting的时间和最后的Demo Day，在整个Sprint时间中占的比例太高，影响了Sprint的效率。如果定义的太长，则Sprint计划的任务的不确定性高。。。

Milestone是项目的计划进度，一个项目分成几个Milestone来完成。Milestone的长度因项目的类型等等情况的不同而不同，一般在1~6个月。如果Milestone太长，计划制定者也可能会定义一些中间结点。

Scrum基本规则里并没有Milestone的概念。那么，如何把一个时间跨度长的Milestone适配到一个短周期的Sprint？如何有效地把Milestone的目标转化成多个Sprint Goal？实践过Scrum的人都应该有这样的疑惑，而且随着项目定义的Milestone和Sprint之间时间差距越大，有效准确地适配Milestone的目标到Sprint目标的难度就越大，对Milestone这个过程的管理难度就越大。如果没有好的方法来解决这个问题，那么在大项目和长的Milestone中，当一些任务不是那么直观去计划，项目在后期就容易出现问题。

 

为了解决Milestone和Sprint之间时间长度差异的问题，可以引入时间长度介于Milestone和Sprint之间，时间长度相对固定的新的概念Release，并为它定义相应的事件：

1）  Release的时间长度为Sprint时间长度的2~4倍。

2）  引入新的事件ReleasePlanning Meeting，Release Review。

4．Scrum的开放性与任务板

Scrum的许多规则，都符合“自组织”的特点。

Task Board，俗称“墙”。在团队工作区的一个区间，把一个Sprint需要完成的任务都贴在墙上。当团队成员、Product Owner等不同角色的人员经过工作区时，可以很容易知道这个Sprint的工作进展情况，顺利与否等等。“墙”可以帮助团队尽可能地让信息暴露，减少信息传递的成本，符合自组织的“信息共享”的特点。所以推荐大家在项目使用”墙“这个工具。

 

5．如何组织好SprintPlanning Meeting

Sprint Planning Meeting无疑是Scrum中最重要的事件之一，也是Scrum定义的事件中最大的一个，不能像每天例会和Sprint回顾会议一样很简单地只要做1，2，3点就可以了。其次Sprint Planning Meeting的内容与具体业务，涉及到项目的具体内容和技术层面，所以Scrum并没有就如何组织好Sprint Planning Meeting给出123的指导。

团队需要在很短的时间里分解Sprint Goal（用户故事列表），产生Sprint Backlog（Task列表），并估计每个Task需要的时间。是否真正理解User Story的需求，正确地分解成Task，并为每个Task估计了一个相对准确的工作量，这些都将直接影响到一个Sprint最终的工作成果。

 

众多因素影响到Sprint Planning Meeting的质量：

1）  团队对项目的理解程度。

2）  团队的技术成熟度。

3）  团队协作的成熟度。

4）  团队的心态。积极还是消极？

5）  会议组织者组织会议的能力。

6）  对敏捷自下而上方式理解的片面性，把有价值的经验排斥在Sprint Planning Meeting之外。

 

这里列举一下对Sprint Planning Meeting可能有帮助的方法：

1）  Team对需要分解的User Story提出问题。

2）  团队为上面的问题找到合理的答案。

3）  对于这个Sprint中新出现的需求，团队最好有Research之类的Task，来保证对新的需求有更深入和清晰的认识。

6．关于RetrospectiveMeeting

在经过了紧张的Sprint开发工作，团队的精神会松懈下来，以及对于Retrospective Meeting的重要性认识不足，早期我们对Retrospective Meeting不够重视，Retrospective Meeting流于形式，甚至出现过没有开Retrospective Meeting的情况。

Retrospective Meeting的重要性体现在：RetrospectiveMeeting是为了满足Scrum迭代趋优的目的。

前面提到自组织的特点之一是：迭代趋优。项目团队在面对变化，形成自组织团队的过程中，迭代趋优是必须经历的一个过程。Retrospective Meeting设计的3个问题，要求团队总结在上一个Sprint中做的好的方面和做的不好的方面。做的好的方面，我们要保持；做的不好的，我们要马上停止。

为了发挥Retrospective Meeting的效用，我们需要：

1）会前的认真准备

2）团队成员自己回顾

3）收集数据

4）对团队提出的问题作出响应

5）共享经验

6）不同层次的Retrospective Meeting

7．大的用户故事

为了更好地维护Product Backlog，这里介绍一个Scrum Guide里没有的新的概念：Epic User Story，中文为“大的用户故事”。当我们还不需要去细化一个需求的时候，我们可以采用一些概念化的描述。“大的用户故事”意味着比较大的工作量、不确定的需求等等。

8．自组织的特点

在敏捷的12条宣言的第11条，要求是“自组织的团队”。认识什么是自组织，自组织团队有什么特点，培养自组织的团队，对于运用好Scrum有很大帮助。

这里和大家分享自组织的特点，从这些特点，大家可以明白敏捷开发方法的许多规则是围绕自组织来设计的。

自组织的特点是：

1）信息共享

2）短程通信

3）微观决策

4）并行行动

5）整体协调

6）迭代趋优