本章由 Sandro Mancuso 撰寫，回顧了 Agile 運動在產業中的演變，指出當技術實踐被忽略、流程被過度強調時所產生的問題，並介紹 Software Craftsmanship 運動如何試圖修補這道裂痕。

Agile 的初始承諾與幻滅#

Agile 最初帶給開發者巨大的興奮感——它承諾了協作環境、短迭代、快速回饋，以及業務與技術合而為一的團隊文化。開發者期待被當作專業人士對待，共同參與決策。

然而，Agile 的核心理念在傳播過程中被簡化和扭曲，最終以「更快交付軟體的流程」這種形式傳入企業。管理者和利害關係人聽到的訊息是：「修好流程，工程就會自然變好」——但這個假設從根本上就是錯誤的。

timeline
    title Agile 與 Craftsmanship 的演變
    2001 : Agile Manifesto 誕生
         : XP 定義技術實踐
    2001~2008 : Agile 轉型浪潮
              : 技術實踐逐漸被忽略
    2008 : Software Craftsmanship 運動成立
    2008+ : Craftsmanship 社群蓬勃發展
          : 彌補 Agile 技術面不足

The Agile Hangover#

大量企業投入 Agile 轉型後，卻發現許多老問題依然存在，作者稱之為 Agile Hangover（Agile 宿醉）：

問題說明
Agile Coach 的問題許多認證只需兩天培訓即可取得，大量 Coach 既缺乏商業經驗也缺乏技術能力
流程透明度被濫用管理者利用 Agile 的透明性來微觀管理開發者，而非賦能
自組織的假象Roadmap 和 Milestone 仍由管理層單方面制定，開發者只是被迫將估算塞入既定時程
技術實踐被打壓Product Owner 認為自動化測試、重構、結對程式設計「浪費時間」，直接要求團隊停止
技術債持續累積沒有架構思考的空間，團隊只被要求「從 Backlog 頂端拿下一個 item，盡快做完」

當策略性技術工作在 Agile 流程中沒有立足之地時，結果就是長期的戰術性迭代和技術債堆疊，產出脆弱的軟體（Fragile Software）。

Expectation Mismatch（期望落差）#

Agile 轉型只專注流程的改善，是一種不完整的轉型。核心的期望落差在於：

  • Agile 期望團隊能在每個迭代結束時交付可上線的軟體
  • 但團隊從一年發布數次轉變為每兩週發布一次，需要截然不同的技術能力
  • 多個團隊同時在同一系統上工作並持續部署，對工程技能的要求極高
  • 開發者需要策略思維、模組化設計，以及同時兼顧彈性與穩健性的能力
  • 然而，轉型預算幾乎從不包含開發者的技能提升

良好的協作可以移除工作中的障礙，但不會讓人自動變得更有技術能力。企業的業務敏捷性（Business Agility）直接取決於其軟體演進的速度，而這又取決於工程技能的水準。

Moving Apart（漸行漸遠）#

Agile 和開發者正在彼此遠離。在許多組織中，Agile 已經等同於 Scrum，XP 被簡化為少數幾個技術實踐。Agile Coach 逐漸被開發者視為「另一層管理」——告訴他們該做什麼，而非幫助他們把事情做好。

  • 技術問題其實就是業務問題，但大多數企業尚未成熟到理解這一點
  • Product Owner 不認為自己是團隊的一部分，出問題時不共同承擔責任
  • Us-versus-them（我們 vs 他們）的對立文化持續存在

Software Craftsmanship 運動#

起源與宣言#

2008 年 11 月，一群開發者在芝加哥聚會，創立了 Software Craftsmanship 運動。他們參照 Agile Manifesto 的精神，發表了建構在其之上的新宣言：

Agile 基礎Craftsmanship 延伸
Working software（能運作的軟體）Well-crafted software（精心打造的軟體）
Responding to change（回應變化）Steadily adding value（持續增加價值）
Individuals and interactions（個人與互動）A community of professionals（專業社群）
Customer collaboration（客戶協作）Productive partnerships（生產性夥伴關係）

四項價值的內涵#

價值內涵
Well-crafted software設計良好、測試充分的程式碼，不怕改動，同時兼具彈性與穩健性
Steadily adding value無論做什麼，都應持續為客戶和雇主提供遞增的價值
A community of professionals彼此分享與學習，提升整個產業的水準，並為下一代開發者做好準備
Productive partnerships與客戶及雇主建立基於相互尊重和專業倫理的關係

Craftsmanship 的核心觀念：軟體開發不是你被迫去做的「工作」，而是你主動投入的「專業服務」。Craftspeople 追求把事情做好，不是因為有人付錢，而是出於對品質的內在渴望。

Ideology versus Methodology（意識型態 vs 方法論）#

這兩個概念的區分是理解 Agile 與 Craftsmanship 關係的關鍵：

  • Ideology（意識型態）：一套理想與價值體系，定義我們追求的目標
  • Methodology（方法論）：一套方法與實踐，是達成目標的手段

Agile Manifesto 和其 12 條原則描述的是意識型態；Scrum、XP、DSDM、Crystal 等則是方法論——它們都是達成同一目標的不同手段。

訓練輪的比喻#

