敏捷开发方法简介

在这里我给大家介绍几种敏捷开发的方法。

首先要感谢维基百科，百度百科，博客园园友，新浪博客，及TechTergat中国区的帮助——我不只是代码的生产者，也是代码的搬运工。

Scrum

Scrum敏捷开发流程主要包括：三个角色、四个会议和三个物件（343）。

三个角色：

　　产品负责人（Product Owner）

                主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

      流程管理员（Scrum Master）

                主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

       开发团队（Scrum Team）

               主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右。

四个会议：

       1、Sprint计划会议 

            Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。

       2、每日立会

       3、Sprint评审会议 

       4、Sprint回顾会议 

三个物件：

       1、产品Backlog  产品Backlog指根据初始需求分解出的任务列表，包括功能性和非功能性的所有功能。

       2、Sprint Backlog Sprint Backlog就是任务列表，如果映射到传统的项目管理理论中就是WBS（work breakdown structure)，而且是典型的采用面向交付物的任务分解方法得到的WBS。

       3、燃尽图。

 

极限编程XP

极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

 

开发人员知道要做什么，以及要优先做什么；

 

工作有效率；

 

有问题或困难时，能得到客户、同事、上级的回答或帮助；

 

对工作做评估，并根据周围情况的变化及时重新评估；

 

积极承担工作，而不是消极接受分配；

 

一周40小时工作制，不加班。 

 

水晶方法

水晶方法，Crystal ，是由 Alistair Cockburn 和 Jim Highsmith 建立的敏捷方法系列，其目的是发展一种提倡“机动性的”^[1]方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的 Crystal 家族成员。水晶系列与XP一样，都有以人为中心的理念，但在实践上有所不同。

透明水晶方法的七大体系特征：

体系特征一：经常交付

体系特征二：反思改进

体系特征三：渗透式交流

体系特征四：个人安全

体系特征五：焦点

体系特征六：与专家用户建立方便的联系

体系特征七：配有自动测试、配置管理和经常集成功能的技术环境

 

DSDM-动态系统开发方法

Dynamic System Development Management，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发 方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。本书主要讲述这样几方面内容：DSDM如何加快产品的 交付，为什么像DSDM这样的敏捷开发方法能够快速体现所开发系统给业务带来的好处，如何组织用户参与项目以开发出可用的系统，如何将不同知识背景的人组 成一个团队，如何应对常规的业务约束以进行项目管理。

　　DSDM的基本原则 DSDM方法建立在9条原则之上，而且在实施过程中，这9条缺一不可。

　　原则1：用户必须持续参与 active user involvement is imperative

　　原则2：必须授予DSDM团队制定决策的权利 DSDM teams are empowered to make decisions including refining or changing requirements without the direct involvement of higher management

　　原则3：注重产品的经常交付 The focus is on frequent product delivery

　　原则4：满足业务用户用途是接受交付品的主要依据 Fitness for purpose is the key criterion

　　开发人员不必沉溺于完美的 解决方案之中，耽误项目时间。在受限的时间内，实现业务利益最大化的交付品才是最重要的。

　　原则5：迭代和增量式开发对得到正确的业务解决方案是必不可少的 Iterative and incremental development is necessary to converge on an accurate business solution

　　采用迭代开发的方法，能够使业务流程逐步进化，使系统不断朝着满足业务需求的方向前进。

　　原则6：开发过程的所有变化可逆 All changes during development are reversible

　　采用迭代和增量式开发过程中，很可能会碰到走错的情况，此时需要回退到一个已知的可靠的点上。

　　原则7：在高层次上制定需求的基线 Requirements are initially agreed at a high level

　　在业务研究中所得出的需求必须在高层次上达成一致。接下来在迭代过程中再得到详细的需求。

　　原则8：测试自始至终贯穿于开发周期之中 Testing is integrated throughout the life cycle — this is essential with an incremental approach

　　开发人员完成一个模块的开发后，自己会进行单元测试。当模块集成到现有系统后，测试人员需要执行集成测试。另外，回归测试在DSDM中占有很重 要的地位。

　　原则9：所有项目涉众间的通力合作是不可获缺的 A collaborative and co-operative approach between all stakeholders is essential 

　　

测试驱动开发

 

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。

 

测试驱动开发的基本过程如下：

 

①　快速新增一个测试

 

②　运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过

 

③　做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法

 

④　运行所有的测试，并且全部通过

 

⑤　重构代码，以消除重复设计，优化设计结构

 

简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号。

测试驱动开发不是一种测试技术，它是一种分析技术、设计技术，更是一种组织所有开发活动的技术。相对于传统的结构化开发过程方法，它具有以下优势：

1) TDD根据客户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。因为关注用户反馈，可以及时响应需求变更，同时因为从使用者角度出发的简单设计，也可以更快地适应变化。

2) 出于易测试和测试独立性的要求，将促使我们实现松耦合的设计，并更多地依赖于接口而非具体的类，提高系统的可扩展性和抗变性。而且TDD明显地缩短了设计决策的反馈循环，使我们几秒或几分钟之内就能获得反馈。

3) 将测试工作提到编码之前，并频繁地运行所有测试，可以尽量地避免和尽早地发现错误，极大地降低了后续测试及修复的成本，提高了代码的质量。在测试的保护下，不断重构代码，以消除重复设计，优化设计结构，提高了代码的重用性，从而提高了软件产品的质量。

4) TDD提供了持续的回归测试，使我们拥有重构的勇气，因为代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。完整的测试会帮助我们持续地跟踪整个系统的状态，因此我们就不需要担心会产生什么不可预知的副作用了。

5) TDD所产生的单元测试代码就是最完美的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。

6) TDD可以减轻压力、降低忧虑、提高我们对代码的信心、使我们拥有重构的勇气，这些都是快乐工作的重要前提。

7)快速的提高了开发效率。

 

 

Lean软件开发（精益软件开发）

和精益制造原则的概念相近，精益开发也可以总结为如下七条原则：

• 消除浪费
• 增强学习
• 尽量延迟决定
• 尽快发布
• 下放权力
• 嵌入质量
• 全局优化

面对开发团队以及最终的产品大小的额外挑战，可以说软件开发是个持续学习的过程。最佳的改善软件开发环境的做法就是增强学习。在代码完成后马上进行测试可以避免缺陷的累积。不是去做成更多的文档或详细设计，而是对各种各样的想法进行实际的编码尝试。用户需求的收集过程可以简单地通过给最终客户演示，并听取他们的反馈来完成。

使用短周期的迭代（每个迭代都应包括重构和集成测试）可以加速学习过程。在决定当前阶段的开发内容并对未来改善的努力方向进行调整时，在客户端帮助下通过简短的反馈会议来增强反馈。通过这些简短的反馈会议，客户代表和开发团队会更多地发现在进一步开发时会遇到的主要问题及可能的解决方案。从而，基于已开发出的原型，客户可以更好地理解自己的需求，开发者也能了解到如何才能更好地满足客户的需求。另一个关于和客户沟通、学习的想法是“基于组的开发”，这种方法聚焦于未来解决方案的约束限定而不是各种可能的解决方案，因此通过和客户的对话加速了解决方案的产生。

 

再次感谢维基百科，百度百科，博客园园友，新浪博客，及TechTergat中国区的帮助——我不只是代码的生产者，也是代码的搬运工。