SCRUM浅谈，User Story，Sprint，Burn Down Chart

什么是SCRUM

首先要知道SCRUM是敏捷开发的方法论之一。
在学习SCRUM之前我们需要简单储备一下基本的知识。
什么是敏捷开发？
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；

为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

什么是迭代？
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

关于Scrum和XP
前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。

什么是Scrum？
Scrum是一种灵活的敏捷软件开发管理过程。这个名词来源于英式橄榄球。Scrum方法由Ken Schwaber和 Jeff Sutherland 提出，而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。它将软件开发团队比作橄榄球队，全队有明确的最高目标：发布产品的重要性高于一切。团队高度自治，队员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着最高目标推进。而且每隔2至6周，每个人都能看到能实际工作的软件，并且据此决定是发布这个版本还是继续开发以加强它的功能。

敏捷的四大宣言是什么，满足四大宣言符合十二准则的即属于敏捷：

TechTarget中国原创内容，原文链接：http://www.searchcio.com.cn/showcontent_54322.htm
敏捷宣言，也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。
　　敏捷软件开发关注保持简洁的代码，经常性测试以及及时地交付应用的功能模块。敏捷宣言的创建是为了替代文档驱动的繁重的软件开发流程，例如瀑布式方法。
　　敏捷宣言强调的敏捷软件开发的四个核心价值是：
　　·个人和互动高于流程和工具
　　·工作软件高于详尽文档
　　·客户协作高于合同谈判
　　·变化响应高于遵循计划

　　敏捷选择提出的12条原则已经应用于管理大量的业务以及与IT相关项目中，包括商业智能（BI）。12原则包括：
　　1.通过早期和连续型的高价值工作交付满足“客户”。
　　2.大工作分成可以迅速完成的较小组成部门。
　　3.识别最好的工作是从“自组织的团队”中出现的，
　　4.为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。
　　5.创建可以改善可持续工作的流程。
　　6.维持完整工作的不变的步调。
　　7.欢迎改变的需求，即时是在项目后期。
　　8.在项目期间每天与项目团队和业务所有者开会。
　　9.在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。
　　10.通过完成的工作量计量工作进度。
　　11.不断地追求完善。
　　12.利用调整获得竞争优势。

SCRUM适用于大中小型项目，在SCRUM中最核心的是团队架构和软件研发框架。

原文参考：http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html
什么是Sprint？
Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。
Product backlog:产品需求列表，产品待开发项(Product Backlog)，产品需要完成的所有用户故事的集合，用户故事有大有小，有史诗级的也有小粒度级别的：根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能； 由Product Owner为Product Backlog中的任务确定优先级别；当开发团队开始做某个任务的时候，再精确定义和分解这个任务。
Product Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之做一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第一个Sprint有活可干。随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。
在Sprint计划会议上，产品负责人人为产品Backlog中的任务确定优先级，并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint中完成哪些功能，并把它们挪到Sprint Backlog中去。如下图：

迭代任务 Sprint backlog: sprint 待办列表或冲刺待办列表，sprint中需要完成的所有用户故事的集合，sprint的用户故事都应该在该sprint中完成，并且都有满意条件。
迭代计划会(Sprint Planning Meeting) ：在每个Sprint开始之前，需要召开Sprint计划会议，一般为4至8个小时。参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner从产品Backlog中挑选优先度高的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能；Scrum团队将这些任务分解成小的功能模块； Scrum团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
Dally meeting:日会议，每日站立会议。如下图：

上图就是每日的站立会议了，既团队每日例会，条件允许的话，每天都应该在同样的时间和地点，所有成员站立着举行。由于是站立的状态开会，因此时间比较短，一般为15分钟左右。这个会议最好是在每天的早晨开，有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。
会议由Scrum Master主持，Scrum团队的所有成员轮流回答上图中的三个问题，即：
- 昨天我完成了什么工作；
- 今天我打算做什么；
- 我遇到了什么障碍；
通过这三个问题，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。Scrum Master除了倾听团队成员的发言外，他还有责任设法解决团队成员在会上提出的困难，尽快扫除阻碍他们工作的障碍。即使有的问题Scrum Master没有能力解决，例如某些技术细节问题等，他也应该找到团队中或其他团队的来帮助快速的解决问题。另外，还有两点需要注意的地方：其一，这是团队成员之间的交流，也是相互的承诺，并不是用来向老板汇报工作进度的；其二，这也不是一个专门用于解决各种问题的会议，成员们遇到的问题可以在会上提出来，而有能力解决这些问题的人可以在会后帮助他们解决问题。
参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图，如下图：

