敏捷方法已穩固地成為主流，但這種流行並非沒有問題。組織領導者抱怨他們沒有獲得預期的效益。本文提出一個流暢模型，將有助於您充分發揮敏捷理念。流暢性會經歷四個不同的區域，每個區域都有其自身的效益、所需的熟練度和關鍵指標。

在 90 年代對極端程式設計有過正面經驗後，我開始對類似的敏捷方法感到好奇，例如 Scrum、Crystal 和 DSDM。深入研究後，我提煉出這些新方法的共同特徵：偏好適應性規劃而非預測性規劃，並將人視為比所使用的流程更重要。隨著時間的推移，這些方法逐漸歸類於敏捷軟體開發（我也修改了這篇文章），但我仍然認為本文中的觀點是了解敏捷精髓的好方法。

這可能不是敏捷運動的開端，但宣言為這項運動取了一個名字，並帶來了最初的能量。十年後，它仍然捕捉到敏捷方法的精髓。

2001 年 2 月，一群十七人齊聚猶他州雪鳥鎮，討論輕量級方法的新風格。其中一項成果是創造了「敏捷」一詞，代表軟體開發中新一代的敏捷流程。我們還共同制定了一份敏捷軟體開發宣言，描述這些敏捷方法的價值觀和原則。吉姆·海史密斯和我為軟體開發雜誌撰寫了這篇文章，進一步說明宣言。

對於許多初次接觸極端程式設計的人來說，極端程式設計似乎要求軟體設計走向死亡。不僅許多設計活動被嘲笑為「大規模前期設計」，而且 UML、靈活架構甚至模式等設計技術都被淡化或直接忽略。事實上，極端程式設計涉及大量的設計，但它的設計方式與既定的軟體流程不同。極端程式設計以允許演化成為可行設計策略的實務，重新振興了演化設計的概念。它也為設計師帶來了新的挑戰和技能，因為設計師需要學習如何進行簡單的設計、如何使用重構來保持設計的簡潔，以及如何以演化的方式使用模式。

在過去十年中，我們開發並改進了許多技術，這些技術允許資料庫設計隨著應用程式開發而演化。這對於敏捷方法而言是一項非常重要的功能。這些技術依賴於將持續整合和自動重構應用於資料庫開發，以及 DBA 和應用程式開發人員之間的密切合作。這些技術適用於生產前和已發布的系統，適用於全新專案和舊有系統。

表面上，敏捷軟體開發的世界一片光明，因為它現在已成為主流。但現實令人擔憂，因為許多做法都是偽敏捷，無視敏捷的價值觀和原則。我們應該關注的三個主要挑戰是：對抗敏捷產業綜合體及其強加流程於團隊的習慣、提升技術卓越性的重要性，以及圍繞產品（而非專案）組織我們的團隊。儘管存在問題，但社群的強大之處在於其學習和適應能力，解決我們最初宣言作者無法想像的問題。

Ryan Lockard（敏捷崛起）邀請我加入 Rebecca Wirfs-Brock，在 Podcast 中討論敏捷專案的架構。Rebecca 開發了責任驅動設計，在我開始我的職業生涯時對我產生了很大的影響。我們討論了我們如何定義架構、測試對架構的影響、網域模型的角色、要準備什麼樣的文件，以及需要多少架構才能事先完成。

當組織採用敏捷思維時，企業架構並不會消失，但企業架構師的角色會改變。企業架構師不再做出選擇，而是幫助其他人做出正確的選擇，然後傳播這些資訊。企業架構師仍然需要形成願景，但接著需要在團隊之間建立橋樑，以建立學習社群。這些將允許團隊探索新的方法並相互學習，而企業架構師則是這種成長的合作夥伴。

在我們撰寫敏捷宣言10 年後，我們這些作者受邀參加敏捷 2011 年大會期間的一場特別活動，以慶祝這個紀念日。17 位作者中有 15 位出席，我們在公園長椅小組回答觀眾的提問和評論。我想我們都驚訝於再次見面的感覺有多好，以及我們多麼容易地回到舒適的合作和討論中。我們的討論包括撰寫宣言的一些背景，回顧過去十年我們滿意和不滿意的事情、敏捷的未來發展，以及敏捷與精實的關係。

