Scrum的历史：
Scrum在英语中是橄榄球的意思。1986年，“The New product Development Game”竹内弘高和野中郁次阐述了一种新的整体性的方法，该方法能够提高商业新产品开发的速度和灵活性：他们将这种新的整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而团队“作为一个整体前进，把球传来传去”。1995年，在奥斯汀举办的OOPSLA‘95上，Sutherland和Schwaber联合发表了论文首次提出了Scrum概念。
没有人拥有scrum，没有scrum标准。
Scrum的概念：
scrum不是构建产品的一种过程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。
scrum能使产品管理和开发实践的相对功效显现出来，以便随时改进。
“Scrum是⼀一个基于团队进⾏行行复杂系统和产品开发的框架 ”-Scrum联盟
Scrum 框架包括 Scrum 团队及其相关的角色、事件、工件和规则。框架中的每个模块都有一个特定的目的，对 Scrum 的成功和使用都至关重要。
“据其定义，Scrum事实上并未谈及软件。 Scrum所涉乃是非软件项目亦可使用的工作管理和团队动力学。 ”-Jeff McKenna
scrum以整体的形式存在，才能作为其他技术、方法论和实践的容器良好运作。
Scrum 3355：
三个角色：Scrum Master、Product Owner（产品负责人）、Team（团队）
三个工件：Product Backlog（产品待办事项）、Sprint Backlog（Sprint待办事项）、可交付产品增量
五大仪式：Sprint（冲刺）、Sprint Planing（Sprint规划）、Sprint Daily Standup（每日站会）、Sprint Review（Sprint评审）、Sprint Retrospective（回顾）
五大价值观：coverage 勇气、openness 开放、focus 专注、commitment 承诺、respect 尊重
角色：
scrum团队里的人们多来自传统领域，头衔各不相同，所有技能scrum团队都需要，但scrum只承认三个互不相同的角色，即scrum master、产品负责人和团队成员。
产品负责人负责最大化产品以及开发团队工作的价值。产品负责人是唯一有权要求团队做事以及改变列表条目优先级的人。持有产品愿景、代表业务、代表客户、拥有产品列表、划定故事优先级、设立故事的接受标准、有空回答团队成员们的问题。产品负责人和团队之间有一层天生的紧张关系，产品负责人想要更多，团队则必须维护可持续的速率，这层紧张关系是有益的。不要合并产品负责人和scrum master。
scrum master负责确保scrum被理解并实施。担当教练的角色，引领团队达到更高级的凝聚力、自组织和表现。也有可能一并担当直接贡献的责任，这种情况下称之为工作型scrum master，或贡献型scrum master。
自组织团队与全功能团队：
自组织团队选择如何最好地完成他们的工作，而不是由团队外的其他人来指使他们。全功能团队拥有完成工作所需要的全部技能，不需要依赖团队外部的人（特性团队）。
全功能团队是具有不同职能专业或多学科技能的团队。当一个团队拥有满足需求的所有技能和资源时，就称为真正的跨职能。这意味者它不依赖跟其他团队的工作交接，也不用等待其他团队的工作。
反例：职能团队、UI团队、业务逻辑团队、测试团队、数据团队等等，团队等待、责任扯皮、交流沟通成本剧增。
特性团队：一种组件跨职能团队的常见方式是让团队对某个特性负责。这个团队对于某个特性从开始到结束全程负责。
反例：组建团队，承担开发特性时一个团队等待另一个团队的风险。
自组织团队：让团队竭尽他们所有的专业能力，不仅仅是完成他们的工作任务，还要自我监督和控制，自己做决定，甚至设计自己的流程。这样能够传递更多的商业价值、更加高效地协同工作以及学的更快等。降低管理成本。
用户故事：
用户故事是产品列表的基础构件。
用户故事模板：作为<某类用户>，我想<做某事>，从而<创造出某些价值>
用户故事模板：用户角色who、功能what、为什么why
Ron Jeffriesd的3C原则：
卡片 Card ：在一堆卡片上写下你期望的软件特性
交谈 Conversatioin ：聚在一起对要开发的软件进行深入讨论
确认 Confirmation ：对完工条件进行确认
产品Backlog:
是scrum的核心，是按重要性排序的需求或故事的列表。
用户故事地图：
一门在需求拆分过程中保持全景图的技术。