在 1990 年代末期，我個人開始反對在簡報中使用投影片，因為我厭倦了設計不良的重點條列簡報。大約十年來，我在演講中完全不使用投影片。在過去的一年左右，我開始再次使用投影片，主要是受到同事 Neal Ford 的啟發，他將令人聞之色變的投影片組變成他演講的真正加分項目（並正在合作撰寫一本 書籍專案 以傳授他的技巧）。當我再次使用投影片時，我也一直在思考如何讓一組投影片成為演講中有效的部分。我試著遵循的主要原則是將它們視為視覺頻道，補充我的口語頻道。我發現以這種方式將它們視為獨立的頻道，有助於我避免簡報中常見的問題，其中許多問題根源於常見的重點條列投影片。

持續整合 愛好者普遍認為的假設之一，就是建置應該是可重製的。我們的用意是，在任何時間點，你都應該能夠採用你正在處理的系統的某個較舊版本，並以與當時完全相同的方式從原始碼建置它。

由於我在演講中再次使用投影片作為視覺頻道，因此我利用動畫搭配圖表來協助傳達我的觀點。主要的簡報程式（Keynote 和 Powerpoint）長期以來都支援動畫，但我傾向尋找更強大且更易於使用的動態圖形工具。

我打算將我的筆電升級到 Snow Leopard 已經很久了。特別是在我取得 Aperture 3 之後，據說它運作得更好。但我一直沒有這麼做，畢竟作業系統升級通常都很麻煩。（儘管 Ubuntu 升級比大多數升級都容易得多。）

2010 年在舊金山舉辦的 QCon，我和 Jez Humble 的訪談

支持 功能分支 最常見的論點之一，是它提供了一種機制，用於處理需要比單一發行週期更長的時間才能完成的功能。想像一下，你每兩週發布一次產品，但需要建構一個需要三個月才能完成的功能。你如何使用持續整合，讓所有人都在主線上工作，同時在你的發布中不顯示半實作的功能？我們經常遇到這個問題，而功能標記是一個處理它的便利工具。

最近前往澳洲參加澳洲敏捷開發研討會，以下是我的一些零散印象。

上週我參加了在奧蘭多舉辦的 Agile 2010 研討會。Agile 20xx 是美國主要的敏捷導向研討會，其根源可追溯到 XP Universe 和 敏捷開發研討會。我並不是主要敏捷研討會的常客，但我去年也去了。這裡有一些零散的印象，而不是嘗試做一個綜合的描述。

在我整個職業生涯中，我看到的一個穩定的主題是軟體開發的性質和重要性。幾年前，一位潛在客戶告訴我們的業務員：「軟體就像下水道管，我希望它能可靠地工作，而且我不想知道細節」。這正是 Nicholas Carr 在 IT Doesn't Matter 中所討論的方法。相反地，我們為許多企業做了工作，在這些企業中，IT 已成為更明確的策略性推手，讓它們能夠進入新市場或大幅增加其市場佔有率。那麼 IT 是像下水道管一樣的實用工具，還是策略性資產？

在敏捷專案中常見的一件事是，開發團隊坐在一個單一的開放式團隊室中。這在極限編程中很早就被提倡，並在第二版中被稱為主要實務之一。敏捷主義者支持開放式團隊室，因為它促進了團隊成員之間的大量非正式且深入的溝通。

在 團隊室 中，工作站的預設配置是中央辦公桌，所有人圍繞著它就坐。然而，現在許多同事比較喜歡 U 型工作區，開發人員坐在 U 形桌子的中間。

我從不認為自己是 iFanboy。在 iPhone 問世後很長一段時間，我仍沒有入手，直到後來因為這是升級我的數據方案至 3G 的唯一方式，我才入手。我使用 Mac，但我也有一台 Ubuntu 桌上型電腦。不過我確實有一台 iPad，而且我認為這是一款重要的產品。

我在敏捷巴西與 Paulo Caroli 的訪談

Neal Ford 和我在巴黎的 USI（2010 年）針對敏捷運作的原因（而非如何運作）發表了一場演講。這探討了讓敏捷發揮效用的核心力量，而不是探討技術。我們特別探討了溝通和回饋的角色，以及它們如何在敏捷環境中相互作用。

