传统开发方法是基于客户能够在需求阶段就给出完整、准确的需求的假设，所以期望于在项目初期获得详细的需求，然后严格控制需求变更，最终完成符合需求的软件。
但我们发现实际上往往需求是“涌现”出来的，也就是说是随着开发的不断进展而不断发现出来的，而无法在项目初期就明确的定义它，也就是说传统开发方法的基本假设是错误的，这一新的假设导致了敏捷方法的一系列实践。
·敏捷方法的核心就体现在它的四句宣言中：
个体与交互 胜过 过程与工具
可以工作的软件 胜过 面面俱到的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
·宣言中还包括以下原则：
对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准。敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。简单--尽可能减少工作量的艺术至关重要。最好的架构、需求和设计都源自自我组织的团队。每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.
·对比迭代方法
相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。
·对比瀑布式开发
两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。