Agile 之所以重要，不只是因為它能提升速度或品質這些表面好處。Martin 認為 Agile 的核心動機來自更深層的哲學與倫理層面——專業主義（Professionalism）以及對客戶的合理期望（Reasonable Expectations）。許多人嘗試 Agile 後又放棄，往往是因為只看到表面承諾而忽略了這些根本原因。

Professionalism（專業主義）#

Martin 最初被 Agile 吸引的原因，是它對紀律高於儀式的承諾。要正確實踐 Agile，你必須結對程式設計、先寫測試、持續重構、追求簡單設計，並在短週期內產出可執行的成果。這些實踐本質上是一種專業承諾。

軟體無所不在#

現代社會已經被軟體徹底滲透。Martin 在他的小木屋裡數了一下，光是身邊就有至少 30 台電腦——從 MacBook、iPhone、AirPods 到恆溫器、安全面板、遙控器。西方社會中，多數人隨時都在十幾台電腦的範圍內，而這些電腦全部需要軟體來驅動。

在今天的社會中，幾乎沒有任何重要的事情可以在不與軟體系統互動的情況下完成——法律的制定與執行、飛機的飛行、汽車的駕駛、食物的採收、股票的交易，全都依賴軟體。

我們統治著世界#

既然一切都依賴軟體，那麼寫軟體的人實質上掌控了世界的運作。但問題是：我們做得並不好。有多少軟體經過充分測試？有多少程式設計師能拿出一套測試來證明他們的軟體確實能正常運作？

Martin 舉了 Toyota 的案例：2013 年 Toyota 因軟體中充斥著全域變數、堆疊溢位風險、義大利麵式程式碼等問題而賠償了數百萬美元。我們的軟體正在殺人，而隨著每一天過去，越來越多的程式碼牽涉到越來越多人的生命與財產。

災難即將來臨#

終有一天，某個程式設計師的一個疏忽可能在瞬間造成上萬人死亡。屆時政治人物會把矛頭指向我們——正如 Volkswagen 排放醜聞中，CEO 將責任推給「幾個軟體工程師」那樣。

最終承擔責任的將是我們，因為是我們的手指在鍵盤上、是我們的紀律不足、是我們的疏忽導致了問題。Martin 寄望 Agile 的紀律能成為將程式設計轉變為真正且受尊重的專業的第一步。

Reasonable Expectations（合理期望）#

Martin 以 CTO 的角度列出了一系列客戶與管理者對開發團隊的合理期望。他指出，當你讀到每一項時，理性的一面會認為它完全合理，但程式設計師的一面可能會感到恐慌。滿足這些期望正是 Agile 的核心目標之一。

不出爛貨（We Will Not Ship Shyt!）#

這本應不需要特別強調，但軟體產業的現實迫使我們必須正視。Martin 舉了幾個例子：

• 洛杉磯航空管制網路因 32-bit 時鐘溢位而關閉
• Boeing 787 因同樣原因導致機上所有發電機停機
• 737 Max 的 MCAS 軟體造成數百人罹難
• healthcare.gov 的安全問題欄位無法接受日期格式，使用者必須像程式設計師一樣思考才能通過

Agile 對 Testing、Refactoring、Simple Design 以及客戶回饋的重視，正是避免出爛貨的直接對策。

持續技術就緒（Continuous Technical Readiness）#

客戶和管理者不期望開發團隊製造人為的部署延遲。但這種延遲在軟體團隊中很常見，通常來自兩個原因：

• 同時開發所有功能，而非優先完成最重要的功能——導致一堆半完成的東西無法部署
• 穩定化期間——團隊留出一段時間持續測試，觀察系統是否出錯

Agile 的解法是：系統在每個 iteration 結束時都應處於技術上可部署的狀態。這意味著每個 iteration 的工作包含所有的程式碼撰寫、測試、文件與穩定化。當系統隨時可部署時，部署就從技術決策變成了商業決策。

穩定的生產力（Stable Productivity）#

新專案初期進展飛快，但隨著程式碼混亂累積，團隊速度會持續下降。這是一個正回饋迴路：