遠距與共同工作並非簡單的二分法，而是有幾種團隊分配模式，每種模式都有不同的權衡和適合它們的有效技術。雖然無法確定確鑿的證據，但我認為大多數團隊以共同工作的方式工作會更有生產力。但是，你可以透過使用分散工作模式來建立一個更有生產力的團隊，因為它讓你能夠接觸到更廣泛的人才庫。

這是我在慕尼黑 2014 年 OOP 大會主題演講的第二部分，也是一個難以形容的演講。我通常喜歡用標題和摘要來描述演講的內容，但這場演講是一趟旅程，我不想告訴你我要去哪裡，而是希望你和我一起探索這片土地。我要說的是，它始於我對大多數敏捷軟體開發採用方式的最大問題，也就是使用者、分析師和程式設計師之間互動的本質。它繼續探討這些角色，提出關於程式設計師與使用者之間的關係、我們對他們的責任，以及最後我認為程式設計師需要面對的兩大挑戰。

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

為什麼我們需要假設軟體應該是柔軟且開放變更的方法。

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

持續整合是一種軟體開發實務，團隊中的每位成員至少每天將他們的變更合併到程式碼庫中，與同事的變更合併在一起。這些整合中的每一項都經過自動建置（包括測試）驗證，以盡快偵測整合錯誤。團隊發現，這種方法可以降低交付延遲的風險，減少整合的工作量，並啟用有助於建立健全程式碼庫的實務，以便快速增強新功能。

每日站立會議已成為許多團隊的常見儀式，特別是在敏捷軟體開發中。然而，許多細微的細節區分了有效的站立會議和浪費時間的會議。

SD Times 採訪敏捷宣言發表 10 週年

我在 2007 年 QCon 大會上與同事 Dan North 共同發表的重點演講。我們都認為開發人員與其客戶/使用者之間的鴻溝是軟體開發中最大的問題。（我們會稱之為鴻溝，但這個詞已經被過度使用了。）在這裡，我們討論這個鴻溝、它為何重要以及我們需要做些什麼來跨越它。我們特別主張，傳統的商業分析師中間人角色扮演著渡輪的角色，而我們真正需要的是一座橋樑，讓開發人員和他們的客戶能夠直接聯繫（而分析師可以建立和維護這座橋樑）。這是我的最愛聯合重點演講之一，因為我認為這個主題非常重要，而且 Dan 是如此激勵人心的共同演講者。

2001 年 2 月，十七位軟體專家齊聚猶他州雪鳥鎮，討論過去稱為輕量級方法的領域的發展。我們決定使用敏捷這個術語來描述這種新型的敏捷方法。我們還撰寫了敏捷軟體開發宣言，闡述了這些敏捷流程的價值觀和原則。我是這些自封的先驅之一，此後遇到許多關於這個小組的起源和敏捷聯盟隨後成立的問題。這是我的對這些事件的回憶。

在過去四年中，Thoughtworks 在印度班加羅爾經營一個實驗室，以支援我們在北美和歐洲的軟體開發專案。傳統的離岸開發方法基於計畫驅動的方法，但我們非常堅定地站在敏捷陣營。在這裡，我討論我們在進行離岸敏捷開發方面的經驗和教訓。到目前為止，我們發現我們可以讓它發揮作用，儘管其好處仍有待爭論。（儘管本文最後一次更新於 2006 年，但我於 2011 年拜訪了我們的離岸工作，發現這些教訓仍然相關，因此本文不需要進一步的重大修改。）

2001 年，我前往雪鳥參加導致宣言的會議時，吉姆採訪我，為他正在撰寫的書收集資料。這提供了我對極限程式設計和幾天後我們稱之為敏捷軟體開發的思考的快照。

隨著 XP 和其他敏捷方法越來越受歡迎，關於如何將 XP 擴充到 10-12 人團隊之外的問題開始浮現。2003 年 2 月中旬，在加拿大艾伯塔省班夫舉辦了一場專門討論這個主題的工作坊。在本文中，我們將報導肯·施瓦伯和馬丁·福勒以及其他領先從業者的主題演講。

