敏捷软件开发是为了防止项目开发中的过程膨胀而提出的。为此，成立了敏捷软件联盟，并创建了《敏捷软件开发宣言》。
我对敏捷开发的感觉有以下几点：
一、在开发过程中强调人以及人与人之间关系的作用。不但要求开发团队要有一个积极向上的氛围，同时还强调成员与成员之间的合作和交流。例如：每两名成员组成一对，共同开发一个功能，并且这种结对要至少每天更换一次。这就保证了信息在项目组内部的流通，同时知识也更容易传播。
二、降低了工具的作用。在开发的过程中，应当优先使用简单的工具，直到证明这些简单的工具不再适用。
三、在每次迭代中，要优先实现已确定的素材，其次再为下一次迭代的素材作打算。在每次迭代中，要以实现当前的素材为准则。“团队最开始的工作是以尽可能最简单的方式实现第一批用户素材。只有当出现一个用户素材迫切需要改变基础结构时，他们才会引入该基础结构”。
四、推荐在编写代码之前，要先编写单元测试和验收测试。然后以通过测试为目的来编写代码。这样“有目的的编写代码”，可以有效地降低代码的冗余。同时，单元测试可以降低代码之间的耦合。
五、重构和隐喻很重要。我想这并不仅仅适用于敏捷开发。
敏捷开发的最重要的意义之一在于：防止软件的腐化。
需求是多变的。需求的一次简单变更就可以轻易破坏代码的优雅和原有的结构。
代码的腐化可以从以下几个角度来定义：僵化性、脆弱性、牢固性、粘滞性、不必要的复杂性、不必要的重复、晦涩性。
如果真的有一点我们写出了这样腐化的代码，我们不应当抱怨需求的变更。
我们能做的是改变我们写代码的方式，尝试以下原则：
1． 遵循敏捷实践去发现问题
2． 应用设计原则去诊断问题
3． 应用适当的设计模式去解决问题
在开发的时候我们应该做到:
分析一点
设计一点
编写一点
测试你所有你能测试的部分
敏捷开发的精髓在于快速响应。
响应什么？相应变化。
谁的变化？需求的变化。
如果我们能够每隔一秒钟就从用户那里重新获得需求，然后进行分析、设计、编码、测试，那么我们就不会抱怨用户的需求总是变化了。因为在这一秒钟的时间段里，用户的需求没有任何变化。但是显然，这不可能。
不可能的地方有两个，一是我们不能每一秒钟就重新获得一次需求。二是我们不可能每次都对用户的需求重新分析、设计。
但是我们可以找到一个相对平衡的时间段和需求块，尽管不是完美的平衡。时间段有多长？取决于用户需求变化的速率。需求变化得越快，那么获取的频率应该越高。每次对多少需求进行分析和设计？这取决于我们拥有多少时间以及我们的工作效率.
为什么需要重构？因为它会使代码更灵活，拥有更好的反应能力。
为什么要拒绝腐化的代码？因为死人是永远不会做出响应的。