本章介紹敏捷開發的起源與核心理念，從「流程膨脹」（Process Inflation）的問題切入，說明 Agile Alliance 的成立背景，並完整闡述敏捷宣言的四大價值觀與十二項原則。
流程膨脹的困境#
許多團隊在經歷專案失敗後，會傾向於建立更多的流程與規範來防止錯誤再次發生。然而，這種做法往往適得其反：
- 流程愈加龐大笨重，反而拖慢開發速度，導致預算與時程持續膨脹
- 團隊的應變能力下降，最終總是交付錯誤的產品
- 團隊誤以為問題出在「流程不夠多」，於是進一步擴大流程——形成惡性循環
注意： 龐大笨重的流程本身就會製造它原本想要防止的問題。這就是所謂的「失控的流程膨脹」（Runaway Process Inflation）。
敏捷聯盟與敏捷宣言#
2001 年初，一群業界專家組成了 Agile Alliance，共同制定了一份價值觀聲明——The Manifesto of the Agile Alliance。
敏捷軟體開發宣言的四大價值觀#
- 個人與互動 重於 流程與工具
- 可運作的軟體 重於 詳盡的文件
- 與客戶協作 重於 合約談判
- 回應變化 重於 遵循計畫
重點： 宣言並非否定右側項目的價值，而是強調在兩者之間，左側項目應被賦予更高的優先權。
個人與互動重於流程與工具#
- 人是成功最關鍵的因素：一個好的流程無法拯救沒有好人才的團隊，但糟糕的流程卻能讓最強的人才失效
- 所謂「強手」不一定是頂尖程式設計師，而是善於與人協作的人
- 工具固然重要，但不應過度依賴——先用小型工具，等確認不敷使用再升級
- 先建立團隊，再讓團隊選擇環境，而非先建好環境再期望團隊自動磨合
可運作的軟體重於詳盡的文件#
- 沒有文件的軟體是災難，但過多的文件比太少更糟——龐大的文件難以與程式碼同步，最終淪為謊言
- 團隊應維護一份簡短且重點明確的架構與設計文件（一、二十頁以內）
- 最佳的知識傳承方式是程式碼本身加上人與人之間的互動
技巧： Martin 的文件第一定律——除非需求迫切且具重要性，否則不要產出文件（Produce no document unless its need is immediate and significant）。
與客戶協作重於合約談判#
- 軟體不是商品，無法先寫好需求規格再用固定價格外包開發——這種做法屢屢失敗
- 成功的專案依賴頻繁的客戶回饋：客戶與開發團隊緊密合作，而非事先定義完所有需求後就消失
- 最好的合約是規範協作方式，而非試圖鎖定範圍與成本
回應變化重於遵循計畫#
- 軟體專案無法精確預測未來：商業環境會變、需求會變、估時也不準確
- 與其制定一份涵蓋全專案的 PERT/Gantt 圖表，不如採用漸進式規劃：
- 下週的工作：詳細計畫
- 未來三個月：粗略計畫
- 一年後：僅有模糊方向
十二項敏捷原則#
- 早期且持續交付有價值的軟體是最高優先。初次交付的功能愈少，最終品質反而愈高；交付愈頻繁，最終品質也愈高
- 歡迎需求變更，即使在開發後期。敏捷流程將變更視為好事，代表團隊對客戶需求有了更深的理解
- 頻繁交付可運作的軟體，週期從數週到數月，愈短愈好
- 業務人員與開發人員必須每天一起工作
- 以受激勵的個人為核心來建構專案，給予他們所需的環境與支持，並信任他們
- 面對面溝通是最有效率的資訊傳遞方式
- 可運作的軟體是衡量進度的首要指標
- 敏捷流程促進可持續的開發步調——不是短跑衝刺，而是馬拉松式的穩定節奏
- 持續追求卓越技術與良好設計能增強敏捷性
- 簡單——最大化「不需要做的工作量」是必要的
- 最佳的架構、需求與設計出自自組織的團隊
- 定期反思並調整團隊的行為方式
補充： 在實務中，多數成功的敏捷團隊傾向混合使用 SCRUM 與 XP——以 SCRUM 管理多團隊協作，以 XP 落實日常開發實踐。
本章小結#
每位軟體開發者的專業目標都是為雇主與客戶創造最高價值。敏捷軟體開發的價值觀與原則，正是為了幫助團隊打破流程膨脹的惡性循環，回歸以簡單有效的技術達成目標的正途。