Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。
敏捷的原则和方法 必须在每天的实践中落地，对人和管理要求高。所以有scrum master
为了适应变化，敏捷的迭代周期短
特征
迭代开发 ：这意味着你应该重复开发过程。
增量交付 ：意味着你应该一步一步地创建产品的“可用”子集，而不是在项目结束时一次性交付。
原则
迭代是受时间框限制的，也就是说即使放弃一些功能，也必须结束迭代。
每次迭代结束的时候让产品达到可交付状态十分重要， 每次迭代都以一个可运行的产品的公布而结束。
迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不能改变，以期集中精力完成已经确定的工作。由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡。经验证明：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, 短期会议固定的日常循环下，每一位团队成员都回答三个问题：
上一次会议我完成了什么？
达到我的目标碰到了什么障碍？
下一次会议之前我需要做些什么？
调整，优化次日工作。
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完成计划会议上选出的Spri