我的演講影片

Neal Ford 和我在巴黎的 USI（2010 年）上發表了一場演講，探討敏捷方法為何有效（相對於如何有效）的一些面向。這深入探討了讓敏捷方法發揮成效的一些核心力量，而不是著重於技術。特別是，我們探討了溝通和回饋的角色，以及它們如何在敏捷環境中相互作用。

遺憾的是，影片似乎被截斷，在演講中段就結束了。我無法找出如何發布完整影片。

#

我在我們撰寫 敏捷宣言 十年後發表了這場演講。我說明了我們撰寫宣言的歷史背景，解釋我們自此經歷的 語意擴散 是其成功的必然結果，主張那些說他們不在乎敏捷方法的人通常是錯的，並強調我們看到敏捷思考中出現一些有趣新活動的兩個領域。

延伸閱讀

• 敏捷軟體開發宣言
• 敏捷指南

#

2014 年，人稱「務實主義者」的 Dave Thomas 對敏捷軟體世界的現況感到不滿，並表示 敏捷已死。在奧胡斯舉行的 goto 會議組織者長期以來一直積極探索敏捷風格，他們認為這是一個讓他和身為宣言作者之一的我，與一些長期使用和推廣敏捷方法的人齊聚一堂的好機會。

延伸閱讀

• Dave 的原始貼文
• 新方法論： 我探討敏捷思考本質的原始文章。

#

我被要求在 OSCON 上做一個 14 分鐘的主題演講，說明為什麼架構很重要。我決定最好的方法是從探討這個尷尬術語的含義開始，並以 Ralph Johnson 最喜歡的郵件清單文章為指導。一旦我完成這項工作，我就轉向探討它為什麼重要，方法是專注於設計耐力假說的經濟論點。

延伸閱讀

• 我之前在 2003 年為 IEEE Software 撰寫的專欄 中洗劫了 Ralph 關於架構含義的電子郵件。
• 設計耐力假說
• 若要深入探討「如何」這個問題，請觀看 Molly Dishman 和我共同發表的關於 敏捷和架構 的稍長演講。
• 關於 軟體設計經濟學 的稍深入演講
• 「架構」一詞來自於建築，但它是一個 不恰當的比喻。

#

我們越來越看到組織轉向以 業務能力 為中心的自主團隊。這有助於軟體開發具有應變能力，並專注於業務成果。但是，這對架構在團隊內部和整個組織中扮演什麼角色呢？

我們認為架構仍然很重要，但必須基於指導，而非命令和控制。在團隊內部和團隊之間培養這種思維需要在幾個領域進行工作

• 了解業務背景
• 優先考慮跨功能需求
• 制定一組架構原則
• 使用鼓勵對齊的實務，例如技術雷達
• 將決策記錄保留為產品的一部分

#

人們經常藉由指出對更精湛的工藝和品質的需求來證明軟體設計工作的合理性。我的觀點是，這種道德論證是錯誤的，我們應該專注於經濟學。隨著糟糕的設計決策的負擔拖慢我們的團隊，大多數軟體工作會隨著時間而變慢。注重設計可以減少甚至逆轉這種情況。

我發現技術債務的比喻是一種思考不良設計後果的好方法 - 我們是支付利息還是償還本金。有些人認為技術債務並非草率設計的結果，但我指出技術債務來自於各種原因，即使是最好的團隊也會產生一些債務。

延伸閱讀

• 高品質軟體值得其成本嗎？
• 設計耐力假說
• 技術債務
• 技術債務象限

#

在 2008 年的舊金山 QCon 大會上，Rebecca Parsons 和我發表了一場關於敏捷方法如何與企業架構群組合作的演講。目前，敏捷專案團隊與架構群組之間存在許多不信任和衝突。我們深入探討其原因，並探討這些群組可以如何合作。

#

我和 Thoughtworks 最資深的開發人員之一 Badri Janakiraman 討論 Rails 應用程式的架構。我們從六角形架構的概念以及資料庫在企業應用程式中的角色開始討論，特別是 Ruby on Rails 應用程式。這些原則影響了使用 Active Record 或資料對應器模式來組織與資料庫合作的決策。然後，我們繼續討論如何使用 Rails 等全端應用程式架構，並在將其視為平台或組件套件之間做出選擇。

