在 20 世纪 90 年代末，我个人开始反对在演示文稿中使用幻灯片，因为我已经厌倦了设计糟糕的项目符号演示文稿。大约十年来，我一直在做完全没有幻灯片的主题演讲。在过去一年左右的时间里，我又开始使用幻灯片了——这主要是因为我看到了我的同事 Neal Ford，他将可怕的幻灯片变成了他演讲的真正增强工具（并且正在合作编写一本 书籍项目 来传承他的技术）。在我重新开始使用幻灯片后，我也一直在思考是什么让一组幻灯片成为演讲的有效组成部分。我尝试遵循的主要原则是将它们视为一种视觉通道，以补充作为我口语的音频通道。我发现，以这种方式将它们视为独立的通道有助于我避免演示文稿中的常见问题——其中许多问题都源于常见的项目符号幻灯片。

持续集成 的拥护者普遍认为构建应该是可重现的。我们的意思是，在任何时候，您都应该能够获取正在处理的系统的某个旧版本，并以与当时完全相同的方式从源代码构建它。

由于我一直将幻灯片作为演讲中的视觉通道，因此我一直在使用图表动画来帮助传达我的观点。主要的演示文稿程序（Keynote 和 PowerPoint）长期以来一直支持动画，但我一直倾向于寻找更强大且更易于使用的动态图形工具。

我一直打算将我的笔记本电脑升级到雪豹。特别是在我买了 Aperture 3 之后，据说它运行得更好。但我从来没有抽出时间来做这件事，毕竟操作系统升级通常很麻烦。（尽管 Ubuntu 升级比大多数升级要轻松得多。）

2010 年在旧金山 QCon 大会上对 Jez Humble 和我的采访

支持 功能分支 的最常见论点之一是，它为需要超过一个发布周期的待定功能提供了一种机制。假设您每两周发布一次产品，但需要构建一个需要三个月才能完成的功能。您如何使用持续集成让每个人都在主线上工作，而不会在您的版本中泄露半成品功能？我们经常遇到这个问题，而功能标志是处理这个问题的便捷工具。

我最近去澳大利亚参加澳大利亚敏捷大会的一些零星印象。

上周，我参加了在奥兰多举行的 2010 年敏捷大会。20xx 年敏捷大会是美国主要的敏捷导向会议，其起源可以追溯到 极限编程大会 和 敏捷开发大会。我不是主要敏捷会议的常客，但我去年也去了。与其试图进行统一的描述，不如说是一些零星的印象。

在我的职业生涯中，我一直看到的一个稳定主题是软件开发的性质和重要性。几年前，一位潜在客户告诉我们的一位销售人员，“软件就像污水管道，我希望它能可靠地工作，我不想知道细节”。这就是尼古拉斯·卡尔在 《IT 不再重要》 中谈到的那种方法。相比之下，我们为许多企业做过工作，在这些企业中，IT 一直是其业务的明显战略推动力，使它们能够进入新市场或显着提高市场份额。那么，IT 是一种像污水管道一样的公用事业，还是一种战略资产？

您在敏捷项目中发现的一件常见的事情是，开发团队坐在一个开放式的团队工作室中。它在极限编程的早期就被提倡，并在第二版中被列为主要实践之一。敏捷主义者喜欢开放式的团队工作室，因为它可以促进团队成员之间进行大量非正式和深入的交流。

在 团队工作室 中，工作站的默认布局是一张中央桌子，每个人都围坐在桌子旁。然而，我的许多同事现在更喜欢 U 形工作台，开发人员坐在 U 形桌子中间。

我从没把自己当成果粉。iPad 推出后很久我才买，而且只是因为这是将我的数据套餐升级到 3G 的唯一途径。我用 Mac，但我也有一台 Ubuntu 台式机。但我确实有一台 iPad，我认为它是一款意义重大的产品。

在巴西敏捷大会上对 Paulo Caroli 和我的采访

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

和许多痴迷于摄影的人一样，我最近也入手了一台 佳能 S90 相机。它小到可以放进口袋，但拥有一些对严肃摄影有追求的人喜欢的东西：全手动控制、RAW 文件支持、良好的传感器和 f2 镜头。

我最近需要住在希思罗机场酒店，以便赶早班机。这样做的一大烦恼是从酒店到机场的交通不便。有很多酒店距离 1-3 号航站楼中心只有半英里，但要到达那里，您必须乘坐希思罗机场巴士服务。这不是一项糟糕的服务，但价格高得惊人：半英里的路程，单程 4 英镑。半英里很容易步行，所以我真的不愿意乘坐公共汽车，更不用说收费如此离谱的公共汽车了。幸运的是，还有另一种选择，尽管希思罗机场很难找到。

在过去的十五年左右的时间里，我做过很多主题演讲。我一直觉得这类演讲很尴尬。如果您在会议期间发表演讲，您会选择一个主题来谈论。您知道有多个主题，所以如果人们来听您的演讲，就意味着他们对您的主题有一定的兴趣。但如果是主题演讲，您面对的是整个会议的观众，所以我觉得我不能把我的演讲内容过于集中。我可能喜欢谈论建模时间事件的复杂性，但我认为这对广泛的受众来说太狭隘了。

软件工程方法与理论 (SEMAT) 是由 Ivar Jacobson、Bertrand Meyer 和 Richard Soley 发起的一项工作。其既定目标是“在坚实的理论、经过验证的原则和最佳实践的基础上重建软件工程”。和软件界许多名人一样，我也被邀请参加。到目前为止，我一直拒绝参加，我觉得有必要解释一下原因。

我们刚刚结束了在意大利 阿马尔菲海岸 为期一周的度假。对于那些正在考虑类似旅行的人，这里有一些零星的印象。

一种（由 Leonard Richardson 开发的）模型，将 REST 方法的主要元素分解为三个步骤。它们引入了资源、HTTP 动词和超媒体控件。

当我在讨论 版本控制工具 时，我说过这是一个不科学的观点集合。在我做这件事的时候，我意识到我可以通过做一项调查，在我的分析中添加一些虚假但令人着迷的数字。谷歌的电子表格让进行调查变得非常简单，所以我无法抗拒。

支持在软件中采用精益技术的一个论点是丰田的成功。那么，丰田 最近的质量问题 是否会破坏精益软件开发的理由？

我和我的同事敦促客户实现的目标之一是完全自动化的部署流程。自动化部署有助于减少软件“完成”到实现其价值之间出现的摩擦和延迟。Dave Farley 和 Jez Humble 正在完成一本关于这个主题的书——《持续交付》。它建立在与 持续集成 相关的许多理念之上，更多地是为了实现快速将软件投入生产并使其发挥作用的能力。他们关于蓝绿部署的部分引起了我的注意，因为它是一种未被充分利用的技术，所以我想在这里简要概述一下。

如果你花时间与软件开发人员谈论工具，那么我听到的最重要的话题之一就是版本控制工具。一旦你开始使用版本控制工具（任何称职的开发人员都会这样做），它们就会成为你生活中很重要的一部分。版本工具不仅对维护项目的歷史记录很重要，它们还是团队协作的基础。因此，我经常听到人们抱怨版本控制工具不好用，这并不奇怪。在我们最近的Thoughtworks 技术雷达中，我们提到了两种企业应该评估使用的版本控制工具：Subversion 和分布式版本控制系统 (DVCS)。在这里，我想对此进行扩展，总结我们在内部进行的关于版本控制工具的许多讨论。

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

一种由产品负责人或分析师编写故事并将其传递给开发人员构建的方法。我认为这是对敏捷思维的深刻误解，因此我更喜欢对话式故事。