在軟體開發的浪潮中，各種敏捷開發方法層出不窮，傳統的「瀑布式」開發一夕之間遭受各種質疑。為什麼「瀑布式」開發的小船說翻就翻？到底**出了問題？
各類大中小型企業所運用的傳統軟體構建方法，即是眾人皆知的「瀑布」型開發方法。此模型存在很多變體，但其典型性是在開發初期制定詳細的計畫，在計畫中最終產品己被仔細研究，設計，並且一切詳細資料都記錄在案
任務已設計制定，並且在工作中使用如gantt (甘特)圖表等工具和microsoft project專案管理軟體。開發團隊預計開發專案的時間是以累計其相每關一步驟而得出的。當專案管理者(stakeholder)全面審核開發計畫並表示贊同，開發團隊即時開始工作。團隊成員完成他們所專長的部分工作，即刻轉交給其他成員，形成生產流水線的形式。當全部工作都已完成，成品將會轉交給產品質量控制部門，在這裡將會進行在產品到達客戶手中之前的全面檢測。在整個流程中，所有相對於原始計畫的分歧都將受到嚴格的控制，以保證生產的成品與原始設計保持一致。
此種模式有優點但也有不足之處。它的最大的優點是非常有邏輯性：在構建之前思考，並全部記錄下來，按照計畫實施，保持各項事務盡可能的有組織性。它有乙個最大的弱點就是：人的參與。
比如：此種方式要求所有的建議和想法都要在開發周期的起始階段提出，此時建議和想法將可以被融入開發計畫之中。但是眾所周知，好的想法和建議的出現會貫穿整個開發過程——在開發啟始階段，在開發中期，有時可以在產品交付使用的前一天，如果整個開發過程中不容許變化的產生，那麼將會遏制創新的產生。在使用「瀑布」型開發方式時，開發末期出現的創新將不是好的徵兆，而是對整個產品開發產生的危機。
瀑布型開發方式特別注重將事件記錄在案，以此作為傳遞重要資訊的首要方法。因此合理的假定是如果我可以把我的想法盡可能都記錄下來，這樣將會使資訊更可靠的傳輸到團隊每乙個成員的頭腦中；另外，因為所有東西都記錄在案，這將是我完成任務的實際的證據。但是實際上，在大多數情況下，沒人會讀這些50頁左右的詳細規格要求資料。同樣，如果有人讀取該資料，那麼將會產生許多的誤解。記錄的資料只是我頭腦中想法的抽象提取；當你閱讀此資料時，你將會產生另乙個抽象的概念，此時與我的真正想法已經相距甚遠了。所以嚴重誤解的產生也就不足為奇了。
當人參與時,還有一種情況會發生——「實際應用中產生的靈感」——在第一次實際應用產品時，你可能會立刻產生20種使產品更加完美的靈感。但是遺憾的是，這些非常有價值的想法通常會在產品開發的末期產生，這時創新是困難和具有**性的——換句話說，是做正確抉擇昂貴的時刻。
人的預知未來的能力是有限的。比如，某場比賽的終結果是出人意料的。不可**的技術問題的突然出現，會強制開發方向的轉變。此外，人們往往非常欠缺對於未來作出長遠計畫的能力——今天猜測未來八個月中每週你如何工作將如幻覺般渺茫，這正是gantt (甘特)圖表的衰敗表現。
另外，瀑布型方式將會促使團隊成員在交接工作時產生敵對的關係。「他要求我構建在規範要求中不存在的東西。」「她經常改變主意。」「我不可能對我不能控制的東西負任何的責任。」這些都引起我們對瀑布方式的另一種思考——在此種方式中工作毫無興趣可言。事實上，進一步說，瀑布型方式是造成產品開發人員苦惱的根源，並且最終產品將不會體現出他們的創造力，技能和開發創造者的激情。人不是機械人，此種將人認為是機械人的流程將會造**們工作激情的喪失。
乙個僵硬的，拒絕變革的流程也會造成低劣產品的產生。客戶可能會得到根據他們第一需求所生產的產品，但是產品在形成階段時還是客戶真正需要的嗎？在開發之前收集所有的需求並將它們嵌入毫無改變可言的頑石般的計畫中，此產品將被宣告只會和起始的想法保持一致，而不是開發團隊在實踐中不斷發現可能性而使其盡善盡美。
許多使用瀑布型方式的團隊不斷的體驗到了它的缺陷，但是它看起來是如此富有邏輯性的方式，因此第一的自然反應就是對內部工作的譴責：「如果我們嘗試更好的使用它，它將會發揮作用」——如果我們計畫的更詳盡，記錄更詳細，更嚴格的拒絕任何變革，一切將會很順利地進行。遺憾的是，許多開發團隊只得到的相反的效果：他們越竭盡全力嘗試此方法，得到的結果越差！
如此，「瀑布式」開發的小船說翻就翻就不足為奇了。
瀑布式開發和敏捷開發的對比
瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷...
瀑布式開發和敏捷開發的對比
瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷...
為什麼要使用響應式開發
允許頁面顯示效果在老舊瀏覽器中有細微的差別，這樣可以使 更易維護，將來更 新的成本也更低。現代瀏覽器可以理解的簡潔 等同於更快速的 快速響應的 在搜尋引擎中 的評級高於慢騰騰的 使用老舊瀏覽器的使用者越來越少，使用現代瀏覽器的使用者越來越多 我們應該支援 大多數！最重要的一點，支援現代瀏覽器，你就能...