首页»软件工程»Scrum:兼顾计划与灵活的敏捷开发

Scrum:兼顾计划与灵活的敏捷开发

来源:leiphone 发布时间:2013-05-09 阅读次数:

  Scrum是一种兼顾计划性与灵活性的敏捷开发过程,原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前,都将有一个计划安排的过程,但冲刺开始后则由队员在原计划的基础上随机应变。

  不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段,Scrum将整个开发过程分为多次迭代(称为Sprint,冲刺)。

  在日常工作时,产品负责人会维护一个按优先级排序的“产品待开发项”(Product Backlog),即从客户价值理解和描述的产品功能条目,通常产品经理承担这一角色。 在每次迭代的第一天,召开Sprint计划会(Sprint Planning Meeting)。产品负责人会逐一挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问,并逐条估算,放入本次迭代的开发任务中,直至任务量饱和。一旦迭代开始,这些任务将不会发生大的发化。

  在迭代期内,团队将决定任务分配、所需的技术等,逐一完成任务。每天团队会进行一个简短的站立会议即每日站会 Daily Stand-up Meeting,沟通当前进度、下一步任务和当前存在的问题,以借助团队的力量解决。团队还维护一张“燃烧图”(Burn Down Chart),即所有任务的累积剩余时间随开发进程与日递减的图形,以观察和预测所有任务是否会按期完成。

  在每个迭代的最后一天,团队会召集评审会(Review Meeting),邀请产品负责人等参加,对已经完成的产品功能条目进行评审,后者做出判断并给出改进反馈。当天还会召开回顾会(Retrospective Meeting),对本次迭代的成功与失败之处做出总结,并在以后迭代中进行改进。

 Scrum中的三个角色

  产品负责人(Product Owner)

  主要由产品经理担任,其为确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROI(profitability of product)负责。

  主要职责包括:确定产品的功能;决定发布的日期和 发布内容;为产品的ROI负责;根据市场价值确定功能优先级;每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);接受或拒绝开发团队的工作成果;参与会议。

  领队(Scrum Master)

  担当团队leader,可以是开发Leader或者Team Leader, 和Product owner紧密合作,及时为团队成员提供帮助。

  主要职责包括:保证团队资源合理利用;保证各个角色及职责良好协作;解决团队开发中的障碍;作为团队和团队外部的接口,协调解决沟通中的问题;保证开发过程按计划进行,组织会议 。

  团队(Team)

  一般情况人数在5-9人。团队成员包括产品经理、开发人员、测试人员、前端开发、UED等。

  团队成员最好都是在项目的一个sprint中是全职的, 在一个Sprint中成员不容许更换。在项目范围内有权利做任何事情已确保达到sprint的目标;向Product owner演示产品功能。

 Scrum的四个会议

  Sprint计划会议

  在每个Sprint之初,由产品负责人讲解需求,并由开发团队进行估算的计划会议。 在会议上需要: 排列需求优先级;分析和评估产品Backlog并确定Sprint目标;计划会议上还需要制定Sprint计划,包括: 根据产品Backlog(User story或功能点)创建Sprint Backlog(即任务);然后为Sprint backlog中的任务做估算,以小时计算;团队成员从产品Backlog中挑选他们承诺完成的条目。

  每日站会(Daily Stand-up Meeting)

  团队每天进行沟通的内部短会,因一般只有15分钟且站立进行而得名,Team成员通常会在会议上讲述如下3点内容:

1) 昨天我做了什么

2) 今天我计划要做什么

3) 我遇到了什么问题,妨碍了我尽可能有效地工作

  ScrumMaster记录会议上提出的问题,但是不要在会议上讨论和解决问题,而是要会后在找相关人员进行讨论和解决。

  Sprint评审会议

  在Sprint结束前给产品负责人及客户演示并接受评价的会议。

  Sprint回顾会议

  在Sprint结束后召开的关于自我持续改进的会议,围绕如下三个问题进行讨论:

1) 本次迭代有哪些做得好

2) 本次迭代我们在哪些方面还能做得更好

3) 我们在下次迭代准备在哪些方面改进

  团队确定问题优先级,并根据优先级确定Team能够解决的Top问题;团队讨论Top问题的措施,并选择在下一个迭代可以完成措施,分配责任人进行跟踪

 Scrum的三个关键WorkItem

  产品Backlog

  产品Backlog是从客户价值角度理解的产品功能列表。

  1. 功能、缺陷、增强等都可以是待开发项。
  2. 一般以条目化的方式描述。
  3. 客户和用户必须能够理览。
  4. 描述怎样使用而非怎样制造。
  5. 整体上从客户价值优先级排序。
  6. 总工作量一般需要0.5~10人天。
  7. 高优先级的条目应有较详尽的描述,低优先级的条目可只有一个名称。

  冲刺(Sprint)Backlog

  Sprint Backlog是从开发技术角度理解的迭代开发仸务。在简单的纯软件环境,可以直接把产品Backlog当作冲刺待开发项分配到迭代中。在复杂的开发环境中,可以把一个产品Backlog分览为Web/后台……软件/硬件……程序/美工……等开发任务。

  燃尽图(Burndown Chart)

  图形化的方式展现了剩余的工作量(y轴)与时间(x轴)的关系。剩下的工作量应该有节奏的增加或减少,并最终显现下降的趋势。

  真的敏捷起来的话是非常有好处的,这对于产品经理来说也是一个考验,需要将所有业务需求清单梳理清楚,排定优先级,预估工作量,迭代验证。

  之前也在创意马拉松ideathon2012上,国外的敏捷团队做汽车,真正的产品敏捷确实效果非常好,不过国外的模式是否适合国内的产品研发环境,是否应该照搬,还是应该有自己特色的敏捷,需要根据实际情况来衡量,为了敏捷而敏捷反而会打乱整个产品流程,工具或者方法都得找到适合成长的土壤才能生根发芽。

  想要敏捷起来,首先得让整个产品团队都有敏捷的意识,否则就容易形式主义。

QQ群:WEB开发者官方群(515171538),验证消息:10000
微信群:加小编微信 849023636 邀请您加入,验证消息:10000
提示:更多精彩内容关注微信公众号:全栈开发者中心(fsder-com)
网友评论(共0条评论) 正在载入评论......
理智评论文明上网,拒绝恶意谩骂 发表评论 / 共0条评论
登录会员中心