Scrum开发过程简述
Scrum开发过程
一、 敏捷原则
个体与交互 胜过 过程与工具
可以工作的软件 胜过 面面俱到的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
这四句价值观用语句表达就是:
自组织团队与客户紧密协作,通过高度迭代式、增量式的软件开发过程响应变化,并在每次迭代结束时交付经过编码与测试的有价值的软件
胜过
与客户确定合同后在初期制定并遵循基于活动的完整计划,在重型过程和工具指导下,通过完成大量文档进行知识传递,最后交付需求
二、 Scrum的定义
Scrum是一个轻量级的软件开发方法
Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发周期包括若干个小的迭代周期,每个小的迭代周期称为一个Sprint,每个Sprint的建议长度2到4周。
在Scrum中,使用产品Backlog来管理产品或项目的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中,Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。
Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表,我们称它为Sprint backlog 。 在每个迭代结束时,Scrum团队将交付潜在可交付的产品增量。
三、 谁使用了Scrum
•Google
•IBM
•Nokia
•Siemens
•Philips
•Accenture
•Sun
•Ubisoft
•Bleum
•SAP
• Microsoft
• Infosys
• Oracle
• Wipro
• Motorola
• Yahoo!
• Schneider
• Agilent
• Irdeto
• Double Click
• Autodesk
• Tencent
• Plenware
• Trendmicro
• Moody’s
• StarCite
四、 Scrum角色
先来说一个故事:
一只鸡对一头猪说:“我们合伙开家饭店吧!”猪想了想,说:“好啊!那我们给这个饭店起个什么名字呢?”鸡说:“就叫【鸡蛋和火腿】好了!”猪回答道:“那还是算了吧,你要做的只是下几只鸡蛋,而我却把命都搭上了!”
因此,我们把与开发相关的干系人分为两类,“猪”类人员和“鸡”类人员。Scrum中,以下几个角色都是“猪”类人员,他们把所有的时间和精力都投入到产品的开发中,并对产品完全负责:
1、 产品负责人
产品负责人(Product Owner)的职责如下:
• 确定产品的功能。
• 决定发布的日期和发布内容。
• 为产品的ROI负责。
• 根据市场价值确定功能优先级。
• 每个Sprint,根据需要调整功能和优先级(每个Sprint开始前调整)。
• 接受或拒绝接受开发团队的工作成果。
Product Owner参与Scrum planning。
2、 ScrumMaster
作为Team Leader和Product owner紧密地工作在一起,他可以及时地为团队成员提供帮助。
他必须:
• 保证团队资源完全可被利用并且全部是高产出的。
• 保证各个角色及职责的良好协作。
• 解决团队开发中的障碍。
• 做为团队和外部的接口,屏蔽外界对团队成员的干扰。
• 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
3、 团队
负责产品的开发
• 一般情况人数在5-9个左右
• 团队要跨职能
(包括开发人员、测试人员、用户界面设计师等)
• 团队成员需要全职。(有些情况例外,比如数据库管理员)
• 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
• 高度的自组织能力。
• 向Product Owner演示产品功能。
• 团队成员构成在sprint内不允许变化。
• 团队整体向产品开发负责。
五、 Scrum工件
1、 产品Backlog
有优先级的故事列表,并估算故事点
2、 Sprint Backlog
当前Sprint要完成的任务列表,并估算工时
• 团队成员自己挑选任务,而不是指派任务
• 对每一个任务,每天要更新剩余的工作量估算
• 每个团队成员都可以修改Sprint backlog,增加、删除或者修改任务
3、 发布燃尽图
直观反应当前发布剩余的工作量,以Sprint周期数和故事点数为单位。
4、 Sprint燃尽图
Sprint燃尽图直观的反映了Sprint过程中,剩余的工作量情况,Y轴表示剩余的工作,X轴表示Sprint的时间。随着时间的消耗工作量逐渐减少,在开始的时候,由于估算上的误差或者遗漏工作量有可能呈上升态势。
六、 Sprint过程
1、 Sprint计划会议
• 团队从产品backlog中挑选他们承诺完成的条目。(做什么)
• 创建Sprint Backlog (怎么做)
• 标识具体的任务并为任务做估算
• 由团队协作完成,而不是Scrum Master
• 考虑了高层设计
2、 Scrum每日站会
团队每天进行15分钟的检验和适应的会议称为Scrum每日站会。每日站会上,每个团队成员需要汇报以下三个问题:
• 从上次会议到现在完成了哪些工作。
• 下次会议前准备完成什么。
• 工作中遇到了哪些障碍。
汇报的对象是团队,不是任何一位领导(PO,SM,团队负责人)。
汇报的重点在于提出问题,进而解决。
每日站会不是进度汇报会议,这个会议是为将产品backlog条目转化成为增量的人(团队)召开的。团队承诺实现Sprint目标和完成产品Backlog条目。每日站会是检验朝向Sprint目标的进程,如果有必要进行后续会议对Sprint中的下一步工作进行调整,目的在在于增加团队实现目标的可能性。这是Scrum经验过程中的重要检验和适应的会议。
3、 Sprint评审会议
Sprint评审会议用来演示在这个Sprint中开发的产品功能给Product Owner. Produc Owner会组织这阶段的会议并且邀请相关的干系人参加。
• 团队展示Sprint中完成的功能
• 一般是通过现场演示的方式展现功能和架构
• 不要太正式
• 不需要PPT
• 一般控制在2个小时
• 团队成员都要参加
• 可以邀请所有人参加
4、 Sprint回顾会议
Sprint回顾会议上,全体成员讨论有哪些好的做法可以启动,哪些不好的做法不能再继续下去了, 哪些好的做法要继续发扬。
• 团队的定期自我检视,发现什么是好的,什么是不好的。
• 一般控制在15-30分钟
• 每个Sprint都要做
• 全体参加
• Scrum Master
• 产品负责人
• 团队
• 可能的客户或其它干系人
七、 开发流程
阶段 |
参与人 |
事务 |
输出 |
开发调研 |
PO,SM,团队 |
讨论产品需求条目 问卷调查 分析 |
故事列表 |
工作量估算 |
SM,团队 |
使用估算扑克估算故事点 确定故事的依赖关系 |
带估算的故事列表 |
发布计划会议 |
PO,SM |
PO确定当前发布的时间和应该包含的故事 PO向各干系人公开发布规划 |
产品Backlog |
Sprint计划会议 |
SM,团队 |
PO确定最近1-2个Sprint的最优先级故事 团队从产品Backlog中的最高优先级故事中挑选承诺完成的条目 分解条目成为工作项 评估工作项工时(小时为单位) |
Sprint Backlog |
Sprint |
SM,团队 |
按Sprint Backlog产出软件产品 软件产品必须是潜在可交付的(经过完整测试,可运行,有完整用户文档) |
潜在可交付的产品增量 |
Sprint评审会议 |
PO,SM,团队 |
团队向PO及相关干系人演示产品增量 收集意见,为下一个Sprint作准备 |
|
Sprint回顾会议 |
PO,SM,团队 |
对开发流程进行回顾,检查哪些方法是值得保留的,哪些是要废弃的。 |
更好的Scrum流程 |