新方法论（原始版本）

设计与构建的分离

方法论的通常灵感来自工程学科，例如土木工程或机械工程。此类学科非常重视在构建之前进行规划。此类工程师将处理一系列图纸，这些图纸精确地指示需要构建什么以及如何将这些东西组合在一起。许多设计决策（例如如何处理桥梁上的负载）都是在制作图纸时做出的。然后将图纸交给不同的组（通常是不同的公司）进行构建。假设施工过程将遵循图纸。在实践中，施工人员会遇到一些问题，但这些问题通常很小。

由于图纸指定了零件以及如何将它们组合在一起，因此它们充当了详细施工计划的基础。这样的计划可以找出需要完成的任务以及这些任务之间存在的依赖关系。这允许对施工进行合理可预测的时间表和预算。它还详细说明了从事施工工作的人员应如何开展工作。这使得施工在智力上不太熟练，尽管它们通常在手工上非常熟练。

因此，我们在这里看到的是两种根本不同的活动。设计难以预测，需要昂贵且有创造力的人员，而构建则更容易预测。一旦有了设计，我们就可以规划构建。一旦有了构建计划，我们就可以以一种更可预测的方式处理构建。在土木工程中，构建在成本和时间上都比设计和规划大得多。

因此，许多方法论的方法如下所示：我们想要一个可预测的计划，可以使用技能较低的人员。为此，我们必须将设计与构建分开。因此，我们需要弄清楚如何为软件进行设计，以便在完成规划后可以轻松进行构建。

那么，此计划采用什么形式？对于许多人来说，这是设计符号的作用，例如 UML。如果我们可以使用 UML 做出所有重大决策，我们就可以制定构建计划，然后将这些设计作为构建活动交给编码人员。

但这里存在关键问题。你能否获得一种能够将编码变成构建活动的设计？如果是这样，构建在成本和时间上是否足够大，以使这种方法值得？

所有这些都会带来一些问题。第一个问题是如何将类似 UML 的设计弄成可以移交给程序员的状态。类似 UML 的设计的缺点在于它在纸面上看起来可能非常好，但在实际必须对该事物进行编程时却存在严重缺陷。土木工程师使用的模型基于多年的实践，这些实践已载入工程规范中。此外，关键问题（例如力在设计中的作用方式）适合进行数学分析。我们唯一可以对类似 UML 的图表进行的检查是同行评审。虽然这有帮助，但它会导致设计中的错误，而这些错误通常只在编码和测试期间才会被发现。即使是像我这样自认为熟练的设计师，在将这种设计变成软件时也常常会感到惊讶。

另一个问题是比较成本。在建造桥梁时，设计工作的成本约占工作的 10%，其余部分是构建。在软件中，花在编码上的时间要少得多（McConnell 建议，对于大型项目，只有 15% 的项目是代码和单元测试，几乎完全颠倒了桥梁建造比率。即使你将所有测试都归为构建的一部分，那么设计仍然是工作量的 50%。）这提出了一个重要问题，即软件中的设计与它在其他工程分支中的作用相比的性质。

这些问题促使杰克·里维斯 提出，实际上源代码是一个设计文档，而构建阶段实际上是编译器和链接器的使用。事实上，任何你可以视为构建的内容都可以并且应该自动化。

这种想法得出了以下一些重要结论

• 在软件中：构建非常便宜，几乎免费
• 在软件中，所有工作都是设计，因此需要有创造力和才华的人员
• 创造性过程不容易规划，因此可预测性很可能是一个不可能的目标。
• 我们应该非常小心用于构建软件的传统工程隐喻。这是一种不同的活动，需要不同的过程

需求的不可预测性

我遇到的每个问题项目中都听到过一句抱怨。开发人员来找我说：“这个项目的问题在于需求总是在变化”。我对此情况感到惊讶的是，任何人对此感到惊讶。在构建业务软件时，需求变化是常态，问题是我们对此做了什么。

一种方法是将不断变化的需求视为需求工程不佳的结果。需求工程背后的理念是在开始构建软件之前充分了解需求，让客户签署这些需求，然后设置限制需求变更的程序，以在签署之后进行更改。

