作者：蔡煥麟
日期：May-17-2002
Agile Software Development 一書的作者是 Alistair Cockburn (唸做 co-burn)，他也是 Writing Effective Use Cases 的作者。本書主要在探討軟體開發領域的相關議題，闡述 Agile 開發方法的精神，試圖提供另一種軟體開發方法來解決日益複雜的軟體開發問題。
Agile 是什麼？根據字典上的解釋，agile 有敏捷、敏銳、靈活、機智等涵義，然而依照書中提倡的觀念來看，「靈活」一詞應該是這套方法論的主要精神。因為這套方法論強調應該視個案的實際需要來靈活運用各種工具和策略，有別於其他紀律型的開發方法（如 RUP），agile 較注重人性，強調不同的人格特質需要運用不同的管理策略，也就是因人、因時、因地制宜的策略。就方法本身而言，並沒有所謂最好的或者放諸四海皆準的方法，只有適當與不適當的差別而已。
本書有一章簡介，雖然說是簡介，但卻是全書中最抽象的一章，如果覺得難以下嚥，大可先略過，等到讀完後面比較具體的內容後再回來讀這部分的內容。書中有許多抽象層次的概念，也提供了許多務實的建議，作者以有限的詞彙跨越了抽象與現實之間的鴻溝，我想這大概是本書最精采也最困難的部分吧。
這篇讀書心得預定的進度是涵蓋一至三章，目前的進度只到第一章而已。
作者在書中舉了許多例子來和軟體開發的情況做比對，例如：詩、攀岩、以及各種遊戲，其中比較有意思的是作者對軟體與工程（engineering）以及軟體與建模（model building）的論述。關於軟體與工程，作者認為許多人把施行工程的活動和結果混淆了，前者是在思考各種解決方案並權衡得失，後者則像個有固定生產程序的工廠。
「當人們說：『把軟體開發工程化』的時候，他們的意思通常是『讓它運作得更像個工廠（的生產線）』，但是如你所見，我們不會把一家工廠的運作視為一項工程。」（p.29）
作者的意思是，人們常掛在嘴邊的「軟體工程」大都意指將軟體開發的程序制式化，如工廠的生產線般有條不紊，只要派些人手負責監控產品的品質即可。但這卻不是「工程」的本質，而是其結果。
在看到作者這段話之前，我也從未認真地想過「工程」的涵義，我大概也犯了觀念混淆的毛病。
作者認為把軟體視為一項工程並不足以提供專案開發的指引，而對於 Ivar Jacobson（公認的物件導向三巨頭之一）宣稱的「軟體開發就是建立模型」更是不以為然，認為此觀念將導致不當的專案決策，書中有這麼一段：
Many people have advocated model building over the last decade, including Ivar Jacobson, who declared, "Software development is model building."
Charactering software development as engineering may not provide much guidance for running projects, but charactering it as model building leads directly to inappropriate project decisions.（p.30）
對於 Ivar Jacobson 的信徒而言，這種說法可能相當刺耳，即使是一般人初次聽到，恐怕也是半信半疑。所以我很好奇作者自己又是如何看待軟體開發與建模，他認為「軟體開發是一場（資源有限的）創造與溝通的合作遊戲（cooperative game）」，而要花多少功夫建模得視專案的需求而定，如果足以用來溝通彼此的觀念，那麼「模型是否完整、圖形記號是否正確、以及是否完全反映真實世界，也就不那麼重要了」。
Cockburn 在書中常引用其他軟體開發團隊的成功經驗，例如：
「我們想要表達的有趣的部分並不在那些模型圖案裡，而是當我們在白板上塗鴉時所進行的對話中。」
（或曰：沒有人會去看那些模型設計文件，腦力激盪的會議比它們有趣多了）
「我們沒時間建立精緻或完整的模型，其實我們經常連建立模型的時間也沒有。」
（或曰：時程這麼趕，誰還有時間去畫那些模型圖？）
記得之前參加過一門物件導向分析設計的訓練課程，主要是教導以 RUP（Rational Unified Process）作為軟體開發的程序，由於完整的 RUP 所需的程序、人力以及要製作的文件很多，當時曾請教講師這些程序如何套用在 5∼10 人的小型開發團隊，講師回答有些程序可以省略，但是由於 RUP 所定義的是一個軟體開發過程中所有必需的步驟，省略的結果必然導致日後維護的成本。似乎言之有理，但令人洩氣。
比較一下前面所舉的例子和 RUP，書中的例子似乎比較符合現狀，而 RUP 則顯得有些高不可攀。那麼，我們是不是就有理由不建立模型？Use Case diagram, Class diagram,...這些圖是不是也不用畫了呢？
也不盡然，Cockburn 只是希望我們不要被「建模」這件事模糊了軟體開發的真正目的，而不是完全不做（要不然他的 "Writing Effective Use Cases" 就不用賣了），模型只是用來溝通的工具，只要能滿足這個目的就夠了，畢竟「溝通的成效比起溝通的形式要來得重要多了」。
在本書的附錄裡面有提到日本劍聖宮本武藏的教戰守則，作者認為很適合用在軟體開發上面，其中一條是：
Do not develop an attachment to any one weapon or any one school of fighting.
軟體開發也是一樣：「不要執著於 UML, RUP, CMM, SEI, XP, CRC...而被他們困住了，要用其所當用。」（p.254）
然而「用其所當用」卻不是件容易的事，好像中庸，道理簡單，實行不易。當我讀到這段時也一樣有這個疑問，抱持著一點好奇和懷疑，我繼續看下去作者如何解釋這道難題。在我接下去閱讀的內容裡，作者嘗試用幾個實際的例子來讓讀者了解一下什麼是「用其所當用」，有些例子告訴我們為了讓專案達到其首要目標－－發行上市，要達到「足夠」的程度其實是很容易的；而有些例子則顯示做得不夠反而導致專案失敗。其中一個講的是「工作產出的足夠（sufficiency
of work products）」，那是一個一千五百萬美元的專案，45
位成員中程式設計師佔了 24 位，歷時 18
個月開發完成，系統分析師每當跟客戶訪談後就直接將訪談結果告知設計師，然後設計師就根據這些口頭描述寫成程式碼（這...真的足夠嗎？）。另一個是克萊斯勒的
untralight sufficiency，在這個案例中，設計文件大部分都是口耳相傳，也就是根本未做成文件的，而這個專案到最後因為人員異動，後面接手的人又沒有任何設計文件可以參考（只有簡單的兩句
user stories，一些測試和程式碼）的情況下，最後宣告失敗。還有一個是案例則是為了確保文件必須反映目前的設計而經常更新文件的內容，反而造成專案進度嚴重落後。
看了幾個過與不及的例子之後，作者也提出了一些實際的建議。他認為要衡量工作產出（文件、模型、CRC
cards...）是否足夠，必須先認清軟體開發的首要目標是交付可用的軟體，次要目標則是為下個專案以及後面接手的人做好準備，而這個準備工作又要做多少才足夠？以及何時進行？簡單地說，只要能夠表達當時設計的理念（或理論）就行了，關於這點，作者希望我們參考附錄中所收錄的一篇
Peter Naur 的文章 "Programming As Theory Building"（註：Naur 是
BNF 表示法的作者之一）。
作者在書中並未全盤否定工程、建模或其他的方法論，而是認為軟體開發不只是單一面向，僅以軟體開發就是工程或就是建模這種說法仍嫌不足，所以另闢蹊徑，試圖提出更周全、更貼近人性的看法。
書中提到一個關於學習境界的有趣論點，就是學習劍道的三個階段：
守：練習基本功夫，一切照章行事。
破：能突破傳統，因地制宜靈活運用各種招式。
離：超脫任何招式與規則，達到無招勝有招的境界。
以金庸的武俠世界來看，「守」就是照秘笈練招式，「破」就是靈活運用並能突破限制創新招，「離」則接近獨孤九劍的無招勝有招的境界了。Cockburn 發現在軟體開發的領域中也有類似的現象，例如以方法論來說，RUP 屬於第一個等級；以程式設計來說，能運用 design patterns 的人可算是到達「破」的境界，而能靈活運用本書的理念開發出成功專案的人，就算是「離」的境界了。
書中並且引用 Kent Beck 的話來說明運用 eXtreme Programming（XP）的三個層次，分別是：
總之，先器後道依然是多數人的學習歷程，初學者仍應學習現有的方法與規則，循序漸進，而不是一句「軟體開發是藝術創作」就把一切規則拋開。
開發程序、建模、以及各種方法論都各有其定位和特長，沒有任何一套方法論可以適用所有的軟體類型和開發團隊，換句話說，軟體開發的成功是無法複製的，這是軟體開發的動態和不確定性所造成的必然現象，專家們則試圖在這些難以捉摸的動態之中找出固定的模式和法則，為我們提供了許多工具和指引，它們都是專家的經驗和智慧的結晶，如同經驗豐富的廚師撰寫的食譜一樣。現在，食譜、材料、和廚具都有了，就看廚師如何善用它們做出好吃的料理了。