敏捷方法强调了“适应性”和对“人”的关注，具体做法：引入迭代式的开发手段实现快速响应，积极适应需求变化；将整个软件生命周期分解为若干个小的迭代周期，缩短了开发周期；注重沟通，希望通过高效的沟通获取切实有效的客户反馈；尽量简化文档，简明够用即可，减少了工作量；注重人的重要性，提倡自我管理，使得团队重点个体成员可以充分发挥自己的聪明才智。
优点：
敏捷敏捷，当然是快辣！开发周期一般较短
集思广益，有利于开发出具有创意的开发成果
简化文档，可以把精力更多的放在软件设计和开发
不必按部就班，更具灵活性
团队成员之间、开发人员与用户之间可以直接沟通，提高了沟通效率。
迭代式的开发可以积极响应用户需求变化。
产品扩展性好
测试驱动开发，白盒测试，有利于测试的覆盖面更广
缺点：
客户不断改需求的话岂不是总是要加班 (Q~Q)
如果组内成员不能混好自我管理，就会加重其他成员的负担
组内成员最好水平相当，且这个团队应该具有不同的知识范围，这样才能做出更好的决策
适用于较小的开发团队，大团队如果完全采用敏捷软件开发则过于松散
瀑布模型（上次介绍过滴，这次就少说点咯~略略略）
与敏捷开发的区别：
文档驱动，注重文档的完整性和重要性;需要花蛮长时间来做需求分析即软件定义和软件设计，一旦完成，则不宜更改，造成应对需求变化付出代价极大。相比敏捷开发，团队中进行详细的分工，每一部门的工作对其他部门部分可见，主要通过文档沟通，文档质量直接影响沟通质量，这就要求文档尽可能完整详细，（可是即使酱紫，也会出现沟通不及时，或存有误解）；一般情况下，产品开发人员通过产品设计人员了解具体的产品需求，即只能通过上一部产生的文档来理解产品需求及产品功能，这可能会造成对产品了解不全面；开发人员更像是流水线上的工人，只需要依据上一部的成果按部就班的完成自己的任务，缺乏成就感。产品的扩展性较差；
我们团队嘛，当然是选择敏捷辣