问题之一在于，仅仅尝试了解需求选项就非常困难。这甚至更困难，因为开发组织通常不会提供需求的成本信息。你最终会陷入一种境地，你可能希望在你的汽车上安装一个天窗，但销售人员无法告诉你它会给汽车增加 10 美元还是 10,000 美元的成本。在不了解成本的情况下，你如何才能弄清楚你是否愿意为那个天窗付费？

估计很困难，原因有很多。部分原因是软件开发是一种设计活动，因此很难规划和计算成本。部分原因是基本材料会不断快速变化。部分原因是很多事情取决于参与的个人，而个人很难预测和量化。

软件的无形性质也会产生影响。在真正使用软件功能之前，很难看出它的价值。只有在你使用某个软件的早期版本时，你才能真正开始了解哪些功能是有价值的，哪些部分没有价值。

这导致了一个具有讽刺意味的观点，即人们期望需求应该是可变的。毕竟，软件应该是“软”的。因此，需求不仅是可变的，而且还应该是可变的。需要花费大量精力才能让软件客户修复需求。如果他们自己涉足过软件开发，情况会更糟，因为那时他们“知道”软件很容易更改。

但即使你能够解决所有这些问题并真正获得一组准确且稳定的需求，你仍然可能会失败。在当今经济中，基本的商业力量正在以过快的速度改变软件功能的价值。现在可能是一组好的需求，但六个月后就不是了。即使客户可以修复他们的需求，但商业世界也不会为他们停滞不前。而且，商业世界中的许多变化都是完全不可预测的：任何人如果说不是这样，要么是在撒谎，要么在股票市场交易中赚了十亿。

软件开发中的所有其他内容都取决于需求。如果你无法获得稳定的需求，你就无法获得可预测的计划。

可预测性是否不可能？

一般来说，不行。有些软件开发是可以预测的。像美国国家航空航天局的航天飞机软件组这样的组织就是一个很好的例子，说明软件开发是可以预测的。它需要很多仪式、大量时间、一个庞大的团队和稳定的需求。那里有一些项目是航天飞机。不过，我不认为很多商业软件属于那一类。为此，你需要一种不同的流程。

最大的危险之一就是假装你可以在不能预测的情况下遵循可预测的流程。从事方法论的人不太擅长识别边界条件：方法论从合适过渡到不合适的地方。大多数方法论者希望他们的方法论能够被每个人使用，因此他们不了解或不宣传他们的边界条件。这会导致人们在错误的情况下使用方法论，例如在不可预测的情况下使用可预测的方法论。

人们很容易这样做。可预测性是一个非常理想的特性。但是，如果您认为自己可以在无法预测时进行预测，则会导致人们在早期制定计划，然后无法正确处理计划失败的情况。您会看到计划和现实逐渐背离。很长一段时间，您可以假装该计划仍然有效。但在某些时候，差异变得太大，计划就会失败。通常，失败是痛苦的。

因此，如果您处于不可预测的情况下，则无法使用预测方法。这是一个沉重的打击。这意味着许多用于控制项目的模型、许多用于整个客户关系的模型不再真实。可预测性的好处非常大，很难放弃它们。与许多问题一样，最困难的部分只是意识到问题的存在。

但是，放弃可预测性并不意味着您必须回归到不可控的混乱中。相反，您需要一个可以控制不可预测性的过程。这就是适应性所要做的。

控制不可预测的流程

那么，我们如何在不可预测的世界中控制自己？最重要的是，仍然困难的部分是准确地知道我们在哪里。我们需要一个诚实的反馈机制，它可以准确地告诉我们情况在频繁的时间间隔内是什么。

这种反馈的关键是迭代开发。这不是一个新想法。迭代开发已经存在了一段时间，名称有很多：增量、进化、分阶段、螺旋……很多名称。迭代开发的关键是频繁地生成最终系统的工作版本，其中包含所需功能的子集。这些工作系统功能较少，但其他方面应忠实于最终系统要求。它们应完全集成，并像最终交付一样经过仔细测试。

