敏捷模型

最近正在看java敏捷開發這本書
摘抄了其中的一些內容並且簡單的做一了些評價

AMDD更加專注於開發，本書之所以選擇AMDD，除了它提出的觀點和我的很一致外，還因爲它的目的是隻做那些足夠好且必要的建模工作（例如，格式自由的結構圖），也許AM網站上的這段話能很好地總結你對產生工件的感受：“你的目的是爲了產生共享性的概念，而不是要寫出很具體的文檔。”我不需要再多說什麼了。

對於XP，你會遇見很多概念，它們會在本章或整本書中遇到。例如，用戶故事（user stories）、CRC卡片、測試先行設計、版本發佈和迭代計劃等。

你的團隊每天都要構建程序並對它進行單元測試，程序經常要進行集成（也許隨着單元測試的通過提交，會不斷地進行），每兩週（即一次迭代）一個獨立的產品就會產生，可以進行部署。客戶每兩週就會測試驅動或使用新增的功能（每兩個月發佈一個新的版本）。

總之，這是一種軟件開發者和用戶雙贏的局面。

以下是XP項目的生命週期
[img]http://dl.iteye.com/upload/attachment/257777/9f954c32-72e1-3230-b717-d6397e7ac8b4.jpg[/img]

探索階段
一般的探索階段包括一組探索性的活動，它能夠幫你更好地理解客戶的需求和接下來該怎麼設計和構建程序，下面是一些在本階段中可能發生的活動的例子。

n 域建模——領域建模可以幫助你來定義主要的業務概念（實體）和它們之間的關係。

n 用戶接口原形和故事板——有些最初版本的頁面可以使我們清楚地知道用戶對產品界面的要求。而一組相關的界面流程圖就是故事板。

n 用戶故事——一些用戶故事的完成標誌着項目的開始，它們組成了發佈的第一個版本。用戶故事（從某種意義上與要做的事相似）由用戶編寫，用簡短的語言描述出用戶定義的產品功能。注意，雖然之前你所收集的用戶故事的數量由項目來決定，但是應該努力確保它是足夠好的並且是有用的。

n 範圍定義——預先定義項目的範圍可以使你知道什麼需求是需要開發的，什麼是可以延期的。它也闡述了用戶對軟件的期望。

n 分析——這是個綜合性的活動。例如，需要在白板上畫出一個非正式的程序架構圖，列出術語，進行分析。


計劃階段

計劃對於不同的人來說具有不同的意義，對於我來說，至少要包括以下部分：

n 版本發佈計劃——它實際上是爲系統的下一版本所做的計劃。它可以很容易地被表單程序、字處理程序或HTML表格彙總在一起。它列出了在下一版本中將要包括的所有用戶故事，並且按照不同的迭代分組。一般地，一個發佈是有固定時間要求的，最短1個月、最長3個月，兩個月一般是比較好的選擇。

n 迭代計劃——在每一次迭代之前都要有一個迭代計劃，包括在下一次迭代中客戶希望實現的用戶故事。迭代時間一般也是固定的，最短一週、最長3周，兩週一般是比較好的選擇。

n 規範定義（代碼、數據庫、過程）——在開始任何開發之前，爲一些東西制定規範來統一化是非常好的做法。例如，這些規範包括：編碼約定、數據庫命名約定和過程（包括構建、繼承和發佈）約定等。


產品的迭代開發階段（漸進式構建軟件）

迭代開發也許是一個你很熟悉的術語，但是不同的人使用不同的軟件開發方法，對迭代和每個迭代過程所包含的內容的理解是不同的。

在我看來，迭代開發意味着每一次迭代中都要有設計、編碼、用戶驗收和生產就緒代碼的部署。生產就緒的代碼要部署到生產環境中，如果在一個大公司，經常部署到生產環境並不是很現實，需要把它先部署到驗收環境中，只要用戶驗收通過，就可以進入到下一個迭代過程中了。總之，每次迭代需要有以下的事件：

n 開發人員對開發任務進行評估，制定下次的迭代計劃；

n 客戶和開發人員事先的溝通交流；

n 設計——包括CRC卡、UML圖等；

n 編碼——測試先行，按照要求重構代碼/數據庫/程序架構，在最後階段優化；

n 用戶驗收測試（UAT）。

n 將迭代後的版本部署到生產環境或驗收環境中，這個過程也叫做發佈一個小版本。

按照這樣的方式進行迭代，可以不斷地建立項目的下一個版本。假定一個項目，我們估計會在3個月內完成，我們會把它分解成每兩週一次的迭代，所以會有大約6次的迭代開發。

每一次迭代的截止時間是工程可以進入下一個階段的時候，換句話說，迭代的小版本成爲了生產就緒的代碼（穩定的代碼），即使它只是完整系統的一個子集。