重構已發展成一種眾所周知的技術，而且大多數軟體開發團隊至少聲稱定期進行重構。然而，許多團隊並未意識到重構可使用的不同工作流程，因此錯失了將重構有效納入其開發活動的機會。在這個簡報中，我探討了各種不同的工作流程。我希望這能鼓勵團隊將重構更深入地整合到其工作中，從而產生設計更好的程式碼庫，讓新增新功能變得更快速、更簡單。

在過去十年左右，重構已成為廣泛使用的技術，用於維持程式碼庫的高內部品質。然而，大多數團隊並未充分利用重構，因為他們不知道可以在其中使用重構的各種工作流程。在慕尼黑舉行的 OOP 2014 主題演講中，我探討了其中一些工作流程：例如，垃圾回收重構、理解重構和準備性重構。我也提醒大家，為什麼重構的常見理由會破壞你的最大努力。（這場演講也有作為 資訊卡片 的處理方式。）

敏捷崛起 播客一直對敏捷宣言的作者進行一系列的訪談。這是我在訪談中的輪次。我對雪鳥工作坊本身的記憶不多，但我能夠描述一些導致宣言的背景。

我最近前往澳洲參加澳洲敏捷會議，以下是零散的印象。

敏捷方法是否應該有認證計畫？

我看到關於敏捷專案最常見的問題之一是，他們如何處理交接給其他團隊。如果你有一個開發團隊離開並將支援交給支援團隊，當敏捷專案傾向於產生遠少於計畫驅動流程的文件時，他們如何應對？

根據敏捷聯盟的現任董事會，敏捷方法 「已經跨越鴻溝」，我認為這表示它們正變得更加廣泛。雖然這有其優點，但也帶來問題。隨著方法論或設計方法變得流行，我們會看到很多人使用或教授它，他們專注於流行，而不是真正的細節。這可能會導致以敏捷的名義完成的事情的報告，而這些事情與運動創始人的原則完全相反。

2001 年在猶他州雪鳥舉行的會議，決定使用「敏捷」一詞，並開始制定「敏捷軟體開發宣言」。

我正在考慮使用敏捷軟體開發，但應該改用精實軟體開發嗎？

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

C3 是克萊斯勒綜合補償專案的簡稱，這是克萊斯勒的一個薪資專案，後來以 極限編程 的「誕生專案」而聞名。

敏捷方法的共同元素之一是它們將程式設計提升為軟體開發中的核心角色，遠遠超過軟體工程社群通常所做的。其中一部分是將程式碼分類為軟體系統的主要文件，如果不是主要文件的話。

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

丹尼爾·特霍斯特-諾思最近在軟體工藝上的部落格文章引發了許多部落格討論（如果你有興趣，我會在下方總結）。其中有很多內容，但他的其中一個主題特別引起我的共鳴，因此有了這篇文章。

當有人在尋找構成頂尖企業軟體開發人員的要素時，對框架和語言的了解，或理解複雜演算法和資料結構的能力通常會成為話題。對我來說，程式設計人員或開發團隊最重要的特質之一是我稱之為客戶親和力的東西。這是開發人員對軟體所要解決的業務問題以及生活在該業務世界中的人們的興趣和親近感。

幾年前，我與一位客戶交談，他告訴我他不喜歡我們正在使用的敏捷方法：「在專案的這麼早期遇到這些困難感覺不對勁」。與他的反應相反，在我看來，這種早期的痛苦是敏捷或任何反覆開發程序的巨大好處之一。

極限程式設計 (XP) 是一種軟體開發方法，主要由肯特·貝克開發。XP 是最早的敏捷方法之一，事實上，XP 是 90 年代後期和 00 年代初期的主要敏捷方法，直到 Scrum 在 00 年代後期成為主流。許多人（包括我自己）認為 XP 是引起人們對敏捷方法關注的主要催化劑，並且作為開始敏捷開發的基礎，它優於 Scrum。

敏捷方法的常見做法（可能是主要做法）是為正在建置的軟體開發一個功能清單（通常稱為故事）。這些功能會透過索引卡、工作佇列、燃盡圖表、待處理事項或任何你選擇的工具來追蹤。

