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

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

隨著 XP 和其他敏捷方法越來越受歡迎，如何將 XP 擴展到 10-12 人以上的團隊開始浮現。2003 年 2 月中旬，一場專門探討此主題的工作坊在加拿大艾伯塔省班夫舉行。在本文中，我們將報導 Ken Schwaber 和 Martin Fowler 的主題演講，以及其他領先從業人員的演講。

我小時候很討厭胡蘿蔔，討厭它的氣味和質地。但是離家自己煮飯後，我開始喜歡它了。胡蘿蔔本身沒有改變，我的味蕾也沒有徹底改變，差別在於烹飪方式。我母親和其他許多那個世代的英國人一樣，廚藝不佳，尤其是蔬菜。她的做法是將胡蘿蔔煮二十分鐘以上。後來我才知道，只要烹飪得當，胡蘿蔔會帶來截然不同的體驗。

這裡不是烹飪網站，而是軟體開發網站。但我發現，技術或工具通常就像可憐的胡蘿蔔，被指責很糟糕，但實際問題在於技術使用不當。

當人們使用「軟體架構師」這個術語時，他們使用建築施工的比喻來幫助人們理解架構師的角色。諷刺的是，他們這樣做時誤解了建築架構師的實際角色。

我遇到過各種程式碼擁有權制度。我將它們分為三大類

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

設計出色的軟體是否值得付出努力？

兩種 軟體開發態度 之一。指導態度認為，由於大多數開發人員並非如此優秀（據傳聞，近 50% 的開發人員低於平均水準），因此我們需要指導他們執行任務的方式。這種指導旨在防止他們對其正在開發的系統造成損害。通常，這種態度會表現在設計和工具中，這些設計和工具可防止開發人員執行特定任務，限制他們可以執行的任務，以使他們遠離複雜的領域。

兩種 軟體開發態度 之一。啟用態度認為，開發人員是負責任的專業人士，因此應賦予他們執行任何必要任務的自由。遵循這種態度的設計應易於使用，但應假設開發人員知道自己在做什麼，因此不會努力防止某項功能遭到濫用。因此，這些工具可能會遭到濫用，但採取的態度是使用者應更加明智，如果他們沒有，他們應得的後果就是如此。

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

我最喜歡的廣告詞之一是：如果感到疼痛，請更頻繁地執行。它表面上看起來很荒謬，但深入探討後會產生一些有價值的意義

成熟度模型是一種工具，可以幫助人們評估個人或團體目前的效能，並協助找出他們需要進一步獲得哪些能力才能提升績效。在許多圈子裡，成熟度模型聲名狼藉，但儘管它們很容易被濫用，但在適當的人手中，它們還是很有幫助的。

我的作品的常客可能知道，我非常懷疑使用其他專業領域的隱喻來推論軟體開發。特別是，我相信工程隱喻對我們的專業造成了損害，因為它鼓勵了將設計與建構分開的概念。

當我在倫敦辦公室閒晃時，這個問題出現在精實製造的脈絡中，這是一個在敏捷圈子中經常使用的隱喻，特別是Poppendiecks。如果我不喜歡土木工程的隱喻式推理，我是否更喜歡精實製造的隱喻式推理？

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

當人們想到程式碼檢閱時，他們通常會想到開發團隊工作流程中的明確步驟。如今，在Pull Request上進行的整合前檢閱是最常見的程式碼檢閱機制，以至於許多人愚蠢地認為不使用 Pull Request 會消除所有進行程式碼檢閱的機會。如此狹隘的程式碼檢閱觀點不僅忽視了許多明確的檢閱機制，更重要的是忽視了可能是最強大的程式碼檢閱技術，也就是整個團隊進行的持續精煉。

你坐在會議中，思考著你的團隊過去幾年來一直在編寫的程式碼。你決定現在能做的最好的事情就是丟棄所有這些程式碼，並在全新的架構上重新建構。這讓你對那些注定失敗的程式碼、你花在上面工作時間，以及你當時所做的決定，有什麼感覺？

對於第 n 次，而且我確定不是最後一次，我開始談論定義實務、將其中一些標籤為「最佳」，以及可能是 C 字開頭的字（認證）。這是一個熟悉的討論，儘管我們才剛開始，但我可以預測它會如何發展。這是一個完全合理的願望，驅使我們找出誰是更好的軟體開發人員，以及現有的開發人員如何提升他們的技能。

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

Shu-Ha-Ri 是一種思考如何學習技術的方式。這個名稱來自日本武術（特別是合氣道），Alistair Cockburn 將其引入作為思考軟體開發技術和方法論的一種方式。

在我的職業生涯中，人們將軟體開發與「傳統」工程進行比較，通常是為了責罵軟體開發人員沒有做好工作。作為一個電子工程學位畢業的人，這在我職業生涯的早期引起了我的共鳴。但這種思考方式是有缺陷的，因為大多數人對工程在實務中的運作方式有錯誤的印象。

軟體開發中的許多辯論都以說話者是否具有指導態度或啟發態度為基礎。這些不同的態度會影響對語言、設計、工具、流程等的選擇。

偶爾有人質疑某個特定專業是否可以用增量的方式使用：「你不能用敏捷專案來執行（安全性 | 使用者介面設計 | 資料庫 | 國際化 | * ），因為這個面向必須事先完成。」

這個月是檢視 IEEE 的軟體工程知識寶典。這是一種定義我們專業知識體系的嘗試，可以為執照專業奠定基礎。

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

在我整個職業生涯中見過的一個穩定主題是軟體開發的本質和重要性。幾年前，一位潛在客戶告訴我們的業務員：「軟體就像下水道管線，我希望它能可靠地運作，而且我不想知道細節。」這就是尼可拉斯·卡爾在IT Doesn't Matter中所談到的方法。相反地，我們為許多企業執行過工作，而 IT 已成為其業務更明確的策略性推手，讓他們得以進入新市場或大幅增加其市場占有率。因此，IT 是像下水道管線一樣的實用工具，還是策略性資產？

在軟體世界中，「瀑布」通常用來描述一種軟體流程風格，與迭代或敏捷風格的理念形成對比。就像軟體中的許多知名術語一樣，它的意義定義不清，起源也模糊不清 - 但我發現它的基本主題是根據活動將大型工作分解成階段。

CHAOS 報告指出，只有 34% 的專案會成功。

Standish Group 的CHAOS 報告多年來一直在談論 IT 專案浪費了數十億美元。34% 的成功率實際上比 2001 年的 28% 有所改善。但我們真正指的「失敗」是什麼？

Yagni 最初是一個縮寫，代表「You Aren't Gonna Need It」（你不會需要它）。這是來自極限編程的咒語，通常在敏捷軟體團隊中普遍使用。這是一種說法，表示我們假設我們的軟體未來需要的一些功能不應該現在就建置，因為「你不會需要它」。