軟件開發中的每個人都應該對變化有著充分的準備。從事軟件業的人大都充滿了自信， 系統分析師會認為自己可以把所有的需求搞清楚，設計和開發人員會覺得他們做出來的東西完美地實現了需求。所以，如果我們對一個開發人員說：某某，你過去做的這個模塊不能用了，我們現在需要重新做起，通常我們會得到積極或者消極地抵制。
應該讓人們認識到：變化并不是對過去工作的否定，而是著眼于未來，使工作更加完善的必要手段。無論是需求，設計還是程序代碼，你不可能一次性就把它們做到完美，而只能通過不斷的修正，讓它趨近于完美。這個過程就是所謂的“重構”。
有些 團隊為了保持開發的穩定性，會 “凍結需求”。所謂的凍結，也就是說在一段時間內要客戶方代表承諾不對已經開發中的需求進行變動。如果你打算做這件事情，首先必須意識到，需求本身就是需求，它是不會因為一個承諾就真正地“凍結”了。如果目前的需求定義并不能反映用戶真正的愿景，在凍結的周期過去以后我們仍然需要對已經做完的工作進行修改。當然，如果需求變化太頻繁，在某些時候有必要對需求進行凍結以便讓開發更加平穩，同時也給軟件開發者和客戶一個反思的時間。但如果是需求分析工作方法有誤，那就有必要作一些檢討了。
要適應變化，我們需要讓客戶和開發團隊有心理上的準備，從而能夠以認真的態度來對待它。還需要有正確的方法來應對變化，比如對變化的成本估算，效果的跟蹤，如何快速有效的對各種變化進行反映等，這是我們必須注意的問題。
周期
很多人簡單的把迭代理解為開發的分階段進行。有些 項目經理會這樣說：我們打算通過4次迭代完成軟件的開發，第一次迭代，完成需求分析和軟件設計，第二次迭代，完成多少多少模塊的開發，第三次，完成其他多少模塊的開發，第四次，配置，部署，上線，測試，修正軟件bug。在這里，雖然他們言必稱“迭代”，但是這樣的迭代和過去傳統的瀑布型開發有多少區別？
迭代開發是要分周期分階段地進行，但是不能認為簡單地把開發周期劃分為幾個不同的階段就是迭代。
很多人對于迭代周期有一些誤解，比如：
認為迭代只適用于開發階段，而需求分析和設計工作則不在此范圍內。
認為迭代周期可以拉得很長，比如兩個月，三個月，甚至一個季度，半年。
將需求分析，設計，開發，測試，部署，用戶反饋，修改當作完整的迭代周期，并要求在前一階段工作完全（或者大部分）完成以后再進行下一步工作（迭代）。
在一個迭代周期內，我們可以做什么事情呢？可以說：所有的事情。如果你認為迭代需要在需求分析完成之后才能開始，或者系統集成必須在所有迭代完成之后才可以進行，你會獲得一個真正的瀑布流程開發。
一個迭代周期意味著對一些特定功能（用例）的探索�！疤剿鳌币辉~可能隨情況不同而有不同的含義。對于抽象級別較高，模糊程度比較高的用例，我們需要通過和用戶的討論將它逐漸分解為更加清楚和清晰的用例。對于目前我們認為已經得到了詳細定義的需求，需要選取合適的部分進行設計和實現，通過這些部分的實現，對需求定義和技術可行性進行反饋。對那些在上次迭代中已經開發完的模塊，應該盡可能快速地讓用戶提出他們的意見，以便了解是否真正解決了用戶面臨的問題，以及還有沒有可以改進的方面，再根據這些意見安排下一階段的工作。
我們是否可以在開發進行之前把需求或者設計全部弄清楚呢？我認為很難。因為通常來講，用戶對于自己的需求只有一個模糊的概念。讓我們假設一個飲食業的例子，有一天餐廳經理把你叫入辦公室說：馬上設計一個新的菜譜，這個菜譜是為某某特定人群定制的，你要讓這些人感覺色香味俱全。不過在你把配料和烹調方法都設計出來之前，我們不打算讓大廚來具體做這道菜，我們不允許失敗，所以你的設計一定要一次成功，你可以用調查問卷，用戶面談等方法獲取最終用戶的需求，但是記�。耗悴荒苋プ鲞@道菜。
這樣的事情你可能會覺得很滑稽，但是在軟件業，類似的事情人們卻認為是天經地義的。
迭代允許我們將開發本身也作為需求探索的一部分，通過用戶對已經實現功能的反饋我們和用戶都會逐漸明白什么樣的軟件是我們最終想要開發的。所以，不要等到所有（或者大部分）的分析完了才開始開發，而是盡早對已經捕獲到的需求進行細化，盡早開發，以獲得反饋。
在安排迭代計劃時，應該指明，這次迭代的目標是什么，在結束時應達到的里程碑是什么。如果有任務提前達到了這個里程碑，我們可以提前結束迭代，或者順便在剩下的時間內安排其他的任務，但是要注意這種安排的合理性，不要因為這個而使得迭代周期被延長。
在一次迭代到達所設定的結束日期時，就必須審視各項任務是否達到了里程碑的要求，如果有任務沒有達到，原因是什么，我們是否需要對需求和技術方案做出調整。對于沒有達到里程碑要求的任務，我們可以采取的辦法有兩種：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
