1：瀑布方法
所有軟件方法的祖先是瀑布方法（waterfall methodology）。它之所以被稱為瀑布方法是因為開發模塊相互之間的依次流動，瀑布方法通過控制閥門的壹系列活動組成。這些控制閥門決定壹個給定的活動是否已經完成並且可以進入下壹個活動。需求階段處理決定了所有的軟件需求。設計階段決定整個系統的設計。代碼在代碼階段編寫。代碼然後被測試。最後產品被發布。
對瀑布方法模型最基本的批評就是瀑布方法對於反饋事物發展狀況耗時太長。軟件的壹些內容那個很容易被理解，而另壹些內容則相反。因此，當用戶對於手邊出現的問題都沒有很好理解的時候，開發人員試圖先完成所有的需求（也就是說，將需求量化到實際的規格說明當中）是非常空難的。更進壹步來說，如果在需求中出現壹個錯誤，它將傳播到設計階段，傳播到代碼中等。同時壹般不存在過程中返回的真正能力。因此，如果進入測試並且發現設計的壹部分是無法工作的，那麽就會進行修改並修補問題而交差，但是這種方法將會失去設計活動的所有上下文環境——妳只是有目的地對系統權宜行事！
認識到這個問題後瀑布方法已經被修改成幾種形式。例如螺旋式瀑布方法它繼承並使用了多個瀑布模型。這種方法縮短了生命周期向下的時間；也就是說，為解決為題提供了叠代方案。
最終，大家無法脫離瀑布方法是因為它確實是合乎常規的方法。首先，這種方法可以決定將要構建的內容。接著，決定將要如何構建這些，下壹步，世界構建這些內容。可以確保自己確實構建自己所需的東西（並且可以成功運行）。
2：統壹過程
統壹過程應用了基於處理系統首先考慮的最重要方面而實施的短期叠代開發。
開發壹個寡欲各種用列（use case）的調查文檔（也就是說，對用戶與系統交互的簡短描述），並且開始排除那些可能對整個系統成功造成風險的用列。只要適合，就可以在開發過程中添加或者刪除用列。
統壹過程的4個階段定義如下：
初始(inception)：系統仍然處於決定系統內容的階段——系統將要完成什麽以及系統的邊界是什麽。如果系統能夠很好的理解，那麽這個階段就非常短。
細化(Elaboration)：正在將體系結構的風險移至系統。壹種表述該階段的說法是，“妳是否已經解決了所有難題？”或者“妳知道如何完成妳將要去完成的事情嗎？”
構造（）正在完成所有相關的用列來使系統為移交做好準備，也就是說，進入Beta版本。
移交（Transition）使系統通過它的最後發布階段以及Beta版本。它可能包括軟件的操作及維護。
這是壹個關註於維護要素的敏捷過程，但是仍然采用了大量用例開發，間模等方面的傳統實踐。
3：極限編程：
極限編程的開發過程就是以代碼為中心的方法。
讓用戶告知妳壹些有關系統是如何如用轉的故事描述，基於故事相互之間的重要性來定制這些系統這樣就可以為自己的團隊提供壹個故事集合，可以在壹個給定的叠代中完成他們，大約兩周時間——每周工作40個小時，妳將團隊劃分，雙人應付沒壹個故事，在代碼被編寫時提供確定數量的內建對等評審。妳和妳的同伴在編寫自己代碼的同時編寫單元測試。在完成自己負責的那段代碼後，將其拿到集成的機器上，放入代碼基線，運行從所有人的代碼中積累而成的單元測試。在完成iji負責的那段代碼後，將會提供壹個運行系統使用戶可以評審來確保自己的工作滿足他們的需要。
註意極限編程並沒有將軟件的設計設置成壹個高級階段。相反它認為那些最前端的設計對於整個系統開發不是很有幫助，並且隨著實際開發的進行它最終還是被修改。
極限編程對於需要持續提供運行系統的軟件卡發來說非常適用。當缺少用戶介入或者項目規模很大時極限編程方法將會不好用，因為這時協調和設計活動實際上變得更重要了。
極限編程合理地考慮開發團體的能力，這樣可以有效計劃。