研发过程+项目生命周期

助力敏捷研发管理过程实践解决方案

随着软件开发方法的不断演进,混合的开发方法在各软件企业和团队中应用越来越广泛。每一种开发方法都有其优点,如传统的瀑布式方要求有详细的项目计划和文档,部署、QA测试和交付过程严谨。而敏捷方法的优点则体现在能够快速迭代,更多的强调人员在整个开发过程中所发挥的作用。

有研究机构数据显示,越来越多的开发团队开始采用混合的开发方法。其中,有的团队同时采用XP、SCRUM等多种敏捷方法,也有同时采用敏捷和传统相结合的方法,而只采用一种敏捷方法的团队或企业的比例还不足三分之一。

基于Scrum方法,TechExcel 提出了大团队敏捷开发方法.

查看完整敏捷方案

DevSuite敏捷研发管理解决方案介绍

为您推荐TechExcel独创的混合敏捷开发方法:SpecDD

基于同时支持敏捷开发和非敏捷开发流程而设计,使得开发团队能用相同的办法来同时管理敏捷型、瀑布型、迭代型等敏捷和非敏捷项目。详情可查看>>

敏捷研发管理方案的优势

敏捷研发管理

团队管理

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会协助他们讨论、判断、实验这些想法。这与普通团队被动接受开发过程的模式截然不同,因此反思会的参与者应该充分表达自己的真实想法。

相关新闻

更多

文章推荐

客户评价

“DevSuite解决方案已经在我们的项目组成功实施,我们非常喜欢DevSuite解决方案中的需求管理、变更管理、任务跟踪管理和知识管理模块,这些模块能够围绕‘知识’对开发过程进行管理,难能可贵的是,DevSuite完全能够支持我们团队的开发模式,具有严格的团队权限管理和工作流控制机制,使我们的敏捷开发流程更加可控。”

— 陈飞舟, 副总裁,
金山游戏


“通过部署DevSuite游戏研发管理工具平台和导入敏捷开发,能更好的为游戏研发大团队提供丰富的理论指导和帮助,为盛大打造优秀的自主研发产品提供了必要的技术保障。盛大不仅仅关注其自身的研发,也持续不断的帮助18 基金投资的研发团队,让所有的研发团队在盛大这个大家庭中,共同快乐的成长,分享成功的经验和喜悦。”

— 李瑜, CEO,
盛大网络


敏捷研发管理

售后服务平台登录

用户名:

密码:

登录