敏捷开发方法学及应用

敏捷开发方法学及应用

简介

本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者，也适用于团队领导人，项目经理，产品经理，开发经理，测试人员，质量保证经理，质量保证工程师，技术作者，用户体验设计者，以及任何与制做发布软件相关的人员。本文着重于技术团队怎么很好的合作去计划，开发并发布软件。本文不着重于编码，技术细节或微软工具。希望本文能改善你的专业生活和团队效率。

背景

下图是Winston Royce的瀑布式开发模型：

（ "Managing the Development of Large Software Systems"，1970 IEE paper）

无论项目有多大有多复杂，有两个关键的步骤常用于所有的计算机程序开发：1) 分析 2) 编码。

接下来，Winston Royce介绍了最重要的五步：

第一步：程序设计

 

分配任务处理流程，功能，数据库处理，明确数据库流程，分配执行时间，明确操作系统间的接口与处理流程模块，描述输入与输出流程，并且明确初步的操作流程。撰写容易理解的，信息量大的，当前时新的概要文档。

 

第二步：撰写设计文档

 

管理软件开发的第一条规则就是无条件服从的执行文档需求。

 

第三步：重复两次

 

第二个非常重要的成功标准以产品是否完全原始为重中之重。如果把还有疑问的计算机程序开发为第一版，考虑到严格的设计/操作领域，那么给客户正式部署的版本实际上是第二版本。

 

第四步：计划，控制，监控测试

 

在成本和计划方面上，这是最有风险的一步。当备选方案几乎或一点不可用时，它会出现在日程安排的最近时间点上。

 

第五步：让客户参与

 

让客户参与到项目中是非常重要的，因为客户可能在最终发布之前较早的认可项目工作。

 

 

 

仔细阅读Royce的文章后发现：

1. 每一阶段都应该迭代式地传递到下一阶段。
2. 软件发布前对软件整体流程实践两次。
3. 简单单一的阶段传递会造成项目失败。

 

不幸地是，上面列出的步骤当中，设计迭代从来没被限制成连续的步骤。

 

 

下面这些东西都是什么？

 

 

答案是：

 

 

 

 

敏捷开发并不意味着只是一种方法。上面雨伞下的术语代表着不同的敏捷开发方法。

 

敏捷软件开发宣言

 

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

• 个人与交互 高于 流程和工具
• 可用软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

也就是说，上面右侧（蓝色字体）内容有其价值，但我们更重视左侧（红色字体）产生的价值。

 

敏捷宣言的十二条原则

 

我们遵循以下原则：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

 

很多开发者都经过这样的噩梦：没有任何实践可以辅佐的项目。由于缺乏有效的实践，项目变得不可预测，重复出现错误，还有白白浪费的辛苦。计划延期，超出预算，质量低下使客户感到失望。开发者也由于更长时间的工作而换来更糟糕的软件而心灰意冷。

 

DSDM

 

DSDM（Dynamic Software Development Method），动态软件开发方法，通过提供一个负责整体开发周期的框架来弥补RAD(Rapid Application Development)快速程序开发的不足。下面是DSDM的主要功能：

1. 用户参与
2. 迭代和递增开发
3. 提高了发布频率
4. 集成测式于每一阶段
5. 已发布产品的可接受程度直接取决于需求的实现

 

FDD

FDD（Feature Driven Development），功能驱动开发，是一种包装方法学。它允许你在非常高的级别上应用一个方法来管理项目，但它也允许你在较低的级别上应用其它方法学。FDD的着重点是能够把估算，日程计划，项目状态汇报作为一个整体或放到颗粒级别上，但是FDD不会规定一个非常细节化的方法让你应用去创建日程计划，相反FDD让你去觉决定该用什么方法。FDD的观点是你可以查看一下你的项目，陈术一下项目的确切状态，如项目进度是否及时，延时或过早等等。

 

Lean

 

