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 （怎么做）

•   标识具体的任务并为任务做估算

•   由团队协作完成，而不是ScrumMaster

•  考虑了高层设计

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流程