敏捷综述
最近一段时间以来，很多人开始谈论敏捷开发、研究敏捷开发，那么究竟什么才是敏捷开发呢?
在2001年2月以前，“敏捷”一词意味着“标记快速的优雅的移动的能力”，或者是“拥有快速的机敏和适应能力的角色。”每个人都对敏捷有不同理解，简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
Iso 9000（09版）标准将在原来八大原则基础上新增敏捷原则，2000年美国军方软件开发标准（DOD 5000.2）推荐迭代为软件开发优选模式，世界影响最大的美国波多里奇国家质量奖将敏捷作为核心的十一大原则之一，可见敏捷浪潮已经袭来,那它是如何发展起来的呢?
20世纪60年代软件规模小，以作坊式开发为主；70年代硬件飞速发展，软件规模和复杂度激增，引发软件危机；80年代引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机；90年代 重型过程软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度变慢；2001年至今敏捷正在流行，随着信息时代到来，需求变化更快，交付周期成为企业核心竞争力，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。软件开发顺应时代变化，从重型过程转向轻量型敏捷。
敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，他们认为：
· 个体和交互胜过过程和工具
· 可以工作的软件胜过面面俱到的文档 ·
客户合作 胜过 合同谈判 ·
响应变化 胜过 遵循计划
并提出了以下遵循的原则：
· 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
· 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
· 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
· 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 工作的软件是首要的进度度量标准。
· 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
· 不断地关注优秀的技能和好的设计会增强敏捷能力。简单是最根本的。
主要的敏捷方法
极限编程（ XP ）
极限编程（ XP ）的主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法，并将它们发挥到极致。比如，为了能及时得到用户的反馈， XP 要求客户代表每天都必须与开发团队在一起。同时， XP 要求所有的编程都采用结对编程（ pair-programming ）的方式。这种方式是传统的同行审查（ peer review ）的一种极端表现，或者可以说是它的替代方式。
过程：
XP 定义了一套简单的开发流程，包括：编写用户案例，架构规范，实施规划，迭代计划，代码开发，单元测试，验收测试等等。
思想：
像所有其他敏捷方法一样， XP 预期并积极接受变化。它具有以下的价值观或原则：
互动交流。团队成员不是通过文档来交流，文档不是必须的。团队成员之间通过日常沟通，简单设计，测试，系统隐喻以及代码本身来沟通产品需求和系统设计。
反馈。反馈是一种信息的交流，能使系统更加完善。反馈与交流密切相关，客户使用或功能测试，单元测试等都能为开发团队提供反馈信息。同时，开发团队也可以通过估计和设计用户案例的方式将信息反馈给客户。
简单。 XP 提倡简单的设计，简单的解决方案。 XP 总是从一个简单的系统入手，并且只创建今天，而不是明天，需要的功能模块。因为它认为，创建明天需要的功能模块可能会由于需求的变化而成为浪费。
勇气。 XP 在这一点所要达到的目的（我们认为）是鼓励一些有较高风险的良好的做法。例如，它要求程序员尽可能频繁地重构代码，必须删除过时的代码，不解决技术难题就不罢休，等等。
团队。 XP 提倡团队合作，相互尊重。 XP 以建立并激励团队为一项重要任务。同时它把互相尊重和实际的开发习惯相结合。比如，为了尊重其他团队成员的劳动成果，每个人不得将未通过单元测试的代码集成到系统中。因此，每个人的代码质量必须过关。
核心做法：
小规模，频繁的版本发布，短迭代周期。
测试驱动开发（ Test-driven development ）。
结对编程（ Pair programming ）。
持续集成（ Continuous integration ）。
每日站立会议（ Daily stand-up meeting ）。
共同拥有代码 Collative code ownership.
系统隐喻（ System metaphor ）。
Scrum
Scrum 是一个敏捷开发框架，它由一个开发过程，几种角色以及一套规范的实施方法组成。它可以被运用于软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。
在 Scrum 中，产品需求被定义为产品需求积压（ product backlogs ）。产品需求积压可以是用户案例，独立的功能描述，技术要求等。所有的产品需求积压都是从一个简单的想法开始，并逐步被细化，直到可以被开发。
过程：
Scrum 将开发过程分为多个 Sprint 周期， Sprint 代表一个 2-4 周的开发周期。每个 Sprint 有固定的时间长度。首先，产品需求被分成不同的产品需求积压条目。然后，在 Sprint 计划会议（ Sprint planning meeting ）上，最重要或者是最具价值的产品需求积压被首先安排到下一个 Sprint 周期中。同时，在 Sprint 计划会上，将会对所有已经分配到 Sprint 周期中的产品需求积压进行估计，并对每个条目进行设计和任务分配。在 Sprint 周期过程中，这些计划的产品需求积压都会被实现并且被充分测试。每天，开发团队都会进行一次简短的 Scrum 会议（Daily Scrum Meeting ）。会议上，每个团队成员需要汇报各自的进展情况，同时提出目前遇到的各种障碍。每个Sprint 周期结束后，都会有一个可以被使用的系统交付给客户，同时进行 Sprint 审查会议（ Sprint review meeting ）。审查会上，开发团队将会向客户或最终用户演示新的系统功能。同时，客户会提出意见以及一些需求变化。这些可以以新的产品需求积压的形式保留下来，并在随后的 Sprint 周期中得以实现。 Sprint 回顾会随后会总结上次 Sprint 周期中有哪些不足需要改进，以及有哪些值得肯定的方面。最后整个过程将从头开始，开始一个新的 Sprint 计划会议。
角色：
Scrum 定义了 4 种主要的角色：
产品拥有者（ Product Owner ）：该角色负责产品的远景规划，平衡所有利益相关者（ stakeholder ）的利益，同时确定产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。
利益相关者（ Stakeholder ）：该角色与产品之间有直接的利益关系，通常也是由客户或最终用户代表组成。他们负责收集编写产品需求，审查项目成果等。
Scrum 专家（ Scrum Master ）： Scrum 专家负责指导开发团队进行 Scrum 开发与实践。它是开发团队与产品拥有者之间交流的联络点。
团队成员（ Team Member ）：即为项目做实际开发工作的开发人员。
Scrum 提供一个敏捷开发框架，其他许多敏捷方法都可以被集成到 Scrum 中。比如测试驱动开发（ test-driven development ）和结对编程（ pair programming ）等都可以被整合到 Scrum 中。
精益开发（ Lean Development ）
精益软件开发模式是从丰田公司的产品系统开发方法中演化而来。它主要包括两个部分：一部分是核心思想及原则，另外一部分由一些在相应的工具构成。
精益开发的核心思想是查明和消除浪费。在软件开发过程中，错误（ bugs ），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法制止。精益开发的其它原则包括 :
强调学习。软件开发过程是一个不断学习的过程。每个团队成员都需要从日常的失败，互动，交流以及信息反馈中学习，不断改进所开发的产品和效率。
不做长久的计划。尽量不要在可能改变的事情上做无谓的努力，这样才能有效的避免浪费。
尽量缩短迭代周期。较短的迭代周期能够加速产品的开发及交付，加快交流，提高生产力。
充分的自主权。激励团队并让所有团队成员自我管理始终是所有敏捷方法获得成功的基本因素之一。
完整性。确保整个系统正常工作，同时真正满足客户的需求是整个团队需要努力实现的完整性。
全局观。精益开发强调整体优化的系统。无论开发的组织还是被开发的产品， 从整体上考虑优化比从各个局部去优化更高效。
对于上述的每个原则，都有一些相应的工具对其加以实现。这些工具包括价值流图（ Value Stream Mapping），基于集合的开发（ set-based development ），拉系统（ pull system ），排队论（ queuing theory ），等等。
精益软件更重要的是不断完善开发过程的一种思维方式。因此，将精益模式与其他敏捷开发模式一起使用将会取得很好的效果。
动态系统开发方法（ DSDM ）是由快速应用程序开发（ RAD ）方法演变而来的敏捷开发模式。 DSDM 在普遍的敏捷价值和原则的基础上，定义了更加详细的流程，以涵盖更完整的项目生命周期。它们包括项目前期活动（ pre-project activities ），项目可行性研究，功能建模，设计和开发，实施或部署，项目后期维护（ post-project maintenance ），等等。同时，每个过程都定义了诸如如何将每个功能模型转化为实际代码，如何将原型交付最终用户使用并审查，如何处理反馈信息等的详细步骤。因此， DSDM 相比于其它敏捷方法在过程上显得比较繁重。
特征驱动开发（ FDD ）是另一种敏捷开发方式，它将用户的功能需求划分成更小的功能特征，然后逐步地在每个迭代周期中开发实现这些产品特征。与 DSDM 方式一样， FDD 仍然会在项目初期对整个项目做较大的规划和建模，以获得对该系统的全面了解。但是相比较 DSDM 来说， FDD 在这些方面更简捷。
Crystal Clear（也叫水晶开发） 是另一种形式的敏捷方法。 Crystal Clear 更专注于人。相比于其他的敏捷方法，它可使人获得更大的解放。据称这种方法更适合于较小规模的开发小组（由 2-8 个人组成）和非关键项目。 Crystal Clear 定义了七种属性。前 3 个属性 - 频繁的交付（ frequent delivery ），渗透交流（ osmotic communication ），反思提高（ reflective improvement ） - 反映出基本的敏捷开发做法和价值，如周期较短的迭代式开发，自我管理的开发团队和反馈带动增量发展等等。另外的 4 个属性分别是：个人安全（ personal safety ），集中（ focus），容易接触专家用户（ easy access to expert users ）和技术环境（ technical environment ）。其中，容易接触专家用户实际就是敏捷方法中提到的客户持续参与，但 Crystal Clear 对此要求较宽松。 Crystal Clear 也提供了一些通用的做法，比如，它提供了三种回顾分析的方法：访谈，问卷调查和工作组。 Crystal Clear 的过程也是相当简单，其中涉及短的迭代周期，日常会议及持续集成等。
还有其他一些敏捷方法如敏捷统一过程（ Agile Unified process ），上下文驱动开发（ Context Driven Development ）， Getting Real 等。敏捷方法都是增量和迭代开发过程，并且强调人多过于整个过程。各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解他们可以帮助我们从多个角度理解敏捷开发，并且搜集更多的最佳应用。
以上便是我从各种渠道了解道的敏捷开发，有错误的地方请指正，谢谢您的不吝赐教！