談到架構，人們最常想到的就是建築。這得感謝亞歷山卓大叔的功勞。另外，設計模式的成功引入到軟體工程，也是乙個促進。這個成功案例讓很多人都去拜讀《建築之永恆之道》。
最近在討論中，突然發現樓房在構建的時候，大部分都是採用迭代式開發的。感覺甚是有意義，特拿出來和大家分享。
我們將樓房中的每乙個房屋比喻成軟體中的功能。那麼在開發過程中，如何計畫這些功能的開發順序，以及每乙個功能的開發步驟，就是乙個非常大的學問。相信每乙個經歷過專案的人都知道。安排不好，就會導致無謂的相互等待。
我們以前預設的工作方式是，將所有的功能模組，全部分出去。先做區域性劃分。比如，什麼型別的模組，由什麼小組來負責。然後在此基礎上，每個小組再安排自己的模組。因為人手一定是比模組數少的多的，所以必然有一部分認為不重要的模組被安排在後面。
請注意上面的模組安排方式。整個功能的安排，是根據開發小組的特性來安排的，加上層級的劃分，對於軟體工程整體計畫的把握性越來越低。特別是專案在每乙個時刻的整體狀況不好判斷。你說寫完了一半的模組的軟體是什麼狀況？不好說吧。我們一般可能會採用另外一種容易接受的方式來描述：
「嗯，現在的軟體可以完成基本功能了。下週就可以交付客戶驗證業務流程了。」
這種描述，由於是從最終結果來描述的，所以往往能被領導和客戶所接受。如果你細心點的話，你就會發現這裡面有乙個問題，如何衡量進度？軟體工程目前並不成熟，所以才導致進度衡量非常麻煩。其中最麻煩的就是軟體模組的整合。每乙個人對於整合都是持懷疑態度的。觀察一下其他成熟行業，特別是建築行業，高度的規格化建設，保障了其在整合的時候的低風險。有一句話常常說，工業化就是規範化。乙個軟體公司或乙個軟體專案，如果做不到這些規範化，那麼就會一直擔心整合。對於進度的把握就會存在問題。
廢話少說，我們看看樓宇的迭代過程。先來做基礎，越高的房子，地基越要打號。再做框架部分，一般是澆築鋼筋混凝土；然後填補減力牆；水、電管道；裝飾裝修。顯然，每一次里程碑的劃分，並沒有按照模組的多少，而是按照大樓的整體結構。
我們軟體做不到類似建築這樣成熟的劃分。但是我認為可以從需求角度，進行幾個里程碑式的劃分。
第一、完成系統基礎技術的工作。類似於建築的地基。
第二、完成系統中功能組合關係的框架。所有的功能都可以在這個框架下進行增加、除錯。這裡面要完成系統在架構過程中要求的模型及各種應對業務變化的模式。
第三、完成系統的基本功能。什麼是基本功能？軟體的目的是解決問題，如果能用使用我們的軟體，雖然比較繁瑣，但是已經可以解決問題了。那就是完成了基本功能。比如乙個郵件系統，已經可以傳送收取郵件了，那麼基本功能就完成了。
第四、完成基礎易用性需求。什麼較基礎易用性？我們軟體在業務分析的時候，必然考慮了使用者的一些基本需求。這時候已經是乙個完整的軟體了。但是沒有什麼亮點。
第五、完整實現系統的規劃。將最後展現給使用者的功能完全實現。其實使用者只看到這些，其他的他們都不是很在乎。當然了，雖然他們會一直使用。就比如你住的房子，你最關注的是房子裡的裝修。但是如果沒有水、電，房子有危險，你肯定會非常不滿意。
我們一直在說迭代，但是基於迭代的方法及步驟卻沒有細化下來。建議我們來多做做這方面的知識積累。大家也多分享一些迭代的過程，共同成長。上面的里程碑劃分，是參考建築來做的，我在實踐中並沒有完全按照上面的方式，一般遇到第四個里程碑的時候，就會出現混亂。大家想法不容易在乙個層次上集中。不過總算是乙個想法吧。
迭代式開發技術
迭代是一開發種技術，用來把系統功能傳遞到一系列的增量的完整版本，每個版本乙個特定固定的時間段被開發，該時間段稱之為迭代。每個迭代的經歷過程 整個迭代過程 圖中顏色代表每次開發每項活動所佔的比重不同 迭代式開發的優點 1 降低風險 2 得到早期使用者反饋 3 持續測試和整合 4 適應變更 開發特徵 1...
迭代式開發技術
迭代是一開發種技術，用來把系統功能傳遞到一系列的增量的完整版本號，每乙個版本號乙個特定固定的時間段被開發，該時間段稱之為迭代。每乙個迭代的經歷過程 整個迭代過程 圖中顏色代表每次開發每項活動所佔的比重不同 迭代式開發的長處 1 減少風險 2 得到早期使用者反饋 3 持續測試和整合 4 適應變更 開發...
一次迭代式開發的研究 怎樣進行迭代式開發
前面我們提到了迭代式開發的巨大優勢，它可以降低我們軟體開發的巨大風險，它可以使我們把握使用者的真正需求，它可以使我們從錯誤與偏差中及時糾正過來，那麼我們應該如何進行迭代式開發呢？要回答這個問題，我們首先要弄清迭代式開發與傳統的瀑布式開發的差別在 b 1.需求分析的差別 b 與傳統的軟體開發一樣，迭代...