組織為什麼要轉向敏捷？乙個原因是它可以使組織處理變化的能力更強。專案進行過程中，使用者需求會經常變化，這就需要開發團隊能夠適應產品需求。敏捷幫助團隊交付滿足使用者需要的產品；這些產品不包含不需要（而且沒有用）的特性。精益軟體開發使用術語「浪費」：一切不增加使用者價值的特性都視為浪費。由瀑布到敏捷軟體開發的轉換是如何幫助組織減少浪費的呢？
\u0026#xd;\n
ron lichty寫了一篇關於「由瀑布轉換到敏捷的最具說服力的理由」的博文。如ron所言，該理由與浪費有關：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n但是對我而言，真正起決定作用的——使我發生了由對敏捷的熱衷到對瀑布的絕望這一轉變——是浪費。浪費資源，浪費開發時間，浪費精力。
\u0026#xd;\n
他問開發人員和開發經理，當收到乙份400頁的需求規格說明書的時候，他們實際上能交付百分之幾。他描述了問答過程，得到的答案如下：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n（……）答案很少超過45%——最典型的是15%到25%——最少會交付需求規格說明書上10%的需求。
\u0026#xd;\n
在確定交付內容的方式上，ron看到了敏捷與瀑布的主要區別，這一點影響了交付價值：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n每次sprint，產品經理都會與開發負責人一起對backlog頂部的事項進行協商排序，以保證團隊總是致力於最有價值的需求。這是我喜歡敏捷的一點。
\u0026#xd;\n
另一方面，在瀑布場景中，答案是幾乎從不進行評估。針對我的問題，***括「對最簡單的需求進行編碼」、「我們最感興趣的需求」（最引人注意的需求！）、「閱讀需求的過程**現的想法」或者「最有趣的需求」。乙份400頁的瀑布需求，其需求的優先順序幾乎普遍是由開發人員而不是產品經理來確定。
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n在產品開發過程中，三項最大的浪費是：
\u0026#xd;\n
構建了錯誤的程式包
\u0026#xd;\n
「沒有什麼跟高效地做根本不需要做的工作一樣沒有用處。」——peter drucker
\u0026#xd;\n
程式包構建錯誤
\u0026#xd;\n
如果看上去沒有足夠的時間進行正確的構建，那麼當然也沒有足夠的時間進行不正確的構建。
\u0026#xd;\n
批處理和佇列思想
\u0026#xd;\n
工作在開展過程中隱藏缺陷、超出時限、導致任務切換以及延遲價值交付。
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n在藍圖設計完成後，瀑布過程試圖「凍結需求」。可想而知，這不現實。需求問題發現的越晚（……），修復成本就越高。在某些情況下，都不可能進行修復。（……）敏捷方法不會試圖預先一次性「確定和凍結需求」。它假設，隨著使用者開始視覺化自己的需求，需求會發展和變化。
\u0026#xd;\n
關於敏捷軟體開發中的迭代是如何提供引導結果的可能性，他給出了自己的觀點：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n敏捷方法試圖將需求、設計、編碼和測試集中到規模較小的迭代開發階段。本質上，敏捷方法是一系列規模較小的包含在敏捷過程之中的瀑布。終端使用者和企業的利益相關人員可以在系統開發的過程中看到和體驗系統。過程修正變得更明顯和更易於操控。
\u0026#xd;\n
根據mike的總結，瀑布專案浪費it預算：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n許多cfo發現自己置身於一部降低運營成本和進行技術投資的複雜而又需要嫻熟技巧的戲中。cfo對cio施加壓力，使他們提出可以充分利用現有投資的計畫，同時還要求他們發展快速響應經濟增長和競爭變化的能力。專案結果沒有失敗選項，但根據統計，瀑布方法浪費了公司it專案預算的60%。
\u0026#xd;\n
在博文「敏捷成本更低，對嗎？」中，kenny grant描述了敏捷方法是如何幫助團隊識別和處理浪費的。據kenny說，在開發軟體的時候，敏捷軟體開發本身並不比瀑布成本更低。使敏捷成本更低的是其處理範圍變更和專案調整的方式：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n因此，比較瀑布和敏捷就像比較蘋果和桔子。在我看來，這是因為，與使用瀑布型開發方法實現相同的業務需求相比，遵循敏捷原則和過程幾乎總是生產出不同的產品。（……）專案範圍內幾乎總是有些部分可以視為浪費，或者其價值不值得以那樣的成本交付。敏捷總是不懈地專注於業務價值，並通過恰如其分的工作鑑別浪費——或者是投資回報率（roi）不佳的需求——從而給團隊改變它或者一起放棄它的機會。
\u0026#xd;\n
考慮到業務需要和需求會在專案進行的過程中發生變化，kenny重新表述了問題「是否『敏捷成本更低？』」：
\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n「對於特定的業務需要，遵循敏捷原則和過程能夠使我們開發出滿足需要（不多也不少）的產品，而又比使用瀑布型開發方法成本更低嗎？」在這種情況下，答案是「是的，絕對！」
\u0026#xd;\n
檢視英文原文：reduce waste by changing from wate***ll to agile
通過由瀑布到敏捷的轉換來減少浪費
組織為什麼要轉向敏捷？乙個原因是它可以使組織處理變化的能力更強。專案進行過程中，使用者需求會經常變化，這就需要開發團隊能夠適應產品需求。敏捷幫助團隊交付滿足使用者需要的產品 這些產品不包含不需要 而且沒有用 的特性。精益軟體開發使用術語 浪費 一切不增加使用者價值的特性都視為浪費。由瀑布到敏捷軟體開...
瀑布模型和敏捷方法的區別
瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷...
敏捷開發和瀑布開發的區別
個人覺得 敏捷開發強調以人為中心,快速迭代，客戶參與多溝通，減少不必要的文件,包括scrum和xp 優點 快速適應變化,做出的專案比較接近客戶需要的 缺點 文件不多，如果人員流動大，維護相對更難 瀑布開發強調文件，就是不同階段按照順序自上而下而來，如需求 設計 編碼 測試 單元測試 系統測試 維護，...