敏捷方法已牢固地融入主流，但这种流行并非没有问题。组织领导者抱怨他们没有获得预期的收益。本文介绍了熟练度模型，它将帮助您充分利用敏捷理念。熟练度通过四个不同的区域演变，每个区域都有其自身的优势、所需能力和关键指标。

在 90 年代我对极限编程的积极体验之后，我对类似的、听起来很像的方法（如 Scrum、Crystal 和 DSDM）产生了兴趣。深入研究后，我提炼出了这些新方法的共同特征：更喜欢适应性计划而不是预测性计划，并且认为人比所用流程对成功更重要。随着时间的推移，这些方法在敏捷软件开发的旗帜下汇集在一起（并且我修改了这篇文章），但我仍然认为这篇文章中的观点是理解敏捷本质的一个好方法。

它可能不是一切的开始，但宣言为这场运动赋予了一个名字，以及最初的一份能量。十年后，它仍然捕捉到了敏捷方法的本质。

2001 年 2 月，17 个人聚集在犹他州的雪鸟，讨论新的轻量级方法风格。其中一个结果是创造了“敏捷”一词来代表一种新的敏捷软件开发流程。我们还共同制定了 敏捷软件开发宣言，它描述了这些敏捷方法的价值观和原则。Jim Highsmith 和我为《软件开发》杂志撰写了这篇文章，以进一步解释宣言。

对于许多与极限编程短暂接触的人来说，似乎 XP 要求软件设计死亡。不仅许多设计活动被嘲笑为“大规模前期设计”，而且诸如 UML、灵活框架，甚至模式之类的设计技术也被淡化或完全忽略。事实上，XP 涉及大量设计，但它采用与既定的软件流程不同的方式进行设计。XP 使演化设计概念焕发活力，其实践允许演化成为一种可行的设计策略。它还带来了新的挑战和技能，因为设计师需要学习如何进行简单设计，如何使用重构来保持设计清洁，以及如何在演化风格中使用模式。

在过去十年中，我们开发和完善了许多技术，这些技术允许数据库设计随着应用程序的开发而演化。对于敏捷方法来说，这是一个非常重要的功能。这些技术依赖于将持续集成和自动化重构应用于数据库开发，以及 DBA 和应用程序开发人员之间的密切协作。这些技术在生产前和已发布的系统中都有效，在绿地项目和遗留系统中都有效。

从表面上看，敏捷软件开发的世界一片光明，因为它现在已经成为主流。但现实令人担忧，因为许多工作都是伪敏捷，无视敏捷的价值观和原则。我们应该关注的三个主要挑战是：对抗敏捷工业综合体及其将流程强加于团队的习惯，提高技术卓越的重要性，以及围绕产品（而不是项目）组织我们的团队。尽管存在问题，但社区的最大优势在于其学习和适应的能力，解决我们最初的宣言作者无法想象的问题。

Ryan Lockard（敏捷起义）邀请我和 Rebecca Wirfs-Brock 一起参加播客对话，讨论敏捷项目中的架构。Rebecca 开发了责任驱动设计，这对我职业生涯的开始产生了很大影响。我们谈论了如何定义架构、测试对架构的影响、领域模型的作用、准备什么样的文档以及需要提前做多少架构。

当一个组织采用敏捷思维时，企业架构不会消失，但企业架构师的角色会发生变化。企业架构师不再做出选择，而是帮助其他人做出正确的选择，然后传播这些信息。企业架构师仍然需要形成愿景，但随后需要在团队之间架起桥梁，以建立学习型社区。这将使团队能够探索新的方法并相互学习，企业架构师作为这种成长的合作伙伴。

在我们撰写 敏捷宣言 十年后，我们这些作者被邀请参加 Agile 2011 大会期间的一个特别活动，以庆祝周年纪念。17 位作者中的 15 位参加了活动，我们举办了一个公园长椅小组讨论，回答观众的提问和评论。我认为我们都对再次见面感到惊讶，以及我们如何轻松地回到舒适的合作和讨论中。我们的讨论包括一些关于宣言写作的背景，回顾过去十年中我们感到满意和不满意的东西，敏捷的未来发展，以及敏捷与精益之间的关系。

远程工作与协同工作之间不存在简单的二分法，相反，团队的分布模式有多种，每种模式都有不同的权衡和适合它们的有效技术。虽然不可能确定确凿的证据，但我感觉大多数团队以协同方式工作效率更高。但是，您可以通过使用分布式工作模型来构建更高效的团队，因为它可以让您接触到更广泛的人才库。

