敏捷软件指南
在过去的十年里，敏捷软件开发已经从一种小众技术发展成为主流的一部分。我很幸运地参与了这个故事的开端，早期参与了“极限编程”的“诞生项目”，并且是“敏捷软件开发宣言”的合著者之一。Thoughtworks 从 2000 年开始使用敏捷技术，此后我们已在全球范围内的项目中成功地使用了它们。我们在企业环境中使用敏捷方法方面积累了大量经验，并致力于分享这些经验，以帮助促进其智能化应用。
martinfowler.com 上有关敏捷软件开发的资料指南。
敏捷软件开发的本质
自敏捷方法的开发者首次开始谈论他们的方法以来，已经过去了十多年。在这段时间里，敏捷思维已经从一种小众活动转变为一种被广泛使用的方法。然而，就像任何流行的技术一样，敏捷软件开发也遭受了“语义扩散”的困扰，因此我们看到的名为敏捷的东西很多与早期先驱者所做的东西已经大相径庭。因此，我认为重新审视敏捷思维的基本要素非常重要。
我一直认为，敏捷思维的本质在于与传统的计划驱动型软件工程的两个对比
敏捷 开发
- 是 适应性 的，而不是预测性的
- 是 以人为本 的，而不是以流程为导向的
计划驱动型 工程期望我们提出一个先于开发的 预测性计划。该计划规定了整个项目的人员、资源和时间表。软件设计也是预先完成的，预计实施将符合此设计。成功 的衡量标准是 开发遵循此计划的程度。
敏捷 计划是一个基线，我们用它来帮助我们控制变更。敏捷团队的计划与传统团队一样周密，但 计划会不断修改 以反映我们在项目期间学到的东西。成功 基于软件 交付的价值。
计划驱动型 工程寻求一种能够提供足够结构以 减少个体差异 至无关紧要的流程。这种工业流程更具可预测性，在人员流动时能更好地应对，并且更容易定义技能和职业道路。
敏捷 工程将软件开发视为一项 主要的人类活动，其中所涉及的人员以及他们如何作为一个团队团结起来是成功的首要驱动力。流程（和工具）可以提高团队的效率，但始终是次要的影响因素。
新方法
在 90 年代对极限编程有了积极的体验之后，我对类似的方法（如 Scrum、Crystal 和 DSDM）产生了好奇。通过深入研究，我提炼出了这些新方法的共同特征：更喜欢适应性计划而不是预测性计划，并将人视为比所用流程更重要的成功因素。随着时间的推移，这些方法汇集在敏捷软件开发的旗帜下（我修改了这篇文章），但我仍然发现这篇文章的视角是理解敏捷本质的好方法。
敏捷软件开发宣言
它可能不是一切的开始，但宣言赋予了这场运动一个名字，并注入了一股最初的能量。十年后，它仍然抓住了敏捷方法的本质。
演讲：敏捷本质与流畅性
自我们撰写敏捷软件开发宣言以来，已经过去了十多年，敏捷模因的成功超出了我们的预期。但就像任何成功一样，都存在着语义扩散的常见危险。我试图通过描述敏捷软件开发的本质来对抗这种疾病：更喜欢适应性计划而不是预测性计划，更重视人而不是流程。
然后，我将描述敏捷流畅性模型，我发现这是一种思考敏捷团队如何变得熟练的有效方式，以及在成为敏捷技术更熟练的用户时通常会经历的步骤。
敏捷流畅性模型
敏捷方法已成为主流，但这种流行并非没有问题。组织领导者抱怨说，他们没有获得预期的收益。本文介绍了一种流畅性模型，可以帮助您充分利用敏捷理念。流畅性通过四个不同的区域发展，每个区域都有其自身的优势、所需的熟练程度和关键指标。
技术实践
为了使敏捷工作，您需要扎实的技术实践。许多敏捷教育都低估了这些，但如果您在这方面偷工减料，您将无法获得敏捷开发可以为您带来的生产力和响应能力优势（让您停留在敏捷流畅性的第一个区域）。这也是我仍然认为极限编程作为核心和起点是已命名的敏捷方法中最有价值的原因之一。
重构指南
重构是一种重构现有代码库的规范化技术，它可以在不改变外部行为的情况下改变其内部结构。其核心是一系列小的行为保持转换。每个转换（称为“重构”）做的事情很少，但这些转换的序列可以产生重大的重构。由于每次重构都很小，因此出错的可能性较小。每次重构后，系统都会保持完全工作状态，从而降低了系统在重构过程中严重崩溃的可能性。
高质量软件值得付出代价吗？
软件开发项目中的一个常见争论是，是花时间提高软件质量，还是专注于发布更有价值的功能。通常，交付功能的压力主导着讨论，导致许多开发人员抱怨他们没有时间来处理架构和代码质量。这场辩论是基于这样一个假设，即提高质量也会增加成本，这是我们的共同经验。但与直觉相反的现实是，内部软件质量消除了减缓新功能开发的障碍，从而降低了增强软件的成本。
持续交付指南
对于软件开发人员来说，编写在其机器上运行的代码已经够难了。但即使完成了，从那里到产生价值的软件还有很长的路要走——因为软件只有在生产中才能产生价值。我的软件交付理念的本质是构建软件，使其始终处于可以投入生产的状态。我们称之为持续交付，因为我们一直在运行一个部署管道，以测试该软件是否处于可交付状态。
自测试代码
自测试代码是我在“重构”中使用的名称，指的是与功能软件一起编写全面的自动化测试的实践。如果做得好的话，这将允许您调用一个执行测试的命令——并且您确信这些测试将发现隐藏在代码中的任何错误。
设计已死？
对于许多短暂接触极限编程的人来说，极限编程似乎要求软件设计的消亡。不仅许多设计活动被嘲笑为“前期大设计”，而且诸如 UML、灵活框架甚至模式之类的设计技术也被淡化或完全忽略。事实上，极限编程涉及大量的设计，但它的方式与已建立的软件流程不同。极限编程通过允许进化成为一种可行的设计策略的实践，重振了进化设计的概念。它还提供了新的挑战和技能，因为设计人员需要学习如何进行简单设计、如何使用重构来保持设计的整洁，以及如何以进化风格使用模式。
代码即文档
敏捷方法的共同点之一是，它们将编程提升到软件开发的核心地位——比软件工程界通常的做法要重要得多。其中一部分是将代码分类为软件系统的主要（如果不是主要的话）文档。
协作
改善人与人之间的协作是敏捷思维的核心。沟通和反馈是极限编程的两个既定价值观，敏捷主义者希望找到方法在他们的项目中最大限度地利用这些价值观
不仅仅是站立：每日站立会议的模式
每日站立会议已成为许多团队的常见仪式，尤其是在敏捷软件开发中。然而，有许多微妙的细节区分了有效的站立会议和浪费时间。
关于结对编程
如今，许多从事软件开发工作的人都听说过结对编程的实践，但它在行业中的采用仍然参差不齐。它被接受程度不同的一个原因是，它的好处并不是立竿见影的，它在中长期内会带来更大的回报。而且它也不像“两个人在一台电脑上工作”那么简单，所以当它让人感到不舒服时，很多人会很快放弃它。然而，根据我们的经验，结对编程对于团队协作和高质量软件至关重要。
用户故事
用户故事是软件系统所需行为的块。它们广泛用于敏捷软件方法中，以便将大量功能划分为更小的部分以用于计划目的。您还会听到将相同的概念称为“功能”，但“故事”或“用户故事”一词如今在敏捷圈中很流行。
对话故事
关于敏捷方法，有一个常见的误解。它集中在用户故事的创建方式以及它们在开发活动中的流动方式。这种误解是，产品负责人（或业务分析师）创建用户故事，然后将它们交给开发人员去实现。这种概念是一种从产品负责人到开发人员的流程，产品负责人负责确定需要做什么，而开发人员负责如何去做。
频率降低难度
我最喜欢的一句妙语是：**如果它让你痛苦，就更频繁地去做它**。这句话表面上看起来毫无意义，但当你深入挖掘时，它却蕴含着一些有价值的意义。
指标的恰当使用
管理层喜欢他们的指标。他们的想法是这样的：“我们需要一个数字来衡量我们做得如何。数字可以让人们集中注意力，并帮助我们衡量成功。” 虽然出发点是好的，但数字管理会无意中导致问题行为，并最终损害更广泛的项目和组织目标。指标本身并不是坏事；只是经常被不恰当地使用。本文论证了管理层传统使用指标所造成的许多问题，并提供了一种替代方案来解决这些问题。
远程工作与集中办公
远程工作与集中办公之间并没有简单的二分法，相反，团队的分布模式有很多种，每一种模式都有不同的权衡和适合的有效技术。虽然不可能找到确凿的证据，但我认为大多数团队在集中办公的情况下工作效率更高。但是，您可以通过使用分布式工作模式来打造更高效的团队，因为它可以让您接触到更广泛的人才库。
在离岸开发中使用敏捷软件流程
在过去四年中，Thoughtworks 在印度班加罗尔设立了一个实验室，为我们在北美和欧洲的软件开发项目提供支持。传统的离岸开发方法基于计划驱动的方法论，但我们坚定地站在敏捷阵营。在这里，我讨论了我们在进行离岸敏捷开发方面的经验和教训。到目前为止，我们已经发现我们可以让它发挥作用，尽管其好处还有待商榷。（虽然本文最后一次更新是在 2006 年，但我们在 2011 年重新访问了我们的离岸工作，发现这些经验教训仍然适用，因此本文不需要进一步的重大修改。）
客户亲和力
当有人在研究是什么造就了一流的企业软件开发人员时，话题往往会转向对框架和语言的了解，或者可能是理解复杂算法和数据结构的能力。对我来说，程序员，或者说开发团队，最重要的特质之一，就是我所说的“客户亲和力”。这就是开发人员对软件所要解决的业务问题以及生活在该业务领域的人们的兴趣和密切程度。
问题
虽然敏捷思维可以帮助许多团队更有效地交付软件，但敏捷软件的世界远非没有问题。与任何流行的方法一样，语义扩散已经出现，导致许多事情以“敏捷”的名义进行，而这些事情与促使我们编写宣言的理念几乎毫无关系。
2018年敏捷软件现状
从表面上看，敏捷软件开发的世界是光明的，因为它现在已经成为主流。但现实令人担忧，因为所做的大部分事情都是伪敏捷，无视敏捷的价值观和原则。我们应该关注的三个主要挑战是：打击敏捷工业联合体及其将流程强加于团队的习惯，提高技术卓越的重要性，以及围绕产品（而不是项目）组织我们的团队。尽管存在这些问题，但社区最大的优势在于其学习和适应能力，能够解决我们宣言的最初作者们无法想象的问题。
语义扩散
我习惯于创造新词来描述我在软件开发中看到的事物。这在该领域的作家中是一种常见的习惯，因为软件开发仍然缺乏很多有用的行话。构建行话的问题之一是，术语很容易失去其含义，这一过程被称为语义扩散——这里又用了一个可能添加到我们行话中的新词。
敏捷强加
根据敏捷联盟现任董事会的说法，敏捷方法已经“跨过了鸿沟”，我认为这意味着它们正在变得更加普遍。虽然这有其优势，但也带来了问题。当一种方法论或设计方法成为时尚时，我们就会看到很多人在使用它或教授它，而他们关注的是时尚，而不是真正的细节。这会导致出现一些以敏捷的名义进行的事情，而这些事情与该运动创始人的原则截然相反。
软弱的 Scrum
我最近听说过很多项目都一团糟。事情是这样的
- 他们想使用敏捷流程，并选择了 Scrum
- 他们采用了 Scrum 的实践，甚至可能是原则
- 一段时间后，由于代码库一团糟，进展缓慢
功能痴迷
敏捷方法的一种常见做法，也许是占主导地位的做法，是为正在构建的软件开发一个功能列表（通常称为故事）。这些功能使用索引卡、工作队列、燃尽图、待办事项列表或您选择的任何工具进行跟踪。