在20世纪90年代末，我个人反对在演示中使用幻灯片，因为我厌倦了设计糟糕的项目符号演示。在大约10年的时间里，我做主题演讲时根本没有幻灯片。在去年左右的时间里，我又开始使用幻灯片了——主要是受到了我同事的启发尼尔·福特谁把可怕的幻灯片变成了他演讲的真正亮点(并且正在合作一个本项目为了传递他的技术)。当我再次使用幻灯片时，我也一直在思考是什么让一组幻灯片成为演讲中有效的一部分。我试图遵循的主要原则是把它们看作是一个视觉渠道，补充我所说的话的音频渠道。我发现，用这种方式把它们看作不同的渠道，可以帮助我避免演示中常见的问题——其中许多问题都源于常见的项目符号幻灯片。

其中一个流行的假设，粉丝持续集成构建应该是可复制的。通过这一点，我们的意思是在任何时候，您都应该能够使用您正在使用的系统的一些旧版本，并以与您当时完全相同的方式从源代码构建它。

当我在演讲中再次使用幻灯片作为视觉渠道时，我一直在使用动画和图表来帮助传达我的观点。主要的演示程序(Keynote和Powerpoint)长期以来都支持动画，但我一直倾向于寻找功能更强大、更容易使用的动态图形工具。

我一直想把我的笔记本电脑升级到雪豹。特别是有一次我买了Aperture 3，据说效果更好。但我一直没有时间去做，毕竟操作系统升级通常是一件很痛苦的事情。(虽然Ubuntu升级比大多数升级要轻松得多。)

2010年，我和Jez Humble在旧金山QCon上接受了采访

的最常见的论据之一FeatureBranch它提供了一种机制来处理那些需要比单个发布周期更长的未决特性。想象一下，你每两周就要发布一次产品，但是需要构建一个需要三个月才能完成的特性。你如何使用持续集成让每个人都在主线上工作，而不会在你的版本中透露一个实现了一半的特性?我们经常遇到这个问题，而功能切换是解决这个问题的一个方便工具。

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

上周我参加了Agile 2010奥兰多会议。Agile 20xx是美国主要的面向敏捷的会议，其根源可以追溯到XP的宇宙和敏捷开发会议．我不是主要敏捷会议的常客，但去年我也去了。这里不打算做一个统一的描述，而是给出一些零散的印象。

在我的职业生涯中，我看到的一个稳定的主题是软件开发的性质和重要性。华体会登录网址几年前，一位潜在客户对我们的一位销售人员说:“软件就像下水道，我希望它可靠地工作，但我不想知道细节。”这就是尼古拉斯·卡尔在IT不重要．与此相反，我们为许多企业做过工作，在这些企业中，IT已成为其业务的更明确的战略推动者，允许他们进入新市场或显著增加其市场份额。那么，IT是像下水道一样的公用事业，还是战略资产?

在敏捷项目中，一个常见的现象是开发团队坐在一个开放的团队房间里。它在极限编程的早期就被提倡，并在第二版中被称为主要实践之一。敏捷主义者喜欢开放的团队空间，因为它促进了团队成员之间非正式和深入的交流。

中的工作站的默认布局团队空间是一张中央办公桌，所有人都围坐在桌子周围。然而，我的一些同事现在更喜欢U -pod，开发人员处于U型表格的中间。

我不认为自己是粉丝。iPhone上市后很长一段时间我都没有买，只买了一部，因为这是唯一能把我的数据套餐升级到3G的办法。我用的是mac电脑，但我也有一个Ubuntu桌面。但我已经有了iPad，我认为这是一个重要的产品。

在Agile Brazil对Paulo Caroli和我的采访

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

像许多沉迷于抓拍的人一样，我最近得到了佳能S90相机。它小到可以装进你的口袋，但有那些自命严肃的人喜欢的东西:全手动控制，RAW文件支持，良好的传感器和f2镜头。

在过去15年左右的时间里，我做过很多主题演讲。我一直觉得这类谈话相当尴尬。如果你在一个会议上做一个演讲，你会选择一个主题来谈论。你知道有多个轨道，所以如果人们来听你的演讲，那就意味着他们对你的话题有一定的兴趣。但你的主题演讲是针对整个会议的，所以我觉得我的演讲不能太集中。我可能喜欢谈论建模时间事件的复杂性，但我觉得对于广泛的观众来说，这个话题太狭隘了

胡萝卜(软件工程方法和理论)是由Ivar Jacobson、Bertrand Meyer和Richard Soley发起的一项努力。它宣称的目标是“基于坚实的理论、经过验证的原则和最佳实践，重新发现软件工程”。和软件界许多臭名昭著的人一样，我也受邀参加。到目前为止，我一直拒绝，觉得有必要解释一下原因。

我们刚从一个星期的假期回来阿玛海岸的意大利。对于那些正在考虑类似旅行的人来说，这里有一些零散的印象。

一个模型(由Leonard Richardson开发)，它将REST方法的主要元素分解为三个步骤。它们介绍了资源、http动词和超媒体控件。

当我讨论VersionControlTools我说过，这是一种不科学的观点聚合。当我这样做的时候，我意识到我可以通过做一个调查来为我的分析添加一些虚假但迷人的数字。谷歌的电子表格使得进行调查的机制非常简单，所以我无法抗拒。

支持在软件中采用精益技术的论据之一是丰田的成功。丰田也是如此最近的质量问题破坏精益软件开发的案例?华体会登录网址

我的同事和我敦促客户实现的目标之一是完全自动化的部署过程。自动化部署有助于减少在“完成”软件和实现其价值之间出现的摩擦和延迟。Dave Farley和Jez Humble即将完成一本关于这个主题的书持续交付．它建立在许多通常与持续集成，推动这种快速将软件投入生产并让它做一些事情的能力。他们关于蓝绿部署的部分引起了我的注意，因为这是一种未被充分利用的技术，所以我想在这里简要介绍一下。

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

这里有一个关于敏捷方法的常见误解。它集中于用户故事的创建方式和贯穿开发活动的流程。误解是产品所有者(或业务分析师)创建用户故事，然后将它们交给开发人员实现。这个概念是一个从产品负责人到开发人员的流程，由产品负责人负责决定什么需要做的和开发人员如何去做它。