敏捷软件开发(Agile Software Development)简介之：什么是敏捷软件开发？

 http://www.ruby-lang.org.cn/read--tid-604.html

敏捷软件开发(Agile Software Development)简介之：什么是敏捷软件开发？

本文部分内容来自： http://en.wikipedia.org/wiki/Agile_software_development
缩略词说明：
ASD: Agile Software Development、 敏捷软件开发

什么是敏捷软件开发？
敏捷软件开发是一个概念意义上的框架，用来取代软件工程项目的概念；它强调 在项目的整个生命周期中， 拥抱并促进由于 软件进化式的发展所带来的 变化。
Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes
evolutionary change throughout the entire life-cycle of the project.
这段定义来自wikipedia，我认为是我接触ASD以来，对ASD最精辟的论述。
请注意其中的三个关键词：
在项目的整个生命周期中：这就涉及到了【敏捷项目管理】、【敏捷需求获取】、狭义的【敏捷软件开发】三个主要的领域和过程。要注意的是，上述三个过程并不是互相分开的，而是你中有我，我中有你。
拥抱并促进变化：世界上唯一不变的是变化。不论在任何领域，漠视、甚至否认、抗拒变化，都不是一个理性，严肃的人所应有的态度。学会如何识别变化的大势，并在可能的时候，促使变化向好的方向发展。这才是面对变化的正确应对之法。
软件进化式的发展：虽然上面提到促进变化的发展，但是软件的演化过程，我相信是有其自身内在逻辑的，存在一些根本规律和指导方针；并不是完全以人的主观意识为主导。
老子讲“顺势而为，无为无不为”，我认为是对上述后两点的精确概括与指导。

了解了这三个方面，下面就要引入大名鼎鼎、如雷贯耳、耳朵都要磨出糨子来的 敏捷宣言（Manifesto for Agile Software Development）了，让我们看看2001年提出的第一版的敏捷软件开发宣言怎么说：
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
☆ Individuals and interacti***** over processes and tools
☆ Working software over comprehensive documentation
☆ Customer collaboration over contract negotiation
☆ Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

我们正在通过实践和帮助人实践，揭示更好的开发软件的方法。我们从实践中得出的价值观是：

☆ 人和交互重于过程和工具。
☆ 可以工作的软件重于求全责备的文档。
☆ 客户合作重于合同谈判。
☆ 随时应对变化重于循规蹈矩。

虽然右项也具有价值，但我们认为左项具有更大的价值。

经过六年的演变，敏捷大师们又提出了 敏捷宣言的重构版本，由于尚未形成共识，暂不在此提出。

在敏捷宣言的背后，有其 遵循的12条原则：
Principles behind the Agile Manifesto

We follow these principles:
☆ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

☆ Welcome changing requirements, even late in development. Agile processes harness change for the customer\'s competitive advantage.

☆ Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

☆ Business people and developers must work together daily throughout the project.

☆ Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.

☆ The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.

☆ Working software is the primary measure of progress.

☆ Agile processes promote sustainable development. The sp*****ors, developers, and users should be able to maintain a c*****tant pace indefinitely.

☆ Continuous attention to technical excellence and good design enhances agility.

☆ Simplicity--the art of maximizing the amount of work not done--is essential.

☆ The best architectures, requirements, and designs emerge from self-organizing teams.

☆ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.


★ 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
★ 即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。
★ 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
★ 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
★ 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
★ 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。
★ 工作的软件是首要的进度度量标准。
★ 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
★ 不断地关注优秀的技能和好的设计会增强敏捷能力。
★ 简单--使未完成的工作最大化的艺术---是根本的。
★ 最好的构架、需求和设计出自于自组织的团队。
★ 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

 

==============

http://blog.csdn.net/barfoo/article/details/2595942

这周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还是文件系统，而且这些核心设计是不能够被推翻的，否则代价巨大不可接受。