敏捷开发简介

敏捷开发简介

敏捷开发

在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐，在全球一百强的企业中，敏捷也已大行其道，受到许多资深项目管理者和开发人员的推崇。欧美软件企业中，有近半企业已采用敏捷方法进行开发。大多数尚未应用敏捷的企业，也都对其有所了解，而且很多在计划实施。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。例如，腾讯内部几乎所有的开发团队都在实施敏捷。

敏捷方法给这些企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3-10 倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到响应的提高。敏捷的成功来源于其方法本身的适用性和团队对它的深入理解和合理运用。下面我们就对敏捷开发做一个简单的介绍和讨论。

　　敏捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（ XP ）， Scrum ，精益开发（ Lean Development ），动态系统开发方法（ DSDM ），特征驱动开发（ Feature Driver Development ），水晶开发（ Cristal Clear ）等等。所有这些方法都具有以下共同特征，它们也是敏捷开发的原则和方法：

1.  迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

2.  增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

3.  开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

4.  持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。  

5.  开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。  

简史

　　许多人认为，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。但是，实际上敏捷方法，特别是迭代和增量开发方法（ IID ）起源于 20 世纪 30 年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是 20 世纪 60 年代初的美国航天局水星计划。在这个项目中，一些极限编程方法如测试先行等也被使用。此后，迭代和增量开发被 IBM 联邦系统部（ FSD ）和沃森研究中心（ Watson Research Center ）采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中，温斯顿. 罗伊斯（ Winston Royce ）建议在一个项目中使用两次瀑布模式，也就是使用两次迭代。  

　　 20 世纪 70 年代，最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。迭代和增量开发从此开始稳步发展，越来越多的项目开始使用这种开发模式。在 1976 年， Tom Gilb 在他的著作《软件度量》（ “Software Metrics” ）一书中阐述了他的迭代和增量开发实践，这可能就是第一部阐述这种方法的书籍。迭代和增量开发的另一次出色发挥，是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。改项目由 IBM 联邦系统部（ IBM FSD ）在 1977 至 1980 年完成。一些典型的敏捷做法，如使用 8 个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。

　　 20 世纪 80 年代，更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在 1895 年，巴里贝母（ Barry Boehm ）正式定义了使用迭代开发的螺旋模型（ Spiral model ）。 80 年代初，在美国国防部发生了一件有趣的事情。美国国防部一直以来都要求其软件开发商在开发过程中使用严格的瀑布开发模型。但是到了 1987 年末，国防部开始“建议”使用迭代和增量开发作为软件开发模式。后来美国国防部的项目审查显示，早期使用瀑布模式开发的软件项目，有 75% 以失败告终，有些开发出来的产品根本没有被使用过，只有 2% 的软件产品无需大量修改就能被正常使用。

　　 20 世纪 90 年代，推荐使用迭代和增量开发的出版物和文献显著增加。在经历了多次有“瀑布心态”（ ‘waterfall mentality’ ）项目的失败之后，美国国防部开始“要求”而不是像 80 年代那样仅仅是“建议”他们的软件开发商使用 IID 开发模式。 Rational 统一开发过程（ Rational Unified Process ）也是在这一时期产生并发展起来的，它具有更规范的迭代渐进过程。到 2000 年底，更多的敏捷方法被广泛推广并被使用于各种不同的项目中。 2001 年二月，一组由 17 位在 DSDM ， XP ， Scrum ， FSD 等领域的专家组成的代表团齐聚美国犹他州，寻找这些方法的共同点。最终，这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟。  

敏捷优势

 

　　为什么瀑布模式多数情况下总会失败？为什么我们需要敏捷开发模式？这个问题在日新月异，飞速发展的今天似乎很容易解释。尽管瀑布模式能够在一个迭代周期内表现优异，但是，在如何管理需求变化面前，瀑布模式却显得无能为力。而事实上，大多数的软件项目都具有以下一些特点：

Ø  在初始阶段，最终用户通常不能准确得知道他们需要什么样的软件。即便知道，也很少有人能准确清楚的表达出来。

Ø  对于某些项目，在一开始，我们可以很好的定义其所有的功能，但是可能有很多细节只能随着项目的不断深入才能被挖掘出来。即便是我们了解了所有的细节，大多数人还是不能很好的处理这些细节，特别是在项目开发初期。

Ø  外部环境如客户的业务模式，技术进步，甚至是系统的终端用户都有可能在开发过程中不断改变。   而预想或试图阻止这些改变通常都是徒劳的。

Ø  在互联网时代，许多 Web 应用程序的开发都是基于对远景客户的预期，而非当前用户的实际需求。在这种情况下，变化从开始就有，而且在系统开始应用后几乎每天都会发生。

　　敏捷方法处理需求和技术变化主要通过迭代过程来管理。在每一次迭代周期结束时，都应交付用户一个可用的，可部署的系统。使用并体验该系统所获得的有价值的反馈意见将按顺序，在随后的迭代周期中和其它需求变化一起在产品中实现和集成。每次迭代周期应尽可能短，以便能及时频繁地处理需求变化和用户反馈。

采用敏捷开发方式将会给企业和用户带来诸多好处：

Ø  精确。它将带给用户真正需要的软件系统。瀑布模式通常会在产品起点与最终结果之间计划出一条直线，然后沿着直线不断往前走。然而当项目到达终点时，用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步的方式向前走，每走完一步，都需要及时调整并为下一步确定当前的方向，直到真正的终点。

Ø  质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如 XP 等，甚至使用测试驱动开发（ test-driven development ），即在正式开发功能代码之前，先开发该功能的测试代码。这些都对敏捷项目的整个开发周期提供了可靠的质量保证。

Ø  速度。敏捷开发提倡避免较大的前期规划，认为那是一种很大的浪费。因为很多预先计划的东西都会发生改变，大规模的前期规划通常是徒劳的。敏捷团队只专注于开发项目中当前最需要的，最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。

Ø  丰厚的投资回报率（ ROI ）。在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。

Ø  高效的自我管理团队。这既是采用敏捷开发的必然结果，也是推动敏捷开发不断前进的动力。敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，每个团队成员的技术能力，交流，社交，表达和领导能力也都能得以提高。

主要的敏捷方法

极限编程（ 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 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 ），然后从其他方法中借鉴对你的团队或组织有所帮助的其他方式加以整合。

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