延伸閱讀

• EAA 書籍的 P
• EAA 目錄的 P

#

軟體架構是一個定義不清的概念，它不適當地借用了建築產業的術語。我們認為架構是選擇系統最重要的屬性，重點在於那些難以改變的事物。架構是隨著系統成長而演變的事物，但只有透過努力和關注才能確保它受到照顧。我們可以透過結合最初的願景和持續的努力來做到這一點。

（達拉斯影片包含問答，總長 65 分鐘。）

#

持續交付現在正成為有效軟體交付組織的核心實務。此演講說明了它的運作原理、部署管線的角色、持續交付與持續部署的差異，以及一些重要的要素。它也涵蓋了持續交付的三個主要好處：降低部署風險、可信的進度和使用者回饋。

延伸閱讀

• 指南
• 書籍
• 定義
• 部署管線

#

軟體架構師的稱號有很多涵義，而且通常不是好的。開發人員認為他們是住在象牙塔裡、忘記如何撰寫程式碼的空談家。專案經理認為他們是追求技術目的不明確的計畫中追求完美的技術人員。然而，對於任何軟體專案的成功來說，架構至關重要，特別是目前對微服務架構的興趣。

我們認為，我們可以在沒有傳統架構角色的情況下支援良好的架構，並介紹技術以取得良好的設計和永續的應用程式。

#

關於微服務的 20 分鐘介紹性演講。我涵蓋了微服務的定義，將它與更單體的方法進行比較，並概述在部署微服務應用程式之前必須做對的重要事項。

延伸閱讀

• 指南 概觀，並連結到更多關於微服務的文章、書籍和影片
• 微服務的定義
• 微服務權衡
• 微服務先決條件

#

我的同事 Jim Webber 在企業整合中以輕量級且以業務為導向的方法建立了良好的聲譽。他也以健談且幽默風趣的演講者聞名。因此，我既緊張又興奮地與他同台在 2008 年 QCon 大會上發表演說。他準備了一場非常有趣的簡報，其中穿插了一些嚴肅的要點。然後，我們就開始進行，也許是受到演講前的啤酒幫助。我們討論了企業整合的歷史、那些自以為強大但其實只是肥胖的系統的成長、敏捷思考的角色、網路的影響（包括 Jim 關於網路發明原因的獨特理論），以及這如何導致游擊隊 SOA。

#

我成長於鐵器時代，當時新的伺服器必須以實體機器的方式訂購，但現在我們生活在雲端時代，新的伺服器可以在幾分鐘內依需求啟動。為了利用雲端時代的速度和靈活性，我們必須重新思考基礎設施的管理方式。

基礎設施即程式碼將基礎設施定義保留在可執行格式中，然後可以像任何其他程式碼人工製品一樣進行管理，並保留在版本控制中。這提供了更準確的文件，以及可以與應用程式程式碼一樣接受相同建置和測試規範的基礎設施。這使我們能夠擴展到更大的基礎設施設定，同時保持更高的程度一致性，降低變更風險，並使我們能夠快速支援新的需求。

延伸閱讀

• Bliki

#

我們在 2012 年 QCon London 的主題演講探討了資料在我們生活中扮演的角色（而且它所做的不只是變大而已）。我們首先探討資料世界如何改變：它的成長、變得更加分散且相互連結。然後我們轉向產業的回應：NoSQL 的興起、轉向服務整合、事件溯源的出現、雲端和新分析的影響，以及視覺化的更大作用。我們快速瀏覽資料現在如何使用，尤其是 Rebecca 特別強調開發中國家的資料。最後，我們考慮所有這些對我們作為軟體專業人員的個人責任意味著什麼。

延伸閱讀

• 資訊簡報

#

事件溯源是一種透過儲存描述更新事件，然後處理該事件來變更目前應用程式狀態來處理更新的方法。事件記錄接著會成為具有公信力的資訊儲存，讓您可以刪除任何應用程式狀態並從事件儲存中重建它們。這基本上是版本控制系統採取的方法。使用事件溯源在稽核、查詢歷史狀態、除錯和分發方面開啟了許多優勢。

