主要敏捷开发方法

主要的敏捷方法

极限编程（ 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 等。敏捷方法都是增量和迭代开发过程，并且强调人多过于整个过程。各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解他们可以帮助我们从多个角度理解敏捷开发，并且搜集更多的最佳应用。

如何选择一种敏捷方法

　　选择一种合适的方法取决于多种因素。在做出决定之前，我们需要充分考虑以下这些方面：

Ø       方法的复杂度。确保你的团队或组织能够应付这种复杂度。

Ø       社区支持。流行的方法可能并不是你最理想的选择，但流行的方法至少有较多的社区及行业支持，可以使你受益匪浅。

Ø       实用工具。选择一种可以为你提供许多支持工具的方法。一个良好的自动化工具可以帮助团队有效的处理日常工作，促进团队协作，并减少管理成本。

Ø       你目前的开发方式和你目前团队关于敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

Ø       你的团队规模。较小规模的团队最好从简单的方式入手。当然，这并不意味着你必须选择那些本身就比较简单的方法如 Crystal Clear 。你可以选择一些相对比较全面的方法，但从简单入手。当你的团队规模逐渐扩大，再增加相应的细节。

Ø       你不需要只遵从一种方法。你可以为团队选择一个主要的方法（如 Scrum ），然后从其他方法中借鉴对你的团队或组织有所帮助的其他方式加以整合。

敏捷总是在不断发展演变，因此，没有一个人能保证目前的敏捷方法都是正确的。每个采用敏捷开发的团队都可以通过发现并形成自己的想法和最佳实践，对敏捷开发做出自己的贡献。