深度解析Agile/ Scrum 一 （连续转载）

Ladd

近几年中兴起的敏捷型（agile)(也被称之为“轻量型”lightweight)的软件开发方法，以矫正官僚繁琐过程，许可对过程进行自主调整为特征，在软件业引起了极大的兴趣。在这篇文章里，将探索敏捷型方法的合理性，着重点并不是放在其“轻重”上，而是于他们的适应性（adaptive)性质和以人优先的理念。也简要介绍了一些敏捷型方法并给出了进一步的参考资料。另外还提出了一些你在决定是否要走这条刚踏出来的敏捷之路时需要考虑的因素。

从无、到繁重、再到敏捷

预见性于适应性

  将设计与建造分离开来

  需求的不可预见性

  预见性是不可能的吗？

  不可预见过程的控制-迭代

  适应性的客户

把人放在第一位

  可兼容性程序插件

  程序员是负责任的专业人员

  面向人的开发过程的管理

  测度的困难性

  业务专家的引领作用

自适应过程

敏捷型方法

  xp(Extreme Programming--极限编程）

  Cockburn的水晶系列方法

  开放式源代码

  Highsmith的适应性软件开发方法（ASD）

  SCRUM

  功用驱动开发方法（FDD）

  动态系统开发方法

  敏捷软件开发宣言

  相关环境驱动测试（Context Driven Testing)

  RUP是一种敏捷型方法吗？

  其他参考资料

你是否应走向敏捷？

从无、到繁重、再到敏捷

多数软件开发任然是一个显得混乱的活动，即典型的“边写边改”（code and fix）.设计过程充斥着短期的、即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。

我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法”（methodology）.这些方法对开发过程有着严格而详尽得规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实战-因此我把他们称为工程方法（engineering methodologies）.

工程方法已存在很长时间了，但是没有取得令人署目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是他们的官僚繁琐，要是按照他的要求来，那有座太多的事情需要做，而延缓整个开发进程。

作为对这些方法的反叛，在过去几年中出现了一类新方法。他们在一段时间里被称为“轻量型”（lightweight）方法，但现在有了一个广为接受的名称，敏捷型方法（agile methodologies）。对许多人来说，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。他们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。

敏捷型与工程型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，他们通常只要求尽可能少的文档。从许多方面来看，他们更象是“面向源码（code-oriented）.事实上，他们认为最根本的文档应该是源码。

但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，他其实反映的是两个更深层的特点:

敏捷型方法是“适应性”而非“预见性”。工程方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在一般情况下工作良好，但（需求、环境等）有变化时就不太灵了。因此他们本质上是拒绝变化的。而敏捷型方法则欢迎变化。其实，他们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

敏捷型方法是“而向人的（people-oriented）而非“面向过程”的（people-oriented）.工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的工作提供支持。

预设性与适应性

将设计与建造分离开来

传统的软件开发正规方法的基本思路一般是从其他工程领域，如土木工程，借鉴而来。这类工程实践中，在实际建造之前，通常非常强调设计规划。工程师首先要画出一系列的图纸，这些图纸准确地说明了要建造什么以及如何建造（包括部分和整体）。许多设计决定，如怎样处理一座桥梁的负荷，在画图纸时就会做出。然后，这些图纸分发给另外一组人员，通常是另外一个公司，去建造。这种方式其实已假定了建造过程将按图纸而来。当然，施工中也会碰到一些问题，但这些都是次要的。

图纸其实就是一个详细的建造计划，它说明了一个项目中必须完成的各个部分，以及如何把这些部分装配成整体。这样的计划可以进一步定出需要完成的各项任务，以及这些任务之间的依赖关系。这样，能较为合理地制定出生产进度表和项目预算。这种模式实际上也规定了建造者如何做（施工），这也隐含着建造者不须是高智能型的，尽管他们可能都有非常高超的手上功夫。

在此，我们看到的是两类非常不同的活动。设计是难于预见的，并且需要昂贵的有创造性的人员，建造则要易于预设。我们有了设计之后，便可对建造进行计划了。而有了建造计划后，我们进行建造则可以是可预见性的了。在土木工和程中，建造不论在经费上还是在时间上的成本都要比设计和计划大得多。

