敏捷式開發(Agile Development)是近來時常耳聞的一個名詞，我們或多或少對於這個名詞有些微的概念，但是卻又很難具體的描述出一個全面性的觀點來。

敏捷式的精神

原則上敏捷式開發主要的精神在於較短的開發迴圈（建立在反覆式開發方式上）以及漸進式開發與交付。換句話來說，專案的成果，包含計劃、各類的需求細節、設計等都會隨著專案的進行而漸漸完整，而非在一開始將所有的計劃與需求擬定完成。

在Craig Larman的Applying UML and Patterns第三版（該書的第二版著重在UP開發流程的說明，在第三版中才加進了敏捷式開發的精神）中花了不少篇幅在闡述敏捷式開發的一些定義。敏捷式開發並非一種制式的開發方法，而是一種軟體開發的精神

在敏捷式開發中有個很重要的觀點是筆者很感興趣的，它認為塑模（Modeling）的目的在於增加開發者瞭解軟體的程度，進而使得軟體更接近於使用者的需求，而非使用塑模之後產生的檔案。

The purpose of modeling (Sketching UML,…) is primarily to understand,not to document.[Apply UML and Patterns,3/e]

換句話說，它希望開發者使用塑模的時機，是當使用這個技術有助於開發者更瞭解被開發的軟體時才使用，例如某些具關鍵性的議題或者高風險性的專案，而非不管三七二十一的將軟體所有範圍的設計都加以塑模留下檔案。

草稿與藍圖

有趣的是，如果我們延伸這個觀點，塑模在敏捷式開發的精神下是一種類似草圖或者草稿的作用。也就是說，用以在團隊開發時討論以及研究議題的一種工具，在過程中利用塑模的技術來讓問題得到解決，一開始的動機並非謂了留下設計圖讓程式設計師去實作。

同樣的觀點在Martin Fowler的UML Distilled Third Edition中也有所著墨，Martin認為，UML作為一項工具，可以有三種被使用的方式，一種是草圖，一種是所謂的藍圖，最後一種則是程式語言。

Martin本身則是將作為一種草圖的工具來使用，當然也有人將其作為藍圖來使用。而將UML作為藍圖來使用到一種極至時將出現UML本身就可視為一種程式語言，例如所謂的模型驅動（MDA）開發。當然這並不在本文的討論範圍內。

Agile

2001年時支援敏捷式開發的社群組成了Agile Alliance(http://www.agilealliance.com/)，並且發表了Agile宣言與原則。

The Agile Manifesto (敏捷宣言)

獨立的工作成員與人員互動 勝於 流程與工具的管理

工作產生的軟體 勝於 廣泛而全面的檔案

客戶的合作 勝於 契約的談判

響應變動 勝於 遵循計劃

The Agile Principles (敏捷原則)

最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿意。

歡迎需求的變動，即使是在開發的晚期。敏捷式流程駕馭變動來作為客戶的競爭優勢。

頻繁的交付工作產生的軟體，自數週至數月，週期越短越好。

領域專家與開發成員必須一同作業，並貫穿整個專案開發時期。

使用積極的工作成員來建構專案，給予他們環境以及支援所需的一切，然後信任他們能夠完成工作。

在開發團隊中最快也最有效的傳遞資訊方法就是面對面的溝通。

工作產生的軟體是衡量進度最主要的依據。

敏捷式流程倡導水平一致的軟體開發

專案發起者，開發人員以及使用者都必須持續的維持專案進度。

持續重視技術的優勢以及設計質量

最好的架構、需求以及設計會出現在能夠自我管理的團隊裡

在規律的反覆之間，團隊會反省與思考如何更有效率，然後相對的來調整與修正團隊的開發方式。

透過以上的條文相信讀者都能比較瞭解敏捷式開發的一些精神。當然，既然稱作一種原則，就代表團隊引用敏捷式開發時，並非照本宣科的一股腦引用，而是應該審視團隊與公司的文化及產業特性，來評估能夠參考的部份。

延伸思考

其實延伸敏捷式開發的議題，筆者聯想到一個一直在臺灣軟體資訊界爭論不休的問題，就是CMMI究竟對臺灣軟體有沒有幫助。其實敏捷式開發的精神與CMMI這類流程與制度導向的觀點在某些層面是有衝突的，如果制度化一切是個良方，那麼敏捷式開發出現就顯得沒有道理。

但是反過來思考，制度化的開發也使得印度內的軟體公司不斷壯大，他們很顯然的不會是使用敏捷式開發來運作。

若是有時間，或許大家可以來思考這樣的議題，希望對於臺灣的軟體界能夠有所幫助吧。