· 精益
提到敏捷首先最早是想到精益思想，最早在日本丰田公司体现，最早的精益思想来自于PDCA(Plan,Do,Check,Action)，PDCA循环是美国质量管理专家休哈特博士首先提出的，在质量管理活动中，要求把各项工作按照作出计划、计划实施、检查实施效果，然后将成功的纳入标准，不成功的留待下一循环去解决。丰田在此基础上，创建丰田生产体系，也就是最早的精益生产。软件行业吸收了精益思想，以及参考极限编程，自适应软件开发等方法逐渐发展出新的“框架”。
· 敏捷的发展历程
· 软件交付危机
70年代~90年代软件工程的实践开始爆发，当时的开发过程大多数是采用比较经典的瀑布式模式，这个过程完整定义了软件从需求到部署的全生命周期的各个阶段，之所以被称为瀑布是因为它要求团队在完成下一步骤之前必须已经完成了上一个步骤：在进行功能设计之前必须先完成需求分析，在详细设计之前必须先完成功能设计，以此类推。一旦一个阶段完成，这个阶段就会冻结，很难将项目恢复到流程的更早阶段。
这种方法让管理者像管理车间流水线一样管理软件开发，花费大量时间在编写计划和设计工作上面，可交付软件的周期也变的更长。与交付可用软件相比，该方法更加注重计划和文档编制。
正如《黑客与画家》中提到过的，土木工程项目等项目很少发生大的变化，他们按部就班就可以顺利交付，例如您今天设计的桥梁很少会在一两年内发生大的变更。
而软件项目不同，他们很少能具有和传统工程项目一样的稳定性，业务需求可能在一夜间发生很大变化，而我们完成一个软件的周期至少需要几个月甚至几年的时间，我们如何面对随时可能出现的变化呢？很明显软件工程需要一种不同以往的管理方法。
我们必须接受一个事实：我们根本无法在构建产品之前精确定义所需的各种功能需求，这是软件工程与大多数其他工程项目的根本区别。
到90年代初期，随着PC在企业中的逐渐普及，市场对定制化软件开发的需求越来越大，同时软件项目管理方法也遇到了前所未有的挑战，这种危机经常被称为”软件开发危机“，表现为软件系统交付的严重滞后。据当时的行业专家估计，一个软件项目从需求确定到软件交付需要经历大概三年左右的时间，这已经很难满足当时企业的快速发展需求，在三年里可能整个业务都发生了根本性变化，这意味着很多项目都不得不因为市场和业务的变化而被取消或延期，即使勉强交付了也可能已经无法满足企业的现实需求。
·敏捷的诞生
2001年敏捷先驱者们发起组成了敏捷联盟，并同时发布了“敏捷软件开发宣言”。
个体和互动 高于 流程和工具
可工作的软件 高于 详尽的文档
客户合作 高于合同谈判
相应变化 高于 遵循计划
2005年，在Alistair Cockburn和Jim Highsmith的领导下，一份根据敏捷软件开发方法来指导软件项目管理的附录发布 -“相互依存声明”。
2009年，Robert C Martin编写软件工艺宣言，根据职业行为和掌握程度来指导敏捷软件开发。
2011年，敏捷联盟创建敏捷实践指南。
· Scrum的发展过程
Jeff Sutherland和Ken Schwaber在90年代初构想了Scrum管理过程，在1995年对Scrum框架进行了梳理并发表了文章“ Scrum Software Development Process”，并在美国德克萨斯州奥斯汀举行的OOPSLA 95会议上完整介绍了这一框架。
对于新的复杂产品的开发，只有为小型且自组织的团队指定目标而不是特定任务，才能达到最佳效果。团队可以自由决定实现这些目标的最佳方法。 Scrum还定义了有时间限制的迭代开发周期，其目标是交付有价值且可用的软件。
Ken和Jeff从两位公认的管理思想家Takeuchi和Nonaka于1986年发表的论文“ The New New Product Development Game”中继承了“ Scrum”的叫法。Nonaka和Takeuchi用“ Scrum”一词强调团队的重要性以及橄榄球等团队运动与成功开发新产品之间的类比关系。他们的研究表明，当小型的，自组织的团队努力去满足目标而不是任务时，就可以在开发复杂的新产品方面取得出色的效果。最好的团队是那些有方向的团队，他们有自己的空间来制定自己的策略，以最佳的方法实现共同目标。团队需要自治才能实现卓越。而Scrum软件开发框架正是实现了用文中描述的理论来开发和维护复杂软件产品的原理和方法。
Scrum非常适合软件项目。Scrum不仅是敏捷世界中最伟大的发明之一，还是当今最流行的框架之一，尽管它已经非常成功地与ExtremeProgramming结合使用，但它专注于项目管理而不关注软件开发实践。
随着Scrum的发展，互联网上散布着各种有关Scrum的理论和主张，这使我想起盲人摸象的故事。Sutherland认为Scrum是一个框架，其中包含了过去五十多年人们所发明的各种最佳实践，能找到最适合你的那组实践才是事情的关键，Ken曾经说过：“不加调整地盲目应用任何技术都是有害的”，并将Scrum与下棋做了一个很好的类比：
“框架”一词的含义是没有指定太多细节，必须由使用框架的人员来决定如何做，我把Scrum等同于象棋游戏，您可以阅读国际象棋的官方规则手册，学习他们，然后您可以下棋，但是你离成为一个国际象棋大师还有很长的路要走。
1995年，Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。
2001年，第一本关于Scrum的书《Agile Software Development with Scrum》诞生。
2002年，Scrum联盟创立，随后几年发布了ScrumMaster认证体系及其衍生产品。
2006年，Jeff Sutherland创立了自己的公司Scrum.inc，继续教授Scrum认证课程。
2009年，Ken Schwaber离开Scrum联盟，并创立了Scrum.org。
2010年， Jeff Sutherland和Ken Schwaber发布《 Scrum指南》，随后对其逐步更新，建立了全球认可的Scrum知识体系。
引用《人月神话》作者弗雷德·布鲁克斯（Fred Brooks）在“ No Silver Bullet—Essence and Accidents of Software Engineering”的文章中的观点：没有任何单一的技术或过程可以带来软件开发效率的显着提高。这句话对敏捷同样适用，并不是实践了Scrum或者XP就可以解决你的所有问题，先定义清楚你们面临的问题，然后去找到适合你的那些实践，勇敢的尝试并取得成功吧。