这样做的好处是，对于将现实有力地带入任何项目来说，没有什么是像经过测试的集成系统那样的。文档可以隐藏各种缺陷。未经测试的代码可以隐藏大量缺陷。但是，当人们实际坐在系统前并使用它时，缺陷就会变得显而易见：无论是错误还是对需求的误解。

迭代开发在可预测的流程中也有意义。但在自适应流程中，它是必不可少的，因为自适应流程需要能够处理所需功能的变化。这导致了一种规划风格，其中长期计划非常灵活，唯一稳定的计划是为单次迭代制定的短期计划。迭代开发为您在每次迭代中提供一个坚实的基础，您可以围绕它制定后来的计划。

对此的一个关键问题是迭代应该持续多长时间。不同的人给出不同的答案。XP 建议迭代时间为一到三周。SCRUM 建议一个月。Crystal 将进一步延长。然而，趋势是尽可能缩短每次迭代。这提供了更频繁的反馈，这样您就可以更频繁地知道自己身处何处。

适应性客户

这种自适应过程需要与客户建立不同类型的关系，特别是当开发由独立公司完成时。当您聘请一家独立公司进行软件开发时，大多数客户更喜欢固定价格合同。告诉开发人员他们想要什么，要求报价，接受报价，然后开发组织就有责任构建软件。

固定价格合同需要稳定的需求，因此需要一个预测流程。自适应流程和不稳定的需求意味着你无法使用通常的固定价格概念。尝试将固定价格模型与自适应流程相匹配最终会产生非常痛苦的爆炸。这种爆炸的讨厌之处在于，客户受到的伤害与软件开发公司一样多。毕竟，如果没有业务需求，客户就不会想要一些软件。如果他们得不到它，他们的业务就会受到影响。因此，即使他们没有向开发公司支付任何费用，他们仍然会亏损。事实上，他们损失的比他们为软件支付的费用还要多（如果该软件的业务价值较低，他们为什么要为其付费？）

因此，在无法使用预测流程的情况下签订固定价格合同，双方都会面临危险。这意味着客户必须以不同的方式工作。

在自适应流程中，客户对软件开发流程拥有更细粒度的控制。在每次迭代中，他们都可以检查进度并改变软件开发的方向。这导致与软件开发人员建立更紧密的关系，真正的业务伙伴关系。并非每个客户组织或每个软件开发人员都适合这种参与程度；但它对于让自适应流程正常工作至关重要。

对客户来说，关键的好处是响应速度更快的软件开发。一个可用但最小的系统可以尽早投入生产。然后，客户可以根据业务的变化以及从系统在现实中的使用情况中学到的知识来改变其功能。

即插即用编程单元

传统方法论的目标之一是开发一个流程，其中涉及人员是可以替换的部件。通过这样的流程，你可以将人员视为可用于各种类型的资源。你有一个分析师、一些编码人员、一些测试人员和一个经理。个人并不重要，只有角色重要。这样，如果你计划一个项目，就不管你得到哪个分析师和哪个测试人员，只要你知道你有多少人，这样你就可以知道资源数量如何影响你的计划。

但这提出了一个关键问题：参与软件开发的人员是否是可以替换的部件？轻量级方法的一个关键特征是它们拒绝了这一假设。

也许最明确地拒绝将人视为资源的是 Alistair Cockburn。在他的论文将人描述为软件开发中非线性的、一阶组件中，他指出可预测的流程需要以可预测方式运行的组件。然而，人不是可预测的组件。此外，他对软件项目的研究使他得出结论，人才是软件开发中最重要的因素。

[他的文章]的标题中，我将人称为“组件”。这就是人们在流程/方法论设计文献中受到对待的方式。这种方法的错误在于，“人”是高度可变和非线性的，具有独特的成功和失败模式。这些因素是一阶因素，而不是可忽略的因素。流程和方法论设计者未能考虑这些因素，导致了我们经常看到的各种计划外项目轨迹。

-- [cockburn-non-linear]

尽管 Cockburn 在以人为本的软件开发观点上最为明确，但以人为先的概念是许多软件思想家的共同主题。问题在于，方法论往往与将人作为项目成功首要因素的概念相悖。

这会产生强烈的积极反馈效应。如果你期望所有开发人员都是即插即用编程单元，你就不会尝试将他们视为个体。这会降低士气（和生产力）。优秀的人才寻找更好的地方，而你最终得到的就是你想要的：即插即用编程单元。