任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。

每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）

Sprint burn down：sprint燃尽图，也就是完成的sprint工作，
Sprint 4 weeks：指的是一个sprint执行的进度，可以根据具体的项目定义。这里意思是1个月，怎么估算理想的时间呢，可以通过计划纸牌游戏确定，如下图：

上图可不是扑克牌，它是计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。
怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时…
Sprint review meeting：sprint审查会议，就是要演示并审核是否完成。Sprint结束时召开；由开发团队展示这个Sprint中完成的功能；长度为两个小时左右；不需要PPT；一般是已完成的功能的Demo； 谁都可以参加：客户、管理层、Product Owner、其他开发人员等等。
在每个Sprint结束时，应该组织一个Sprint评审会议。Scrum开发团队将在会上展示他们在这个Sprint中所做的工作。一般采用向大家演示产品新功能的方式来展示。
相对来说，Sprint评审会议不必很正式。通常不需要用到PPT幻灯片，而且长度最好控制在两个小时之内。也就是说，不要让Sprint评审会议成为Scrum团队的负担，他们不必花太多时间来准备这个会议。
Sprint评审会议的参与者，可以包括所有对该产品感兴趣的人：产品责任人，Scrum团队，利益相关者，管理层人员，客户，甚至来自其他项目的开发人员等等。
在Sprint评审会议上，Scrum团队用Demo的形式展示产品的新功能之后，与会人员依据在Sprint计划会议上确定的本Sprint的目标来评审具备了这些新功能的产品。
为什么一定要用Demo的形式来展示产品的新功能呢？因为这种方式有很多好处：
首先，参与会议的人都能直观的看到Scrum团队的工作成果；其次，利益相关者们可以据此提出更切合实际的反馈意见；第三，为了完成Demo，团队会努力完成并发布那些功能，即使只是发布在测试环境下，也比没完成的好。如果不做Demo，也许不少功能会停留在“已完成99%”的阶段。相比较起来，在有Demo的情况下，也许“已完成”的功能数量会相对少一些，但它们是确确实实完成了的，否则，那些“99%”的貌似完成的功能势必还要拖到下个Sprint来解决。
假如有一个刚从传统的开发模式转而采用Scrum的团队，由于不习惯这种自我约束、自组织的方式，在Sprint中并没做多少工作，那么在会上演示的时候，他们会觉得很尴尬。没准老板看到他们花了这么多时间只做了这么少的工作而感到很生气。发生这种情况当然是大家都不想看到的，但良药苦口，在下一个Sprint中，这个团队肯定会吸取教训，他们会明白无论什么情况下都必须Demo，那么他们必然会很好的完成这个Sprint并演示给大家看。
Release：可以执行的版本。
通过上图可以构件SCRUM在实际开发工作中是怎样运行的，如何通过Scrum指导开发？：

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），项目开发过程中需求的改变也要写进去，在每个迭代(Sprint)开始之前，要开一个迭代计划会议(Sprint Planning Meetting)。在会上，产品责任人(Product Owner)为 Product Backlog中的各功能需求确定优先级(或者是在会前完成)；
2、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story（用户故事）作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化；
3、随后Scrum开发团队（“自组织的开发团队”）按照优先级，从Product Backlog中挑选出他们认为能在本次迭代中完成的任务，根据Product Backlog列表，做工作量的预估和安排,把它们从Product Backlog中挪到Sprint Backlog中来,形成一个Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成，最好是精确到小时）；
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）。刚开始由产品负责人或这SCRUM Master主持，熟悉几天后可以每个人轮流组织站立会议，提高大家参与感，方式在实际工作中越开越失去意义，站立会议是根据实际情况而确定的，在项目开始之前或者项目发布时候，问题多且复杂，可以半天开一次站立会议；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

SCRUM团队架构

传统的项目团队架构模型，示例如下:

实际的项目团队架构模型，示例如下:

虚线可能是项目经理兼职，灰色可能大部分没有或者可有可无。

【Scrum开发流程中的三大角色】

