時至今日，Agile Process的精神已經成為共識，但是沒有一種固定的流程可以重復使用在不同的方案上，而且不管是RUP、XP、SCRUM、或其他的開發流程都允許相當大的彈性，我們必須按方案性質的不同，調整或混合出適合的開發流程，并允許團隊在進行中做必要的彈性修改，才能夠達成目標。
2.敏捷之驅動開發
在XP開發實踐中的TDD(Test Driven Development)，它有一個別稱叫 Test-First Programming，要求開發的第一步是根據需求，必須先寫單元測試程序，然后再寫實現程序讓符合需求的測試通過。我們知道XP中的需求是以“用戶故事”(User Story)的形式描述的，而用戶故事實質上就是一種軟件“特性”(Feature)。TDD 講的是如何通過編寫“測試”，尤其是單元測試，來驅動軟件的設計和編程。
系統測試從哪里來?來自系統需求。系統需求從哪里來?來自用戶目標，TDD則也不例外。在需求不穩定的情況下，這樣的TDD會有什么問題?會不會帶來許多冗余的工作?答案是肯定的，這樣必然會帶來單元測試的不穩定，這就需要敏捷開發人員有相當強的抽象能力，抽象、界定出主要相對穩定需求就可以實施TDD。
敏捷團隊可以采用在軟件工程學里有比較成熟的OOAD(Object Orient Analysis & Design，面向對象的分析和設計)軟件開發方法(參見筆者著作《我也能做CTO之程序員職業規劃》的高級程序員技術能力)，在用戶需求層面找到，并抽象出相對不變的需求。OOAD科學分析法體現的是‘現實事實的抽象理解能力’，以業務為中心來分析解決問題，不涉及求解方案。分析階段所做的主要工作是理解問題和需求構模，將現實世界中的問題映射到問題域，從而穩定主要需求。OOAD包括‘設計模式能力’，反映計算機世界來體現現實世界。
分析階段主要是明確用戶的功能需求，滿足用戶所需的系統部件及其結構。設計階段則主要是確定實現用戶需求的方法，即怎樣做才能滿足用戶需求，并構造出系統的實現藍圖。
OOAD方法要求在設計中要映射現實世界中(指問題域，如圖2所示)的對象和實體，如程序員、汽車、項目實施人員等。這就需要在設計中盡可能地接近現實世界，以最自然的方式表述實體。所以，面向對象技術的優點就是能夠構建與現實世界相對應的問題模型(橋梁)，并保持它們的結構關系和行為模式。
例如，我們通常做的系統分析是在假定需求不變的情況下進行的，這樣可以把企業的資源配置到最優的程度，但是企業的需求是變化、不穩定的，那么以變化的需求為基礎建立起來的軟件系統當然也就不穩定了。需求是項目的根本，既然需求都是不穩定的，那么何以建立起穩定的企業信息系統呢?
圖2 軟件需求抽象示意圖
采用OOAD開發的方法時的需求不穩定，可分析出這不穩定的東西就是對象。世界都是由對象組成的，而對象都是持久的，例如動物、植物已經有相當長的時間。雖然對象也在變化，動物、植物也在不斷進化。但對象在一個相當長的時期內都存在，動植物的存在時間肯定比任何一家企業長久。面向對象開發方法的精髓就是從企業的不穩定需求中分析出企業的穩定對象，以企業對象為基礎來組織需求、構架系統。這樣得出的系統就會比傳統的系統要穩定得多，因為企業的模式一旦變化，只需將穩定的企業對象重新組織就行了。
在敏捷XP中，采用的是TDD驅動軟件的設計和編程實踐，即，測試驅動開
發。筆者負責過很多項目的敏捷實踐中，更喜歡UDD(Use Case-Driven Development)比較適合目前的國情。它可根據用戶目標，編寫軟件需求，根據軟件需求，編寫系統(驗收)測試，即，用戶目標驅動。利用 UML 對軟件的設計進行建模，這部分建模當然是敏捷的(agile)。簡單的只需幾秒鐘可以迅速在人的大腦中完成，復雜的則可以畫在紙上、白板上，記錄在建模工具生成的電子文檔中，當需求穩定后可以迅速轉化成軟件應用代碼，在結合TDD會有很不錯的效果，這種理論體系有些像太極原理，需求的變化看似武術中的招式，采用UDD見招破招，無招勝有招，這種客戶的需求應變使得UDD更為敏捷。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