这是我在慕尼黑 OOP 2014 上的主题演讲的第二部分，这是一个很难描述的演讲。通常我喜欢用标题和摘要来描述演讲的内容——但这个演讲是一段旅程，我不想告诉你我要去哪里，而是想和你一起探索这片土地。我要说的是，它从我对大多数敏捷软件开发的采用方式的最大问题开始——用户、分析师和程序员之间交互的本质。它继续探索这些角色，提出关于程序员与用户关系、我们对他们的责任以及我认为程序员需要面对的两个重大挑战的问题。

Neal Ford 和我在巴黎 USI（2010 年）做了一个关于敏捷为什么有效（而不是怎么做）的演讲。这探究了一些使敏捷有效的核心力量，而不是关注技术。我们特别关注沟通和反馈的作用，以及它们如何在敏捷环境中相互作用。

为什么我们需要假设软件应该是柔软的、开放变化的方法。

Paulo Caroli 和我在敏捷巴西的访谈

持续集成是一种软件开发实践，其中团队中的每个成员至少每天将他们的更改合并到代码库中，以及他们同事的更改。每次集成都通过自动构建（包括测试）进行验证，以尽快检测集成错误。团队发现这种方法可以降低交付延迟的风险，减少集成的工作量，并使实践能够培养健康的代码库，以便快速增强新功能。

每日站立会议已成为许多团队的常见仪式，尤其是在敏捷软件开发中。但是，许多微妙的细节区分了有效的站立会议和浪费时间的会议。

敏捷宣言发布 10 周年后的《SD Times》访谈

我在 QCon 2007 上与我的同事 Dan North 一起做的主题演讲。我们都认为开发人员与其客户/用户之间的差距是软件开发中最大的问题。（我们称之为鸿沟，但这个词被过度使用。）在这里，我们谈论了这个差距，为什么它很重要，以及我们需要做些什么来跨越它。我们特别认为，传统的中间人业务分析师的角色充当渡船，而我们真正需要的是一座桥梁，它能够使开发人员与其客户（以及分析师可以构建和维护这座桥梁）直接联系起来。这是我最喜欢的联合主题演讲之一，一方面是因为我认为这个主题非常重要，另一方面是因为 Dan 是一位非常有启发性的联合演讲者。

2001 年 2 月，十七位软件专家齐聚犹他州的雪鸟，讨论当时被称为轻量级方法的不断发展的领域。我们决定使用“敏捷”一词来描述这种新型的 敏捷方法。我们还撰写了 敏捷软件开发宣言，阐述了这些敏捷流程的价值观和原则。我当时是这些自封的先驱者之一，此后我收到了许多关于该小组起源和敏捷联盟随后成立的问题。这是我对这些事件的回忆。

在过去的四年里，Thoughtworks 在印度班加罗尔设立了一个实验室，以支持我们在北美和欧洲的软件开发项目。传统的离岸开发方法基于计划驱动的方法，但我们坚定地站在敏捷阵营。在这里，我将讨论我们在进行离岸敏捷开发方面的经验和教训。到目前为止，我们已经发现我们可以使其发挥作用，尽管其益处仍有待商榷。（虽然这篇文章最后更新于 2006 年，但我于 2011 年访问了我们的离岸工作，发现这些教训仍然具有现实意义，因此这篇文章不需要进一步的重大修改。）

2001 年，我前往雪鸟参加了导致宣言诞生的会议，吉姆为他的著作采访了我。它提供了我对极限编程和几天后我们称为敏捷软件开发的思考的快照。

随着 XP 和其他敏捷方法的流行，人们开始提出关于如何将 XP 扩展到 10-12 人团队以外的问题。2003 年 2 月中旬，加拿大班夫举办了一场专门针对该主题的研讨会。在本文中，我们报道了肯·施瓦伯和马丁·福勒的主题演讲，以及其他领先实践者的演讲。

重构已发展成为一种众所周知的技术，大多数软件开发团队至少声称定期进行重构。然而，许多团队并不了解重构可以使用的不同工作流程，因此错过了将重构有效地纳入其开发活动的机会。在本演示文稿中，我探讨了各种不同的工作流程。我希望它能鼓励团队将重构更深入地融入他们的工作，从而产生设计更好的代码库，使添加新功能变得更快更容易。