产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。提供愿景，提供边界，提供User Story优先级。特别注意：需要和开发团队沟通需求，需要考虑研发团队的研发能力，也就是不能压榨技术团队，不能强制或者强迫加班加点。
流程管理员（Scrum Master [ SM ]）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。没有行政权利（也就是说无法解雇员工），训练团队正确的做事方法，遵循SCRUM流程和做事原则，不代替团队做决定。特别注意：要忍住帮团队做决定的冲动，产品负责人和SCRUM Master不建议是同一人。
“自组织”的开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面（基本角色包括：需求分析师，业务分析师，程序员，测试人员，软件架构，DBA，用户体验师），但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；主动与产品负责人，SM沟通，能够从大局出发，自觉完成工作，成员可以采用任何工作方式，只要能达到Sprint的目标。开发团队不是编码完就完成了。而是完成后要和团队一起沟通，演示并保证满意条件，最后提交可交付的产品并集成。在这个过程中一定要主动积极。
SCRUM Team的特点包括：
一起讨论需求。跨职能工作。自我管理，主动工作。团结合作，学习进步。注重团队承诺。一荣俱荣，一损俱损。
团队协作示例：

SCRUM最佳实践

User Story

SCRUM在需求方面的核心理念

1. 需求是涌现的
   
   • 不要试图在项目初期就明确所有需求。
   • 通过用户故事来组织及细化需求
2. 将些需求转变为讨论需求
   
   • 使用用户故事来讨论需求
   • 所有人都参与讨论需求，持续明确需求细节

用户故事

示例：
作为网站所有者，我希望系统可以统计广告点击率，以便我能清楚广告收益。
标准格式及作用
- 作为—-角色（作用：可以通过用户的角度来思考问题）
- 希望可以—-目标（作用：思考系统有什么功能，达到什么效果）
- 以便—-原因（作用：思考该功能对于该用户有什么实质的价值）

用户故事的难点

需求是由大大小小的用户故事组成，最开始的往往是个史诗级别的“大故事”，需要拆分成中故事，小故事。
难点：
1. 发现和提炼用户故事。
2. 由粗到细的拆分用户故事。
3. 安排用户故事优先级，安排到不同的sprint中去实现。

如何写出第一个用户故事

实战：网上售票系统，写出一个用户故事。
参考答案：作为*XX局长，我希望做一套网上售票系统，以便*更高的为人民服务。

开始分解用户故事

细分 “以便…”这部分
反向思考 “我希望..”这部分
进行系统涉众（也就是干系人）分析，列出关键用户
思考各用户在本产品上的利益所在
思考“希望….”（目标）部分。
思考“以便…”（原因）部分，确认“希望…”这部分是否合适。也就是反向思考目标和原因是否匹配。

Sprint

一个sprint就是一个小版本，建议时长是1个月，也可以更短。
一个sprint不是一个小“瀑布”，很难区分需求、设计、编码或测试阶段。所有工作都基于对用户故事的讨论。测试先行，测试驱动，单元测试必不可少。设计也是“涌现”式的，不是一次性做好了就好，也是不断改进的。
产品负责人和SCRUM自组织的团队商量并确定每个sprint的用户故事。
怎么估算用户故事呢？
- 精确估算有“满意条件”的用户故事。
- 精确估算在sprint中的用户故事。
- 粗略估算或暂不估算大、中故事。
- 估算由SCRUM“自组织的团队”负责。
- 精确估算时单位最好为小时，粗略估算时单位最好为天。

Burn Down Chart（燃尽图）

用来跟踪sprint中未完成工作的情况。每做完一个sprint的用户故事就烧掉，最后烧完sprint也就完成了。如下图，每一个点代表一个用户故事，或者故事点，或者可度量的工作量。所有点组成sprint。我个人认为以用户故事为一个点，因为sprint backlog中的用户故事已经是一个很喜欢的用户故事了，所以可以作为度量图。有人也有根据故事点做度量图，故事点就是拿出用户故事中的一个点作为基准故事点（最好找出可以正好1天完成的点），然后将用户故事中的所有点与这个基准点去比较，如果比基准点难就估算为1.x天，如果比基准点easy就估算0.x天等等。。。

其他

结对编程

这个就是两个程序员用一台电脑编程，
优点：
一个编程另一个同时评审及优化，轮流开发工作
同一段代码两个人熟悉
两个人互相切磋和互相学习。

持续集成

或者说Daily build每日集成
符合四大宣言之一可用的软件比详尽的需求更优。

测试驱动，测试自动化

参考：http://www.ibm.com/developerworks/cn/linux/l-tdd/