延伸閱讀

• 文章我的 2005 年文章更詳細地說明了此技術

#

最近大家都在談論無模式資料庫，但幾乎總是會有模式。隱含的模式看起來很靈活，但通常更糟，因為它會讓人更難找出如何使用資料。當人們想要無模式時，他們通常需要的是變數狀態，這對於自訂欄位和非均勻資料結構很有用。

延伸閱讀

• 資訊簡報

#

「NoSQL」一詞的起源是 Twitter 聚會的標籤，但它們已成為對關係式資料庫二十年霸權最嚴峻的挑戰。由於它們名稱的偶然性，它們涵蓋的範圍很廣，沒有太多定義 - 但將它們中的許多歸類在 聚集導向資料庫 的標籤下是有用的。

NoSQL 資料庫引入了與一致性相關的問題，但值得記住的是，即使使用 ACID 交易，我們仍然經常必須在應用程式中管理並發更新。許多 NoSQL 資料庫支援分散式資料的能力進一步複雜化了一致性，導致 CAP 定理在一致性和可用性（以及回應時間）之間進行權衡。這種權衡從根本上來說是一個商業決策，而不是技術決策。

NoSQL 資料庫是現代資料需求的嚴肅選擇，但不是唯一的選擇。我們現在正處於 多語持久性 的時期，我們必須根據特定的資料存取需求來選擇資料儲存技術。

這是我的最熱門演講（原先的 Aarhus 影片有超過 75 萬次觀看次數）。

延伸閱讀

• 指南
• 書籍
• 定義

#

大多數 NoSQL 資料庫都強迫人們以不同於關係世界的方式思考一致性。聚集導向資料庫自然消除了關係系統中對交易的一些需求。資料庫交易並不能阻止我們處理並發更新中的問題。將分散式加入我們的資料會增加我們需要處理的一致性問題類型。CAP 定理主要關於分散式系統中一致性和可用性（實際上是延遲）之間的權衡 - 這種權衡主要是一個商業決策。

（這個演講是我 NoSQL 簡介演講 的一致性部分，並重複了該演講中的材料。）

延伸閱讀

• 書籍

#

軟體專業人員不能認為自己只是聽命行事，做金主要求我們做的事，我們有責任為我們的軟體如何影響我們的使用者和更廣泛的社會負責。即使我們認為自己沒有什麼好隱藏的，我們的隱私對於保護那些令人討厭的人是必要的，他們可以防止貪腐並讓社會進步。電子郵件轉移到線上服務導致電子郵件供應商的集中令人擔憂，這使得大規模監控我們重要的通訊形式變得更容易。即使看似無害的攔截也可能導致嚴重的問題，因為這些關於我們的資訊對公司來說是有價值的，即使對政府來說是無害的。

我們需要透過努力擴大電子郵件加密的使用來減少這些問題，這樣大規模監控的成本就會變得過高。這方面的挑戰主要是使用者體驗和軟體封裝的挑戰，而不是需要對密碼學有深入了解的事情。

（這場演講的前 12 分鐘是我「不只是寫程式的人」演講的濃縮版。）

延伸閱讀

• 隱私對我們所有人來說都很重要，因為它保護那些令人討厭的人，他們讓我們的社會保持自由。
• Tim Bray 在同一場會議上的演講

#

我成長於鐵器時代，當時新的伺服器必須以實體機器的方式訂購，但現在我們生活在雲端時代，新的伺服器可以在幾分鐘內依需求啟動。為了利用雲端時代的速度和靈活性，我們必須重新思考基礎設施的管理方式。

基礎設施即程式碼將基礎設施定義保留在可執行格式中，然後可以像任何其他程式碼人工製品一樣進行管理，並保留在版本控制中。這提供了更準確的文件，以及可以與應用程式程式碼一樣接受相同建置和測試規範的基礎設施。這使我們能夠擴展到更大的基礎設施設定，同時保持更高的程度一致性，降低變更風險，並使我們能夠快速支援新的需求。

