与传统软件工程相比，它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中“人”的作用。
本文将介绍敏捷软件开发的历史背景与发展，探讨敏捷软件工程相对于传统软件工程的特点，并阐述一些我个人在学习过程中的认识和思考。
20世纪六十年代，计算机硬件技术有了很大的发展，为计算机的广泛应用创造了条件，并要求软件与之相适应。当时的软件生产具有个体化、作坊式特点，开发工具落后，开发平台单一，程序设计语言功能差。尤其是软件维护工作，耗费大量的人力、物力和计算机资源，许多程序的个体化特性使得它们无法修改和维护。有的干脆废弃原有系统不用，从头编写新软件。
与此同时，七十年代时，软件的规模越来越大，结构越来越复杂，软件管理和维护困难，开发费用不断增加。这种软件开发技术、开发工具和生产方式落后的状况与计算机应用迅速普及和对软件的需求日益增加形成了尖锐的矛盾，由此而产生了“软件危机”。
软件危机的产生使计算机软件专家认识到软件开发必须以新的方法作指导，原有的软件开发方法必须改变，他们决定把工程技术的思想引入软件开发领域，使软件开发走上工程学科的途径，以摆脱日益严重的软件危机。于是，美国和西欧的一些科学家在1968年的NATO(北大西洋公约组织)会议上第一次提出了“软件工程”这个名词，是利用工程学的方法开发和维护计算机软件的一门学科。从此，软件工程正式诞生，人们开始了软件工程的研究。
八十年代，软件工程引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机。至九十年代，软件失败的经验促使过程不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度变慢。
从2000年代开始，随着信息时代到来，需求变化更快速，软件的交付周期成为企业的一项核心竞争力，因此，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行开来。2001年初，由于许多公司的软件团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，并称自己为敏捷联盟。
我对敏捷联盟的宣言的理解大致为：
1）个体和交互胜过过程和工具。
“人和人之间的交互是复杂的，并且其效果从来都难以预期，但却是工作中最为重要的方面。” 人是获得成功的最为重要的因素。一个优秀的团队不一定由一群最顶尖优秀的程序员组成，在团队中，能够和他人很好的合作、顺利的沟通以及高效的交互能力比单纯的编程能力更为重要。即使有一群高水平的程序员，如果没有良好的沟通，也未必可以组成一个高效的团队，毕竟人不是“插入即兼容的编程装置”。项目的顺利进行需要由具有合作精神、自组织且有凝聚力的团队来保证，合适的工具虽然也非常重要，但是工具的作用不应该被过分的夸大，我们应该明白物极必反，过多或过于庞大复杂的工具和缺少工具一样都是不合适的。总之，团队的构建要比环境的构建重要的多，应该首先致力于构建合适的团队，再基于需要来配置合适的环境。
2）可以工作的软件胜过面面俱到的文档。
没有文档的软件是一种灾难，这意味着没有严格规划和明确目标的盲目行动，显然是非常低效的，然而，过多的文档并不意味着高效，相反，这会花费大量的时间和精力来编制和更新。因此，编写和维护一份恰如其分的文档是明智的，文档应该简短，主题鲜明，逻辑概括性强。在团队成员的交流中，近距离的培训和交互是最有效的方式。应该竭力避免注重文档而非软件导致进度拖延的情况发生。Martin文档第一定律告诉我们：直到迫切需要并且意义重大时，才来编制文档。
3）客户合作胜过合同谈判。
传统：你想清楚你具体要个啥？
敏捷：你再看看还有啥要改的。
Just kidding，但是，确实，我们无法像订购其他用品一样来订购一个软件，在我的认识里，软将更大程度上像是一个“作品”而非一个严格意义上的“产品”，所以像大多数艺术创作一样，让人在固定的时间内以固定的成本来复刻客户的需求，是难以达到的，即使这种简单的交易模式非常具有诱惑力，但一个指明需求、进度以及项目成本的合同其实存在根本上的缺陷，如果仅仅依赖于此，则很大可能会导致项目的失败。因此，“敏捷”认为，成功的项目需要的是有序和频繁的客户反馈，而不仅仅是冰冷的合同和死板的工作汇报会议。软件开发团队客户在工作上建立密切的联系，尽量经常的沟通和反馈。合同的编制也应该对项目的开发协作起指导作用，而非去约束和规定进度和成本上的细节来试图使开发工作受到完全的控制。
4）响应变化胜过遵循计划。
在瞬息万变的现代信息社会，响应变化的能力常常决定着一个软件项目的成败。因此计划的构建应该保证足够灵活来适应商务和技术方面的变化。
计划不可考虑的过远，因为商务环境以及客户需求的变化往往是不可预见的。即使需求被确定下来也并不代表开发时间就随之确定。因此，较好的策略是，先进行短期的详细计划，和稍长的粗略计划。以便灵活地作出改变。计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划，这样可以保证短期内工作的有序高效和长期上的灵活适应性。
此外，敏捷软件开发开发提出了12条更详尽的原则，宗旨和宣言一致，也是体现了与传统软件工程的区别所在。
1、最优先要做的是：通过尽早地、持续地交付有价值的软件来使客户满意。
2、即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3、经常交付可工作的软件，其时间间隔可以是几周到几个月。 交付的时间间隔越短越好。
4、在整个项目开发期间，业务人员和开发人员必须天天在一起工作。
5、不断激励开发人员，开展项目的有关工作。给他们提供所需要的环境和?支持，并信任他们能够完成所承担的工作。
6、在团队内部，最有效果的、最有效率的传递信息的方法，就是面对面的交谈。
7、首要的进度度量标准是工作的软件。
8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9、不断关注优秀的技能和设计，增强敏捷能力。
10、简单是根本的。
11、最好的体系结构、需求和设计，出自自己组织的团队。
12、每隔一段时间，团队对如何才能有效的工作进行反省，然后对自己的行为进行适当的调整。
我们知道，传统的软件开发采用的是瀑布式开发的流程，包括收集需求、定义、设计、编码、测试、发布等阶段。前一阶段的完成为后一阶段开始的先决条件，每个阶段都有其明确的目标和审核标准，整个过程严格有序，可预测性逐步增强，这样的好处是避免资源的无效投入，步步为营，保证开发质量。
但传统开发模式也存在着明显的缺陷，这种瀑布式流程的每个阶段间具有强烈的依赖关系，导致问题的产生可能会导致连锁的后果。如果前一阶段未达到标准，也会造成后续阶段的停滞。举个似乎是我的编译课老师举过的例子，一个工程有五个部分的话，如果每个部分做到90分，那么最终的工程就只能得到59分，就是一个不合格的工程。因此这种模式的灵活性差，很难应对后期需求的变化，调整的代价高昂。
所以，在这样的背景下诞生了敏捷开发的理念，灵活性的提高便是其最大的优势。市场需求瞬息万变导致成品需求收集完整性难以保证，可以说在瀑布式开发中的前几阶段我们连九十分都很难做到，所以传统软件工程的失败率之高便不言而喻了。
我很认可一种说法，敏捷开发相对于传统开发是一个核心思维的转换：从“Fix scope，Flex time”转向“Fix time，Flex scope”。在市场变化和技术变化背景下，既然市场需求和产品定义的“范围”无法实现固化，因而资源需求也不确定，那不妨切换重心，旋转一下我们的坐标系，固定资源，来尽可能达到“范围”的最大化实现。从“计划驱动”转向为“价值驱动”。而且敏捷开发更强调“人”的价值功效，康德说，“人即目的”，从这个角度来说，敏捷软件开发的宗旨像是软件工程发展史上的“文艺复兴”运动。
最后表达一些我个人不成熟的想法，敏捷软件开发的出现根本上来自于商业环境的现实，人力成本高昂，商业市场上“快鱼吃慢鱼”的竞争模式等等。敏捷开发这种模式取“敏捷”二字为名，但“敏捷”并不仅仅意味着“多快好省”，速度只是敏捷的一部分，正如我前文提到的，软件开发更像一门艺术，应该在合理范围内尽量高效，但浮躁和急功近利是无所裨益的，真正以“人”为驱动力并不应该意味着使开发人员心力交瘁，开发生理潜能的极限，如何协调个中利害关系，想必还是任重道远。
原文：http://www.cnblogs.com/xyMeow/p/5988633.html