概述：
Scrum 不是一个标准化过程，不能保证你在有条不紊地按照步骤一步一步顺序执行后，就能在指定的时间和预算内产出让客户满意的高质量产品。Scrum 框架是建立在一套价值观、原则和实践之上，在这个框架的基础上，各个组织可以添加相关工程实践特有的实现方式以及在实现 Scrum 实践时所采取的特定方法。这样形成的就是你们特有的 Scrum 版本。
Scrum 角色：
1. 产品负责人：
1.1 唯一有权决定要构建哪些特性并以何种顺序构建这些特性的人；
1.2 对于 Scrum 团队要实现的目标，产品负责人要保持一个清晰地构想并把它传达给每一位参与者；
1.3 产品负责人还要确保总能完成价值最高的工作；
1.4 他要与 ScrumMaster 和开发团队紧密合作，及时解答他们提出的问题；
2. ScrumMaster：
2.1 帮助每个参与者理解并乐于接受 Scrum 的价值观、原则和实践。
2.2 她充当教练，在过程方面发挥教导作用；
2.3 在采用 Scrum 时，要帮助组织顺利适应这个过程；
2.4 作为辅助者，她要帮助团队解决问题和改进 Scrum 的使用状况；
2.5 她还有责任保护团队不受外界干扰，发挥领导作用，清除阻碍团队生产率的障碍；
2.6 她不同于项目经理或开发经理，她没有权力控制团队，不是管理者，是领导者；
3. 开发团队：
3.1 一个由几种职位的人组成的多样化跨职能团队，负责产品的设计、构建和测试；
3.2 进行自我组织，确定采用哪种最佳方式来实现产品负责人设定的目标；
3.3 一般是5~9人，如果是一个大型团队，那就拆分成若干个 Scrum 团队，每个团队不超过9个人；
Scrum 活动与工件：
1. 产品列表：
1.1 产品负责人结合 Scrum 团队其他成员与利益干系人的意见，最终负责确定和管理工作顺序，并采取产品列表的形式传达给别人；
1.2 高价值条目位于列表的顶部，低价值条目出现在底部；
1.3 产品列表是一个不断演进的工件；
1.4 建立和优化 PBI、估算并确定它们的优先顺序，这些活动统称为“梳理”；
1.5 条目大小等同于成本，为了合理确定条目的优先级，产品负责人需要知道条目的成本。
1.6 在实践中，一般使用相对大小测量，比如故事点或理想天数。这时候不考虑绝对值，而是考虑一个条目与基准条目的相对值。
2. 冲刺：
2.1 在 Scrum 中，工作在不超过一个月的迭代或循环中进行，这个迭代或循环称为冲刺；
2.2 每个冲刺完成的工作应当创建一些对客户或用户来说具有明确价值的东西；
2.3 冲刺总是有固定的开始和结束日期，而且持续期应当都是相等的；
2.4 一个冲刺中通常不允许改变范围内的目标或是更换人员；
3. 冲刺计划：
3.1 针对冲刺目标，开发团队要对产品列表进行评审，确定在可持续的节奏工作时根据实际情况在当前冲刺中能够完成的高优先级条目；
3.2 可持续的节奏指的是开发团队能够轻松、长时间保持的工作节奏；
3.3 每个特性能分解成一组任务，这些任务组成了“冲刺列表”；
3.4 开发团队会给出每项任务所需工作量的估算值，通常以小时计；
3.5 把 PBI 分解为任务是一种设计形式，是适时（just-in-time）制定特性完成计划。大多数 Scrum 团队在执行一个两周到一个月的冲刺时，都尽量在4~8小时内完成冲刺规划；
4. 冲刺执行：
4.1 执行为了完成特性而所需的所有任务级的工作；
4.2 团队成员要定义自己的任务级工作，然后按照自认为最佳方式进行自组织，并实现冲刺目标；
5. 每日例会：
5.1 理想的做法是在每天同一时间，开发团队举行一定时间范围内的每日例会，不超过15分钟；
5.2 每个成员轮流回答三个问题：
在上次每日例会之后我完成了什么？
在下次每日例会之前我计划做什么工作？
有什么障碍让我无法取得进展？
5.3 每日例会不是用来解决问题的，它是用来检视、同步、适应性制定每日计划的活动；
6. 完成：
6.1 在 Scrum 中，我们把冲刺的成果称为“潜在可发布产品增量”，意思是团队同意做的东西都做完了；
6.2 最激进的一个定义是当业务部门想要交付时，能够确定每个冲刺中要为内外部客户构建什么；
6.3 最好理解为对冲刺中实际构建的产品的信心，如果业务部门想要交付的话，那我们在交付这个冲刺的结果之前，不需要再做其他重要工作了，比如测试和集成等等；
7. 冲刺评审：
7.1 这个活动的目的是检查与调整正在构建的产品；
7.2 它是检视和调整产品的时机；
8. 冲刺回顾：
8.1 它是检视和调整过程的时机；
8.2 开发团队、ScrumMaster 和产品负责人一起讨论 Scrum 及相关技术实践中哪些是可行的、哪些是不可行的。重点关注的是必要的持续过程改进，找出数量适中的过程改进项并承诺在下一个冲刺中采用；