所以，我们看到的是两类非常不同的活动。设计是难于预见的，并且需要昂贵的有创造性的人员，建造则要易于预设。我们有了设计之后，便可对建造进行计划了。建造将会是直接而明确的。

那么，计划应该采用什么形式呢？对许多人来说，这是设计“标识符号”（notation），如果我们通用UML作出所有主要的技术决定，那么就可以用UML来做建造计划，然后把计划交给程序员去编码，即是建造活动。

但这是里存在一个关键问题。你是否能作出这样的设计使得它能够 让编码成为一项建造活动？如果能，那么这样干的成本上是否充分地小而使得这种值得一用？

这提出了几个问题。第一个问题是到底有多困难能使一个用类似UML作出的设计达到交给程序员就能直接编码的。用象UML那样的语言作出的说干就干在纸上看起来非常漂亮，而实际编程时可能会发现严重的缺陷。土木工程师使用的模型是基于多年的工程实践，并结晶在工程典章中。更进一步来说，一些设计上的关键部分，如应力作用，都是建立于坚实的数学分析之上。而在软件设计中，我们对UML图纸所能做的只是请起居室同行审阅。这当然是很有帮助的，但是往往一些设计错误只能在编码和测试时才能发现。甚至于熟练的设计者，我自认为我属此列，就常常对在把设计变成软件的过程中出现的错误感到意外。

别一个问题是费用比较。建一座桥梁时，设计费用一般占整个工程的10%左右，余下的90%左右为施工建造费用。而在软件开发中，编码所战友的时间一般要少得多。Mconnell指出在大型项目中，编码和单元测试只占15%，这几乎和桥梁工程中的比例倒过来了。即使把所有测试工作都算作是建造的一部分，设计仍要占到50%。这就是提出了一个重要问题，那就是其他过程领域的设计相比，软件设计到底是什么性质。

这些问题导致了Jack  Reevves 提出源码也就是设计文档，而建造应该是编译和链接。的确，任何你认为属于建造的工作都应当是造化的。

这些讨论导致了下面一些重要结论：

·在软件开发中，具体建造费用非常低，几乎忽略不计。

·软件开发中所有工作是设计，因此需要富有创造性的才智之士。

·创造性的过程是不太容易计划的，因此，可预见性是个不可能达到的目标。

·我们应该对用传统工程模式来进行软件开发的做法保持足够的警觉，因为它们是不同类型的活动，因此需要不同的过程。

需求的不可预见性

在每个我参加的问题项目都有这样的一种情况，开发人员跑来抱怨说，“这个项目的问题是需求老是在变”。而让我意外的是每个人都对此感到意外。其实在建造商用软件系统中，需求变更是常态，问题是我们如何来处理它。

一种方法是把需求变更看成是因需求工程（requirements engineering）没作好而导致的结果。一般来说，需求工程（或曰进行需求分析）是要在着手建造软件之前，获取一副已完全理解了的待建系统的画面，然后取得客户认可签发，并且还要建立一套规章来限制需求变更。

该方法的一个问题是要准确获取所有需求是困难的，特别是当开发商不能提供某些需求的费用信息时。例如，你买车时想在你的车上装一个天窗，而推销员却不能告诉你要在国人上只再加10元钱呢，还是10000元。如果不知道这点，你如何能决定你是否愿意花钱在车上加个天空呢。

作软件开发的费用估算是不容易的，这有多种原因。部分原因是因为软件开发是一种设计活动，因此难于精确计划。部分原因是系统的“基本材料”变化非常之愉。部分原因是开发活动极大地依赖于项目参与人员，而个体是难于预测和量化的。

软件的“不可触摸”性也是一个原因。在系统建成之前，有时很难一项功能的具体价值。也就是说，只有在实实在在地使用系统时，你才能知道哪些功能是有用的，哪些没有什么用。

这样的结果颇具讽刺意味，即人们期待需求应该是可变以的。毕竟，软件应该是“软”的。所以需求不仅是可变的，简直就应该变的。要让客户把需求固定下来要花很大的力气，特别是当他们“参与”了软件开发并且“知道”软件是多么易于修改。

但是，即使你能把所有的需求都固定下来，并不意味着你的开发就是阳光灿烂了，你可能仍然会在昏暗之中。在当信的经济形势下，决定并推动软件系统功能我的因素飞快地变化着。现在一组很好的功能六个月以后可能就是不那么好了。商业世界并不会因你的系统的需求固定下来了而停止不动，商业世界的许多变化是完全不可预测的。如果有人不承认这一点，要么他拘谨，要么他已炒股成了百万富翁了。

