（1）允許變更需求。需求總是會變化，這是事實。給專案帶來麻煩的常常主要是需求變化和需求“蠕變”，它們會導致延期交付，工期延誤客戶不滿意，開發人員受挫。通過向用戶演示迭代所產生的部分系統功能，我們可以儘早的手機使用者對於系統的反饋，及時改正使用者需求的理解偏差，從而保證開發出來的系統真正地解決客戶問題。

（2）逐步整合元素。在傳統的專案開發中，由於要求一下子整合系統中所有的模組，整合階段往往要佔到整個專案很大比例的工作量，這一階段的工作經常是不確定並且非常棘手的。在迭代式方法中整合可以說是連續不斷的，每一次迭代都會增量式整合一些新的系統功能，要整合的元素都比過去少得多，所以工作量的難度都是比較低的。

（3）儘早降低風險。迭代開發的主要指導原則就是以構架為中心，在早期的迭代中所要解決的主要問題就是儘快確定系統架構，通過幾次迭代來儘快的設計出能夠滿足核心需求的系統架構，這樣就可以迅速降低整個專案的風險。等到系統架構穩定之後，專案的風險就比較低了，這個時候再去實現系統中尚未完成的功能，進而完成整個專案。

（4）有助於提高團隊的士氣。開發人員通過每次迭代都可以在短期內看到自己的工作成果，從而有助於他們增強信心，更好的完成開發任務。而在非迭代式開發中，開發人員只有在專案接近尾聲時才能看到開發的結果，在此之前的相當長時間，大家還是在不確定性中摸索前近。

（5）生成更高質量的產品。每次迭代都會產生一個可執行的系統，通過對這個可執行系統進行測試，我們在早期的迭代中就可以及時發現缺陷並改正，效能上的瓶頸也可以儘早發現並處理。因為在每次迭代中總是不斷地糾正錯誤，我們可以得到更高質量的產品。

（6）保證專案開發進度。每次迭代結束時都會進行評估，來判斷該次迭代有沒有達到預定的目標。專案經理可以很清楚的知道有哪些需求已經實現了，並且比較準確的估計專案的狀態，對專案的開發進度進行必要的調整，保證專案按時完成。

（7）容許產品進行戰術改變。迭代化的開發具有更大的靈活性，在迭代過程中可以隨時根據業務情況或市場環境來對產品的開發進行調整。例如為了實現有的同類產品競爭，可以決定採用搶先競爭對手一步的方法，提前釋出一個功能簡化的產品。

（8）迭代流程自身可在進行過程中得到改進和精煉。一次迭代結束時的評估不僅要從產品和進度的角度來考察專案的情況，而且還要分析組織和流程本身有什麼待改進之處，以便在下次迭代中更好的完成任務。