我的演讲视频

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

遗憾的是，视频似乎被截断了，并在演讲中途结束。我一直无法弄清楚如何发布完整视频。

#

在我们撰写敏捷宣言十年后，我发表了这篇演讲。我阐述了我们撰写宣言的历史背景，解释了为什么我们从那时起经历的语义扩散是其成功的必然结果，并认为那些说他们不关心敏捷的人通常是错误的，并强调了我们在敏捷思维中看到一些有趣的新活动的两个领域。

延伸阅读

• 敏捷软件开发宣言
• 敏捷指南

#

2014 年，Dave "Pragmatic" Thomas 对敏捷软件世界的现状感到不满，他说敏捷已死。奥尔胡斯 goto 大会的主办方长期以来一直积极探索敏捷风格，他们认为这是一个很好的机会，可以将他和本人（作为宣言的两位作者）以及一些一直在接受敏捷方法并在该领域使用和扩展敏捷方法的人聚集在一起。

延伸阅读

• Dave 的原始帖子
• 新方法论：我的原创文章，探讨了敏捷思维的本质。

#

我被要求在 OSCON 大会上做一个 14 分钟的主题演讲，解释为什么架构很重要。我决定最好先从探索这个尴尬术语的含义开始，并以我最喜欢的 Ralph Johnson 的邮件列表帖子为指导。完成之后，我通过关注设计耐力假设的经济论证来解释为什么它很重要。

延伸阅读

• 我之前在2003 年为 IEEE 软件撰写的专栏中引用了 Ralph 关于架构含义的电子邮件。
• 设计耐力假设
• 要稍微了解一下“如何”做，请参阅 Molly Dishman 和我发表的关于敏捷与架构的稍长一些的演讲。
• 关于软件设计的经济学的更深入的演讲
• 架构一词来自建筑，但它是一个不恰当的比喻。

#

我们越来越多地看到组织转向以业务能力为中心的自主团队世界。这有助于软件开发快速响应并专注于业务成果。但这为团队内部和更广泛组织中的架构留下了什么角色？

我们认为架构仍然很重要，但必须基于指导而不是命令和控制。在团队内部和团队之间培养这种思维需要在以下几个方面开展工作

• 了解业务背景
• 优先考虑跨职能需求
• 制定一套架构原则
• 使用鼓励一致性的实践，例如技术雷达
• 将决策记录作为产品的一部分

#

人们经常通过指出对更高工艺和质量的需求来证明软件设计方面的努力是合理的。我的观点是，这种说教式的论点是错误的，我们应该关注经济效益。随着时间的推移，大多数软件工作都会放缓，因为糟糕的设计决策的负担会拖慢我们团队的速度。注重设计可以减少甚至逆转这种情况。

我发现技术债务的比喻是思考糟糕设计后果的好方法——我们是支付利息还是偿还本金。有些人认为技术债务不是草率设计的产物，但我指出技术债务有多种原因，即使是最好的团队也会产生一些技术债务。

延伸阅读

• 高质量软件物有所值吗？
• 设计耐力假设
• 技术债务
• 技术债务象限

#

在 2008 年旧金山 QCon 大会上，Rebecca Parsons 和我发表了一个关于敏捷方法如何与企业架构团队合作的演讲。目前，敏捷项目团队和架构团队之间存在很多不信任和冲突。我们深入探讨了为什么会这样，并探索了这些团队如何协同工作的方法。

#

我和 Thoughtworks 最资深的开发人员之一 Badri Janakiraman 之间关于 Rails 应用程序架构的讨论。我们首先讨论了六边形架构的概念以及数据库在企业应用程序（尤其是 Ruby on Rails 应用程序）中的作用。这些原则影响了使用 Active Record 还是 Data Mapper 模式来组织与数据库协作的决定。然后，我们继续讨论如何使用像 Rails 这样的全栈应用程序框架，并选择将其视为平台还是组件套件。

