1986年，Scrum首次应用于产品开发，竹内弘高和野中郁次郎在 《The New New Product Development Game》文章首次提到将Scrum应用于产品开发。
1993年，Jeff Sutherland在首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。
1995年，Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。
2001年，敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。
2002年，Ken Schwaber和MikeCohn共同创办了Scrum联盟。
Scrum敏捷开发让团队以一个整体走完全程，产品开发过程从一个精心挑选的多学科团队的不断互动中产生，团队成员从开始到结束都在一起工作，该过程不是在定义好的、高度结构化的阶段中进行的，而是在团队成员的相互作用下产生的。
- Scrum的特点
4.1内置的不稳定性
高层通过发出一个宽泛的总体战略方向的信号来启动项目，并设置了一个极具有挑战的目标，同时赋予项目团队极大的自由来完成这个项目，这样既给团队压力，同时把团队推到墙边并把他们逼到极致发挥他们的创造力。
4.2自组织的项目团队
当项目团队被驱动到“零信息”的状态时，他们就会呈现出一种自组织的特征，这种状态存在模糊性和波动性，因此需要项目团队像初创团队一样运作，承担主动性和风险，并制定独立的议程，当一个群体表现出三个条件：自治、自我超越和异花授粉，这个群体就拥有了自组织的能力。
自治：公司的参与仅限于在一开始的指导、资金和道义支持，日常工作中高层很少介入，团队可以自由地设定自己的方向。
自我超越：项目团队全神贯注于对“极限”的永无止境的追求，从总部提出的指导方针开始，他们开始建立自己的目标，并在整个开发过程中不断提升目标。
异花授粉：由具有不同职能专业、思想过程和行为模式的成员组成的项目团队进行新产品研发，这种多样性孕育了新的思想和概念（这里和黑客增长理念接近，多样团队的观点碰撞，获得更具创意的实验方案）。
4.3重叠的开发阶段
在瀑布式方法下，一个项目以循序渐进的方式经历几个阶段，只有在满足了前一阶段的所有需求之后，才能从一个阶段过渡到下一个阶段，通过一些检查点控制风险，但这种方法几乎没有为集成留下空间，某个阶段的瓶颈可能会减慢甚至停止整个开发过程。而在整体或橄榄球方法下，这些阶段有相当大的重叠，这使得团队能够吸收整个开发过程中产生的振动或“噪音”，重叠方法加强了共同责任和合作，激发了参与和承诺，团队必须同步进度以满足最后期限，突出了解决问题的重点，鼓励主动采取行动，发展多样化的技能，并提高对市场条件变化的敏感性。
4.4多重学习
由于项目团队的成员与外部信息来源保持密切联系，他们可以快速响应变化的市场条件。团队成员参与一个不断尝试和犯错的过程，以减少他们必须考虑的选择的数量。他们也获得了广泛的知识和多样化的技能，这有助于他们创建一个能够快速解决一系列问题的多才多艺的团队。
4.5微妙的控制
尽管项目团队在很大程度上是独立的，但他们并不是不受控制的，管理层建立了足够的检查点，以防止不稳定、含糊不清和紧张局势演变成混乱。与此同时，管理避免了那种损害创造力和自发性的严格控制。相反，它强调的是“自我控制”、“通过同伴压力的控制”和“通过热爱的控制”，我们统称它们为“微妙的控制”。
4.6学习的组织转移跨
层次和跨职能积累知识的动力只是学习的一个方面，项目成员也有同样强烈的动力将他们的学习成果转移给小组以外的其他人，将学习内容转移到后续的新产品开发项目或组织内的其他部门。
Scrum敏捷开发的实施让开发团队有了一定自主权，已安排好的计划很大程度上不会被打断，同时上下游相互配合，为一个共同的目标而努力，每个人都清楚团队其他人的工作内容，每天都知道项目的实时进度，团队是一个整体的存在，而不是每个人独立工作下的个体，有着很强的集体荣誉感。
但Scrum能否成功实施，关键要先获得高层的认同和理解，让高层们理解Scrum的要义、利弊，如果Scrum能带来高效、优质的开发成果，那就在制定绩效结果并在实施过程中放权，让每个成员真正意识到项目成果是自己的事，而不是领导的事。如果是职能型的研发团队，同时也要获得各需求方的认可和支持，分享在这种方法下对整体的收益最大化，否则可能会面临各种不理解，最终可能导致实施失败。
因此，我们要落地Scrum敏捷开发，就要做好“猪”与“鸡”两种角色之间心理上的平衡与和谐，“鸡爷爷”切不可把“小猪”们看成是一群猪八戒，空有一身本领，但好吃懒做。“小猪”们也不可把“鸡爷爷”想象成周扒皮，只会半夜鸡叫，影响正常的开发进度。猪和鸡双方相互理解，达到项目开展过程中的平衡点，才能让整个项目顺利的完成。
敏捷开发的落地，人是最重要的，在做敏捷开发之前，需要先组建一直敏捷的团队，而作为这个团队的负责人，必须要对于敏捷有着清晰的认知。
二、敏捷开发的理解
很多人对敏捷开发的理解就是快，做项目中如果不快就对不起敏捷这两个字，但快到什么程度却没有概念，因此往往没有参与过完整敏捷开发项目的人，遇到一些问题之后“比如不是他想象的那么快”，就对敏捷开发提出质疑，觉得敏捷开发也就那样，究其根本是对敏捷开发的片面理解，或者只是了解了皮毛就觉得掌握了全部，而忽略其本质；
敏捷开发的目的是用来适应快速变化的市场，就像冲浪一样，一直处在动态、不停的变化当中，而在项目研发过程中遇到的需求变化和沟通平衡的挑战，就是你在冲浪时遇到的海浪，它们从不停止且永远在变化，所以我们要快速的适应变化。
首先，敏捷开发是一种做事情的方法。
它适用于范围软件、运维、服务等领域，但在硬件领域就不太适用，硬件一般不允许需求中途改变；
它适用于竞争激烈的市场，这种情况下，赶在对手之前交付一个不完美但能用的产品，并通过用户反馈不断优化就非常重要了；
它适用于快速变化的市场，研发团队和外部信息保持紧密联系，不仅能让产品能够适用于当前的外部市场，而且还能按时交付；
它适用于小团队，一般为5~9人，这样能使敏捷开发提倡的“面对面”沟通方式是可行的；
所以它的快在于应对市场变化的灵活度，在于团队配合的沟通和协作效率，在于对按时交付可使用软件信念的坚定，而不是某个项目原本开发需要3个月，简单的认为用了敏捷开发就一个半月就能交付了。
其次，它是一套工具集。
你可以通过各种最佳实践提炼出自己的敏捷实践方法，也可以选择其中几个你认为有用的来提高团队的工作效率，比如站会，看板，用户故事，演示、计划会、评审会、反思会等活动工具。
最后，敏捷开发也是一种企业管理方式。
它专注于团队的整体绩效，而不是个人的单打独斗能力，在实际工作中将决策权交给团队，以人为核心，发挥个人的主观能动性，提倡创新和效率，也需要负责人日常工作要不断强调的核心理念；
它把大项目拆成小项目去做，每次使用Sprint作为一个冲刺版本，每个Sprint控制在2~4周内，持续输出有价值的软件；
综合以上内容，敏捷开发是指在高度协作的环境中，持续不断地快速输出可交付的产品，通过反馈进行自我调整和完善的方法。
1.敏捷原则
围绕着敏捷宣言，在实际工作中，我们总结出一系列的原则，使敏捷开发更具可操作性；
可工作的软件是主要的进度度量标准
我们最优先要做的是通过尽早，经常性地交付可以工作的软件来使客户满意
要持续不断交付可用的软件，周期从几周到几个月不等，时间越短越好
最好的需求调研、产品架构、和产品设计来自于自组织的团队
善于激励项目员工，给他们提供所需环境和支持，并信任他们能胜任工作
在团队内部，最有效果和最有效率的传递信息的方式是面对面交流
敏捷过程提倡可持续的开发速度，项目方、开发人员和用户应该能够保持恒久稳定的进展速度
要做到简洁，尽最大可能减少不必要的工作
即使到了开发后期，也欢迎需求变化，要善于利用需求变更，帮助客户获得竞争优势
开发团队每隔一段时间，都会对如何能有效地工作进行反省，然后相应地对自己的行为进行调整
不断地关注最优秀的技术和良好的设计能增强敏捷能力
项目开发过程中，业务人员与开发人员需要在一起工作
随着敏捷的不断实践和理解，团队还可以提出自己的敏捷原则，最终让每个人认可并执行，打造出整体输出的高效团队。
2.团队组成
在一个敏捷开发团队中，有以下几种角色：
Product Owner 产品负责人
产品负责人是需求的制定者，代表了用户的意愿，保证Scrum团队从业务角度来说做正确的事情，产品负责人负责编写用户故事，排出优先级，并确定好每次Sprint的冲刺内容；
他是产品的既得利益者，也同时是部门负责人/项目负责人，责任是制定团队的目标，把握方向，为产品是否为客户想要的结果负责，同时也承担着团队管理的责任，给团队赋能，协调公司资源，激励团队成员，以及对弱能力成员进行辅导，最终让团队成员整体作出成绩。
Scrum Master 敏捷教练
为项目进度和交付结果负责的人，是团队的负责者，提供服务要满足团队最高优先级需要；同时确保Scrum的正确理解和使用，使得每次Sprint的收益最大化，他必须了解完整的开发过程，以及开发过程中上下游的关系，擅长使用Scrum各种工具，并在实际的工作中引导团队成员；
ScrumMaster是团队的保护伞，确保团队集中精力完成冲刺，同时他要扫清妨碍团队生产效率的一切障碍；ScrumMaster还要帮助他人理解变革的需要，在Scrum团队之外Scrum所带来的影响及Scrum能帮助达到的广泛而深远的收益。ScrumMaster还要确保组织的各个层面都发生有效的变革，不仅能够促成短期的成功，而且能够得到长期的收益。
这个角色可以是一个专职岗位，专职的好处是项目管理更加专注和专业，引入快，但可能会工作不饱和，因此一个专职的ScrumMaster可以参与多个项目；也可以从团队中选一个资深的团队成员兼任，兼任的好处是降低了人力成，对项目和产品理解更深，协作效率更高，但对ScrumMaster能力要求较高，对于成员的工作会有一定影响；
但不管是专职还是兼任的，这个角色要有很强的责任心才能按时交付、足够细心才能控制好进度，擅长沟通才能扫清障碍，善于提问才能给团队启发，让开发团队自己找到答案，实现自组织管理；
Scrum Team 开发团队
人数不宜过多，5~7人比较理想，包含产品、设计、前端、后端、测试等多角色，是实际价值产出者；
开发团队的职责是合理评估好工作量，每天完成既定的工作内容，遇到阻碍要积极解决，解决不了需要及时需求帮助，承诺按时交付可工作的软件。
敏捷开发的团队是一个自组织的团队，这个团队接受外部给与的任务和约束条件，自行决定如何完成任务，在团队中，团队成员自己决定做什么，如何做；就像一个篮球队，上场之后教练和老板就失去了球队的控制权，场上的任何决定只能靠团队成员自己来做；而角色的区分，让项目成败不全压在团队负责人身上，整个团队要去承担相应的责任。
4.自组织团队特点
在一个自组织的团队中，具备以下6个特点：
尊重：是指团队成员之间和团队外部之间彼此尊重，公司放心授权，团队间彼此信任，才能建立起高效的合作；每个成员敢说、敢做、敢犯错，不不断试错中快速找到正确的路径。
透明：透明是建立信任和尊重关系最好的方法，讲明原则，制定规则，在各种实践中保持透明，尽量将一切活动可视化，使用看板、燃尽图等工具。
目标：团队要有明确的目标，团队才有前进的动力和方向；让团队明白项目背后的意义，团队成员才能明白自己付出的价值，在团队中达成价值、完成标准、验收标准等共识。
承诺：有了目标就要有承诺，团队各成员之间相互承诺，完成彼此的责任和任务，做到当天的事情当天毕，对团队承诺的事情，一定要做到。
团队：一个项目团队就是一个整体，在项目开发过程中，要时刻强调以团队作战，团队共同进退，增强每个人的集体荣誉感。
辅导：互相辅导是提升团队能力的最佳途径，也是实现团队间尊重、承诺的好方法，比如师徒制、Code Review、反思会等。
同时，定义好每个角色的责任边界。
产品负责人：为团队的配合度负责，为员工的流失负责，为最终交付产品的客户使用满意度负责；为打造高效的敏捷流程负责；
敏捷教练：要为项目交付时间负责，为没拦住开发过程中需求变更负责，为长期加班状态负责，为线上bug负间接责任，为员工流失负间接责任；
产品经理：要做到项目启动会时，为PRD完备负责；在DL日期之前，不再变更需求，也不再插新需求，也就要求产品的逻辑要思考全面；为交付时间负责间接责任，为拦住需求方提负担过重的需求负责；
开发团队：要为里程碑进度负责；要为交付时间负责；为线上bug负间接的责任；
测试：为线上的bug负责。
想要打造自组织的团队，需要负责人坚信敏捷开发带来的团队变化，倡导敏捷文化，打造诚实守信、精益求精的团队氛围，在一个一个项目实践中磨合；
如果是新团队建议刚开始就使用敏捷工作方法，形成部门规矩，后续新人融入之后能够快速适应；而成熟团队需要潜移默化，切勿着急改变，挑选合适的成员来进行试点，有了一定结果之后再推广到其他的项目团队中。
三、完整开发流程
一个软件产品的完整开发流程分为4个部分，分别是：
1) 需求确定阶段
2) 产品研发阶段
3) 产品验收阶段
4) 全量测试发布阶段
在实际的开发过程中，为了提高效率，②③是有可能重叠交替进行，Scrum框架为每一个阶段都设定了对应的解决方案。
1.Scrum框架-334
