靈活模型

最近正在看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次的疊代開發。

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