就像許多沉迷拍照的人一樣，我最近入手了 Canon S90 相機。它小到可以放進你的口袋，但卻具備自認嚴肅的人會喜歡的功能：全手動控制、RAW 檔案支援、良好的感測器和 f2 鏡頭。

我最近需要入住希斯洛機場飯店，以便趕早班飛機。這麼做的最大困擾是從飯店到機場的交通不便。有許多飯店距離 1-3 航廈中心僅半英里，但要前往這些飯店，你必須使用希斯洛 Hoppa 巴士服務。這項服務不差，但費用令人咋舌：半英里路程，單趟 4 英鎊。半英里路程很容易步行，所以我真的不願意搭乘巴士，更何況它收取如此荒謬的費用。幸運的是，還有另一種選擇，儘管希斯洛機場讓它很難找到。

在過去大約十五年來，我做了許多主題演講。我總是覺得這類型的演講有點尷尬。如果你在會議的某個場次中演講，你會挑選一個主題來談。你知道有多個場次，所以如果人們來聽你的演講，這表示他們對你的主題有一定程度的興趣。但是對於主題演講，你對著整個會議演講，所以我覺得我不能讓我的演講太過於專注。我可能喜歡談論時間事件建模的複雜性，但我覺得這對廣泛的聽眾來說是一個太過狹隘的主題

SEMAT（軟體工程方法與理論）是由 Ivar Jacobson、Bertrand Meyer 和 Richard Soley 發起的計畫。其聲明的目標是「根據穩固的理論、已驗證的原則和最佳實務，重新建立軟體工程」。像軟體界許多聲名狼藉的人，我受邀參與。到目前為止，我拒絕了，並覺得有必要解釋原因。

我們剛從義大利的阿瑪菲海岸度完一週的假。對於考慮類似行程的人，以下是幾個零散的印象。

一個模型（由 Leonard Richardson 開發），將 REST 方法的主要元素分解成三個步驟。這些步驟引入了資源、http 動詞和超媒體控制。

當我討論版本控制工具時，我說那是一個不科學的意見彙整。在我這樣做的時候，我意識到我可以透過進行調查，為我的分析增加一些虛假但令人著迷的數字。Google 的試算表讓執行調查的機制變得非常簡單，所以我無法抗拒。

用於支持在軟體中採用精實技術的論點之一是豐田的成功。因此，豐田的最近品質瑕疵會破壞精實軟體開發的論點嗎？

我和同事們敦促客戶達成的目標之一是完全自動化的部署程序。自動化部署有助於減少在軟體「完成」與實現其價值之間出現的摩擦和延遲。Dave Farley 和 Jez Humble 正在完成一本關於此主題的書 - 持續交付。它建立在通常與持續整合相關聯的許多概念之上，更朝向快速將軟體投入生產並使其執行某些動作的能力邁進。他們關於藍綠部署的部分引起了我的注意，因為這是一種未被充分利用的技術，所以我認為我可以在這裡簡要概述一下。

如果您花時間與軟體開發人員討論工具，我聽到的最大主題之一是版本控制工具。一旦您開始使用版本控制工具，任何稱職的開發人員都會使用，它們就會成為您生活中很重要的一部分。版本工具不僅對於維護專案的歷史記錄很重要，它們也是團隊合作的基礎。因此，我經常聽到關於版本控制工具不佳的抱怨也就不足為奇了。在我們最近的Thoughtworks 技術雷達中，我們列出了兩項企業應該評估使用的版本控制工具：Subversion 和分散式版本控制系統 (DVCS)。在這裡，我想進一步說明這一點，總結我們在內部關於版本控制工具進行的許多討論。

以下是關於敏捷方法的一個常見誤解。它集中在使用者故事的建立方式以及在開發活動中流動的方式。誤解在於產品負責人（或業務分析師）建立使用者故事，然後將它們放在開發人員面前實作。這個概念是從產品負責人到開發的流程，產品負責人負責決定需要完成什麼，而開發人員則負責如何完成。

一種由產品擁有者或分析師撰寫故事，並傳遞給開發人員建置的方法。我認為這對敏捷思考有深刻的誤解，因此更偏好 ConversationalStories。