方法論和實踐就像腳踏車的輔助輪：

  • 一開始很有幫助，讓人安全起步
  • 但如果過度依賴輔助輪，反而阻礙真正的成長
  • 目標是學會騎腳踏車，而不是「採用輔助輪」

Jim Highsmith 的觀點：「沒有實踐的原則是空殼，沒有原則的實踐則淪為機械式的照做。原則引導實踐，實踐實現原則，兩者相輔相成。」

Software Craftsmanship 的實踐觀#

Craftsmanship 刻意不綁定特定實踐——因為綁定會讓它變得脆弱且過時。它推崇的是持續尋找更好實踐的精神。

然而，目前 Craftsmanship 社群普遍認為 XP 是現有最佳的 Agile 開發實踐集合，包括：

  • TDD、Refactoring、Simple Design
  • Continuous Integration、Pair Programming
  • Clean Code、SOLID 原則
  • 小型 Commit、小型 Release、Continuous Delivery
  • 模組化設計、自動化一切可自動化的手動重複性工作

聚焦在價值，而非實踐本身#

推廣實踐時，常見的錯誤是推銷解決方案而不先建立問題共識：

  • 錯誤的問法：「如何說服主管做 TDD？」
  • 正確的做法：先就目標達成共識（例如：將整體測試時間從兩週縮短為兩分鐘），再討論哪種實踐能達成目標
  • 唯一不可接受的是：拒絕一個實踐，卻提不出更好的替代方案

誰該討論哪些實踐#

  • 關乎業務與技術協作的實踐：兩方都應參與討論
  • 關乎開發者如何建構系統的實踐（如 TDD）：不需要業務方介入
  • 開發者不應為寫測試請求許可，也不應為測試、重構、或讓功能上線就緒建立獨立任務——這些是開發工作的一部分，不是可選項
  • 業務和開發者的對話應圍繞 why、what、when，而非 how

每次開發者主動揭露工作細節（how），就是在邀請管理者來微觀管理他們。開發者應該能清楚描述自己的工作方式及其優勢，但不應讓他人來決定他們如何工作。

Craftsmanship 對個人的影響#

Craftsmanship 重新定義了軟體開發者與工作的關係：

  • 擁有一份 Job（工作） vs 擁有一份 Profession（專業） 是截然不同的
    • Job：「我在 X 公司工作」——工作不是你身份的一部分
    • Profession：「我是一位軟體開發者」——專業是你身份的一部分
  • 擁有專業意味著你願意投資自己的時間和金錢來精進技能，追求長期而充實的職涯
  • 這不代表犧牲家庭或個人生活，而是找到平衡，讓工作成為帶來滿足感的生活一部分

Craftsmanship 對產業的影響#

自 2008 年以來，全球各地成立了大量 Software Craftsmanship 社群和研討會，吸引了數以萬計的開發者：

  • 這些社群聚焦在 Agile 的技術面，彌補了 Agile 社群過度偏重流程面的不足
  • 開發者在此學習 TDD、CI、Pair Programming、Simple Design、SOLID、Clean Code、Refactoring
  • 也學習微服務架構、部署管線自動化、雲端遷移、新語言與新範式
  • 社群具有高度包容性，歡迎所有背景和經驗層級的開發者

對企業的影響#

  • 許多完成 Agile 轉型的企業現在轉向 Craftsmanship 來提升工程能力
  • 但 Craftsmanship 不像 Agile 那樣容易「賣」給管理者——管理者理解 Scrum，卻對 XP 等程式設計技術不感興趣
  • 現代的 Agile Coach 大多無法教授 XP、無法與開發者結對、無法協助重構遺留程式碼或制定技術策略
  • 然而企業需要的正是可靠的系統和有能力且有動力的技術團隊——這正是 Craftsmanship 擅長的領域
  • 擁抱 Craftsmanship 的企業往往能看到內部實踐社群蓬勃發展，開發者主動組織學習活動、改善程式碼品質、探索新技術

Craftsmanship 與 Agile 的關係#

兩個運動之間曾存在張力：

  • Craftsmanship 批評 Agile 過度聚焦流程、忽略工程
  • Agile 批評 Craftsmanship 視野狹隘、缺乏對業務和人際問題的關注

但這些分歧更多源於部落主義，而非根本性的意見差異。兩者的核心追求高度一致：

  • 都追求客戶滿意
  • 都重視緊密協作
  • 都偏好短回饋循環
  • 都想交付高品質、有價值的成果
  • 都要求專業態度

要達成真正的業務敏捷性，企業不僅需要協作性和迭代性的流程，也需要優秀的工程技能。結合 Agile 與 Craftsmanship 是達成這一目標的最佳途徑。

Conclusion#

Kent Beck 在 2001 年 Snowbird 會議上說，Agile 是為了彌合開發與業務之間的裂痕。然而隨著專案管理者大量湧入 Agile 社群，最初創造這個社群的開發者反而感到被邊緣化，於是離開並組成了 Craftsmanship 運動。古老的不信任由此延續。

但 Agile 和 Craftsmanship 的價值觀是高度一致的。這兩個運動不應該是分離的。希望有一天，它們能再次合而為一。

Backward Becoming Agile Conclusion Forward