許多人相信你無法在敏捷專案中訂定固定價格合約。由於敏捷流程的重點在於你無法預測未來，這並非不合理的假設。然而，這並不表示你無法提出固定價格的敏捷合約，其真正的意思是你無法提出固定範圍的合約。

許多公司喜歡撰寫固定範圍和價格的合約，因為他們認為這樣可以降低風險。幻象表示他們的財務義務固定在合約價格。如果他們沒有獲得令人滿意的軟體，那麼他們就不會花錢。

最近我聽說許多專案發生問題。問題如下

• 他們想使用敏捷流程，並選擇 Scrum
• 他們採用 Scrum 做法，甚至可能是原則
• 過了一段時間後，進度緩慢，因為程式碼庫一團糟

我最喜歡的口號之一是：如果感到痛，就更常做。表面上看起來這句話似乎沒有道理，但深入探討後會發現一些有價值的意義

一般的開發人員可以使用敏捷方法嗎？

一個常見的問題是大型專案是否可以用敏捷技術來執行。畢竟，許多敏捷方法都是為較小的專案設計的，而他們所排斥的重量級想法在較大的專案中更為需要。

關於結對程式設計的一些常見迷思。

對於許多人來說，關於敏捷方法最難理解的事情之一就是敏捷的以人為本。那些對敏捷流程有興趣的人們都同意，流程是專案成功的次要影響。 敏捷宣言 的第一個價值觀是，個人和互動比流程和工具更有價值。

所有敏捷方法都強調系統開發人員與最終受益的客戶之間直接互動的重要性。敏捷宣言說：「業務人員和開發人員必須在整個專案中每天合作」，這強調了互動的高頻率。極限程式設計透過其現場客戶實務來強調這一點。

回顧主要指令是回顧實務中的重要部分，自從諾姆·科斯首次啟動實務以來，它一直是回顧思考的不可或缺的一部分。最近我讀了帕特·庫亞的新版回顧手冊，該手冊基於帕特在 Thoughtworks 擔任技術主管時所擁有的豐富回顧經驗。我發現帕特對主要指令的建議令人反感，但不得不說他幾乎肯定正確。

我經常遇到一個抱怨，即敏捷方法沒有嚴謹的定義。抱怨者可能會談論這意味著你無法判斷某個特定團隊是否正在使用敏捷方法。他們也可能會說，這使得很難教導人們如何執行敏捷方法 - 課程是什麼？

在某種程度上，我確實感受到了這種抱怨的痛苦 - 但我接受沒有治癒方法。這種缺乏嚴謹性是敏捷方法定義本質的一部分，也是其核心哲學的一部分。

對於第 n 次，而且我確定不是最後一次，我將展開一場關於定義實務、將其中一些標籤為「最佳」以及可能是 C 字（認證）的對話。這是一場熟悉的討論，儘管我們才剛開始，但我可以預測它將如何進行。它是由一個完全合理的渴望所推動，即找出誰是更好的軟體開發人員，以及現有的開發人員如何提升自己的能力。

自我測試程式碼是我在 重構 中用來指稱與功能性軟體結合撰寫全面自動化測試的實務。如果執行得當，這將允許您呼叫執行測試的單一指令，而且您有信心這些測試將找出隱藏在程式碼中的任何錯誤。

人們時不時會質疑某個特定專長是否能以漸進的方式使用：「你無法在敏捷專案中執行（安全性 | 使用者介面設計 | 資料庫 | 國際化 | * ），因為這個面向必須事先完成。」

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

時盒迭代是一種區分和安排專案工作的方式，特別與敏捷軟體專案相關。團隊將軟體的明顯功能分解為使用者故事，並將時間分解為固定期間（例如一週），稱為迭代。然後，他們透過將故事分配到迭代中來安排故事。故事會進行粗略估計，以便團隊可以找出有多少故事適合一個迭代。

使用者故事是軟體系統所需行為的區塊。它們廣泛用於敏捷軟體方法，將大量功能分為較小的部分以進行規劃。您也會聽到相同的概念稱為功能，但「故事」或「使用者故事」這個術語現已普遍用於敏捷圈中。