决定以人为先是一项重大决定，需要很大的决心才能坚持下去。将人视为资源的概念深深植根于商业思维中，其根源可以追溯到 弗雷德里克·泰勒 的科学管理方法的影响。在管理一家工厂时，这种泰勒主义方法是有意义的。但对于我认为软件开发属于的高度创造性和专业性工作来说，这是不成立的。（事实上，现代制造业也在远离泰勒主义模式。）

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

泰勒主义概念的一个关键部分是，从事这项工作的人并不是最能想出如何最好地完成这项工作的人。在一家工厂里，这可能是出于几个原因。部分原因是，许多工厂工人并不是最聪明或最有创造力的人，部分原因是管理层和工人之间存在紧张关系，因为管理层在工人赚得更少时赚得更多。

最近的历史越来越向我们展示，对于软件开发来说，这是多么的不真实。越来越聪明、有能力的人被软件开发所吸引，既被它的浮华所吸引，也被潜在的丰厚回报所吸引。（这两者都让我放弃了电子工程。）股票期权等计划越来越多地将程序员的利益与公司的利益联系在一起。

（这里很可能有代际效应。一些轶事证据让我怀疑，在过去十年左右的时间里，是否有更多聪明的人涉足软件工程。如果是这样，这将解释为什么计算机行业如此崇拜年轻人，就像大多数崇拜一样，其中必须有一点真理。）

当你想要雇用和留住优秀人才时，你必须认识到他们是称职的专业人士。因此，他们是决定如何开展技术工作的最佳人选。泰勒主义关于一个独立的计划部门决定如何做事的想法只有在计划人员比执行者更了解如何更好地完成工作时才有效。如果你有聪明、有动力的人在做这项工作，那么这是不成立的。

管理以人为本的流程

以人为本在轻量级流程中以多种不同的方式体现出来。它会产生不同的影响，并非所有影响都是一致的。

关键要素之一是接受流程，而不是强加流程。通常，软件流程是由管理人员强加的。因此，它们经常遭到抵制，尤其是在管理人员远离积极开发相当长一段时间的情况下。接受流程需要承诺，因此需要团队所有成员积极参与。

最终得出这样一个有趣的结果：只有开发人员自己才能选择遵循一个自适应流程。这对于 XP 来说尤其如此，它需要大量的纪律来执行。这就是 Crystal 如此有效补充的原因，因为它旨在尽可能地减少纪律性。

另一点是，开发人员必须能够做出所有技术决策。XP 解决了这一问题的核心，在它的规划过程中，它指出只有开发人员才能估计完成某些工作需要多长时间。

这种技术领导力对于许多处于管理职位的人来说是一个巨大的转变。这种方法需要责任共享，开发人员和管理人员在项目的领导中拥有平等的地位。请注意，我说的是平等。管理层仍然发挥作用，但承认开发人员的专业知识。

造成这种情况的一个重要原因是我们行业的技术变革速度。几年后，技术知识就会过时。这种技术技能的半衰期在任何其他行业都是无与伦比的。即使是技术人员也必须认识到，进入管理层意味着他们的技术技能会迅速枯萎。前开发人员需要认识到，他们的技术技能会迅速消失，他们需要信任并依赖当前的开发人员。

业务领导的作用

但技术人员无法自己完成整个过程。他们需要业务需求方面的指导。这导致了自适应流程的另一个重要方面：他们需要与业务专业知识密切联系。

这超出了大多数项目中业务角色的参与范围。轻量级团队无法通过偶尔的沟通而存在。他们需要持续获取业务专业知识。此外，这种获取并不是由管理层处理的，而是每个开发人员都可以获得的。由于开发人员是其所在学科的专业人士，因此他们需要能够与其他学科的其他专业人士平等地合作。

当然，其中很大一部分原因在于自适应开发的本质。由于自适应开发的整个前提是事物会迅速变化，因此你需要持续联系以告知每个人有关更改的信息。

