前面我們提到了迭代式開發的巨大優勢，它可以降低我們軟體開發的巨大風險，它可以使我們把握使用者的真正需求，它可以使我們從錯誤與偏差中及時糾正過來，那麼我們應該如何進行迭代式開發呢？要回答這個問題，我們首先要弄清迭代式開發與傳統的瀑布式開發的差別在**。
[b]1.需求分析的差別[/b]
與傳統的軟體開發一樣，迭代式開發同樣需要與客戶進行乙個充分的需求分析。但與傳統的軟體開發不一樣，迭代式開發不要求初期的需求分析是乙個完全的需求分析。它承認需求分析需要乙個過程，它承認需求的變化（或者說需求是乙個進化的過程）。所以，在迭代式開發中，起初的需求分析只要進行到當時的階段能夠理解到的程度就可以了，而不是瀑布式開發那樣需要完成所有的需求分析並最終確認下來。至於其它還沒有分析到的內容，我們會在每個迭代的需求階段逐漸加深理解，逐漸細化，直至最終完成軟體的開發。因此，迭代式開發的需求分析始終貫穿整個軟體開發的過程。
[b]2.軟體開發的差別[/b]
迭代式開發的軟體開發階段，與傳統軟體開發的方式存在著巨大的差異，迭代式軟體開發採用的是「持續整合（continuous build）」的軟體開發方式。傳統的開發方式，當需求被確認下來並開始軟體開發時，首先進行的工作是分模組進行開發，就如同車間生產一樣，不同的模組被分配到了不同的小組或個人進行分頭開發。在此期間，誰都不能拿出可執行的軟體交付物，直到開發中後期的整合階段。而迭代式開發不同，它將整個開發過程分為了數個迭代，並且在每個迭代結束時要交付可執行的軟體，正因為如此，迭代式開發採用持續整合的方式。
持續整合的基本思想就是每個人每天完成的開發工作都能立即集成為乙個可執行的軟體產品。為了實現持續整合，我們必須改變我們的開發順序。傳統的開發順序，首先是開發並完善各個子模組。當各個子模組都完成開發以後，才最終組裝並集成為乙個可執行的軟體。採用這種順序開發不可能保證持續整合。迭代式開發，在初次確認業務需求以後，首先開發的是軟體最主要最基本的功能，在開發這些功能時也往往只考慮主流程而忽略分支流程。採用這種方式，可以在最短時間內交付可以執行的軟體。之後我們交給客戶去體驗、去確認、給我們提意見，我們再不斷去調整和完善這些主要功能，或者開發其它次要功能，使軟體開發以一種進化式的方式進行下去。
採用持續整合的方式，使軟體開發中利益攸關的各方隨時可以了解軟體開發的進度，以視覺化的方式看到軟體開發的成果，及時糾正軟體開發過程中的問題。更重要的是，所有利益攸關方中最重要的一方——客戶，由於自身的侷限描述不清自己的需求，通過視覺化的方式一次一次看見可執行的軟體，更直觀地提出自己的意見，使自己的需求越來越清晰，並有效地告知開發者。而我們作為開發中，通過這種方式，使我們有更多的機會與客戶有效溝通，從而對業務領域理解越來越深刻，也使我們的開發成果始終有客戶確認，與客戶的需求保持一致。即使有時出現偏差，也能及時得到糾正。最終，我們交付的軟體必然是客戶滿意的。
由此看來，迭代式開發與傳統開發，其開發的過程差異真的不小。
[url=一次迭代式開發的研究：軟體開發的風險[/url]
[url=一次迭代式開發的研究：什麼是迭代式開發[/url]
[url=一次迭代式開發的研究：怎樣進行迭代式開發[/url]
[url=一次迭代式開發的研究：迭代開發從這裡開始[/url]
[url=一次迭代式開發的研究：準確的工作量評估[/url]
[url=一次迭代式開發的研究：功能的優先順序評估[/url]
[url=一次迭代式開發的研究：乙個迭代式專案計畫[/url]
[url=一次迭代式開發的研究：開始真正的工作[/url]
[url=一次迭代式開發的研究：從容應對需求變更[/url]
[url=一次迭代式開發的研究：需求變更的關鍵步驟[/url]
[url=一次迭代式開發的研究：where you are[/url]
[b]（續）[/b]
一次迭代式開發的研究 Where you are
其實做乙個專案經理真不是乙個好的職業，它需要太多的千錘百鍊才能修煉出來。這不僅需要反覆經歷 失敗 總結 再失敗 的輪迴，而且需要有一顆無比堅強的心，能夠在無數次經歷無比艱難並且令人沮喪的時刻而能堅持不懈 毫不氣餒。乙個專案經理就像一位將軍。將軍百戰死，而專案經理呢，經歷無數專案以後沉澱下來的，更多的...
一次迭代式開發的研究8 開始真正的工作
我們經過以上一系列的分析，工作量評估與優先順序評估，制訂出乙個迭代式的專案計畫，再經過一系統使用者確認與公司評審以後，終於可以開始我們真正的開發工作。其實，迭代式開發的執行過程，也就是製作和不斷去關注與評估專案進度表的過程。因此，當專案進入執行開發過程時，專案經理應當首先製作專案進度表。現在我們看看...
一次迭代式開發的研究10 需求變更的關鍵步驟
前面我們提到了需求變更。當客戶提出了需求變更，經過與我們的需求人員的詳細討論與分析，最後確定下來了變更內容和修改方案。但這時草率地開始進行設計和開發是不正確的，它將成為專案後期的乙個巨大的風險，一顆定時zhadan，為什麼呢？我們來詳細分析分析。每當發生需求變更的時候，不管是大是小，專案的許多因素都...