延伸閱讀

• Bliki

#

事件溯源是一種透過儲存描述更新事件，然後處理該事件來變更目前應用程式狀態來處理更新的方法。事件記錄接著會成為具有公信力的資訊儲存，讓您可以刪除任何應用程式狀態並從事件儲存中重建它們。這基本上是版本控制系統採取的方法。使用事件溯源在稽核、查詢歷史狀態、除錯和分發方面開啟了許多優勢。

延伸閱讀

• 文章我的 2005 年文章更詳細地說明了此技術

#

非決定論測試是在基礎程式碼沒有任何變更的情況下，有時會通過、有時會失敗的測試。如果不加以處理，它們會讓你的整個測試套件變得毫無用處。你首先需要隔離它們，然後修復它們。常見原因包括缺乏測試隔離、非同步以及與遠端服務通訊

延伸閱讀

• 文章

#

人們經常藉由指出對更精湛的工藝和品質的需求來證明軟體設計工作的合理性。我的觀點是，這種道德論證是錯誤的，我們應該專注於經濟學。隨著糟糕的設計決策的負擔拖慢我們的團隊，大多數軟體工作會隨著時間而變慢。注重設計可以減少甚至逆轉這種情況。

我發現技術債務的比喻是一種思考不良設計後果的好方法 - 我們是支付利息還是償還本金。有些人認為技術債務並非草率設計的結果，但我指出技術債務來自於各種原因，即使是最好的團隊也會產生一些債務。

延伸閱讀

• 高品質軟體值得其成本嗎？
• 設計耐力假說
• 技術債務
• 技術債務象限

#

最近大家都在談論無模式資料庫，但幾乎總是會有模式。隱含的模式看起來很靈活，但通常更糟，因為它會讓人更難找出如何使用資料。當人們想要無模式時，他們通常需要的是變數狀態，這對於自訂欄位和非均勻資料結構很有用。

延伸閱讀

• 資訊簡報

#

重構是一種維持程式碼庫健全的重要技術。它通常在 測試驅動開發 的背景下進行說明，但在開發人員的工作流程中，重構可以應用在許多地方。特別重要的是以 機會主義 的方式使用它，以便在問題一出現時就能立即修復。定期重構的價值不在於對工藝的呼籲，而是出於商業原因，以確保有價值軟體的未來流動。

延伸閱讀

• 資訊簡報

#

大多數 NoSQL 資料庫都強迫人們以不同於關係世界的方式思考一致性。聚集導向資料庫自然消除了關係系統中對交易的一些需求。資料庫交易並不能阻止我們處理並發更新中的問題。將分散式加入我們的資料會增加我們需要處理的一致性問題類型。CAP 定理主要關於分散式系統中一致性和可用性（實際上是延遲）之間的權衡 - 這種權衡主要是一個商業決策。

（這個演講是我 NoSQL 簡介演講 的一致性部分，並重複了該演講中的材料。）

延伸閱讀

• 書籍

#

關於微服務的 20 分鐘介紹性演講。我涵蓋了微服務的定義，將它與更單體的方法進行比較，並概述在部署微服務應用程式之前必須做對的重要事項。

延伸閱讀

• 指南 概觀，並連結到更多關於微服務的文章、書籍和影片
• 微服務的定義
• 微服務權衡
• 微服務先決條件

#

自我們撰寫敏捷軟體開發宣言以來已超過十年，而敏捷迷因比我們預期的還要成功。但就像任何成功一樣，總是有語意擴散的危險。我試圖透過描述敏捷軟體開發的精髓來對抗這種疾病：偏好適應性規劃而非預測性規劃，並優先考慮人而非流程。

然後我描述了敏捷流暢度模型，我發現這是一個思考敏捷團隊如何變得熟練的有效方法，以及您在成為敏捷技術更熟練的使用者時通常會經歷的步驟。

延伸閱讀

• 新方法論：我對敏捷方法精髓的原始介紹
• 敏捷流暢度模型

#

持續交付現在正成為有效軟體交付組織的核心實務。此演講說明了它的運作原理、部署管線的角色、持續交付與持續部署的差異，以及一些重要的要素。它也涵蓋了持續交付的三個主要好處：降低部署風險、可信的進度和使用者回饋。

