brooks在「20年後的人月神話（the mythical man-month after 20 years）」明確提出了迭代開發的概念「增量開發模型更佳——漸進地精化」。這種開發方法對專案產生的激勵作用是不可估量的，作者在北卡羅來納大學時，「我常常會被螢幕上第一幅圖案、第乙個可執行的系統對團隊士氣產生的鼓舞效果而感到震驚。」而在c++的現實專案中，在極大的壓力下，當第乙個可執行的原型出現在開發人員面前時，長期的疲憊、沮喪一掃而空。從而，為繼續開發提供了動力。這裡，長時間高負荷工作並不是被提倡的，但增量開發是軟體開發動力學的一種重要手段。
迭代開發可以用「外科手術隊伍」、oo及設計模式的實現來實踐。物件導向框架的分析設計思想，並不一定非要用物件導向的語言實現。它的乙個重要特點，是固化使用者要求或者是待開發系統中相對穩定的部分，以犧牲模型某個維度的代價來得到較穩定的模型。然後，在該框架的基礎上不斷地迭代。「外科手術隊伍」則由具有豐富經驗的「外科醫生」操刀，來主持需求分析和建立迭代框架。少數的人能確保框架不帶有過多不必要的非結構性的功能特色，從而保證框架的簡捷和良好的擴充性。
迭代開發本身是對變更這個「怪物」的一劑良藥，不同迭代週期能較好地容納階段（量子）化的變更。在變更的同時，始終有可執行的系統供除錯、測試，從而確保專案的質量——質量決定成本，「遠遠超過終端使用者需求的質量是一種取得更高生產力的手段。」（《人件》，即將由清華大學出版社出版，譯者為umlchina翻譯組方春旭、葉向群）。
同樣，brooks在「未雨綢繆（plan to throw one away）」中提出了拋棄型原型的概念，並在「《人月神話》的觀點：是或非？（propositions of the mythical man-month: true or false？）」中強調「因此，為捨棄而計畫，無論如何，你一定要這樣做。」迭代開發是容納原型，包括拋棄型和非拋棄型。而且，它是乙個很好說服管理層和使用者的途徑——因為，不同的迭代週期和任務本來就在計畫之中。在c++的專案中，對於沒有堅持在框架設計完成之後，拋棄框架**原型，至今還有些遺憾，相應所付出的代價就是產品質量和開發人員對該專案信心的喪失。
另外乙個提高專案產品質量的方法，brooks在「整體部分（the whole and the parts）」的「系統整合除錯」中給出了專家意見，「使用經過除錯的構件單元」、「搭建充分的測試平台」、「一次新增乙個構件」和「階段（量子）化、定期變更」。這在目前的實踐中依然有指導意義。現在的軟體測試水平相信業界人士都非常清楚：很少有規範化的測試；白盒測試基本不做；專案壓力過大，不斷壓縮測試時間……。因此，仔細的系統整合測試非常有必要，能夠做到《人月神話》中，os360的系統測試一半已經非常不錯了。
迭代開發優點
它允許需求的變化。需求的變化和 進一步的蔓延 技術和客戶驅動的特性的累加 一直是專案中導致麻煩 延期交付 令客戶不滿意和使開發人員洩氣的主要原因。為了解決這些問題，使用迭代開發方法的團隊應該在專案開發的幾周裡就關注生成 和演示可執行的軟體，這樣就強制了需求的檢查並可以幫助減少需求從而反映系統的本質。...
迭代增量開發
迭代增量模型是軟體開發過程中 常用的開發模型。其中的增量 是指是軟體開發過程中，先開發主要功能模組，再開發次要功能模組，逐步完善，最終開發出符合需求的軟體產品。比如，需要開發乙個類似word的軟體，應該首先開發出檔案管理 儲存 讀取檔案 基本編輯功能 列印等，而其它不太常用的功能可以最後開發。迭代 ...
迭代開發規範
開發任務在需求管理系統 redmine 建立總的任務單 包含概要設計文件 詳細設計文件 開發子任務 整體驗收測試規程 之後根據任務拆分建子任務單，專案開發人員根據各自特長認領開發任務，每個子任務有明顯進展及時更新子任務狀態 子任務完成進度可參考以便專案管理者檢視最新專案整體進度。迭代開發 功能單 開...