序言
瀑布模型是大型组织编写软件的最常用方法之一。它需要复杂、混乱的开发过程，并将其变成简单明了的东西：
弄清楚需要做什么（需求）
确定如何做（架构和设计）
编写软件（编码）
确保该软件可以运行（测试）
交付（部署）唯一的问题是，它不起作用。或者应该换一种说法：瀑布模型通常不能很好地工作。公司试图将瀑布变成由开发、测试人员和项目经理组成的装配线。在这些角色之间传递信息很困难，因此他们倾向于依赖文档，然而文档通常很模糊，有时甚至毫无参考价值。更糟糕的是，当需求方在做出决定后又改变主意时，修改成本将大幅上涨，因此，瀑布倡导者建议限制或控制变更。因此，当软件发布时，它很难真正满足客户的需求。
而对于敏捷开发，客户可以确定功能的优先级，首先获得最重要的功能，在每个版本发布之后开会计划下一个版本。相较于瀑布模型，生产率提高是因为各种问题不会被轻易的忽视。团队之中每个人都致力于提供有价值的东西。测试角色也向前移动，从单纯的验证活动逐演变为规范活动。
危险和陷阱
当实施得当时，敏捷方法能够真正地得以实现：需求方定期查看工作进度，每次发布后都可以改变主意，并首先看到最重要的功能。但是以我的经验，敏捷方法具有三个主要的潜在风险：敏捷方法容易被误解。对于敏捷的实施，人们很容易觉得自己是对的，但实际上是错误的。敏捷方法使价值可见。敏捷方法容易被误解
敏捷的哲学包括：大量的客户参与，对变更的及时响应而不是一味遵循计划，尽早并经常发布，以及