Scrum敏捷开发培训分享(二)

Scrum是一种兼顾计划性与灵活性的敏捷开发过程,原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前,都将有一个计划安排的过程,但冲刺开始后则由队员在原计划的基础上随机应变。不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段,Scrum将整个开发过程分为多次迭代(称为Sprint,冲刺),一般为期2~4周。

在日常工作时,产品负责人会维护一个按优先级排序的“产品待开发项”(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 Planning Meetings(Sprint计划会议),Sprint Review Meeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)。

Scrum Master

担当团队leader,可以是开发Leader或者Team Leader, 和Product owner紧密合作,及时为团队成员提供帮助。主要职责包括:保证团队资源合理利用;保证各个角色及职责良好协作;解决团队开发中的障碍;作为团队和团队外部的接口,协调解决沟通中的问题;保证开发过程按计划进行,组织Scrum Planning Meetings(Sprint计划会议), Daily Stand-up Meeting(每日站会), Sprint Review Meeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会) 。

团队(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上看到过国外的敏捷团队如何做汽车,真正的产品敏捷确实效果非常好,不过国外的模式是否适合国内的产品研发环境,是否应该照搬,还是应该有自己特色的敏捷,需要根据实际情况来衡量,为了敏捷而敏捷反而会打乱整个产品流程,工具或者方法都得找到适合成长的土壤才能生根发芽,想要敏捷起来,首先得让整个产品团队都有敏捷的意识,否则就容易形式主义。个人观点仅供参考,结合之前的《敏捷开发培训分享》,相信大家能对敏捷有一个初步的了解了。感觉有点像先进的SAP ERP系统,却不是每个国内企业都能用起来的。



无觅相关文章插件,快速提升流量

“Scrum敏捷开发培训分享(二)”9 条评论

拜读了,有空我们聊聊。

感谢分享

happytime | 2012-11-11 23:18 |

学习了,正在尝试敏捷

color | 2012-11-12 08:55 |

看文章,支持一下。

wordpress | 2012-11-12 11:15 |

学习了。

edown | 2012-11-13 23:15 |

分析的很透彻,很欣赏你的看法,学习了。

commenter

文章都不错

pchome | 2012-11-19 09:52 |

你是怎么想的呢?

player | 2012-11-21 23:00 |

这么好的文章,要顶。