將剩余的工作列入下一次迭代計劃中去，
將本次迭代的結束時間向后延遲，等待任務的完成
前一種辦法適合于有很大工作量沒有完成的情況，這可能也同時說明計劃的制定有問題，在制定下次迭代計劃時應該考慮對任務完成時間進行調整。后一種辦法適合剩余工作量不是很大的情況。
通常來說，一次迭代完成以后應該有一個產品的新版本可用。這也就意味著：將集成和發布分散到每次迭代中去。借助于一些自動化工具（比如ant），我們甚至可以做到每日構建。
一個迭代周期應該有多長呢？這并沒有一個統一的說法，而是應該視目標和可用的 資源而定。但是，迭代周期不宜過長，也不宜過短。迭代周期過長的話，會延緩反饋的時間，可能將許多問題隱藏或是堆積了起來。迭代周期過短，會讓人身心疲勞，事情難有大的成效。一般來說，迭代周期應該在2-6周之間。如果安排的迭代周期超過了兩個月，你可能就必須審視一下迭代計劃的合理性了。
不要認為下一次迭代應該和上次迭代的時間差不多，刻板地把所有迭代規定一個統一的時間是一個很壞的做法。但是你可以把以前迭代周期中的工作效率作為估算下次迭代時間的一個依據。
目標
一次迭代必須有明確的目標：我們希望通過這次迭代達到什么目的。在制定目標時，應該同時考慮另外一個問題：如何檢查該目標是否已經達成。這就是所謂的“里程碑”。
迭代計劃必須有明確而可行的目標。明確的意思是它應該是可度量的，不能太模糊，因為你很難檢查一個模糊的目標是否達成。比如，我們可以說，這次迭代的目標是對xxx方面的需求作進一步細化和評審，完成xxx模塊的開發以加入到軟件的下一版本中去。這樣的目標是明確而且可行的。反過來，如果我們這樣說：我們要通過和用戶的討論明確絕大部分愿景，同時要有一個初步的開發�！敖^大部分”和“初步”這樣的詞讓人感到困惑：多少是絕大部分呢，在總量尚未明確的前提下，怎么能夠知道完成的確是“絕大部分”而不是“一小部分”？“初步的開發”似乎告訴我們這次開發量比較小，但是具體開發哪個部分，或者開發到什么程度，并沒有指出一個明確的概念。
由此產生了一個困惑，軟件項目是一個不斷探索的過程，我們怎么能夠明確地對未來的事情作安排呢？譬如在項目初始調查用戶愿景時，為了實現“明確”的目標，是否這樣定義任務：完成20%的用戶愿景調查？
很顯然，用戶愿景總量到底有多少我們并不知道，所以在這次迭代完成以后如果我們問：是否真的完成了20%而不是15%？很難得到答案。
為了避免出現這種情況，你必須換個角度來看問題，比如我們可以說：對xxx部門和yyy部門的用戶做愿景調查。在迭代完成后，可以檢查是否這兩個部門所有用戶的訪談，調查都已經完成，是否這些部門每個人都認為自己表達了全部的意思。
所以，如果你發現很難對制定的目標進行度量，那么換一個角度來看事情吧，你可能就會找到一個合適的表達方式。如果你從所有的角度都看不到事情是可以度量的，那么這可能意味著這件事情可能還沒有到應該去實施的地步，這時你應該把它從迭代計劃中去掉。對于這種情況，有人可能會說：那我們這次迭代可做的事情就很少了，如果真是這樣，那就進行一次小的迭代吧，可能把這次迭代的工作做完了以后就會有更多的工作可以安排了。
有些 項目經理在日程表上，很詳細地寫著：第一次迭代，某月某日到某月某日，第二次迭代：某月某日到某月某日，第三次迭代。。。這樣的做法是不恰當的。因為它假設了后面幾次迭代的任務量，但是實際上，在前面的工作完成之前，你很難對以后的工作得到一個明確地概念。而且在這樣的計劃上，可能并沒有用于測量迭代成果的里程碑，這樣的迭代最后很可能會演變成為瀑布式的開發。所以，在一次迭代完成之前，不要對急著去計劃下次迭代，特別是不要試圖精確定義下次迭代的時間，因為你連下次迭代要做什么都還不清楚。
為什么目標的可度量性這么重要呢？在 團隊開發中，很多信息因為人與人的交流不暢而無法得到正確地反饋，這讓我們沒有辦法實時地掌握項目的進展情況，退而求其次，我們必須階段性地了解這些信息。如果目標難以度量，迭代結束后我們很難明確到底有哪些工作沒有完成，也就無法看到事情的問題所在。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