延伸阅读

• EAA 模式集
• EAA 模式目录

#

软件架构是一个定义不清的概念，它从建筑行业借用了不恰当的术语。我们将架构视为系统最重要属性的选择，重点关注那些难以更改的内容。架构是可以随着系统增长而演变的东西，但只有通过努力和关注才能确保它得到照顾。我们可以通过结合初始构想和持续努力来做到这一点。

（达拉斯视频包括问答环节，总共 65 分钟。）

#

持续交付现在正成为高效软件交付组织的核心实践。本演讲解释了它的工作原理、部署管道的作用、持续交付和持续部署之间的区别，以及一些重要因素。它还涵盖了持续交付的三个主要好处：降低部署风险、可信的进度和用户反馈。

延伸阅读

• 指南
• 书籍
• 定义
• 部署管道

#

“软件架构师”这个头衔带有很多含义，而且通常都不太好。开发人员认为他们是纸上谈兵的人，他们身处象牙塔，已经忘记了如何编写代码。项目经理认为他们是追求完美的技术人员，而这些完美主义的追求却服务于一些模糊的技术目的。然而，对于任何软件项目的成功来说，架构都是至关重要的，尤其是在当前人们对微服务架构兴趣浓厚的情况下。

我们认为，即使没有传统的架构师角色，我们也可以支持良好的架构，并引入一些技术来获得良好的设计和可持续的应用程序。

#

关于微服务的 20 分钟介绍性演讲。我将介绍微服务的定义，将其与更单一的架构方法进行比较，并概述在部署微服务应用程序之前必须做好的重要事项。

延伸阅读

• 《指南》概述以及更多关于微服务的文章、书籍和视频的链接
• 微服务的定义
• 微服务的权衡
• 微服务的先决条件

#

我的同事 Jim Webber 在企业集成方面采用轻量级和面向业务的方法，并因此享有盛誉。他还以其强健有力且引人入胜的演讲风格而闻名。因此，当我在 2008 年 QCon 大会上与他一起做主题演讲时，我既紧张又兴奋。他准备了一场妙趣横生的演讲，其中穿插着一些严肃的干货。然后我们就全身心地投入其中——可能是演讲前喝的那一品脱啤酒起了作用。我们谈到了企业集成的历史、那些自以为强大但实际上只是臃肿的系统的增长、敏捷思维的作用、网络的影响（包括 Jim 关于网络发明原因的独特理论），以及这些因素如何导致了游击式 SOA。

#

我成长于“铁器时代”，那时新服务器必须作为物理机器订购，但现在我们生活在“云时代”，新服务器可以在几分钟内按需启动。为了利用云时代的快速和灵活，我们必须重新思考如何管理基础设施。

基础设施即代码以可执行的形式保存基础设施定义，然后可以像管理任何其他代码工件一样管理这些定义，并将其保存在版本控制中。这提供了更准确的文档，并且基础设施可以像应用程序代码一样进行构建和测试。这使我们能够扩展到更大的基础设施配置，同时保持更高程度的一致性，降低变更风险，并使我们能够快速支持新需求。

延伸阅读

• Bliki

#

我们在 2012 年伦敦 QCon 大会上的主题演讲探讨了数据在我们生活中所扮演的角色（以及它不仅仅是越来越大）。我们首先来看看数据世界是如何变化的：它正在增长，变得更加分布式和互联。然后我们转向行业的反应：NoSQL 的兴起、服务集成的转变、事件溯源的出现、云的影响以及可视化发挥更大作用的新分析。我们快速浏览了数据目前的用途，Rebecca 特别强调了发展中国家的数据。最后，我们思考了所有这一切对我们作为软件专业人员的个人责任意味着什么。

延伸阅读

• Infodeck

#

