各類大中小型企業所運用的傳統軟體構建方法，即是眾人皆知的「瀑布」型開發方法。此模型存在很多變體，其典型性是在開發初期制定詳細的計畫，在計畫中最終產品已被仔細研究，設計，並且一切詳細資料都記錄在案。任務已設計制定，並且在工作中使用如根特圖表等工具和microsoft project專案管理軟體進行專案管理工作。開發團隊預計開發專案的時間是以累計其相關每一步驟而得出的。當專案管理者(stakeholder)全面審核開發計畫並表示贊同，開發團隊即時開始工作。團隊成員完成他們所專長的部分工作，即刻轉交給其他成員，形成生產流水線的形式。當全部工作都已完成，成品將轉交給產品質量控制部門，在這裡將會進行在產品到達客戶手中之前的全面檢測工作。在整個流程中，所有相對於原始計畫的分歧都將受到嚴格的控制，以保證生產的成品與原始設計保持一致。此種模式優缺點明顯。有點是非常有邏輯性，在構建之前思考，並全部記錄下來，按照計畫實施，保持各項食物盡可能的有組織性。弱點是人的參與。比如，要求所有的建議和想法都要在開發周期的最初階段提出，此時建議和想法將可以被溶入到開發計畫中，但是眾所周知，好的想法和建議的出現會貫穿整個開發過程，在開發最初的階段，在開發中期，也可能在產品交付前一天，如果整個開發過程中不容許變化的產生，那麼將會遏制創新的產生；另一點就是諸如定型老產品用新技術重新替換之類專案，由於需求分析階段的盲從性及時間緊迫等等因素的干擾，導致分析出現偏差，最終帶來的後果是預估時間不夠，專案進展達不到預期的目標，對整個產品開發帶來危機。瀑布式開發方式特別注重將事件記錄在案，以此作為傳遞重要資訊的首要方法。因此最合理的假定是如果我們可以把想法盡可能地記錄在案，這樣將會使資訊更可靠地傳輸到團隊的每乙個成員的頭腦中，但是很多情況下沒人會大量閱讀文件，即便閱讀了也會有產生誤解的可能性。
當人參與時，還有一種情況會發生――「實際應用中產生的靈感」――實際開發過程中很多創意是到開發的最後階段才被提出並且實現的。在專案最初階段無法準確判斷開發的走向。
人的預知未來的能力是有限的。不可**的技術問題的突然出現，會強制開發方向的轉變。此外，人們對於未來作出長遠計畫的能力的欠缺也導致了你無法估計出未來數月內每週你的工作安排。
另外，瀑布式開發由於成員經常改動想法或不能對不能控制的東西負責等等此類容易促使團隊成員產生敵對的關係，讓工作毫無興趣可言。事實上，進一步說，瀑布式開發是造成產品開發人員苦惱的根源，並且最終產品將不會體現出他們的創造力，技能和開發創造者的激情。人不是機械人，此種將人認為是機械人的流程將會造**們工作激情的喪失。
另外，乙個拒絕變革的流程也會造成低劣產品的產生，最原始的需求未必和最終的產品相一致，拒絕開發團隊在實踐中不斷發現可能性而是其盡善盡美的計畫也會是乙個失敗的計畫。
許多使用瀑布型方式的團隊不斷的體驗到了它的缺陷，但是它看起來是如此具有邏輯性的方式，因此第一的自然反映就是對內部工作的譴責：「如果我們嘗試更好的使用它，如果我們的計畫更加詳盡，記錄更加仔細，拒絕任何變革，一切將會很順利地進行。遺憾的是，許多開發團隊只得到的相反的效果；結果越差。」
瀑布式開發和敏捷開發的對比
瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷...
瀑布式開發和敏捷開發區別
敏捷開發，首先把客戶最關注的軟體原型先做出來，交付或者上線，在實際場景中去修改彌補需求中的不足，快速修改，再次發布版本。再次上線或者交付。通過一些敏捷實踐方式，細化story，可以提供更小的迭代。如此迴圈，直到使用者 客戶 滿意。適用於需求不明確的專案 創新性的專案或者需要搶占市場的專案。瀑布式開發...
瀑布式開發和敏捷開發的對比
瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷...