这周5和周6参加了两天公司组织的Agile相关知识的培训，对Agile的认识比以前更多了一些。初次接触Agile大概在四五年前，大约是刚上研究生的时候。在学校的图书馆中看到了敏捷开发和极限编程(XP)等字眼的书，当时没太在意，感觉自身的专业方向不搭边，随便翻翻看，发现也没怎么看懂，囧。
从这几年的工作经验来开，当时没看懂是应该的，看懂了才是怪事。Agile的开发模式需要有相当经历的开发经验的人才能够理解，因为这是一个“草根”的开发模式，或者说做事哲学。
1. Agile是什么?
很难对Agile有个明确的定义说明什么是Agile的，什么不是Agile的。Agile从出生开始即是为了解决软件开发中过重的开发模式而诞生的，为了减少文档驱动的开发模型中反馈周期过长，难以应对需求变化而诞生的。它是针对这些缺点而提出的改进方式。Agile的哲学是“结果是最重要的，所有的过程手段都是为结果服务的；如果过程导致结果不理想，那就改进这个过程”。因此，Agile的开发模式是一个逐渐改进的方式，直到Team能够应付不断的需求变化，能够快速响应，能够快速的给客户创造价值。我的理解：能够满足上述要求的开发模式都可以认为是Agile的。
2. 文档驱动 VS 测试驱动
常规的开发模式是以文档驱动的。需要有很详细的需求文档，根据需求文档进行初始设计、详细设计，然后是编码实现和测试。这种模式有其优点存在，比较适用于需求变化不是很大，变化速度不快的项目，典型的例子就是军方的武器系统的开发。但这种模式对民用软件行业，特别是互联网行业的项目而言就显的太沉重了，基本上完全不能快速的响应政策、市场和客户的变化。
Agile提出了以测试驱动的开发模式。Agile中的测试强调自动化的单元测试和自动化的集成测试。以大量的可以自动化运行的单元测试保证任何微小的改动在check in代码库中之前都是逻辑正确的，自动化的集成测试则可以保证不同模块之间的漏洞能够尽早的发现，能够尽早的fix bug，减少后期修改bug的成本。
Agile的开发模式中，是测试先行的方式。它的特点如下：
首先根据User Story编写测试代码，然后根据测试代码的要求完成逻辑代码。在这个阶段不关注逻辑代码的任何编码标准和规范，也不关注代码性能，以最小的时间代价实现正确的功能为终极目标。完成后开始运行测试代码，直到所有的测试点都通过。
完成上述任务后，我们就已经初步拥有了一个可以正常运行，完成核心功能的系统了，这时候可以让客户参与进来，和客户确认做出来的东西是不是真的是用户需要的。与此同时，开发team需要对代码进行重构，每次重构都需要进行所有的测试代码进行测试，保证重构后不会引入新的bug。好的代码结构是不停重构出来的。
3. Agile与技术架构的矛盾
Agile要求迅速响应变化，但变化经常给原有的设计带来挑战。Agile并不是不要设计直接进行开发，Agile模式仍然是需要一定的预先设计的。特别是系统的核心，如数据存储是DB还是文件系统，而且这些核心设计是不能够被推翻的，否则代价巨大不可接受。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/barfoo/archive/2008/06/29/2595942.aspx