在过去十年左右的时间里，重构已成为一种广泛使用的技术，用于保持代码库的高内部质量。然而，大多数团队没有充分利用重构，因为他们没有意识到可以使用它的各种工作流程。在本篇来自慕尼黑 OOP 2014 的主题演讲中，我探讨了一些这些工作流程：例如垃圾清理重构、理解重构和准备重构。我还提醒人们，为什么重构的常见理由会破坏你最好的努力。（本次演讲也以 信息演示文稿的形式呈现。）

敏捷起义播客一直在对敏捷宣言的作者进行一系列采访。这是我坐在受访者席位上的时候。我不记得雪鸟研讨会本身的很多事情，但我能够描述一些导致宣言诞生的背景。

我最近前往澳大利亚参加澳大利亚敏捷大会的零散印象。

是否应该为敏捷方法设立认证计划？

我看到关于敏捷项目的常见问题之一是如何处理向另一个团队的移交。如果你有一个开发团队离开并将支持工作移交给支持团队，那么当敏捷项目往往比计划驱动流程产生更少的文档时，他们如何应对？

根据敏捷联盟现任董事会的说法，敏捷方法 已经“跨越了鸿沟”，我认为这意味着它们正在变得越来越普遍。虽然这有其优势，但也带来了问题。当一种方法论或设计方法变得流行时，我们会看到很多人使用它或教授它，他们关注的是时尚而不是真正的细节。这会导致人们以敏捷的名义做出的行为与运动创始人的原则背道而驰。

2001 年在犹他州雪鸟举行的会议，决定使用“敏捷”一词，并开始制定“敏捷软件开发宣言”。

我正在考虑使用敏捷软件开发，但我应该使用精益软件开发吗？

上周我参加了在奥兰多举行的 2010 年敏捷大会。20xx 年敏捷大会是美国主要的敏捷导向型会议，其根源可以追溯到 XP 宇宙和 敏捷开发大会。我一直没有定期参加主要的敏捷会议，但我去年也参加了。与其尝试进行综合描述，不如说一些零散的印象。

C3 是克莱斯勒综合薪酬项目（Chrysler Comprehensive Compensation project）的简称，这是一个克莱斯勒的薪资项目，后来被称为 极限编程的“诞生项目”。

敏捷方法的共同点之一是，它们将编程提升到软件开发中的核心地位，这远远超过了软件工程界通常的做法。其中一部分是将代码归类为软件系统的主要文档，如果不是主要文档的话。

关于敏捷方法，这里有一个常见的误解。它集中在用户故事的创建方式以及它们在开发活动中的流动方式。误解在于，产品负责人（或业务分析师）创建用户故事，然后将其交给开发人员来实现。这种观念认为，这是一个从产品负责人到开发人员的流程，产品负责人负责确定需要做什么，而开发人员负责确定如何做。

丹尼尔·特霍斯特-诺斯最近关于软件精益求精的博客文章引发了许多博客讨论（如果你有兴趣，我会在下面总结）。文章中有很多内容，但其中一个主题特别引起我的共鸣，因此有了这篇文章。

当有人在考察构成一流企业软件开发人员的因素时，谈话往往会转向框架和语言的知识，或者可能是理解复杂算法和数据结构的能力。对我来说，程序员，或者说开发团队中最重要的一种特质，我称之为客户亲和力。这是开发人员对软件正在解决的业务问题以及生活在那个商业世界中的人们的兴趣和亲近感。

几年前，我和一位客户交谈，他告诉我他不喜欢我们正在使用的敏捷方法的一点：“在项目的早期阶段遇到这些困难感觉不太对劲”。与他的反应相反，在我看来，这种早期的痛苦是敏捷或任何迭代开发流程的一大好处。

极限编程 (XP) 是一种软件开发方法，主要由 肯特·贝克 开发。XP 是最早的 敏捷方法 之一，实际上，XP 是 90 年代后期和 21 世纪初的主流敏捷方法，在 Scrum 在 21 世纪初成为主流之前。许多人（包括我自己）认为 XP 是引起人们对敏捷方法关注的主要催化剂，并且优于 Scrum，是开始敏捷开发的基础。

敏捷方法的一种常见，也许是占主导地位的做法是，为正在构建的软件开发一个功能列表（通常称为故事）。这些功能使用索引卡、工作队列、燃尽图、积压工作或你选择的任何工具进行跟踪。