1. 程式碼越亂 → 開發越慢
2. 開發越慢 → 時程壓力越大
3. 壓力越大 → 越傾向製造更多混亂
4. 管理層加人 → 新人學到舊有的壞習慣 → 生產力繼續下滑

flowchart TD
    A[程式碼越來越亂] --> B[開發速度下降]
    B --> C[時程壓力增加]
    C --> D[更傾向製造混亂]
    D --> A
    C --> E[管理層增加人手]
    E --> F[新人學到壞習慣]
    F --> B

最終，開發者會提出「從頭重寫」的建議。但 Martin 分享了一個真實案例：Tiger Team 花了十年仍未能取代舊系統，因為舊系統是個不斷移動的目標——就像 Zeno 的阿基里斯與烏龜悖論。

客戶期望生產力保持穩定——年初花兩週完成的功能，一年後類似的功能也應該花差不多的時間。Agile 的 Testing、Pairing、Refactoring 和 Simple Design 是打破惡性循環的技術關鍵，而 Planning Game 則是對抗時程壓力的解藥。

低成本的適應性（Inexpensive Adaptability）#

“Software” 這個詞本身就說明了一切：soft（容易改變的）+ ware（產品）。軟體被發明出來就是為了讓機器行為容易改變。

• 如果需求變更會摧毀你的架構，那是你的架構有問題
• 開發者應該慶祝變更，因為變更正是我們存在的理由
• 客戶期望軟體系統容易修改，且修改成本小且與變更幅度成比例

Agile 的 TDD、Refactoring 和 Simple Design 共同確保系統能以最小代價安全地進行變更。

持續改善（Continuous Improvement）#

人類做事會隨時間越做越好——畫家改善畫作、作曲家改善歌曲、屋主改善房屋。軟體也應如此：系統越老應該越好，設計與架構應隨時間改進。

然而軟體產業最大的罪狀恰恰相反——我們讓系統隨時間越來越糟。開發者預期系統會越來越髒、越來越脆弱，這是極度不負責任的態度。

無懼的能力（Fearless Competence）#

為什麼軟體不會隨時間改善？因為恐懼。

看到醜陋的程式碼，第一個念頭是「我應該清理它」，第二個念頭是「我不敢碰它」——因為碰了可能會壞，壞了就變成你的責任。這種恐懼讓開發者變得無能，無法做出必要的清理。

想像你有一個按鈕，按下去幾秒鐘就能知道系統是否正常（綠燈）或壞掉（紅燈）。有了這個按鈕，你就能放心地清理程式碼，每次小改動後按一下確認沒問題。TDD 就是那個按鈕。 搭配 Refactoring、Pairing 和 Simple Design，你就能無懼地維持程式碼品質。

QA 不該找到任何問題（QA Should Find Nothing）#

QA 執行測試後，應該回報一切正常。每次 QA 發現問題，開發團隊都應檢討流程並修正，確保下次 QA 什麼都找不到。QA 應該疑惑為什麼自己被放在流程末端檢查永遠正常的系統——因為 QA 有更好的位置可以發揮價值。

測試自動化（Test Automation）#

這張圖片中的手屬於一位 QA 經理，他手中拿著的是一份手動測試計畫的目錄——列出了 80,000 個手動測試案例，每六個月由印度的測試大軍執行一次，花費超過一百萬美元。2008 年金融危機爆發後，CFO 將預算砍半，QA 經理不得不決定哪一半的測試不再執行。

手動測試終究會被淘汰，原因有二：

1. 成本壓力：手動測試昂貴，永遠是被削減的目標
2. 時間擠壓：開發者很少準時交付給 QA，QA 不得不選擇性地執行測試，部分測試就此流失

人類不是機器。要求人類做機器能做的事既昂貴、低效又不道德。所有能自動化的測試都必須自動化，手動測試應僅限於無法自動驗證的項目以及探索性測試（Exploratory Testing）——這才是 QA 發揮人類創造力與想像力的地方。

互相補位（We Cover for Each Other）#