Lean思想是一种进行系统优化的途径，它关注于减少浪费，提高整个系统总体流程。Lean在制造业上有着丰富的历史，近几年在在软件开发行业也越来越流行。Lean来源于制造业中的Lean(Lean Manufacturing: http://www.mindtools.com/pages/article/newSTR_44.htm)，它是一组为满足质量，速度和客户需求而定制的原则。

 

七大Lean软件开发原则：

1. 估算浪费
2. 构建质量
3. 创建知识
4. 延迟承诺
5. 快速交付
6. 尊重人
7. 优化整体

 

软件产品的交付工作应用这些原则并不是我们的最终目的。我们并不是说让我们用Lean吧，而是把Lean原则做为决策的向导或参考去选择可以改善整体系统的技术。比如，TDD测试驱动开发，通过在每一个功能点上创建功能自我测试从而构建软件的完整性和完善性。

 

Plan（译外话：指瀑布式开发Waterfall Development）

 

在计划驱动开发中，如果一个项目确切的按照计划执行，那么它就是成功的。因此，在软件开发中计划驱动开发依赖于需求的稳定性，明确性和固定性。你或许知道这些奢侈的性质是在大多数软件项目中不存在的。

 

计划驱动方法学，在初期的设计阶段的需求变更中成本花费较低，但是一旦到了开发阶段需求变更将会花费昂贵的代价。所以，很多的工作被要求在初期计划设计阶段完成。然而，软件开发不同于普通的项目，我们不能保证将来的开发阶段会完全按照初期的设计进行，无论你的设计有多么出色。

 

"Walking on water and developing software from a specification are easy if both are frozen."- Edward V. Berard

在水上行走和开发软件都只有当它们被冻结时才会变得容易。

 

敏捷开发打破了对需求稳定性的依赖，它有一个专门的流程用于负责需求变化，主要体现在它的自适应计划和进化式设计。

 

自适应计划，意思是多次的仔细检查整体项目流程，经常会再次制定计划并再次适应。

进化式设计，有一些实践对它很有帮助，如自我测试代码，持续集成，重构，简易设计等。

 

敏捷开发是价值驱动，传统的瀑布式开发是计划驱动。这并不是说计划驱动就没有价值，在特定的实际情况下它们都有各自的有优缺点。关键是怎么平衡使用两种方法，在特定情况下采取它们的长处而回避它们的短处。

 

Plan VS Agile

计划驱动开发模式和敏捷驱动开发模式在基本原理差异上有两大不同。

第一大不同：计划驱动模型中只能在项目完成时才能部署一个新模块，而且是较大的模块。敏捷驱动模型中可以频繁的部署新模块，甚至较小的模块。

第二大不同：计划驱动是序列化的，敏捷驱动是并发的。在计划驱动模型中，一个流程的开始必须在前一个流程完全成功结束的前提下进行。在敏捷驱动模型中，任何时候都可能在做计划，流程是并发的或互相穿插的。

 

 

“Plan your work, then work your Plan” by Martin Fowler and Neal Ford

先计划你的工作，后工作你的计划。

     

      

 

 

敏捷开发和计划驱动开发(瀑布式开发)：

• 都提供了操作流程，操作工具和操作技术。
• 都需要严格的有条不紊的方法进行软件开发。
• 都各自有优缺点。
• 敏捷开发适合的情况，计划驱动模型不一定适应。
• 敏捷开发强调流程上的不同。
• 计划驱动模型强调正式的沟通与控制。
• 敏捷开发强调连续的沟通和处理变化的能力
• 计划驱动模型是关卡式控制质量，敏捷开发是高迭代式开发确保质量。
• 计划驱动模型仅在产品最终完成后进检查，敏捷开发每完成一小块工作就进行检查。
• 计划驱动模型以预估什么将被交付为起点，敏捷开发以完成一个需求为目标做为起点

适应变化能力(Y轴)                            时间(X轴)

 

 

 

可见性(Y轴)                               时间(X轴)

 

 

 

 

 

 

在敏捷开发中：

客户满意度是以迅速，持续的交付可用软件为导向。
强调人和互动要高于强调流程和工具。

客户，开发者，还有测试人员一直保持互动。
可用软件频繁的被交付使用（按周交付高于按月交付）

面对面交流是最好的沟通形式。
业务人员和开发者保持近距离的，日常的协作。
持续关注出色的技术和设计。
适应易变情况。
需求中较晚的改动也受欢迎。

 

善于使用计划驱动模型的管理团队同样也能够善于使用敏捷开发方法。

缺乏能力使用计划驱动模型的管理团队也没有能力使用敏捷开发方法。

敏捷开发Agile

 

敏捷软件开发的原理和价值用于帮助团队打破流程循环膨胀，着重于用简单的技术去实现目标。目标？什么是目标？

每一个软件开发者，开发团队的主要目标是为老板和客户制造尽可能高的价值。

敏捷开发的核心是把传统的软件开发方法(瀑布式开发)的五个步骤压缩成一个一周的开发周期。用敏捷开发方法去开发一个系统时，项目中会不断贯穿着重复的周期开发和较小模块的开发，并在开发过程中允许开发者测试和检查。高速度，低成本，灵活性是敏捷开发的主要优势。

 

敏捷开发发展极为迅速，从2001年的只有1%的开发者使用敏捷开发到现在的60-80%的开发者在使用敏捷开发。更大的吸引力是因为敏捷开发提供：

• 改善的质量
• 在项目过程中有更多的机会做出修改更正
• 提高客户或商业满意度
• 使业务和IT更好的组合在一起
• 更优化的面向市场的时间

 

敏捷开发使用者从来不会害怕变化。他们把需求变化看作是好事，因为这些变化意味着团队又收获了更多关于怎样满足客户的经验。敏捷开发团队成员一起协作项目的方方面面。每一个成员都允许为项目整体提出意见或做贡献。没有一个团队成员是单一的负责架构或者需求或者测试。团队分享这些责任，同时每个成员都会对它们产生影响。

我们有很多的敏捷开发流程：Scrum，crystal，BDD(Behavior-Driven Development行为驱动开发)，TDD(Test-Driven Development测试驱动开发)，FDD(Feature-Driven Development功能驱动开发)，ADP(Adaptive Software Development自适应软件开发)，XP(Extreme Programming极限编程)，等等等等。然而，大量成功的敏捷开发团队从所有这些方法中吸取经验与知识，进而调整生成他们自己特有的敏捷开发方式。这些改编后的方法通常与SCRUM还有XP组合在一起，SCRUM实践用来管理使用极限编程XP的团队。

 

 

极限编程XP

 

As developers we need to remember that XP is not the only game in town.- Pete McBreen
作为开发者，我们需要记住极限编程并不是城里唯一的游戏。

极限编程强调团队合作(经理，客户，开发者)。它从五个关键点改善软件项目：沟通，简明，反馈，尊重，还有勇气


维基百科对极限编程的定义：极限编程XP是一种软件开发方法，它的意图是提搞软件质量及对用户需求变化的响应能力。作为一种敏捷软件开发方法，它提倡在短开发周期中频繁地发布，从而提高软件生产力并提出新客户需求能够被采纳的检查点。


极限编程是一系列嵌入到敏捷开发中的简易并坚实的实践。极限编程是一个非常好的通用软件开发方法。许多项目团队都采用它，同时更多的团队通过添加或修改实践来把它变得更适用。

• 它是大多数敏捷开发方法的始祖
• 在90年代末期和21世纪初期，Kent Beck提出了热门的话题
• 协调流程与实践

 Kent Beck 的基本观念:

• 采取已关注过的有效团队实践
• 迫使它们走向极端

 

“迫使它们走向极端”是什么意思呢？是不是如下图一样？

或者下图

 

不，这不是极限编程。让我们看看它的真正意思：

 

出色的实践	迫使它走向极端
代码复查	结对编程
测试	TDD测试驱动开发和常数回归
软件设计	不停地重构
简单	最简单的事会有意想不到的效果
集成测试	不断的集成/整合
短迭代	把制定计划当作游戏

极限编程是一系列遵循敏捷开发原则和价值的实践。极限编程是离散的方法，而敏捷开发是一类方法。有很多的敏捷开发方法，极限编程只是其中一种。

极限编程在敏捷开发方法中是范围宽阔，出类拔萃的。Scrum有些类似极限编程，拥有极限编程的大多数特征。但是在细节是它们有很多的不同，公平的说Scrum是是极限编程的子集。甚至，许多Scrum团队争论着要把极限编程实践加入Scrum流程中，如满意度测试，结对编程，持续集成，以及测试驱动开发。
 

在所有敏捷开发方法当中，极限编程是唯一的一种方法为开发者的日常工作提供深度的，意义深远的开发准则。在这些准则中，测试驱动开发是最革命性的。下图中都是一些出色的极限编程实践。

 

Scrum

 

Scrum是和种迭代式及递增式的敏捷软件开发框架，它用于管理软件项目，产品，或程序的开发。它的着重点是一个灵活的，全面的产品开发策略，它把一个开发团队通常作为一个单位进而实现一个常规目的。相反，它不着重于传递的序列化式的方法。Scrum会问传统瀑布式开发“为什么我们要花费这么长时间，这么多努力去做一件事？为什么我们不能衡量出做一件事所需时间和人力？” Scrum拥抱变化和创造力，因为这是人们的工作方式。Scrum有一个流程学习结构，能够让团队评估他们做了什么以及他们怎样做的。

• 1986年，Scrum第一次被定义成一个灵活的全面的产品开发策略。--Hirotaka Takeuchi，Ikujiro Nonaka
• 1995年，Sutherland和Schwaber共同地发表了一篇关于Scrum方法学的论文。

 

 

Scrum角色

 

三个核心角色：

1. 产品持有人 Product Owner
2. 开发团队 Development Team
3. Scrum领导人 ScrumMaster

 

产品持有人 Product Owner

• 产品持有人代表着公司或股东的权益并传递客户的声音。
• 专门负责确保商业价值
• 制定以客户为中心的一些工作条目，排序后放到产品待处理列表（Product backlog）中。
• Scrum团队应该有一个产品持有人，他/她也可以是开发团队中的一员。
• 产品持有人不是Scrum领导者(ScrumMaster)。

开发团队 Development Team

 

• 在每一个Sprint周期结束后，负责交付将来需要发布的产品的模块。
• 由3到9人组成并拥有各种所需技能（分析，设计，开发，测试，技术沟通，文档，等等）。
• 自我组织，有可能需要与更高级的项目管理部门交流。

Scrum领导人 ScrumMaster

• 专门负责扫清团队在交付Sprint目标或产品中遇到的障碍。
• 不是团队领导人，但是扮演着团队与可能分散团队注意力的影响之间的缓冲区。
• 确保Scrum流程的使用在计划中。
• 规则强制执行人。团队保护者，以保持团队专注于他们手中的工作。
• 也会被看作一个人民公仆去加强这些双重观点。
• 不同于一个项目经理，没有与ScrumMaster不相关的人员管理职责
• 没有任何额外的员工责任。

Backlog未完成项列表

 

产品的待完成项列表是一个需求的排列列表，我们维护这个列表是为了更好的开发产品。它的组成有功能，BUG修复，非功能需求等任何为了成功发布可用软件系统的所必须的内容。在Scrum中，开始一个项目不必先开发一个冗长文档去记录所有的需求。这个敏捷产品backlog对于第一个Sprint足够了。当有更多产品需求时和客户需求时，Scrum产品backlog允许变更和增加。

Sprint backlog是开发团队下个Sprint需要处理的工作列表。这个列表是产品backlog最上面的需求项衍生出来的，直到开发团队在这个Sprint中有足够的工作去做。开发团队通过问一些问题来完成backlog的选择，如“我们是不是也能做这个？”。

 

从概念上讲，团队从优先级最高的Scrum backlog开始画一条线划分出优先级较低的项，同时线上面的backlog也是团队认为他们可以完成的项。在实践中，团队通常不会去选择优先级最高的五项再选择优先级较低的两项组合在一起即使它们是互相关联的。

 

 

敏捷开发调查

这项调查发起于2012年8月9日至2012年11月1日之间，由VersionOne赞助的。调查从软件开发社团的不同渠道中选择了4048人。数据由Analysis.Net Research分析并总结成报告。

 

谁知道敏捷开发？

一般情况下，相比业务人员，越接近开发团队角色的人了解敏捷开发的越多

 

敏捷开发失败原因

 

进一步使用敏捷开发的障碍物

使用敏捷开发最大的担心

 

 

总结

 

一个好的敏捷团队会选择最适合他们的管理与技术实践。当试着去使用敏捷开发时，会有一万个借口为什么这行不通。只有那些真正理解敏捷开发优势并真心实意地想要使用敏捷开发的人们才会有可能成功。那些正在搜索为什么Agile会失败的人们，他们可能最终会找到答案也可能放弃之前所做的一切努力不再使用敏捷开发。Elisabeth Hendrickson称这种行为“假敏捷开发”。

 

 

为了支持一下我的结论，让我们引用一些名言(从Robert C. Martin收集):
"In preparing for battle I have always found that plans are useless, but planning is indispensable." - General Dwight David Eisenhower 

在战斗准备中，我总是发现那些计划是鸡肋，但是制定计划是不可缺少的。

局限于别人的方法世界里不是可取的，因为公司需求，公司情况，项目都有可能一直在变化着。如果你想你的项目成功，你一定要灵活地应用这些现成的方法去管理项目。任何单一的方法都不是一把尚方宝剑，因此关键是看哪种方法适合你并能协调你的方法去满足你的个人需求。

记住，Scrum和Agile不是一个死产品 ，它是在持续改进的基础上不断进行中的一门哲学。

 

翻译：http://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t

同步：http://blog.csdn.net/leewhoee/article/details/17221919