许多人认为，你不能在敏捷项目中使用固定价格合同。由于敏捷流程的重点是无法预测未来，因此这种假设并非不合理。然而，这并不意味着你不能制定固定价格的敏捷合同，真正的意思是，你不能制定固定范围的合同。

许多公司喜欢编写固定范围和价格的合同，因为他们认为这降低了他们的风险。这种想法认为他们的财务义务固定在交易价格上。如果他们没有得到满意的软件，那么他们就不会为此付出任何代价。

我最近听说过很多项目中都存在一个问题。它是这样的

• 他们想要使用敏捷流程，并选择Scrum
• 他们采用了Scrum的实践，甚至可能包括其原则
• 一段时间后，由于代码库混乱，进度变得缓慢

我最喜欢的口头禅之一是：**如果它让你痛苦，那就更频繁地去做**。它表面上看起来毫无意义，但当你深入挖掘时，它会产生一些有价值的意义

普通开发人员可以使用敏捷方法吗？

一个常见的问题是大型项目是否可以使用敏捷技术。毕竟，许多敏捷方法都是为较小的项目设计的，而它们所抵制的那些重量级理念在更大的项目中更需要。

关于结对编程的一些常见误解。

许多人难以理解敏捷方法的一点是，敏捷方法是以人为本的。那些对敏捷流程感兴趣的人一致认为，流程对项目成功的影响是次要的。敏捷宣言的第一个价值是，个人和互动比流程和工具更重要。

所有敏捷方法都强调系统开发人员与最终受益者（客户）之间直接互动的重要性。敏捷宣言中写道：“业务人员和开发人员必须在整个项目中每天一起工作”，这是为了强调高频率的互动。极限编程通过其现场客户实践来强调这一点。

回顾的黄金法则（Prime Directive）是回顾实践的重要组成部分，自Norm Kerth首次推出回顾实践以来，它一直是回顾思考的不可分割的一部分。最近我阅读了Pat Kua的新书《回顾手册》，这本书基于Pat作为Thoughtworks的技术主管在回顾方面积累的丰富经验。我发现Pat对黄金法则的建议令人反感，但不得不承认他几乎肯定是对的。

我经常遇到一种抱怨，即敏捷方法没有严格的定义。抱怨者可能会谈论这意味着你无法判断一个特定的团队是否在使用敏捷方法。他们也可能会说，这使得教人们如何使用敏捷方法变得困难——课程是什么？

在某种程度上，我确实感受到了这种抱怨的痛苦——但我接受没有解决办法。这种缺乏严格性是敏捷方法的定义特征的一部分，是其核心哲学的一部分。

第n次，我确信不是最后一次，我正在参与关于定义实践、将其中一些标记为“最佳”以及可能出现的C词（认证）的讨论。这是一个熟悉的讨论，虽然我们才刚刚开始，但我可以预测它将走向何方。它是由一种完全合理的愿望驱动的，即识别谁是更好的软件开发人员，以及现有的开发人员如何提高他们的能力。

自测试代码是我在重构中使用的名称，指的是与功能软件一起编写全面自动化测试的实践。如果做得好的话，这将允许你调用一个单一的命令来执行测试——并且你确信这些测试将揭示隐藏在你代码中的任何错误。

人们不时地会质疑某个特定领域是否可以以增量的方式使用：“你不能在敏捷项目中做（安全 | 用户界面设计 | 数据库 | 国际化 | *），因为这方面必须在前期完成。”

在敏捷项目中，你经常会发现开发团队坐在一个开放的团队房间里。这在极限编程的早期就被提倡，并在第二版中被列为主要实践之一。敏捷人士喜欢开放的团队房间，因为它促进了团队成员之间大量的非正式和深入的沟通。

时间盒迭代是一种划分和安排项目工作的方法，尤其与敏捷软件项目相关。团队将软件的可见功能分解成用户故事，并将时间分解成固定周期（例如一周），称为迭代。然后，他们通过将故事分配到迭代中来安排这些故事。故事被粗略地估算，以便团队可以计算出每个迭代可以容纳多少个故事。

用户故事是软件系统所需行为的片段。它们在敏捷软件方法中被广泛用于将大量功能分解成更小的部分，以便于规划。你也会听到相同的概念被称为**功能**，但如今在敏捷圈中，“故事”或“用户故事”这个词已经变得流行起来。