软件开发的一切都的一切都取决于系统需求，如果需求不固定，你就不能制订出一个预见性的计划？

预见性是不可能的吗？

一般来说，不可能。当然，有一些软件开发项目中，预见性是可能的。象NASA的航天飞机的软件开发项目，应是这样一个例子。它需要大量的会议、充足的时间、庞大的团队、以及稳定的需求。毕竟，这些是航天飞机的项目。但我并不认为一般的商用软件开发属于这类系统，所以你需要不同的开发过程。

如果你不能遵循一个可预见性方法，而你强装能够，那么这是非常危险的。通常，一个正规方法的创造者不是很善于（或乐于）给出其方法的边界条件，换句话说，当这些边界条件不满足时，则该方法就不适用。许多方法学者希望他们的方法能够放之四海而皆准，所以他们既不去了解，也不公布他们方法的边界条件。这导致了众在错误的情形下来使用一种方法，例如，在不可预见性的环境中使用一种预见性的方法。

使用预见性方法具有强烈的诱惑力，因为预见性毕竟是一个非常需要的我。可是，当你不能达到预见性时而你相信你能够，这半会导致这样一种局面：你可以很早就制订出计划，便不能适当地处理计划崩溃的情形。你看见现实与计划慢慢地偏离，百里你可以在很长的时间里，闭关认为计划仍是有效可行的。命题当偏离积累到足够的时候，你的计划就崩溃了，这通常是很痛苦的。

所以说，在不可预见性的环境中是不能使用预见性方法的。认识到这点是一个很大的喃。它意味着我们用的许多控制项目的模式，许多处理客户关系的模式，都不会再是正确的了。预见性的确有非常多的好处，我们很难就放弃预见性而推动这些益处。象很多问题一样，最困难的一点是认识到这些问题的存在。

可是，放弃预见性并不意味着回到不可控制的一片混乱之中。你所需要的是另一类过程，它们可以让你对不可预设性进行控制，这就是“适应性”的作用了。

不可预见过程的控制－迭代

那么，我们如何对付一个不可预测的世界？最重要，也是最困难的是要随时知道我们在开发中的情形处境，这需要一个诚实的反馈机制来不断准确地告诉我们。

这种机制的关键之点是“迭代式”（iterative）开发方法。这并不是一个新思路，迭代式开发方法已存在很久了，只是名称不同，如：“递增式”（Incremental），“渐进式”（Evolutionary），“阶段式”，“螺旋式”（Spiral）等等。迭代式开发的要点是经常不断地生产出最终系统的工作版本，这些版本逐步地实现系统所需的功能。它们虽然功能不全，但已实现的功能必须忠实于最终系统的要求，它们必须是经过全面整合和测试的产品。

这样做的理由是：没有什么比一个整合了的、测试的系统更能作为一个项目扎扎实实的成果。文档可以隐藏所有的缺陷，示经测试的程序可能隐藏许多缺陷。但当用户实实在在地坐在系统前来使用它时，所有的问题都会暴露出来。这些问题可能是源码缺陷错误（bug），也有可能是对需求理解有误。

虽然迭代式开发也可用于可见性环境，但它基本上还是用“适应性”（adaptive）过程，因为适应性过程能及时地对付需求变更。需求变更使得长期计划是不稳定的，一个稳定的计划只能是短期的，这通常是一个“迭代周期”（iteration）。迭代式开发能让每个迭代周期为下面的开发计划提供一个坚实的。

迭代式开发的一个重要问题是一个抚今追昔周需要多长。不同的人有不同的答案，XP(极限编程)建议一到三周，SCRUM建议一个月，Crystal(水晶系列)更长一些。不过一般的趋势是让每一个周期尽可能地短。这样你就能得到频繁的反馈，能不断地知道你所处的状况。

适应性的客户

这类适应性过程需要与客户建立一种新型的关系，特别是当开发是由一家签约公司进行的时候。因为当雇佣一家签约公司来进行开发时，多数客户愿意订一个固定价格的合同。他们告诉开发方他们所需要的功能，招标，签约，然后的命题开发方去建造系统了。