对于开发人员来说，没有什么比看到自己的辛勤工作付诸东流更令人沮丧的了。因此，确保开发人员既能获得高质量的业务专业知识，又能获得足够高质量的业务专业知识以使开发人员信任他们非常重要。

XP（极限编程）

在所有轻量级方法论中，这是最受关注的一种。部分原因是由于 XP 领导者，特别是 Kent Beck，获得关注的非凡能力。这也是因为 Kent Beck 吸引人们采用这种方法并发挥领导作用的能力。然而，在某些方面，XP 的流行已经成为一个问题，因为它已经相当程度上排挤了其他方法论及其有价值的思想。

XP 的根源在于 Smalltalk 社区，特别是 Kent Beck 和 Ward Cunningham 在 20 世纪 80 年代末的密切合作。他们两人在 90 年代初的众多项目中改进了自己的实践，扩展了他们对既适应性强又以人为本的软件开发方法的思想。

从非正式实践到方法论的关键一步发生在 1996 年春天。Kent 被要求审查克莱斯勒的工资项目进展。该项目由一家承包公司使用 Smalltalk 进行，并且遇到了麻烦。由于代码库质量低下，Kent 建议抛弃整个代码库并从头开始他的领导。结果是克莱斯勒 C3 项目（克莱斯勒综合补偿），此后成为 XP 的早期旗舰和培训基地。

C3 的第一阶段于 1997 年初上线。该项目此后继续进行，后来遇到困难，导致 1999 年进一步开发被取消。在我写这篇文章时，它仍然支付着最初的 10,000 名受薪员工的工资。

XP 以四个价值观开始：沟通、反馈、简单和勇气。然后，它建立了 XP 项目应该遵循的十几个实践。其中许多实践都是古老的、经过尝试和测试的技术，但经常被许多人遗忘，包括大多数计划流程。除了恢复这些技术之外，XP 将它们编织成一个协同的整体，其中每个技术都得到其他技术的加强。

最引人注目、也最吸引我的一点是它非常重视测试。虽然所有流程都提到了测试，但大多数流程都非常不重视测试。然而，XP 将测试作为开发的基础，每个程序员在编写生产代码时都会编写测试。这些测试被集成到持续集成和构建过程中，为未来的开发提供了一个高度稳定的平台。

在这个平台上，XP 构建了一个进化设计流程，该流程依赖于每次迭代重构一个简单的基本系统。所有设计都围绕当前迭代进行，没有为预期的未来需求进行任何设计。结果是一个有纪律但令人惊讶的设计过程，它以一种可以说是所有适应性方法论中发展得最好的方式将纪律与适应性相结合。

XP 已经发展出广泛的领导力，其中许多源自开创性的 C3 项目。因此，有很多信息来源。目前最好的 摘要 是由局外人 Jim Highsmith 撰写的，我稍后会介绍他自己的方法论。Kent Beck 撰写了 极限编程详解，这是 XP 的关键宣言，解释了该方法论背后的原理，并对其进行了足够的解释，以告诉人们他们是否有兴趣进一步追求它。

另外两本书正在筹备中。C3 项目的三位成员：Ron Jeffries、Ann Anderson 和 Chet Hendrickson 正在撰写 极限编程安装，这是基于 C3 经验对 XP 的解释。Kent Beck 和我正在撰写 极限编程规划，讨论了如何以这种自适应方式进行规划。

除了书籍之外，还有相当多的网络资源。XP 思想的早期倡导和发展大部分发生在 Ward Cunningham 的 wiki 网页 协作写作环境中。这个 wiki 仍然是一个迷人的发现之地，尽管它漫无边际的性质确实会让你陷入其中。要找到一种对 XP 更有条理的方法，最好从 C3 校友的两个网站开始：Ron Jeffries 的 xProgramming.com 和 Don Wells 的 extremeProgramming.org。Bill Wake 的 xPlorations 包含大量有用的论文。C++ 和 OO 设计的知名作者 Robert Martin 也加入了 XP 推广者的行列。他的公司 ObjectMentor在其网站上发表了许多论文。他们还赞助 xp 讨论 egroup。

Cockburn 的 Crystal 系列

