敏捷的诞生
软件工程从1960年代出现，在1970s-1990s出现了第一次爆发。早期的软件开发多数采用瀑布开发模式，即必须完成当前步骤才可以进行下一步骤，首先要完成对整个项目的需求分析，才可以开始功能设计，之后才能够进行详细设计。已经开始和完成的步骤几乎不可能进行回滚，这也使得每一步骤的战线被很大程度地拉长，繁复的文档常常挤压开发的时间。
2001年，在美国盐湖城外的雪鸟城，17位软件专家聚集一堂，完成了软件开发历史上非常重要的协议：敏捷宣言。敏捷宣言的完成标志着软件开发从瀑布时代迈向了敏捷时代。
应用
敏捷并非是某一种方法论，而是一种价值观，所有符合敏捷宣言的软件开发实践均可纳入敏捷范畴。例如Scrum, 极限编程，精益软件开发，测试驱动开发，看板等等。敏捷的应用范围也不仅仅局限在软件开发商，在产品开发中也被广泛地应用，例如著名汽车企业丰田就是看板的首创公司。以下具体讨论两种敏捷实践方法：看板方法和极限编程。
1. 看板方法
看板方法源自丰田的“及时生产”（JIT: just-in-time）系统, 由于该方法严格限制在制品（work in progress)，可以有效可视化并减少瓶颈而广泛地应用于软件开发行业。在制品的堆积在生产过程中会造成大量浪费 —— 瓶颈。如果瓶颈没有被及时的识别出来，就会在这一步骤上越积越多，无法向下一个步骤流转，不仅影响交付，还会造成在制品过多，增加了库存压力。软件开发也是如此，假设软件A的开发有三个步骤：分析需求 - 开发 - 测试 - 部署。如果开发是瓶颈且没有识别到，则会导致大量在制品（分析好的需求和未写完的代码）堆积，无法交付测试，软件也无法按时交付，此时引入看板就是很好的选择。
看板将生产步骤划分为正在进行（doing）和完成（done）两部分，设定当前doing没有完成的时候，不能开始下一个任务。只有当当前开发全部完成，开发才可以从PO分析好的需求中领取下一个任务，从而拉动PO开始分析下一个需求，如此来拉动整个系统的流转。
2. 极限编程（XP)
XP 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：
在更短的周期内，更早地提供具体、持续的反馈信息。
在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
依赖于口头交流、测试和源程序进行沟通。
倡导持续的演化式设计。
依赖于开发团队内部的紧密协作。
尽可能达到程序员短期利益和项目长期利益的平衡。
极限编程的实践
测试驱动开发：因为测试是在编码之前完成的，所以写完的测试一定会运行失败，接下来再写代码使测试可以通过。TDD保证你的产品功能，不管公司和技术团队实现的是大规模的变更还是小规模的变更。
结对编程：让2名开发人员写同一段代码，使用同一个键盘和同一台显示器。因为结对大大降低了浪费的时间和缺陷，所以能带来更高质量的代码，并带来高水平的协作。
集体代码所有制和持续集成：如果每段代码不只有一个人熟悉，那么就不会有什么交流瓶颈了。把代码持续集成到一个主干可以避免重复和不匹配的代码。
重构：在当时的情况下，写的代码是解决已知问题的。通常，团队巧妙地解决了他们的问题，然后持续重构和修改代码，确保代码库能以最为高效的方式不断满足业务最新的需要。