事件溯源是一种处理更新的方法，它通过存储描述更新的事件，然后处理该事件来更改当前应用程序状态。然后，事件日志成为信息的权威存储，允许您删除任何应用程序状态并从事件存储中重建它们。本质上，这就是版本控制系统采用的方法。使用事件溯源在审计、查询历史状态、调试和分发方面开辟了几个优势。

延伸阅读

• 文章 我 2005 年的文章更详细地解释了这项技术

#

现在有很多关于无模式数据库的讨论，但几乎总是有一个模式。隐式模式看起来很灵活，但通常更糟糕，因为它使得弄清楚如何使用数据变得更加困难。当人们想要无模式时，他们通常需要的是可变状态，这对于自定义字段和非均匀数据结构很有用。

延伸阅读

• Infodeck

#

“NoSQL”一词的起源是 Twitter 聚会的标签，但它们变成了对关系数据库二十年霸权的最严峻挑战。由于其名称的偶然性，它们涵盖了范围很广的内容，而且没有太多定义——但将其中许多内容归入面向聚合的数据库的旗帜下是很有用的。

NoSQL 数据库引入了关于一致性的问题，但值得记住的是，即使使用 ACID 事务，我们仍然经常需要在应用程序中管理并发更新。许多 NoSQL 数据库支持分布式数据的能力进一步复杂化了一致性，导致 CAP 定理在一致性和可用性（以及响应时间）之间进行权衡。这种权衡从根本上说是一个业务决策，而不是技术决策。

NoSQL 数据库是满足现代数据需求的严肃选择，但不是唯一选择。我们现在正处于多语言持久化的时代，我们必须根据特定的数据访问需求选择数据存储技术。

这是我最受欢迎的演讲（原始的 goto 奥胡斯视频的观看次数超过 750,000 次）。

延伸阅读

• 指南
• 书籍
• 定义

#

大多数 NoSQL 数据库迫使人们以不同于关系世界的方式思考一致性。面向聚合的数据库自然地消除了对关系系统中事务的一些需求。数据库事务并不能阻止我们处理并发更新中的问题。向数据中添加分布式会增加我们需要处理的一致性问题的种类。CAP 定理主要是在分布式系统中一致性和可用性（实际上是延迟）之间的权衡——这种权衡主要是一个业务决策。

（本次演讲是我NoSQL 简介演讲中关于一致性的部分，并重复了该演讲中的内容。）

延伸阅读

• 书籍

#

软件专业人员不能认为自己仅仅是接受指令的人，只做资助者要求我们做的事情，我们有责任为我们的软件如何影响用户和更广泛的社会负责。即使我们认为自己没有什么可隐瞒的，我们的隐私对于保护那些防止腐败和促进社会进步的麻烦制造者也是必要的。电子邮件向在线服务的转移导致了电子邮件提供的集中化，这令人担忧，这使得对我们一种重要通信形式进行大规模监控变得更加容易。即使是看似无害的拦截也会导致严重的问题，因为这些关于我们的信息对企业来说是有价值的，即使对政府来说是无害的。

我们需要通过努力扩大电子邮件加密的使用来减少这些问题，这样大规模监控的成本就会变得令人望而却步。这方面的挑战主要是用户体验和软件打包方面的挑战，而不是需要对密码学有深入了解的挑战。

（本次演讲的前 12 分钟是我“不仅仅是代码猴子”演讲的压缩版。）

延伸阅读

• 隐私对我们所有人来说都很重要，因为它保护了那些让我们社会保持自由的麻烦制造者。
• Tim Bray 在同一次会议上的演讲

#

我成长于“铁器时代”，那时新服务器必须作为物理机器订购，但现在我们生活在“云时代”，新服务器可以在几分钟内按需启动。为了利用云时代的快速和灵活，我们必须重新思考如何管理基础设施。

基础设施即代码以可执行的形式保存基础设施定义，然后可以像管理任何其他代码工件一样管理这些定义，并将其保存在版本控制中。这提供了更准确的文档，并且基础设施可以像应用程序代码一样进行构建和测试。这使我们能够扩展到更大的基础设施配置，同时保持更高程度的一致性，降低变更风险，并使我们能够快速支持新需求。