Alistair Cockburn 自 90 年代初期受 IBM 委托撰写有关方法论的文章以来，一直在研究方法论。然而，他的方法与大多数方法论学家不同。他并没有仅仅依靠个人经验来构建关于如何做事理论，而是补充了他的直接经验，积极寻求采访项目以了解它们如何运作。此外，他不害怕根据他的发现改变他的观点：所有这些都使他成为我最喜欢的方法论学家。

他的书，面向对象项目生存指南，是他关于运行项目的第一个建议，仍然是我运行迭代项目的首选图书推荐。

自那本书以来，他进一步探索了轻量级方法，提出了 Crystal 系列方法论。这是一个系列，因为他认为不同类型的项目需要不同类型的方法论。他沿着两个轴研究这种变化：项目中的人数和错误的后果。每种方法论都适合网格的不同部分，因此一个可能损失自由支配资金的 40 人项目与一个六人命门项目的方法论不同。

Crystals 与 XP 共享以人为本的定位，但这种以人为本是以不同的方式完成的。Alistair 认为人们很难遵循有纪律的过程，因此，与其遵循 XP 的高纪律，Alistair 探索了仍然可以成功的最不守纪律的方法论，有意识地用生产力换取执行的容易性。因此，他认为，尽管 Crystal 的生产力不如 XP，但更多的人将能够遵循它。

Alistair 也在迭代末期审查中投入了大量精力，从而鼓励流程进行自我改进。他断言，迭代开发旨在尽早发现问题，然后让人们对其进行纠正。这更加强调人们监控其流程并在开发过程中对其进行调整。

开源

您可能会对这个标题感到惊讶。毕竟，开源是一种软件风格，而不是一种流程。然而，开源社区中确实有明确的行为方式，并且他们的许多方法既适用于闭源项目，也适用于开源项目。特别是，他们的流程面向物理分布的团队，这一点很重要，因为大多数自适应流程都强调同处一地的团队。

大多数开源项目都有一个或多个维护者。维护者是唯一被允许将更改提交到源代码存储库的人。然而，除了维护者之外的人员也可以对代码库进行更改。关键区别在于，其他人需要将他们的更改发送给维护者，然后由维护者对其进行审查并将其应用到代码库中。通常，这些更改以补丁文件形式进行，这使得此过程更加容易。因此，维护者负责协调补丁并维护软件的设计内聚性。

不同的项目以不同的方式处理维护者角色。有些项目为整个项目分配一个维护者，有些项目划分为模块并为每个模块分配一个维护者，有些项目对维护者进行轮换，有些项目在同一代码上有多个维护者，还有些项目结合了这些想法。大多数开源人员都是兼职的，因此对于这样的团队如何协调完成全职项目存在问题。

开源开发的一个特殊功能是调试高度并行化。因此，许多人可以参与调试。当他们发现错误时，他们可以将补丁发送给维护者。对于非维护者来说，这是一个很好的角色，因为大部分时间都花在查找错误上。对于没有强大设计技能的人来说，这也是一个好角色。

开源的流程尚未得到很好的编写。最著名的论文是 Eric Raymond 的大教堂与集市，虽然这是一篇优秀的描述，但篇幅也很短。Klaus Fogel 的关于 CVS 代码存储库的书也包含几章关于开源流程的精彩章节，即使那些永远不想执行 cvs 更新的人也会感兴趣。

Highsmith 的自适应软件开发

Jim Highsmith 花费多年时间致力于预测方法。他开发了它们，安装了它们，教授了它们，并得出结论，它们存在严重的缺陷：特别是对于现代企业而言。

他最近的书重点关注新方法的自适应特性，特别强调应用起源于复杂自适应系统（通常称为混沌理论）领域的思想。它没有提供像 XP 工作那样的详细实践，但它确实为自适应开发为何重要以及在更深层次的组织和管理层面的后果提供了基本基础。

SCRUM

SCRUM 在面向对象领域已经存在一段时间，尽管我承认我对它的历史或发展并不太了解。它再次关注这样一个事实，即定义且可重复的流程仅适用于在定义且可重复的环境中解决定义且可重复的问题，并适用于定义且可重复的人员。

SCRUM 将项目划分为 30 天的迭代（他们称之为冲刺）。在开始冲刺之前，您需要定义该冲刺所需的功能，然后让团队交付它。重点是在冲刺期间稳定需求。