延伸閱讀

• 指南
• 書籍
• 定義
• 部署管線

#

這場演講很難描述。通常我會用標題和摘要來說明演講內容，但這場演講是一趟旅程，我不想告訴你我要去哪裡，而是希望你和我一起探索。我要說的是，這場演講的開頭是我對大多數敏捷軟體開發採用方式最大的問題，也就是使用者、分析師和程式設計師之間互動的本質。接著探討這些角色，提出程式設計師與使用者的關係、我們對他們的責任，以及最後我想程式設計師必須面對的兩大挑戰。

#

當人們談論敏捷方法時，他們通常會專注於產品和專案管理方面。透過提供小版本，並從每個版本中學習，團隊可以隨著我們了解使用者的需求而快速改變方向。這讓我們可以在不確定的環境中快速建置提供價值的軟體。

這種工作方式很有價值，但為了讓它發揮作用，我們需要一個支援快速變更的程式碼庫，不只針對其細節，也針對其整體架構。為了建置這樣的程式碼庫，我們需要幾項技術實務，這些實務支撐著敏捷流暢度模型的提供區域。

• 自測試程式碼讓我們在進行變更時能夠自信地偵測錯誤
• 重構讓我們可以在不引入錯誤的情況下快速變更程式碼
• 持續整合讓團隊的所有成員可以在不互相干擾的情況下進行變更
• YAGNI 讓軟體盡可能保持簡單，讓它更容易擴充

#

延伸閱讀

• 指南頁面
• 書籍

#

Thoughtworks 經常舉辦「季度技術簡報」 - 在我們設有辦公室的城市中舉辦的開放式社區演講。在多倫多的這場 QTB 中，Scott Shaw 和我談論如何建立 IT 和企業之間的新關係。它說明了我們為何認為應該解散 IT 部門。

#

在 2009 年倫敦 QCon 的演講中，我調查了 Thoughtworks 在 2006-2008 年間使用 Ruby 的情況，當時我們進行了 41 個專案。我的演講涵蓋了我們對 Ruby 的生產力、速度和可維護性的看法。我得出的結論是，Ruby 應該被視為一個認真的開發環境。

延伸閱讀

• 文章

#

我的同事 Zack Exley 和我談論 2008 年歐巴馬總統競選活動中使用的軟體。我發現特別有趣的一個面向是軟體如何協助競選活動的組織方式並與之互動。

延伸閱讀

• 文章

#

行動裝置仍比傳統網路佔較小的流量，但其佔有率正在成長，因此我們需要思考我們的策略，以開發有效的行動應用程式。我們討論思考產品願景、將使用者參與的風格區分為「前傾」、「後傾」和「俯視」風格，同時將其整合到跨媒體應用程式中。我們討論為何專注於價值比流量更重要，雷射和涵蓋所有基礎的平台策略，並認為 Android、iOS 和網路是三種可行的平台選擇。Giles 以我們與一家主要航空公司合作的案例研究作為結尾。

延伸閱讀

• 支援多個行動平台
• 選擇行動實作策略
• martinfowler.com 上關於行動裝置的其他文章

#

我們提供持續交付的一小時概述。主題包括持續交付的理由、部署管線、持續整合、DevOps 和部署策略。亮點是 Jez 將候選版本比喻為希臘神話中的英雄。

延伸閱讀

• 指南
• 書籍

#

人們談論將企業轉型為數位組織，這一切都很美好，但除非您有一個能做好工作的技術組織，否則這是不可能發生的。

Nicole Forsgren 進行了一項研究，將 IT 績效與組織績效相關聯，以及她的 DevOps 研究如何找出 IT 績效的三個重要指標：部署頻率、部署前置時間和平均復原時間。彩券的簡單範例說明了快速週期時間的貨幣價值。

我們觀察到高績效技術團隊的特性包括：使用持續傳遞、以業務為導向、技術領先，並在信任的氛圍中運作。要走得遠，你需要朝正確的方向前進，同時也要照顧好你的車輛。

#