有鑑於傳統結構化軟體開發方式管理不易, 失敗率高, 因此近來也有人大力推薦 Agile Design 敏捷式開發方法, 據說績效很好.

請問有人可以簡單說明一下什麼是 Agile Design 嗎 ? 其優點何在 ? 可以適用於較大型的軟體開發嗎 ?

若要簡單說明 Agile Design，我就從網路上轉貼一段敘述文字請你參考吧 :

『 ...... 敏捷式軟體開發注重的兩個重點：快速與便宜。敏捷式軟體開發之所以熱門，第一個主要的原因就是因為正式的軟體工程方法需要過多步驟來完成整個軟體的開發，相較而言，正式的軟體工程方法對於改變的處理也是缺乏競爭力的，因此敏捷式開發方法強調速度。而第二個原因就是成本的考量，傳統的方法花費了太多的成本來進行每一項既定的程序，而敏捷式開發適時地捨去某些程序，降 低軟體開發品質的程度可以維持在可容忍的程度內，也讓它比傳統方法便宜【註一】、【註二】。』

以上文字摘錄自細說「軟體工廠」概念，作者是吳信輝先生。

【註一】：你真的搞懂了什麼叫敏捷式 ( Agile ) 開發嗎？

【註二】：敏捷的軟體開發流程

對此一主題有興趣的軟體人，不妨到http://140.115.156.9/agilemethod/index.php 這個網站看看，那裡可以下載到中央大學陳振炎教授6/15研討會的資料，也有一些先進分享的經驗與相關討論。也許您會有一些意想不到的收穫。

軟體品質協會資深管理師 周茂松

目前我們有一個軟體外包案，承包商聲稱採用 Agile Design Process (敏捷式設計的開發流程)，可以簡化傳統軟體工程所要求的技術文件(包括軟體需求規格書 SRS 和設計說明書 SDD)，並且強調該公司有內部規範的 Coding Standard (程式撰寫標準)，即使程式設計人員異動也很容易接手，因此就不需要對他們的開發過程做太多的管控要求，只要確認產出的結果是否符合使用者的需求即可。請問這樣的說法是對的嗎 ? 有沒有什麼潛在的風險 ?

順便請問: 採用 Agile Design Process 有沒有適合條件或者環境配合的要求 ? 有哪些特別需要注意的地方呢 ?

「敏捷方法的擁護者不是反對方法論。他們擁抱模型，但是不只是把幾張圖歸檔到公司蒙塵的儲藏庫中。他們擁抱文件，但是不把紙張浪費在很少使用也不維護的卷宗上。他們堅持規劃，但是也承認在變化快速的環境中規劃的侷限性。敏捷過程的提倡者強調的核心要素是時程。它是成功最重要的標準。敏捷方法迫使組織面對時程的牽制。」以上這段文字譯自：Trustworthy Systems Through Quantitative Software Engineering (by Lawrence Bernstein, C. M. Yuhas)的第1.5.6節的第一段。

所以，請不要以“採用敏捷方法”作為軟體開發專案不塑模、不寫文件、不規劃與不管理的藉口。

為了對敏捷方法有更深刻的認識，我們不妨先檢視一下人類移動自己身體的方法與能力。

首先讓我們看第一個場景：數十對剛為人父母的年輕夫妻，帶著自己才幾個月大的寶貝，參加嬰兒的爬行比賽。比賽開始後，有的一直往前爬；有的歪歪斜斜的爬著；有的在中途一屁股坐下來，不論在場邊的爸媽如何叫喚與指示，它就是不動如山；也有的索性哭了起來…各種情況不一而足。在第一場中順利贏得勝利的，在第二場的比賽中也可能會和第一場的表現完全不同(爬不到終點)。由這樣的場景，我們可以知道：嬰兒最初的“爬”行能力，是不可重複的、不可預期的與不可管理的。

其次，當人學會“走”路時，不論是把它運用在日常生活中的一般走路、全班學生的齊步走、模特兒的走台步、軍隊的行軍或者郊外的踏青 … 它都是建立在“走”這件事是可重複的、可預測的與可管理的。

最後，人如果只會用“走”的方式移動自己的身體，是無法滿足許多“時間”加諸於人類“生存”上的限制。譬如：在追趕快要離站的火車時、在警匪追逐的過程中、在運動場與人競技時、在災難即將發生時…，人要用“跑”、“跳”、“翻”、“滾”、“滑”…，甚至是“撲”的，更為敏捷的方法來移動身體，才能在這些情境中克服“時間”對人的限制。

把以上三類人移動身體的能力，類比到組織“開發軟體的方法與能力”上。那麼，第一類“爬”這種能力對應的是使用“没有方法”的方法的組織能力(通常就是CMMI Level 1的組織能力)。第二類“走” 這種能力對應的是一般使用“非敏捷方法”的組織能力(通常為CMMI Level 2~5的組織能力)。第三類：“跑跳翻滾撲滑”對應的就是“敏捷”方法與能力。對絶大多數的人而言，會走的一定會爬，會跑跳翻滾滑的一定會走。對組織開發軟體的能力而言，理應如是。

天下没有白吃的午餐，有得必有失。“跑跳翻滾滑”固然能滿足“時間”的限制，其付出的代價也很高。譬如：它要消耗比較多的體力，也會把衣服弄髒弄亂甚至弄破，嚴重的可能受傷，甚至送命。軟體開發的敏捷方法也不例外。

軟體開發專案要不要採用“敏捷方法”，首先要考慮客戶對專案的時程是否有異於常情的要求 (意指：該專案所要求的時限，是否以“正常－走”的方法，是不可能達成的。)？ 其次，要問該專案於“時限”內完成時，客戶是否可取得“重大利益”？ 再來，還要問客戶願意“用什麼來交換”這項時間上的利益？ 客戶有沒有經過授權的代表可全程參與專案，於必要時代表客戶逕自做出決定？ 接著要考慮該專案要“敏捷到什麼程度”，才能符合客戶時限上的要求？ 最後，要問開發團隊有没有使用該敏捷方法的能力？ 如果以上的問題都有肯定而明確的答案，那麼這個軟體專案才具有使用敏捷方法的必要性與可行性。否則，請不要輕言專案採用“敏捷方法”。更不要以採用了“敏捷方法”做為不塑模、不寫文件、不規劃與不管理的藉口。

願以上的說明能稍微澄清許多人對“敏捷方法”的誤解。

謝謝軟品協會周管理師的詳細解惑，以下我也摘錄一段源自台灣微軟網站林耀珍先生的文章做為呼應：

Agile Process (敏捷的開發流程) 具有下列幾項共通的特性：

1. 客戶與開發人員形成密切合作的團隊，因為客戶無法於初期定義完整的規格，而開發人員於開發過程中也常常無法知悉外在環境或業務的變動，所以需要兩者密切合作方能開發適用的軟體。
2. 專案最終的目標是可執行的程式，因此所有的中間產品必須經過審慎評估，確認有助於最終目標，才需要製作中間產品。
3. 採用 Iterative 與 Incremental 方式分階段進行，密集 Review 是否符合需求。
4. 流程可以簡單，但規劃與執行必須嚴謹。
5. 強調團隊合作，賦予高度的責任，團隊有自主權得以因應變化做調整。

由此看來，採用敏捷式軟體開發的先決條件應該是：

客戶與軟體開發人員都已經具備了相當的成熟度，彼此間的配合默契與互動信任已經很好，為了追求快速而願意簡化某些流程或文件，但其規劃與執行管控必須嚴謹，才能使產出的軟體仍具有一定的品質與可維護性。