概述Scrum和敏捷的历史发展
一、2001年雪鸟会议，敏捷概念的提出
2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。虽然Agile的概念是在2001年被提出，但这并不等于敏捷开发实践是在2001年才被提出。雪鸟会议是对之前几十年中软件开发实践探索的总结，是水到渠成的一个结果。
二、敏捷开发简史
许多人认为，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。但是，实际上敏捷方法，特别是迭代和增量开发方法（IID）起源于20世纪30年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是20世纪60年代初的美国航天局水星计划。在这个项目中，一些极限编程方法如测试先行等也被使用。此后，迭代和增量开发被IBM联邦系统部（FSD）和沃森研究中心（Watson Research Center）采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中，温斯顿.罗伊斯（Winston Royce）建议在一个项目中使用两次瀑布模式，也就是使用两次迭代。
20世纪70年代，最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。迭代和增量开发从此开始稳步发展，越来越多的项目开始使用这种开发模式。在1976年，Tom Gilb在他的著作《软件度量》（“Software Metrics”）一书中阐述了他的迭代和增量开发实践，这可能就是第一部阐述这种方法的书籍。迭代和增量开发的另一次出色发挥，是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。该项目由IBM联邦系统部（IBM FSD）在1977至1980年完成。一些典型的敏捷做法，如使用8个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。
20世纪80年代，更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型（Spiral model）。80年代初，在美国国防部发生了一件有趣的事情。美国国防部一直以来都要求其软件开发商在开发过程中使用严格的瀑布开发模型。但是到了1987年末，国防部开始“建议”使用迭代和增量开发作为软件开发模式。后来美国国防部的项目审查显示，早期使用瀑布模式开发的软件项目，有75%以失败告终，有些开发出来的产品根本没有被使用过，只有2%的软件产品无需大量修改就能被正常使用。
20世纪90年代，推荐使用迭代和增量开发的出版物和文献显著增加。在经历了多次有“瀑布心态”（‘waterfall mentality’）项目的失败之后，美国国防部开始“要求”而不是像80年代那样仅仅是“建议”他们的软件开发商使用IID开发模式。Rational统一开发过程（Rational Unified Process）也是在这一时期产生并发展起来的，它具有更规范的迭代渐进过程。到2000年底，更多的敏捷开发方法被广泛推广并被使用于各种不同的项目中。2001年二月，一组由17位在DSDM，XP，Scrum，FSD等领域的专家组成的代表团齐聚美国犹他州，寻找这些方法的共同点。最终，这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟。
三、软件交付危机
1970年至1990年是软件工程的基础理论和实践的爆发时期，当时的基本思路是将软件工程等同于物理工程，并尽可能在设计和构建过程中借鉴物理工程项目的管理理论与方法，最终产生了大家都熟悉的瀑布模型。这个过程完整定义了软件从需求到部署的全生命周期的各个阶段，之所以被称为瀑布是因为它要求团队在完成下一步骤之前必须已经完成了上一个步骤：在进行功能设计之前必须先完成需求分析，在详细设计之前必须先完成功能设计，以此类推。一旦一个阶段完成，这个阶段就会冻结，就像没有上山的水一样，也很难将项目恢复到流程的更早阶段。
这种方法给管理者带来了可以像控制制造业项目一样控制软件项目的错觉，那就是花在计划上的时间越多，花在编写代码上的时间就越少，并且代码越好。这增加了更多繁重的过程和方法，与交付可用软件相比，该方法更加注重计划和文档编制。并且这个过程大家忽略了一个关键的问题：在十年或更长时间里，机械或土木工程项目很少发生大的变化，例如您今天设计的桥梁很少会在一两年内发生大的变更，而软件项目则完全不一样。软件项目很少能具有和传统工程项目一样的稳定性，业务需求可能在一夜间发生很大变化，而我们完成一个软件的周期至少需要几个月甚至几年的时间，我们如何面对随时可能出现的变化呢？很明显软件工程需要一种不同以往的管理方法。
另一个问题是软件设计既是一个学科又是一门艺术，受人的因素的影响。人们可能根本不清楚如何能更好的定义软件，用户可以描述他们的工作流程，但不一定能清晰的告诉软件设计人员如何将这部分工作自动化及这些功能应该如何工作。我们必须接受一个事实：我们根本无法在构建产品之前精确定义所需的各种功能需求，这是软件工程与大多数其他工程项目的根本区别。
到90年代初期，随着PC在企业中的逐渐普及，市场对定制化软件开发的需求越来越大，同时软件项目管理方法也遇到了前所未有的挑战，这种危机经常被称为”软件开发危机“，表现为软件系统交付的严重滞后。据当时的行业专家估计，一个软件项目从需求确定到软件交付需要经历大概三年左右的时间，这已经很难满足当时企业的快速发展需求，在三年里可能整个业务都发生了根本性变化，这意味着很多项目都不得不因为市场和业务的变化而被取消或延期，即使勉强交付了也可能已经无法满足企业的现实需求。这种情况在某些行业中表现的更为极端，比如在航空航天和国防领域，一个复杂系统可能需要经过20年才能投入实际使用，例如1982年开始服役的航天飞机中还在使用1960年代的信息和处理技术，高度复杂的软硬件系统通常需要数十年的时间进行设计、开发和部署。
四、敏捷诞生
事实上，人们最初设想是如何可以更好的接受及处理变更决策，让瀑布模型具备退回到上一步的能力，并作出一些决策和期望的调整，然后实际上由于工期和预算的限制使这变得几乎不可能执行，团队必须坚持早期决策才能确保在预算和给定时间内完成工作，团队会条件反射一样拒绝变化。
越来越多的行业领导者认为必须有更好的软件构建方法来改变这一切，他们期望能更快速构建可以工作的软件并将其交付最终用户，这会带来两个重要的好处：1. 它使用户能更快的获取软件带来的一些商业利益。 2. 它可以让团队能够更早获得有关软件范围和方向的快速反馈，这在后来被看做敏捷的一个最关键特征。
最终2001年初在犹他州的Snowbird召开了那次重要的会议，会议小组成员包括Kern，极限编程先驱Kent Beck和Ward Cunningham，Arie van Bennekum，Alistair Cockburn以及其他十二个人，这些人在敏捷社区中是众所周知的明星。这次会议后他们发表了著名的敏捷宣言，随着敏捷宣言的发表，Agile这个词开始在全世界传播，其中最为大家熟知的敏捷方法应该就是Scrum和XP了，大多数声称实践敏捷方法的团队都说他们正在使用Scrum。
五、SCRUM的发展过程
Jeff Sutherland和Ken Schwaber在90年代初构想了Scrum管理过程，在1995年对Scrum框架进行了梳理并发表了文章“ Scrum Software Development Process”，并在美国德克萨斯州奥斯汀举行的OOPSLA会议上完整介绍了这一框架。
Scrum基于以下理念：对于新的复杂产品的开发，只有为小型且自组织的团队指定目标而不是特定任务，才能达到最佳效果。团队可以自由决定实现这些目标的最佳方法。 Scrum还定义了有时间限制的迭代开发周期，其目标是交付有价值且可用的软件。
Ken和Jeff从两位公认的管理思想家Takeuchi和Nonaka于1986年发表的论文“ The New New Product Development Game”中继承了“ Scrum”的叫法。Nonaka和Takeuchi用“ Scrum”一词强调团队的重要性以及橄榄球等团队运动与成功开发新产品之间的类比关系。他们的研究表明，当小型的，自组织的团队努力去满足目标而不是任务时，就可以在开发复杂的新产品方面取得出色的效果。最好的团队是那些有方向的团队，他们有自己的空间来制定自己的策略，以最佳的方法实现共同目标。团队需要自治才能实现卓越。而Scrum软件开发框架正是实现了用文中描述的理论来开发和维护复杂软件产品的原理和方法。
Scrum是一个EmpiricalProcess（与DefinedProcess相对），它通过两个InspectAndAdapt周期来管理产品开发。 在开发和使用早期版本的Scrum的过程中，Ken曾请求著名的过程控制研究工程师Babatunde A. Ogunnaike Tunde教授研究软件开发过程。Tunde研究了几种流行的商业软件开发方法，得出的结论是瀑布式和预测性过程并不适合软件开发工作。他证实了Scrum所倡导的经验性方法是首选的过程。经验主义多用于完成复杂的工作，由于大多情况下复杂工作中未知的事情多于已知的事情，并且变化和不确定性很高，这就使得预测的价值变得很小。
Scrum非常适合软件项目。Scrum不仅是敏捷世界中最伟大的发明之一，还是当今最流行的框架之一，尽管它已经非常成功地与ExtremeProgramming结合使用，但它专注于项目管理而不关注软件开发实践。
随着Scrum的发展，互联网上散布着各种有关Scrum的理论和主张，这使我想起盲人摸象的故事。Sutherland认为Scrum是一个框架，其中包含了过去五十多年人们所发明的各种最佳实践，能找到最适合你的那组实践才是事情的关键，Ken曾经说过：“不加调整地盲目应用任何技术都是有害的”，并将Scrum与下棋做了一个很好的类比：
“框架”一词的含义是没有指定太多细节，必须由使用框架的人员来决定如何做，我把Scrum等同于象棋游戏，您可以阅读国际象棋的官方规则手册，学习他们，然后您可以下棋，但是你离成为一个国际象棋大师还有很长的路要走。
六、SCRUM的发展脉络
·Scrum首先在Individual，Inc.，Fidelity Investments和IDX（现为GE Medical）中进行了尝试和完善。
· 在2001年2月，Jeff和Ken参与“敏捷宣言”签署，是签署宣言的17位软件开发大师之一。发表敏捷宣言后，成立了敏捷联盟，Ken Schwaber担任第一任主席。
·2001年，受肯特·贝克（Kent Beck）的启发，肯·施瓦伯（Ken Schwaber）与迈克·比德尔（Mike Beedle）合著了第一本关于Scrum的书《Agile Software Development with Scrum》。
·2002年，Ken Schwaber与Mike Cohn和Esther Derby共同创立了Scrum联盟，由Ken主持该组织，在随后的几年中，创建并发布了非常成功的ScrumMaster认证体系及其衍生产品。
·2006年，Jeff Sutherland创立了自己的公司Scrum.inc，继续教授Scrum认证课程。
·Ken在2009年秋天离开了Scrum联盟，并创立了Scrum.org，主要是通过Professional Scrum系列培训进一步提高了Scrum的质量和有效性。
·Jeff和Ken在2010年首次发布《 Scrum指南》，并在2011年、2013年、2017年对其进行了逐步更新，从而建立了全球认可的Scrum知识体系。
自1995年首次发行至今，Scrum已被全球众多软件开发公司所采用。今天，它被认为是敏捷软件开发中应用最广泛的框架。在Scrum上已经出版了1000多本书，该方法也已经成功地应用于其他领域，例如：制造，营销，运营和教育。
最后我们引用《人月神话》作者弗雷德·布鲁克斯（Fred Brooks）在“ No Silver Bullet—Essence and Accidents of Software Engineering”的文章中的观点：没有任何单一的技术或过程可以带来软件开发效率的显着提高。这句话对敏捷同样适用，并不是实践了Scrum或者XP就可以解决你的所有问题，先定义清楚你们面临的问题，然后去找到适合你的那些实践，勇敢的尝试并取得成功吧。