軟體團隊應該像球場上的球隊一樣運作——一個人倒下，其他人補上空缺繼續推進。如果 Bob 是資料庫專家但生病了，Jill 應該能接手他的工作。知識不應被鎖在個人的孤島中。

Pair Programming、Whole Team 和 Collective Ownership 這些 Agile 實踐支撐了這個期望。

誠實的估算（Honest Estimates）#

最誠實的估算是「我不知道」，但這不完整。你可以：

• 相對估算：你可能不知道 Login 頁面要多久，但你知道 Change Password 大約是 Login 的一半時間
• 機率範圍：Login 頁面需要 5 到 15 天，平均完成時間 12 天

估算是有根據的猜測，會隨時間改善，但估算永遠不是承諾。

要敢說「不」（You Need to Say “No”）#

你被雇用更多是因為你說「不」的能力，而非你寫程式的能力。當事情真的不可行時，無論時程壓力多大、無論多少管理者要求結果，你都必須說「不」。

持續積極學習與指導（Continuous Aggressive Learning & Mentoring）#

產業變化快速，開發者必須持續學習——即使公司無法提供培訓資源，也要自己想辦法。同時，教學是最好的學習方式，當新人加入團隊時，主動教導他們。

The Bill of Rights（權利法案）#

在 Snowbird 會議上，Kent Beck 提出 Agile 的目標是彌合商業與開發之間的鴻溝。為此，Kent Beck、Ward Cunningham 和 Ron Jeffries 等人制定了一套權利法案。客戶的權利與開發者的權利互補，像手套一樣契合，在兩個群體之間建立了期望的平衡。

Customer Bill of Rights（客戶權利）#

• 整體計畫的知情權：有權知道什麼能在何時以多少成本完成——但這不代表固定範圍加固定日期，而是基於機率的計畫（例如：95% 機率完成前 10 個 story、50% 機率完成接下來 5 個）
• 每個 iteration 的最大價值：有權期望開發者在任何時候都在做最重要的事，每個 iteration 提供最大可用的商業價值
• 可見的進度：有權在運行中的系統看到進展，並透過客戶自己指定的可重複測試來證明功能正常
• 變更的權利：有權改變需求、替換功能、調整優先順序，而不需付出高昂代價——畢竟這就是「軟體」存在的意義
• 時程管理的權利：有權及時得知時程與估算的變化，以便透過調整範圍來達成所需日期；可隨時取消並保留反映目前投資的可用系統

客戶沒有權利要求強制遵守時程。他們的權利在於透過調整範圍來管理時程，以及及時知道時程面臨風險以便做出管理決策。

Developer Bill of Rights（開發者權利）#

• 清晰需求與優先順序：有權知道什麼是需要的，以及明確的優先順序宣告。此權利在 iteration 內有效——iteration 內需求視為不可變（但開發者可選擇放棄此權利，若變更微不足道）
• 高品質工作的權利：有權在任何時候產出高品質的工作。商業方無權要求開發者偷工減料或損害專業聲譽
• 尋求幫助的權利：有權向同事、管理者和客戶尋求幫助——同時，有求助的權利就伴隨著被求助時提供幫助的責任
• 自主估算的權利：沒有人能替你估算。估算是猜測，會隨時間改善，估算不是承諾
• 自主接受責任的權利：專業人員接受工作，而非被指派工作。開發者有權拒絕特定任務——可能是能力不足、認為他人更適合，或基於個人與道德理由（如 Volkswagen 排放醜聞中的工程師）。但接受即意味著負責：負責品質與執行、持續更新估算、溝通狀態、需要時求助

Conclusion（結語）#

Agile 不是流程，不是潮流，也不僅僅是一套規則。 Agile 是一套由權利、期望與紀律組成的體系，構成了一個道德專業的基礎。那些實踐這些紀律的人，接受並符合管理者、利害關係人和客戶的合理期望，同時享有並遵守 Agile 賦予開發者和客戶的權利。這種對權利與期望的相互接受——這種紀律的宣示——正是軟體倫理標準的基石。