IT業(yè)界正在經(jīng)歷著(zhù)重大的改變，從慣例性的開(kāi)發(fā)方法（prescriptive development techniques）轉化為敏捷方法。經(jīng)常出現令人困惑的現象，開(kāi)發(fā)者不愿意遵循過(guò)程，也弄不明白希望遵循的幾千頁(yè)文檔倒底哪里有問(wèn)題。隨后出現了備受開(kāi)發(fā)者歡迎的敏捷方法，例如極限編程(xp)，特征驅動(dòng)的方法FDD，以及敏捷建模，不幸的是，很多管理人員對敏捷方法持保留態(tài)度，不愿意采用他們，這就產(chǎn)生了一種矛盾，開(kāi)發(fā)者愿意遵循這些經(jīng)過(guò)驗證的軟件過(guò)程，但是他們卻不能這樣做。
下面是4種重要的開(kāi)發(fā)方法：
- 敏捷軟件開(kāi)發(fā)
- 統一建模語(yǔ)言UML
- 統一過(guò)程
- 模型驅動(dòng)架構
傳統慣例性軟件開(kāi)發(fā)方法的問(wèn)題：
- 慣例性過(guò)程在業(yè)界失敗率相當高
- 大多數開(kāi)發(fā)人員不愿意采用慣例性過(guò)程，不管有沒(méi)有意識倒，他們會(huì )找到各種理由破壞這種嘗試
- “大設計先行big design up front”的方法，對于軟件開(kāi)發(fā)來(lái)說(shuō)是相當危險的，因為他們無(wú)法支持變化和反饋
- 大多數慣例性對于實(shí)際的軟件開(kāi)發(fā)人員來(lái)說(shuō)，起到推動(dòng)作用是很小的
為了迎接這些挑戰，2001年2月，17個(gè)方法學(xué)家組成的敏捷軟件開(kāi)發(fā)聯(lián)盟
www.agilealliance.org ，經(jīng)過(guò)討論，達成了一致性的觀(guān)點(diǎn)：
如果要在軟件開(kāi)發(fā)中取得成功，需要關(guān)注以人為中心的問(wèn)題，并遵循那些易于支持變化的開(kāi)發(fā)技術(shù)，他們編寫(xiě)了敏捷宣言，定義了4項價(jià)值以鼓勵更好地開(kāi)發(fā)軟件：
1． 個(gè)體和交互勝過(guò)過(guò)程和工具
強調人是軟件項目獲得成功最重要的因素，但是光有優(yōu)秀的程序員還是不夠的，需要構建團隊，構建團隊需要團隊成員能夠很好的合作，溝通。
合適的工具是非常必要的，但是沒(méi)有必要使用過(guò)于龐大笨重的工具。除非項目特別的需要，否則使用最簡(jiǎn)單夠用的工具。
2． 可以工作的軟件勝過(guò)面面俱到的文檔
首先作者指出了，沒(méi)有文檔的軟件是一種災難，代碼不是傳達系統原理和結構的理想介質(zhì)。然后又指出如果文檔太多，將會(huì )比沒(méi)有文檔更具有災難性。這是因為：維護文檔需要很大的工作量，如果文檔和代碼不可以保持一致，文檔就會(huì )成為一種謊言。作者強調了文檔的重要性，同時(shí)又說(shuō)沒(méi)有必要維護太多的文檔，直到迫切感到需要文檔的時(shí)候才使用文檔。
3． 客戶(hù)合作勝過(guò)合同談判 客戶(hù)可能沒(méi)有一次確定問(wèn)題本質(zhì)的能力，有時(shí)他們會(huì )改變主意，與客戶(hù)一起工作是艱苦的，但是這是工作的現實(shí)情況。軟件開(kāi)發(fā)人員需要不斷的得到客戶(hù)的反饋，而合同往往會(huì )隨著(zhù)時(shí)間的變化和需求的變更變得沒(méi)有意義。
4． 響應變化勝于遵循計劃
業(yè)務(wù)環(huán)境在變化，技術(shù)也在變化，響應變化的能力常常決定著(zhù)一個(gè)軟件項目成敗，當我們制定計劃時(shí)，應該確保計劃是靈活的，并且易于適應商務(wù)上和技術(shù)上面的變化。
關(guān)于怎樣制定計劃，作者給出了這樣的建議：
1） 計劃不能考慮的太遠，這是因為i商務(wù)環(huán)境可能變化，II一旦客戶(hù)看到運行的軟件，客戶(hù)可能會(huì )提出改變的建議（這一點(diǎn)很常見(jiàn)喲）III即便我們確信客戶(hù)的需求是不會(huì )變更的，正確的估計項目時(shí)間也并非易事。
Q：上級交給了我一個(gè)任務(wù)，我們怎樣才能正確地估計時(shí)間？
2） 作者給出了一個(gè)他認為合理的制定計劃的策略，為下兩周作一個(gè)詳細的計劃，為下三個(gè)月做出一個(gè)粗略的計劃，在以后就做極為粗糙的計劃了。我們應該清楚地知道下兩周要完成的任務(wù)，粗略的了解一下以后三個(gè)月要實(shí)現的需求，系統一年后要做什么，有一個(gè)粗糙的想法就行了。
由敏捷宣言的四句話(huà)引出了敏捷的12個(gè)原則：這12個(gè)原則是敏捷方法區別于重型過(guò)程的特征所在。
1． 我們最優(yōu)先要做的是通過(guò)盡早的，持續的交付有價(jià)值的軟件使客戶(hù)滿(mǎn)意
敏捷之所以這么做是因為，盡可能早的交付可以更好的得到客戶(hù)對需求理解的反饋，從而可以讓客戶(hù)更具已有的系統引導團隊開(kāi)發(fā)出滿(mǎn)足他們需求的軟件。
敏捷為什么這樣做呢？作者給出了這樣一個(gè)論文結論來(lái)做這一條原則的論證：“初期交付的系統中包含的功能越少，最終交付的系統質(zhì)量越高。”，“系統交付的越頻繁，最終產(chǎn)品的質(zhì)量就越高。”
2． 即使到了開(kāi)發(fā)的后期，和歡迎改變需求，敏捷過(guò)程通過(guò)變化來(lái)為客戶(hù)創(chuàng )造競爭優(yōu)勢。
這是一個(gè)關(guān)于態(tài)度的聲明。
作者指出了敏捷使用者不懼怕需求的改變，是因為他們會(huì )盡力的保證軟件的靈活性；通過(guò)什么來(lái)保證靈活性呢？是通過(guò)面向對象設計和模式。這一點(diǎn)說(shuō)明敏捷是離不開(kāi)OO的。不過(guò)這一點(diǎn)并不是什么區別于重型過(guò)程的特征所在。重型的方法也會(huì )努力的保持軟件的靈活性的。
3． 經(jīng)常性的交付可工作的軟件。交付的間隔時(shí)間越短越好，間隔的時(shí)間可以從幾個(gè)月到幾周。
經(jīng)常性的交付確實(shí)可以更好的把握用戶(hù)的需求。從而提高系統的質(zhì)量。
4． 在整個(gè)項目的開(kāi)發(fā)期間，業(yè)務(wù)人員必須和開(kāi)發(fā)人員天天在一起工作。
為了溝通更好的了解需求。
5． 啟用有積極性的開(kāi)發(fā)者，給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作。
敏捷把人作為項目成功的最主要的因素，過(guò)程環(huán)境和管理都被認為是次要的，如果他們對人有負面影響，就要對他們進(jìn)行改變。
6． 最好的交流方式是面對面的交流。
強調了最好的交流方式是面對面的交談，而并非文檔。
7． 可以工作的軟件是首要的進(jìn)度度量指標。
8． 敏捷過(guò)程提倡可持續的開(kāi)發(fā)。責任者，開(kāi)發(fā)者，用戶(hù)要保持一個(gè)長(cháng)期的恒定的開(kāi)發(fā)速度。
9． 不斷的關(guān)注優(yōu)秀的技能和好的設計可以提高敏捷能力。
10． 簡(jiǎn)單是至關(guān)重要的，簡(jiǎn)單拒絕過(guò)渡設計。
11． 最好的架構，需求和設計出自于自組織的團隊。
這一點(diǎn)和傳統的分析人員，設計人員，開(kāi)發(fā)人員… 分的很細有很大的區別，在敏捷團隊中任何人都可以參與分析，設計，開(kāi)發(fā)。
12． 每個(gè)一定的時(shí)間團隊都會(huì )對如何才能更有效的工作方面做出總結，反省。然后相應的對團隊的行為進(jìn)行調整。
以人為本的敏捷開(kāi)發(fā)
“既然無(wú)法阻止變化發(fā)生，我們就要找出適應變化的方法。”Fowler并非空手而來(lái)，隨他登場(chǎng)的還有敏捷開(kāi)發(fā)。
什么是敏捷開(kāi)發(fā)？一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法。在敏捷開(kāi)發(fā)中，軟件項目的構建被切分成多個(gè)子項目，各個(gè)子項目的成果都經(jīng)過(guò)測試，具備集成和可運行的特征。簡(jiǎn)言之，就是把一個(gè)大項目分為多個(gè)相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過(guò)程中軟件一直處于可使用狀態(tài)。
敏捷開(kāi)發(fā)是全新理論嗎？答案莫衷一是。細心的人們可以發(fā)現，敏捷開(kāi)發(fā)其實(shí)借鑒了大量軟件工程中的方法。迭代與增量開(kāi)發(fā)，這兩種在任何一本軟件工程教材中都會(huì )被提到的方法，在敏捷開(kāi)發(fā)模式中扮演了很重要的角色。再向前追溯，我們還也可見(jiàn)到瀑布式與快速原型法的影子，也許還有更多。
改善，而非創(chuàng )新。敏捷開(kāi)發(fā)可理解為在原有軟件開(kāi)發(fā)方法基礎上的整合——取其精華，去其糟粕。因此敏捷開(kāi)發(fā)繼承了不少原有方法的優(yōu)勢。“在敏捷軟件開(kāi)發(fā)的過(guò)程中，我們每?jì)芍芏紩?huì )得到一個(gè)可以工作的軟件，”Fowler介紹，“這種非常短的循環(huán)，使終端客戶(hù)可以及時(shí)、快速地看到他們花錢(qián)構建的軟件是一個(gè)什么樣的結果。”
