敏捷研发管理方案的优势

团队管理
Scrum Master
负责管理Scrum流程, 确保Scrum正常运转。
Scrum Master是教练, 是牧羊犬,是Scrum项目秩序的维护者。
产品负责人
负责管理产品Backlog 并使游戏项目价值最大化,代表项目的全体利益相关者。
团队
团队是负责开发软件的跨职能小组。团队是自我管理的,在Scrum Master 的帮助下,团队提出承诺,完成自己的承诺,实现软件价值。
Scrum of Scrums
传统Scrum方法仅适用于5-10人的团队,通过Scrum of Scrums的方法,可以将Scrum团队扩展到很大规模。我们可以将团队分解为多个小的子团队,每个子团队均有一名Scrum Master,听命于项目经理,每个子团队也有相对应的产品负责人。子团队成员会随着项目的进展而不断调整,但是在一个Sprint周期内,团队成员与产品负责人是固定不变的。
团队扩展
传统开发团队只包含了程序员,Scrum 团队是一个跨职能的团队,要求团队中不但有程序人员,也要包含了测试、美术甚至是脚本策划人员,凡是生产最终游戏产品的人员,均可以包含在团队之中,团队的跨职能保障了每个团队都能够独立工作解决困难,不需要依赖其他团队。
产品负责人组
当产品负责人数量较多时,产品负责人也会进行分组,游戏公司是典型的例子。 在游戏项目中,策划人员充当着产品负责人的角色,由于游戏庞大负责,策划人员也会进行分组,策划人员分组时可以考虑和团队分组保持同步,以加强Scrum工作效率。
产品Backlog 管理
建立Backlog层次结构
策划人员负责创建Backlog条目,完善条目信息,为条目设定优先级。 详细描述故事标题、优先级、故事。
故事评审
建立故事之间关联联系。
工作流程管理
Sprint 计划会
计划会之前,Scrum Master 会创建新的Sprint,设定Sprint的起止日期。Sprint内部还可按照子团队的划分再次细化,以适应Scrum of Scrums管理方法。
之后为每个子团队分配工作总时间,每个人告诉Scrum Master在这个Sprint 周期内,能够提供多少天的工作时间,这个数值将会作为Sprint工作任务分配的参照。Sprint计划会分为两部分,前一部分,为产品负责人为大家讲解用户故事, 按照优先级顺序逐条讲解故事,团队成员会向产品负责人提出和故事相关的种种疑问,产品负责人负责回答团队的问题,并随时补充故事描述或调整优先级。
计划会的后半部分中,团队要对故事的规模进行估算,通常先整个小组估算任务,会后再分配任务,这样才有利于以团队的整体智慧和能力估算一个任务的工作量,从而避免错误理解、笨拙的实现方法或不知道可以重用以往成果等问题。故事规模以点为单位,之后我们还要将规模转换为工作时间,故事点到时间的转换比率,可以同过以往Sprint实现情况来获得 将故事按照优先级顺序,分配到Sprint中。
预警星到达甘特图最右端说明分配的任务已经达到预计任务量,这时团队决定是否继续向Sprint内添加任务。
Sprint目标,即"我们为什么要进行这个Sprint?为什么我们不直接放假算了?[1]"Sprint目标是整个Sprint内工作的核心方向,是在整个Sprint当中团队判断应该做什么,不应该做什么的标准。Sprint目标是团队和产品负责人共同制定的,尚未完成的目标,如:"完成内测前最后的生活技能和聊天系统调整","修改洗钱Bug,并保证端午节活动上线"等。
Daily Standup Meeting

初期在自维护团队文化形成之前,往往由Scrum Master为团队成员分配, 但应当不断鼓励队员主动承担适合自己的工作,而非因为"已经完成了自己的任务"而袖手旁观。
Scrum实施初期,大家还没有形成严格的纪律性,任务状态与时间更新普遍存在遗漏问题,我们可以将4、5 中的工作放在每日立会中,作为每日立会的固定程序。
评审会
评审会上,产品负责人、干系人、团队成员和Scrum Master均须参加,团队成员按照Sprint中的完成的故事逐条演示,产品负责人、项目干系人对该功能进行评审,并将评审结果记录下来。
反思会

反思会上常见的问题:
- 上个Sprint中我们哪些事情做的好?
- 我们还需要改进哪些事情?
- 我们可以在下个Sprint中尝试什么?
- 我们要在下个Sprint中调整些什么?
作为一个自维护团队,Scrum 团队被鼓励在不与Scrum框架冲突的情况下,做任何他们认为正确的改进和尝试:是否需要减少文档?是否需要重新分配团队?Sprint周期长度是否合适?等等,产品负责人和Scrum Master会协助他们讨论、判断、实验这些想法。这与普通团队被动接受开发过程的模式截然不同,因此反思会的参与者应该充分表达自己的真实想法。
相关新闻
- SpecDD:混合的敏捷方法
- Scrum与SpecDD的工作流区别
- 为什么设计并创造SpecDD
- 团队成功之道
- 敏捷项目管理原则
- 敏捷的实际应用价值
- 敏捷项目管理 - 简介
- 敏捷应用生命周期管理(ALM)
- 实施敏捷框架
- TechExcel亮相2012中国敏捷大会
文章推荐
- SpecDD:混合的敏捷方法
- Scrum与SpecDD的工作流区别
- 为什么设计并创造SpecDD
- 团队成功之道
- 敏捷项目管理原则
- 敏捷的实际应用价值
- 敏捷项目管理 - 简介
- 敏捷应用生命周期管理(ALM)
- 实施敏捷框架
- 如何在DevSuite中使用SCRUM
客户评价
“DevSuite解决方案已经在我们的项目组成功实施,我们非常喜欢DevSuite解决方案中的需求管理、变更管理、任务跟踪管理和知识管理模块,这些模块能够围绕‘知识’对开发过程进行管理,难能可贵的是,DevSuite完全能够支持我们团队的开发模式,具有严格的团队权限管理和工作流控制机制,使我们的敏捷开发流程更加可控。”
— 陈飞舟, 副总裁,
金山游戏
“通过部署DevSuite游戏研发管理工具平台和导入敏捷开发,能更好的为游戏研发大团队提供丰富的理论指导和帮助,为盛大打造优秀的自主研发产品提供了必要的技术保障。盛大不仅仅关注其自身的研发,也持续不断的帮助18 基金投资的研发团队,让所有的研发团队在盛大这个大家庭中,共同快乐的成长,分享成功的经验和喜悦。”
— 李瑜, CEO,
盛大网络