什么是敏捷开发？
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过 测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可 使用状态。
它采用的是迭代式开发：迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
什么是Scrum？
Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
Scrum敏捷开发的好处
Scrum敏捷开发可以显著增加项目成功的可能。
目前，淘宝，腾讯这样的大公司早已实行了敏捷开发管理。在北京，上海的中小型公司里Scrum敏捷开发也很流行，有很成功的项目经验。
Scrum流程图
从这幅图我们不难发现，完成Scrum敏捷开发的流程为：
第一步：Product Backing 找出完成产品需要做的事情。
第二步:Sprint Backlog 决定当前冲刺需要解决的事情。
第三步：Sprint 冲刺。
冲刺期间要开每日立会(Scruming Meeting)，大家站着开会，大家一次报告：
1.我昨天做了什么。
2.我今天要什么。
3.我碰到了哪些问题。
第四步：得到软件的一个增量版本，发布给用户。然后在此基础上进一步计划增量的新功能和改进。
Scrum开发的一些注意事项：
1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天 要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可 以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本 发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
运用Scrum开发流程中的一些场景图：
上图是一个 Product Backlog 的示例。
上图就是每日的站立会议，参会人员可以随意姿势站立，任务看板要保证让每个人看到，
当每个人发言完后，要走到任务版前更新自己的燃尽图。
任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
上图可不是扑克牌，它是计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。
怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时...
下面列举一个Scrum敏捷开发的具体案例：
- Sprint 计划会议 1：原始需求者、产品负责人及团队一起，确定任务优先级，定出 Sprint 目标和既定产品 Backlog。
- Sprint 计划会议 2：团队将既定产品 Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。
- Scrum 每日例会：项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在 15 分钟内。
- Sprint 验收会议：由原始需求者或产品负责人断定实际所发布的功能是否与既定的 Sprint 目标一致。
- Sprint 回顾会议：项目团队分析Sprint中的成功经验和所遇到的障碍。
整个Sprint的周期（时间盒）确定为10天（两周），具体的时间安排为：
- Sprint会议（0.5天）
- 开发（8天）
- 验收&总结（0.5天）
- 技术提升日（1天），自主学习技术
1、 需求收集
1.1 需求的分类
需求可与分为业务团队的，也可以包括团度内部的，比如性能优化。
1.2 需求提交模板
| 需求种类 | 优先级 | 需求类型 | 需求标题 | 详细描述 | 验收条件 | 价值验证 | 提交时间 | 需求人 | 备注 |
① 需求种类 可从以下四种情况中选择
- – 任务
- – 可用性问题（Bug）
- – 性能问题
- – 概念想法
注意：即使是概念性的想法，目前技术上无法实现的想法都可以收集。
② 优先级 可从以下五种情况中选择
- – 特别的严重
- – 非常重要
- – 很重要
- – 普通
- – 低
注意：切忌将所有的任务的优先级都设置的非常的高，这里不提供非常紧急这样的表述。我们只会根据重要程度去执行任务，所以紧急的任务需要业务部门及需求方尽早的提出。
③ 需求类型 可以是两种类型
- – 详细需求
- – 毛坯需求
注意：我们的需求并不是要求一定要完整的，及时是一些非常毛坯的需求，也可以提交过来，毛坯的需求由产品负责人进行分析和梳理，暂不清楚的可选择搁置。
④ 需求标题 有自己进行书写，但是需要遵守的规范是采用动宾短语格式。
比如：“导出+CN酒店每天的PV、UV等流量数据”
注意：这里的需求内容一定是站长使用者角度是提出的，切勿出现专业的程序方面的表述：如添加一个导出的按钮。还有需要注意的是动词切忌使用大而宽泛的词，比如“管理”，类似“管理关键词”这样的需求是严格避免的，这样会使得要开发的内容变得没有清晰的边界。
⑤ 详细描述 需要按照用户故事的格式进行书写。具体用户故事格式的要求如下：
用户故事是从用户的角度来描述用户渴望得到的功能。需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。一个好的用户故事包括三个要素：
- 角色：谁要使用这个功能。
- 活动：需要完成什么样的功能。
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：作为一个<角色>, 我想要<活动>, 以便于<商业价值>
比如：作为一名酒店前端开发人员，我期望查看所有酒店页面的页面打开时间，以便了解哪些页面需要进行技能优化。
一个好的用户故事同时要符合INVEST原则，INVEST原则分别是：
- 独立性（Independent）: 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
- 可协商性（Negotiable）: 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事带有了太多的细节，实际上限制了和用户的沟通。
- 有价值（Valuable）: 每个故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
- 可以估算性（Estimable）:开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
- 短小（Small）: 一个好的故事在工作量上要尽量短小，最好不要超过8个人/天的工作量,至少要确保的是在一个迭代能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
- 可测试性（Testable）: 一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。
注意：
- 角色的范围不能过大，比如是作为一名“用户”，这样是的不被接受的。
- 商业价值也不能大而宽泛，比如，能为公司创造业绩。如果要写也一定要对业绩做初步估算，比如，预期会给公司带来每月1万张订单。
⑥ 验收条件 是开发完成后检验的标准，所以一定要认真填写，否则可能开发出来的东西与预期不达标。
以上面的“导出+CN酒店每天的PV、UV等流量数据”为例，它的验收条件可以为：
- 1) 可以为每个用户设置是否拥有此导出权限
- 2) 导出的时间可以细化的天。即可导出每天的流量。
- 3) 导出数据的最大时间跨度为31天
- 4) 对于导出数据做好日志记录，后期可查是谁进行了导出。
- 5) 导出的字段包括：PV、UV、跳出率、新访客占比。
⑦ 价值验证 说明如何跟踪上线后的效果
2、Sprint 计划会议 1
目标：定出 Sprint 目标和既定产品 Backlog。
2.1 会议准备
□ 所有会议资源都已预订
□ 会议室
□ 投影仪
□ 笔记本
□ 在会议前一天确定议程，将目标和议程发送给所有与会者
□ 原始需求人（可选择不来）
□ 产品负责人
□ Scrum Master
□ 开发团队
□ 已按优先级排列产品 Backlog整理完毕
□ Sprint 时间表已经安排
□ Sprint 计划会议 1 的时间安排
□ Sprint 计划会议 2 的时间安排
□ Sprint 的第一天已确定
□ Sprint 的最后一天已确定
□ Scrum 每日例会的时间安排
□ Sprint 验收会议的时间安排
□ Sprint 回顾会议的时间安排
2.2 会议议程
□ 把 Sprint 时间表公开给所有人
□ 产品负责人向团队产品阐述需求（用户故事）
□ 开发人员对用户故事不清楚的点可以及时提出。
□ 产品负责人或者原始需求者负责解答不清楚的故事点。
□ 如果讨论现场发现有遗漏的需求，可由产品负责人添加至产品Backlog。
□ 如果对需求的优先级存在异议，可会上讨论，确定最终的执行顺序。
□ 产品负责人& 需求方和小组成员相互认可这 Sprint 目标和既定产品 Backlog
2.3 会议结果
□ 为 Sprint 计划会议2的进行准备好既定产品 Backlog
2.4 补充内容
产品Backlog模板（基本同需求模板）
| 需求种类 | 优先级 | 需求类型 | 需求标题 | 详细描述 | 验收条件 | 提交时间 | 需求人 | 备注 | 跟进人 | 预计完成时间 | 实际完成时间 | Sprint版本号 | 处理情况 |
处理情况可从以下几种类型中选择
- – 等待处理
- – 正在进行
- – 已经完成
- – 不予处理
- – 暂时搁置
- – 需要讨论
3、Sprint 计划会议 2
目标：确定所有任务，生成 Sprint Backlog，确认 Sprint 目标
3.1 会议准备
□ 要求原始需求者离开会议，参会人员为
□ 产品负责人
□ Scrum Master
□ 开发团队
□ 在Sprint 计划会议1后10分钟举行
□ Sprint 计划会议1中整理的既定产品 Backlog
□ 任务估时牌（按1,2,3,5,8,13估算）
3.2 会议进程
□ 团队成员按顺序分析既定产品 Backlog的讨论实现细节
□ 编码
□ 测试
□ 代码审核
□ 学习新技术
□ 编写文档
□ 部署
□ 上传
□ 可看情况确定是否使用扑克估时
□ 任务超过一天时，需要拆成多个小任务
□ 如果团队评估下来任务过多，可和产品负责人一起删减任务
□ 如果团队评估下来任务过少，可和产品负责人一起从产品Blaclog中引入新的需求。
3.3 会议结果
□ 将最终确认的可完成的需求清单邮件至
□ 原始需求人
□ 产品负责人
□ Scrum Master
□ 开发团队
□ 将最终确认的任务列表邮件至
□ 产品负责人
□ Scrum Master
□ 开发团队
3.4 补充内容
Sprint Backlog模板
| 优先级 | 需求标题 | 详细描述 | 验收条件 | 需求人 | 跟进人 | 处理人 | 任务描述 | 处理日期 | 估时 | 实际耗时 |
需求和任务是一对多的关系，及一个需求可以产生多个任务，任务可以是程序类描述，如“数据数据库设计”
4、Scrum 每日例会
目标：团队成员间工作进度的沟通和协调
4.1 会议准备
□ 邀请与会者
□ 外部团队协助人员（如有有需要的话）
□ 原始需求人（只有选择是否参加，过程中不可发言）
□ 在 Sprint Backlog 上的所有任务都是可以增删修改，可重排序的
□ 一台电脑，中间标识任务的状态，可设为“待处理”，“正在处理”，“已完成”的。
4.2 会议进程
注意：
- – 会议限定在15分钟内
- – 团队里的每个成员都必须回答以下三个问题，并考虑其相关的行动。
□ 上次会议时的任务哪些已经完成?
□把任务从“正在处理”状态转为“已完成”状态
□ 下一次会议之前，你计划完成什么任务？
□ 如果任务状态为“待处理”：转为“正在处理”状态
□ 如果任务不在 Sprint Backlog 上：添加这个任务
□ 如果任务不能在一天内完成：把这任务细分成多个任务
□ 如果任务可以在一天内完成：把任务状态设为“正在处理”
□ 如果任务状态已经是“正在处理”：询问是否存在阻碍任务完成得问题
□ 有什么问题阻碍了你的开发
□ 如果有阻碍你开发进度的问题：把该障碍加入到障碍 Backlog 中，Scrum Master负责记录
□ 如果展开了一个问题的讨论
□ 提醒团队的成员们注意把精力集中在回答关键问题上
□ 如果相关人员想发表些言论
□ 礼貌地提醒他，该会议只允许让小组成员讨论
4.3 会议结果
□ 得到最新的障碍 Backlog
□ 得到最新的 Sprint Backlog
□ 最新的工作进度图（燃尽图）
□ 第一次的例会创建一封邮件，由Scrum Master会议后将例会内容回复此邮件。
4.4 障碍Backlog
障碍 Backlog 列举了所有团队内部和团队相关的和阻碍项目进度的问题。Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。
10 大典型障碍
– 会议规则没能被遵循
– 产品远景和 Sprint 目标不清晰
– 没有产品负责人负责回答提问
– 产品 Backlog 未能按商业价值区分优先级
– 并不是所有负责交付产品的人员都是团队里的成员
– Scrum Master 还要处理其他任务，不能集中精力
– 团队人数过多
– 团队没有能坐在一起工作的空间
– 团队的 Sprint Backlog 混乱
– 中间遇到了技术难题
5、Sprint 验收会议
目标：根据团队这次 Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。
5.1 会议准备
□ 所有会议资源都已预订
□ 会议室
□ 投影仪
□ 笔记本
□ 在会议前一天确定议程，将目标和议程发送给所有与会者
□ 原始需求人（可选择不来）
□ 产品负责人
□ Scrum Master
□ 开发团队
□ 对于每个人来说 Sprint 目标都是公开的
□ 对每个人来说既定产品 Backlog 是公开的，可获取的
5.2 会议进程
□ 团队按 Backlog 中的问题，逐个地介绍这次 Sprint 的结果，和演示新功能。
□ 如果产品负责人或需求方想要改变功能：添加一个新问题到产品 Backlog 中
□ 如果对功能有一个新的想法：添加一个新问题到产品 Backlog 中
□ 如果小组报告项目遇到阻碍现在还没能解决：把该障碍加入到障碍 Backlog
5.3 会议结果
□ 对这次 Sprint 的结果和整个产品的开发状态的共识
6、Sprint 回顾会议
目标：通过总结以往的实践经验来提高团队生产力。
注意：主要指导原则：不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩。
6.1 会议准备
□ 邀请与会者：
□ Scrum Master
□ 团队所有成员
□ 产品负责人（可选）
□ 附属工具
□ 便签纸
□ 白板
□ 在白板上写上主要指导原则
□ 在白板上画上一个至少三页纸连在一起长的时间轴
□ 在白板上写上“我们的成功经验是什么”
□ 在白板上写上“有什么能够改进”
□ 在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”
附属工具：
6.2 会议进程
□ 介绍会议目标
□ 介绍会议主要指导原则
□ 在时间轴上，标记出 Sprint 的开始和结束时间
□ 向与会者解说如何使用该便签纸进行工作
□ 派发便签，并且让每人写上他们认为这次 Sprint 中最为重要的事，限时 5 分钟
□ 每个与会者轮流把他的贴纸贴到白板的时间轴上，并用两句话来解说这事有什么特别的地方
□ 分发便签纸，并让每人写上“我们的成功经验是什么”，限时5分钟
□ 每个与会者轮流把他的贴纸贴到白板“我们的成功经验是什么”的区域上，并解说。
□ 分发便签纸，并让每人写上“有什么能够改进的”，限时5分钟
□ 每个与会者轮流把他的贴纸贴到白板“有什么能够改进的”的区域上，并解说。
□ 对于挂纸板上“有什么能够改进”的区域中的每一项
□ 询问团队“谁去负责解决这个问题？”
□ 把便签纸移到挂纸板中“谁负责”的区域中
□ 和团队一起把这些区域按优先次序排好
□ 给会议做个总结
□每个与会者对 Sprint 回顾会议作简短的回馈
6.3 会议结果
□ 白板上“谁负责”这栏对于公司内所有人是公开的
□ 把与公司范围相关的障碍增加到障碍 Backlog 中去
□ 把与团队范围相关的障碍增加到障碍 Backlog 中去
□ 整理所有会议结果，邮件至团队中所有人
注明：
案例分析参考博客： http://www.biaodianfu.com/scrum-flow.html
Scrum一些场景图参考：http://blog.csdn.net/bihailan123/article/details/50708863
文章写的很简明，谢谢以上两位博主！