延伸阅读

• Bliki

#

事件溯源是一种处理更新的方法，它通过存储描述更新的事件，然后处理该事件来更改当前应用程序状态。然后，事件日志成为信息的权威存储，允许您删除任何应用程序状态并从事件存储中重建它们。本质上，这就是版本控制系统采用的方法。使用事件溯源在审计、查询历史状态、调试和分发方面开辟了几个优势。

延伸阅读

• 文章 我 2005 年的文章更详细地解释了这项技术

#

非确定性测试是指有时通过、有时失败的测试，而底层代码没有任何变化。如果不加以处理，它们会使你的整个测试套件变得毫无用处。首先，你需要隔离它们，然后修复它们。常见的原因包括缺乏测试隔离、异步性和与远程服务的对话。

延伸阅读

• 文章

#

人们经常通过指出对更高工艺和质量的需求来证明软件设计方面的努力是合理的。我的观点是，这种说教式的论点是错误的，我们应该关注经济效益。随着时间的推移，大多数软件工作都会放缓，因为糟糕的设计决策的负担会拖慢我们团队的速度。注重设计可以减少甚至逆转这种情况。

我发现技术债务的比喻是思考糟糕设计后果的好方法——我们是支付利息还是偿还本金。有些人认为技术债务不是草率设计的产物，但我指出技术债务有多种原因，即使是最好的团队也会产生一些技术债务。

延伸阅读

• 高质量软件物有所值吗？
• 设计耐力假设
• 技术债务
• 技术债务象限

#

现在有很多关于无模式数据库的讨论，但几乎总是有一个模式。隐式模式看起来很灵活，但通常更糟糕，因为它使得弄清楚如何使用数据变得更加困难。当人们想要无模式时，他们通常需要的是可变状态，这对于自定义字段和非均匀数据结构很有用。

延伸阅读

• Infodeck

#

重构是保持代码库健康的重要技术。它通常在测试驱动开发的上下文中被描述，但在开发人员的工作流程中，有许多地方可以使用重构。特别重要的是随机应变地使用它，以便问题一出现就能得到解决。定期重构的价值不在于某种对工艺的追求，而是出于商业原因，以确保未来有价值的软件的流动。

延伸阅读

• Infodeck

#

大多数 NoSQL 数据库迫使人们以不同于关系世界的方式思考一致性。面向聚合的数据库自然地消除了对关系系统中事务的一些需求。数据库事务并不能阻止我们处理并发更新中的问题。向数据中添加分布式会增加我们需要处理的一致性问题的种类。CAP 定理主要是在分布式系统中一致性和可用性（实际上是延迟）之间的权衡——这种权衡主要是一个业务决策。

（本次演讲是我NoSQL 简介演讲中关于一致性的部分，并重复了该演讲中的内容。）

延伸阅读

• 书籍

#

关于微服务的 20 分钟介绍性演讲。我将介绍微服务的定义，将其与更单一的架构方法进行比较，并概述在部署微服务应用程序之前必须做好的重要事项。

延伸阅读

• 《指南》概述以及更多关于微服务的文章、书籍和视频的链接
• 微服务的定义
• 微服务的权衡
• 微服务的先决条件

#

自从我们撰写敏捷软件开发宣言以来，已经过去了十多年，敏捷模因的成功超出了我们的预期。但与任何成功一样，语义扩散的危险也一直存在。我试图通过描述敏捷软件开发的本质来对抗这种疾病：更倾向于适应性计划而不是预测性计划，更重视人而不是流程。

然后，我将描述敏捷流畅度模型，我发现这是一种思考敏捷团队如何变得精通以及您在成为敏捷技术的更熟练用户时通常会经历的步骤的有效方法。

