雖然自己一身從事著軟體開發的工作，但是對於平時採用何種開式模式卻很少思考過，今天特地花了點時間看了一些文件，感覺自己以前的開發模式採用瀑布模式的比較多，如果是相對大一點的專案，採用這種開發模式風險大一點，如果採用迭代模式，則風險相對小一點。如果某家公司是做軟體外包的業務，則適合於採用迭代模式進行開發(如果是小專案而且工期又短就另說了，一般軟體外包的專案不會太小），如果是小專案且需求比較清楚，如開發乙個新聞發布系統，不到乙個月就可以完工，則採用瀑布模式會比較合理。
1.瀑布模式
我們開發乙個產品，如果不太複雜，會採用瀑布模型，簡單的說就是先需求定義，然後構建框架，然後寫**，然後測試，最後發布乙個產品。
這樣，幾個月過去了，直到最後一天發布時，大家才能見到乙個產品。
這樣的方式有明顯的缺點，假如我們對使用者的需求判斷的不是很準確時——這是很常見的問題，一點也不少見——你工作了幾個月甚至是幾年，當你把產品拿給客戶看時，客戶往往會大吃一驚，這就是我要的東西嗎？
via:2.迭代模式
迭代的方式就有所不同，假如這個產品要求6個月交貨，我在第乙個月就會拿出乙個產品來，當然，這個產品會很不完善，會有很多功能還沒有新增進去，bug很多，還不穩定，但客戶看了以後，會提出更詳細的修改意見，這樣，你就知道自己距離客戶的需求有多遠，我回家以後，再花乙個月，在上個月所作的需求分析、框架設計、**、測試等等的基礎上，進一步改進，又拿出乙個更完善的產品來，給客戶看，讓他們提意見。
就這樣，我的產品在功能上、質量上都能夠逐漸逼近客戶的要求，不會出現我花了大量心血後，直到最後發布之時才發現根本不是客戶要的東西。
這樣的方法很不錯，但他也有自己的缺陷，那就是周期長、成本很高。在應付大專案、高風險專案——就比如是太空梭的控制系統時，迭代的成本比專案失敗的風險成本低得多，用這種方式明顯有優勢。
如果你是給自己的單位開發乙個小mis，自己也比較清楚需求，工期上也不過花上個把月的時間，用迭代就有點殺雞用了牛刀，那還是瀑布模型更管用，即使是做得不對，頂多再花乙個月重來，沒什麼了不起。
via
3.敏捷開發
人與人之間的互動是複雜的，並且其效果從來都是難以預期的，但卻是工作中最重要的方面。
-- tom demacro和timothy lister
敏捷軟體開發宣言：
n 個體和互動 勝過 過程和工具
n 可以工作的軟體 勝過 面面俱到的文件
n 客戶合作 勝過 合同談判
n 響應變化 勝過 遵循計畫
雖然右項也有價值，但是我們認為左項具有更大的價值。
敏捷宣言遵循的原則：
n 我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。
n 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
n 經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
n 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
n 圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
n 在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。
n 工作的軟體是首要的進度度量標準。
n 敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。
n 不斷地關注優秀的技能和好的設計會增強敏捷能力。
n 簡單是最根本的。
n 最好的構架、需求和設計出於自組織團隊。
n 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
當軟體開發需求的變化而變化時，軟體設計會出現壞味道，當軟體**現下面任何一種氣味時，表明軟體正在腐化。
n 僵化性： 很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其它改動。
n 脆弱性： 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。
n 牢固性： 很難解開系統的糾結，使之成為一些可在其他系統中重用的元件。
n 粘滯性： 做正確的事情比做錯誤的事情要困難。
n 不必要的複雜性： 設計中包含有不具任何直接好處的基礎結構。
n 不必要的重複性： 設計中包含有重複的結構，而該重複的結構本可以使用單一的抽象進行統一。
n 晦澀性： 很難閱讀、理解。沒有很好地表現出意圖。
敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計，因此，不需要乙個成熟的初始設計。他們更願意保持設計盡可能的乾淨、簡單，並使用許多單元測試和驗收測試作為支援。這保持了設計的靈活性、易於理解性。團隊利用這種靈活性，持續地改進設計，以便於每次迭代結束生成的系統都具有最適合於那次迭代中需求的設計。
via
參考：rup:
產品的加減法：敏捷開發與快速迭代:
uml:
erwin:
幾種軟體開發模式概述
瀑布模型 wate ll model 是由w.w.royce在1970年最初提出的軟體開發模型，在瀑布模型中，開發被認為是按照需求分析，設計，實現，測試 確認 整合，和維護堅定地順暢地進行。瀑布模型 wate ll model 最早強調系統開發應有完整之週期，且必須完整的經歷週期之每一開發階段，並系...
軟體開發模式
軟體的開發模式包括 大棒開發法 邊寫邊改法 瀑布法 快速原型法和螺旋模式法，它們的定義及特點如下 第一，大棒開發法。它是源於能量爆發創造宇宙，萬物都由能量和物質積聚而成的理論，但如果不是遵循某種正確的排列和組合，形成的將不是預先期望的事物 大棒模式與上述理論一樣 一大堆能量 這裡指開發軟體所需的人力...
軟體開發模式
軟體開發模式大概有11種，如下所示 邊做邊改模型 build and fix model 瀑布模型 wate ll model 快速原型模型 rapid prototype model 增量模型 incremental model 迭代模型 stagewise model 螺旋模型 spiral m...