下面就讓我們來看看敏捷流程如何將瀑布式流程的問題逐一破解：
● 瀑布式流程問題之一：
版本發布的時間越來越長。在敏捷流程中，版本是由一系列增量整合在一起組成的，這些增量通過乙個乙個迭代按順序開發。我們還可以在任意時間停止迭代。一旦發現產品的價值已經達到最大，尤其是發現軟體裡過半的功能很少被使用的時候，就可以停止迭代。我們還可以在到達交付期限或者預算上限的時候，停止迭代並發布軟體。我們只會開發並積累有價值的增量。
● 瀑布式流程問題之二：
無法按時發布。在敏捷流程中，版本的發布延遲最多不會超過30天，因為每個迭代的最長期限就只有30天。當到達交付期限的時候，就可以交付累積的增量。由於不會在迭代中開發低價值的功能，因此可以比以往更早地發布完整的系統。在傳統開發流程中，常用功能佔所有功能總數的不到一半。而在敏捷流程中，我們根本不會在不常用的功能上浪費時間。
● 瀑布式流程問題之三：
在版本發布的最後階段讓軟體穩定的時間越來越長。在敏捷流程中，每個迭代所產生的增量都是完整和可用的，後續迭代所產生的增量都會包含之前所有迭代產生的增量，因此任何迭代產生的增量都是完成且可用的。也就是說，沒有軟體穩定化時期，因為軟體一直保持穩定。
● 瀑布式流程問題之四：
做計畫的時間越來越長，而且不準確。在敏捷流程中我們不再做大而全的計畫，而只是設定最終目標，然後確定為了達到該目標所需的**值功能和特性，同時還會確定交付日期以及估算成本。這樣在第乙個迭代開始前做計畫所需的時間通常只有瀑布式或**型流程的20%。我們只會為即將到來的迭代的需求做詳細的計畫，因此我們把每個迭代的計畫稱為「及時雨計畫」。另外值得注意的是，需求是湧現的，在評審迭代產生的軟體增量的時候，我們可能會發現下乙個迭代需要實現的最佳需求。
● 瀑布式流程問題之五：
在發布期間很難進行改變。版本發布中期的概念在迭代增量式專案中已經不復存在了。我們能夠以最小的代價，在每個迭代開始前發現或者提出需求。
● 瀑布式流程問題之六：
質量持續惡化。在敏捷流程中，每個迭代產生的增量都是完整可用的。因此，增量必然已經通過質量測試。而後續迭代產生的增量同樣要滿足相同的質量要求，也就是說我們再也不必在專案的最後階段為了趕上交付期限而犧牲質量，因為質量始終伴隨著這個軟體的整個開發過程。
● 瀑布式流程問題之七：
拼命競賽進度使員工士氣受挫。版本穩定化階段已經不再需要了，因此加班的「死亡之旅」也隨之而去。
瀑布式迭代與敏捷
在採用敏捷開發的實踐當中，有一種特別的開發過程，他融合了瀑布模型和迭代的思維，但又與敏捷的思維存在差異，我把這種過程稱之為瀑布式迭代。瀑布式迭代過程總體上採用迭代的方式，即像敏捷一樣，以迭代為單位逐漸推進，每個迭代以啟動會 迭代活動 迭代總結為全過程，並且每個迭代都會交付產出物。唯一不同的是單獨看乙...
敏捷開發流程
在動手設計前，第一步需要對市面上的同類競品進行較為深入的分析，提煉出競品的產品框架 各模組的設計特點，通過對比分析，總結出各競品的優缺點，取其精華，取其糟粕，真正做到後來居上。結合之前的競品資料和使用者資料，我們已經可以有的放矢地開始設計產品的大框架 主要任務流程和操作形式。最初的草稿採用多種方案，...
敏捷開發流程
敏捷開發總的流程如下 1.需求規劃和分期 2.需求評審 3.需求講解 4.方案評審 5.每日晨會 6.效能測試 7.codereview 8.demo 9.測試階段 10.線上bug修改流程 如何進行scrum開發？1 我們首先需要確定乙個product backlog 按優先順序排列的乙個產品需求...