Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。

敏捷的原则和方法 必须在每天的实践中落地，对人和管理要求高。所以有scrum master

为了适应变化，敏捷的迭代周期短

特征

1. 迭代开发 ：这意味着你应该重复开发过程。

2. 增量交付 ：意味着你应该一步一步地创建产品的“可用”子集，而不是在项目结束时一次性交付。

原则

• 迭代是受时间框限制的，也就是说即使放弃一些功能，也必须结束迭代。

• 每次迭代结束的时候让产品达到可交付状态十分重要， 每次迭代都以一个可运行的产品的公布而结束。

• 迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不能改变，以期集中精力完成已经确定的工作。由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡。经验证明：4周是非常好的时间。

• 能否每个Sprint生成满足质量定义的PSPI      是Scrum 执行效果的试金石。

角色
  

product owner

作为产品负责人，PO清楚地知道产品的愿景，需要对产品待办列表的梳理、优化、优先级排序等负责。PO决定Why和What，一般可以对应为我们理解的产品经理和业务分析师的角色。
  

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

Scrum master

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍， 一般可以对应为我们理解的项目经理的角色。

Scrum team

主要负责软件产品在Scrum规定流程下进行开发工作。每位成员可能负责不同的技术方面（开发、测试），要求团队有很强的自组织能力，能够交付一个端到端的真正对客户有价值的产品。

• 曾经需要由经理或者lead来分配任务的团队，现在需要自己评审，估算，制定故事点数来管理BUG，然后再自己承诺在一个sprint中要解决的问题。

• 开发小组的工作

• 作为一个整体工作 ：开发团队、测试团队、客服团队和product       owner一起工作

• 按短迭代周期工作       ：大部分是 2～4周，在 Scrum中采用的是 30个日历天，也就是 4 周。

• 每次迭代包括：分析、设计、编码、测试，变成可交付的软件（称之为功能增量）

• 关注业务优先级：按照PO制定的优先级交付功能

• 检查与调整 ：每次新迭代开始，敏捷小组都会结合上一次迭代中获得新知识做出相应调整。

概念/工具

• 产品代办列表      Product backlog

• 使用产品Backlog来管理产品的需求,       产品backlog是一个按照商业价值排序的需求列表

• PO首先将需求按照优先级进行排列，产生一个Product       Backlog。作用类似于传统开发中项目经理确定需求文档

• 用户故事 user       story ：尽量减少依赖

• 冲刺代办列表 Sprint      backlog

• 先有product       backlog

• 产品经理和项目团队紧密协作，一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。

• 当研发团队制定了迭代清单后，除了团队成员外，任何人都不能再加入需求。

• 看板

• 工作流可视化

• 高度可视化的调度系统

• DOD

• 用户故事完成dod

• 迭代完成dod

• 发布完成dod

• CI/CD 持续集成/部署

一次集成要做哪些事情呢？它至少包括：获得所有源代码、编译源代码、运行所有测试，包括单元测试、功能测试等；

会议

• Sprint计划会议， sprint      planning meeting

• 每日站会 Daily      scrum meeting, 短期会议固定的日常循环下，每一位团队成员都回答三个问题：

1. 上一次会议我完成了什么？

2. 达到我的目标碰到了什么障碍？

3. 下一次会议之前我需要做些什么？

调整，优化次日工作。

• Sprint 评审会议

检验发布目标的进展，优化下一个sprint

• Sprint回顾会议

回顾已经完成的sprint， 并且确定做出什么改善使下个sprint更高效，快乐，满意

流程

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的产品需求中；