敏捷方法大全

敏捷是一种思想，如何用敏捷的思想来进行生产或开发，又有很多敏捷方法。关于敏捷开发方法的知识，我搜集整理了一下，大致如下：

目前常见的敏捷方法的有：

• 软件开发节奏，Software Development Rhythms
• 敏捷数据库技术，AD/Agile Database Techniques
• 敏捷建模，AM/Agile Modeling
• 自适应软件开发，ASD/Adaptive Software Development
• 水晶方法，Crystal
• 特性驱动开发，FDD/Feature Driven Development
• 动态系统开发方法，DSDM/Dynamic Systems Development Method
• 精益软件开发，Lean Software Development
• Scrum
• 测试驱动开发，TDD/Test-Driven Development
• XBreed
• 极限编程，XP Extreme Programming

 

下面分别对以上的敏捷方法进行简单的介绍。

 

极限编程XP（eXtreme Programming）

 

极限编程是敏捷开发主流方法之一。计划永远赶不上变化，XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。

 

极限编程主要有4大核心要点沟通、简单、反馈、勇气；

 

极限编程遵循的原则：

• 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

• 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

• 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

• 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

• 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

• 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

• 工作的软件是首要的进度度量标准。

• 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

• 不断地关注优秀的技能和好的设计会增强敏捷能力。

• 简单是最根本的。

• 最好的构架、需求和设计出于自组织团队。

• 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

 

极限编程12个实践：

 

完整团队

XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

计划游戏

计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

客户测试

作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

简单设计

团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

结对编程

所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

测试驱动开发

编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

改进设计

随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

 持续集成

团队总是使系统完整地被集成。

集体代码所有权

任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

编码标准

            系统中所有的代码看起来就好像是被单独一人编写的。

隐喻

 将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

可持续的速度

团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑

 

极限编程采取了11个面向对象的设计原则

单一职责原则(SRP)

就一个类而言，应该仅有一个引起它变化的原因。

开放-封闭原则(OCP)

软件实体应该是可以扩展的，但是不可修改。

Liskov替换原则(LSP)

子类型必须能够替换掉它们的基类型。

依赖倒置原则(DIP)

抽象不应该依赖于细节。细节应该依赖于抽象。

接口隔离原则(ISP)

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

重用发布等价原则(REP)

重用的粒度就是发布的粒度。

共同封闭原则(CCP)

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。

共同重用原则(CRP)

一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。

无环依赖原则(ADP)

在包的依赖关系图中不允许存在环。

稳定依赖原则(SDP)

朝着稳定的方向进行依赖。

稳定抽象原则(SAP)

包的抽象程度应该和其稳定程度一致。

 

Lean      精益开发

精益管理的思想起源于丰田公司，归纳起来精益思想是在创造价值的目标下，通过改良流程不断地消除浪费。现已被广泛用于生产制造管理，但用于IT软件项目产品开发的实践尚属凤毛麟角。

 

精益开发有7个原则：

• 消除浪费 – 将所有的时间花在能够增加客户价值的事情上。

• 增强学习 – 在遇到棘手的问题的时候增加反馈

• 尽量推迟决策：根据实际情况保持可选方案的开放性，但时间不能过长。

• 尽快交付：当客户索取价值时应即交付价值。

• 授权团队：让创造增值的员工充分发挥自己的潜能力。

• 嵌入完整性：不要在发布时候添加完整性 – 应该嵌入完整性。

• 着眼整体：防止以损害整体为代价而优化部分的倾向。

 

精益开发的22 thinking tools

消除浪费

  工具1：识别浪费              工具2：价值流图

增强学习

  工具3：反馈                       工具4：迭代法

  工具5：同步                       工具6：基于集合的开发

尽量推迟决策

  工具7：选择权思考           工具8：最后负责时刻

  工具9：制定决策

尽快交付

  工具10：拉动系统             工具11：排队理论

  工具12：延误成本

授权团队

  工具13：自决权                   工具14：动机

  工具15：领导                       工具16：专业技能

嵌入完整性

  工具17：感知完整性           工具18：概念完整性

  工具19：重构                       工具20：测试

着眼整体

  工具21：度量                     工具22：合同

 