价格合同需要稳定的需求，即一个可预见性过程。适应性过程和不稳定的需求意味着你不能做这种固定价格的合同。把一个固定价格模式弄到适应性过程将导致一个痛苦的结局。最糟糕的是客户将与软件开必者受到同样的伤害，毕竟客户不会想要一个不需要软件。即使他们未付开发方一分钱，他们仍然推动许多。的确，他们推动的比要付给开发商的要多（他们凭什么付这笔钱，如果这个软件的商业价值很？）

因此，在可预见性过程不能用的情况下，签订固定价格合同对双方来说都有危险。这意味着客户须换一种工作方式。

这并不是说，你不能为你的软件固定一笔预算。这实际意味着你不能固定时间、价格和范围（scope）。通常一个敏捷方法是固定时间和价格，而让范围能够可控制地变化。

在适应性过程，客户实际上能够对软件开发过程进行很深入细微的控制。在每一个迭代阶段中，他们都能检查开发进度，也能变更软件开发方向。这导致了与软件开发者更密切的关系。或曰真正的商业伙伴关系。但并不是每一个客户，也并不是每一个开发商都准备接受这种程度的介入，不过如要让适应性过程能很好工作，这种合作程度是基本的要求。

这种开发方式可以给客户带来很多的益处。首先，这种开发的“回应性（responsive）很好的。一个可用的，尽管是很小的系统能够尽早投入使用。客户可以根据实际使用情况，以及变更了的需求，来及时改变一些系统功能。

这样一种方式能够更真实地反映出项目的实际状态。可预见性过程的问题是：项目质量是根据与计划的一致来衡量的。当实际情况与计划脱节时，人们秀难提出来。一般 的结果是在项目的后期出现进度上的大滑坡。在敏捷型的项目中， 第一个周期都对计划进行评审。如果有什么糟糕的事情的话，它也会早点被发现，因此仍然会有时间来解决。的确，这种风险皑皑是迭代式开发的一个关键优点。而敏捷型开发更进了一步，因为它的周期很短，同时它也把这些变化得机会。

这点对于定义什么是成功项目有重要的意义。预见怀项目是否成功是由它是否很好地按计划执行来衡量的。一个项目如果在规定的时间和预算内完成，那就是成功的。对于繁重型环境而言，这种衡量是没有意义的。对于繁重型项目实践者来说，最重要的是商业价值（business value）－客户得到的软件的价值是否大于他们的投入。一个好的预见性项目是依计划而行，而一个好的型项目会建造出一个与最初计划不太一样却是更好的软件。

把人放在第一位

实施一个适应性过程并不容易，特别是它要求一组高效的开发人员，高效既体现在高素质的个体，也体现在有能让团队一致的工作方式。这里有一个有趣的和谐：并非只是适应性过程需要强的团队，多数优秀的开发人员也愿意采用适应性过程。

可兼容性程序插件

传统正规方法的目标之一是发展出这样一种过程，使得一个项目的参与人员成为可替代的部件。这样的一种将人看成是一个种资源，他们具有不同的角色，如一个分析员，一些程序员，测试员及一个管理人员。个体是不重要的，只有角色才是重要的。这样的一来，在你计划一个项目时，你并不在乎你能得到哪个分析员，哪些测试员，你只需养成认错可得到多少，知道资源数量会如何影响你的计划。

但这有一个关键问题：参与软件开发的人员是可替代的部件吗？敏捷型方法的一个重要牲就是拒绝这种观点。

也是最明确地反对这种观点的当数Alistair Cockburn在他的论文“软件开发中人是非线性，一阶的部件”中，他指出可预见性软件开发过程要求“部件”的行为也可预见性的。但是，人并非可预见性的部件。更进一步，他对软件项目的研究导致了如下结论：人是软件开发中最重要的因素。

在本文的标题里，我将入称为“部件”。（传统）过程/方法就是这样看待 入的。这种观点的错误在于没有看到“入”是非常可变的和非线性的，不同的个体具备特有的成功或失败模式。那些因素是一阶的，不可忽略的。一种过程或方法的设计者如不能充分考虑到这些因素，那么其后果就是项目的无计划轨迹。就象我们经常看到的那样。



本文章转载来源于http://www.iasn.com.cn/xwzx/html/77.html