延伸阅读

• 新方法论：我对敏捷方法本质的最初介绍
• 敏捷流畅度模型

#

持续交付现在正成为高效软件交付组织的核心实践。本演讲解释了它的工作原理、部署管道的作用、持续交付和持续部署之间的区别，以及一些重要因素。它还涵盖了持续交付的三个主要好处：降低部署风险、可信的进度和用户反馈。

延伸阅读

• 指南
• 书籍
• 定义
• 部署管道

#

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

#

当人们谈论敏捷方法时，他们通常关注的是产品和项目管理方面的事情。交付小版本，从每个版本中学习，使团队能够在我们了解用户需求时快速改变方向。这使得我们能够在不确定的环境中快速构建提供价值的软件。

这种工作方式有很多价值，但要使其发挥作用，我们需要一个支持快速变化的代码库，不仅要改变其细节，还要改变其整体架构。为了构建这样的代码库，我们需要几种技术实践，这些实践支撑着敏捷流畅度模型的交付区域。

• 自测试代码允许我们在进行更改时自信地检测故障。
• 重构允许我们在不引入错误的情况下快速更改代码。
• 持续集成允许团队的所有成员进行更改，而不会相互干扰。
• YAGNI，保持软件尽可能简单，使其更容易扩展。

#

延伸阅读

• 指南页面
• 书籍

#

Thoughtworks 经常组织“季度技术简报”——在我们设有办事处的城市为社区举办的公开演讲。在多伦多举行的这次季度技术简报中，Scott Shaw 和我谈论了如何建立 IT 和业务之间的新关系。它解释了为什么我们认为应该解散 IT 部门。

#

为了在 2009 年伦敦 QCon 大会上发表演讲，我调查了 Thoughtworks 在 2006 年至 2008 年期间对 Ruby 的使用情况，在此期间我们完成了 41 个项目。我的演讲涵盖了我们对 Ruby 的生产力、速度和可维护性的看法。我的结论是，Ruby 应该被认真对待，将其视为一个开发环境。

延伸阅读

• 文章

#

我的同事 Zack Exley 和我谈论了 2008 年奥巴马总统竞选活动中使用的软件。我发现特别有趣的一点是，软件如何支持和互动竞选活动的组织方式。

延伸阅读

• 文章

#

移动设备在流量中所占的比例仍然小于传统网络，但其份额正在增长，因此我们需要考虑制定有效的移动应用程序开发战略。我们讨论了产品愿景，将用户参与风格分为“前倾”、“后仰”和“低头”三种风格；同时将它们整合到一个跨媒体应用程序中。我们谈论了为什么关注价值比关注流量更重要，激光和覆盖所有平台的平台战略，并认为 Android、iOS 和 Web 是三个可行的平台选择。Giles 最后以我们与一家大型航空公司的合作案例研究结束了演讲。

延伸阅读

• 支持多个移动平台
• 选择移动实施战略
• martinfowler.com 上关于移动设备的其他文章

#

我们对持续交付进行了长达一小时的概述。主题包括持续交付的理由、部署管道、持续集成、DevOps 和部署策略。最精彩的部分是 Jez 将候选版本拟人化为希腊神话中的英雄。

延伸阅读

• 指南
• 书籍

#

人们都在谈论将企业转型为数字化组织，这固然很好，但如果没有一个能够出色完成工作的技术组织，这一切都是不可能实现的。

Nicole Forsgren 做了一项研究，将 IT 绩效与组织绩效相关联，以及她的 DevOps 研究如何确定了 IT 绩效的三个重要指标：部署频率、部署交付周期和平均恢复时间。彩票的简单例子说明了快速周期时间的货币价值。

我们观察到的高绩效技术团队的特征包括：使用持续交付、以业务为导向的组织、技术领先，以及在信任的氛围中运作。要想走得更远，你需要朝着正确的方向前进，但也要照顾好你的交通工具。

#