Scrum

 

SCRUM也是一种流行的敏捷开发方法，它是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。

 

Scrum 有5大核心要点：

承诺（Commitment）----Be willing to commit to a goal

专注（Focus）---- do your job, don’t worry about anything else

开放（Openness）---everything is visible to everyone

尊重（Respect）--- respect the different people who make up a team

勇气（Courage）--- have the courage to commit, to act, to be open and to expect respect.

 

Scrum 有3个3

 

3个角色：敏捷开发团队、Team Leader、Product owner

 

3 个会议：计划(Iteration Planning meeting)、每天站立会议（Standup meeting）、成果展示会议（Iteration Demonstration meeting）

最后还应该有一个总结（Retrospective meeting）

 

3个work products：Product Backlog, Sprint Backlog 和Burndown Chart.

 

注：

Backlog：可以预知的所有任务，包括功能性的和非功能性的所有任务。

Sprint：一次跌代开发的时间周期。

Burndown Chart ：显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。

 

DSDM动态系统开发方法

http://en.wikipedia.org/wiki/DSDM

 

DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。

 

DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。

 

DSDM 有5个阶段：

　　可行性研究
　　业务研究
　　功能建模阶段（迭代式）
　　设计编程阶段
　　实施阶段
DSDM有9个基本原则：
　　1：用户必须持续参与
　　2：必须授予DSDM团队制定决策的权力
　　3：注重产品的经常交付
　　4：满足业务用途是接受交付品的主要依据
　　5：迭代和增量式开发对得到正确的业务解决方案是必不可少的
　　6：开发过程中的所有变化可逆
　　7：在高层次上制定需求的基线
　　8：测试自始自终贯穿于开发周期之中
　　9：所有项目涉众间的通力合作是不可或缺的

DSDM 的7个关键技术

时光盒(timebox)

MoSCoW法则：对需求进行优先级划分的法则

Must have this requirement to meet the business needs.

Should have this requirement if at all possible, but the project success does not rely on this.

Could have this requirement if it does not affect the fitness of business needs of the project.

Would have this requirement at later date if there is some time left (or in the future development of the system).

原型（Prototyping）

测试（Testing）

讨论会（Workshop）

建模（Modeling）

配置管理（Configuration Management）

 

 

Agile Unified process

http://www.ambysoft.com/unifiedprocess/agileUP.html

 

AUP其实是一个轻量级的RUP，有7个原则：

1.模型（ Model）：理解业务模式及问题，并在项目中有相应的解决方案

2.实现（ Implementation）：将模型转化为可执行的代码，并执行基本的测试，尤其是单元测试

3. 测试（Test）：进行目标评估以确保质量。包括发现Bug、确认系统按设计预期工作正常以及满足需求。

4. 部署（Deployment）：制作产品发布计划，并执行计划。

5. 配置管理（Configuration Management）：配置所有与项目相关的文档、代码等的访问权限。不仅包括版本控制，还有变化控制和管理。

6. 项目管理（Project Management）：指导所有的项目活动。包括风险管理、人力管理（任务分配、进度跟踪等）、部门间协调以保证项目在预算内按时竣工。

 7. 环境（ Environment）：为项目的顺利进行提供支持，使向导（标准和指导方针）、工具（软件，硬件等）能随时可得。

Philosophies

The Agile UP is based on the following philosophies:

1. 团队成员知道自己在做什么

团队成员不必要详细阅读流程中的文档，但应不停地接受培训和概要性的指导。AUP提供产品详细信息的链接，如有兴趣可仔细阅读，但不强迫。

2. 尽可能简约

任何事情的描述尽量简单明晰，一页能描述就不要长篇大论。

3. 敏捷

AUP符合敏捷软件开发和敏捷联盟的原则

4. 专注于高价值的活动

将注意力集中在有价值的事情上，不要受项目中其他可做可不做的事情干扰。

5. 不要被工具束缚

AUP过程中可以使用一些工具，建议使用最适合、最简单的工具。

6. 根据需求自己精简AUP过程.

随需定制自己的AUP，不必购买特定的工具、参加培训等。

 

Crystal Methods

Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。

FDD

FDD（Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。

ASD

ASD（Adaptive Software Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。