然而，管理层在冲刺期间并不会脱离参与。团队每天都会举行一个简短（十五分钟）的会议，称为 scrum，团队在会议上讨论第二天将要做什么。特别是，他们会向管理层提出障碍：阻碍进度并需要管理层解决的问题。他们还会报告已完成的工作，以便管理层每天了解项目的进展情况。

SCRUM 文献主要关注迭代规划和跟踪过程。它在许多方面与其他轻量级方法非常接近，并且应该与 XP 的编码实践配合良好。

目前还没有关于 SCRUM 的书籍，但有许多网络资源。Ken Schwaber 主持 controlChaos.com，这可能是对 SCRUM 最好的概述。Jeff Sutherland 一直都有一个关于对象技术问题的活跃网站，其中包括 关于 SCRUM 的部分。在 PLoPD 4 书中也有对 SCRUM 实践的良好概述。

Coad 的特性驱动开发

功能驱动开发 (FDD) 是由长期 OO 大师 Peter Coad 开发的。与其他自适应方法一样，它专注于提供有形功能的短迭代。在 FDD 中，迭代持续两周。

FDD 有五个流程。前三个在项目开始时完成。

• 开发总体模型
• 构建功能列表
• 按功能规划

后两个在每个迭代中完成。

• 按功能设计
• 按功能构建

每个流程都分解为任务并给出验证标准

开发人员分为两类：类所有者和首席程序员。首席程序员是最有经验的开发人员。他们被分配了要构建的功能。然而，他们并不是独自构建。相反，首席程序员会确定哪些类参与实现该功能，并召集他们的类所有者组成一个功能团队来开发该功能。首席程序员充当协调员、首席设计师和导师，而类所有者则负责该功能的大部分编码工作。

FDD 的主要描述在 Peter Coad 等人的 UML in Color 书中。他的公司 TogetherSoft 也对 FDD 进行咨询和培训。

其他来源

还有许多其他关于轻量级方法主题的论文和讨论。虽然这些可能不是完整的方法，但它们确实提供了对这个不断发展的领域的见解。

如果仅仅是因为许多对模式感兴趣的人也对更具适应性和人性化的方法感兴趣，编程模式语言 会议经常包含涉及该主题的材料。吉姆·科普林在 PLoP1 上发表的一篇论文是早期的一篇重要论文。沃德·坎宁安的 Episodes 模式语言出现在 PLoP2 中。吉姆·科普林现在主持 OrgPatterns 网站，这是一个 wiki，收集了组织模式的模式。

迪尔克·里赫勒向 XP2000 提交了一篇论文，比较了 XP 和自适应软件开发的价值体系。Coad 信的 7 月刊 将 XP 与 FDD 进行了比较。IEEE Software 的 7 月刊包含几篇关于“流程多样性”的文章，涉及这些方法。

哪种自适应流程？

所有这些流程都是新的，我只能提供一些第一手经验来指导您。在我看来，问题在于团队规模以及他们准备接受多少纪律。

对于倾向于尝试的十几个或更少的开发人员，我肯定会推动 XP。团队可能不会一开始就全力以赴地进行 XP 流程，但您仍然可以通过部分 XP 方法获得很多好处。对我来说，使用此流程的关键测试是自动化单元测试。如果团队准备这样做，那么技术基础将到位。如果他们做不到，那么我不认为他们会处理好其余的事情。

如果纪律不存在，或者团队规模太大，那么我倾向于遵循 Crystal 的建议。它当然是最轻量的，而 Cockburn 特别适应开发经验教训。在这些情况下，我仍然会使用 XP 规划流程。

然而，话虽如此，我正在与一个 40 人的团队合作，他们成功地尝试了许多 XP 实践，并且非常接近完整的 XP，因此，凭借决心和一个敬业的团队，您可以在至少一些这些界限之外调整您的流程。

这才是真正的关键信息。无论你开始使用什么流程，它都不会成为真正适合你的流程。你必须掌控自己的流程，对其进行监控并根据自己的情况进行调整。最终它必须成为你的流程，任何其他标签都是次要的。