週期　很多人簡單的把迭代理解為開發的分階段進行。有些專案經理會這樣說：我們打算透過4次迭代完成軟體的開發，第一次迭代，完成需求分析和軟體設計，第二次迭代，完成多少多少模組的開發，第三次，完成其他多少模組的開發，第四次，配置，部署，上線，測試，修正軟體bug。在這裡，雖然他們言必稱“迭代”，但是這樣的迭代和過去傳統的瀑布型開發有多少區別？迭代開發是要分週期分階段地進行，但是不能認為簡單地把開發週期劃分為幾個不同的階段就是迭代。很多人對於迭代週期有一些誤解，比如：認為迭代只適用於開發階段，而需求分析和設計工作則不在此範圍內。 認為迭代週期可以拉得很長，比如兩個月，三個月，甚至一個季度，半年。 將需求分析，設計，開發，測試，部署，使用者反饋，修改當作完整的迭代週期，並要求在前一階段工作完全（或者大部分）完成以後再進行下一步工作（迭代）。 在一個迭代週期內，我們可以做什麼事情呢？可以說：所有的事情。如果你認為迭代需要在需求分析完成之後才能開始，或者系統整合必須在所有迭代完成之後才可以進行，你會獲得一個真正的瀑布流程開發。　一個迭代週期意味著對一些特定功能（用例）的探索。“探索”一詞可能隨情況不同而有不同的含義。對於抽象級別較高，模糊程度比較高的用例，我們需要透過和使用者的討論將它逐漸分解為更加清楚和清晰的用例。對於目前我們認為已經得到了詳細定義的需求，需要選取合適的部分進行設計和實現，透過這些部分的實現，對需求定義和技術可行性進行反饋。對那些在上次迭代中已經開發完的模組，應該儘可能快速地讓使用者提出他們的意見，以便了解是否真正解決了使用者面臨的問題，以及還有沒有可以改進的方面，再根據這些意見安排下一階段的工作。　我們是否可以在開發進行之前把需求或者設計全部弄清楚呢？我認為很難。因為通常來講，使用者對於自己的需求只有一個模糊的概念。讓我們假設一個飲食業的例子，有一天餐廳經理把你叫入辦公室說：馬上設計一個新的菜譜，這個菜譜是為某某特定人群定製的，你要讓這些人感覺色香味俱全。不過在你把配料和烹調方法都設計出來之前，我們不打算讓大廚來具體做這道菜，我們不允許失敗，所以你的設計一定要一次成功，你可以用調查問卷，使用者面談等方法獲取終端使用者的需求，但是記住：你不能去做這道菜。　這樣的事情你可能會覺得很滑稽，但是在軟體業，類似的事情人們卻認為是天經地義的。迭代允許我們將開發本身也作為需求探索的一部分，透過使用者對已經實現功能的反饋我們和使用者都會逐漸明白什麼樣的軟體是我們最終想要開發的。所以，不要等到所有（或者大部分）的分析完了才開始開發，而是儘早對已經捕獲到的需求進行細化，儘早開發，以獲得反饋。　在安排迭代計劃時，應該指明，這次迭代的目標是什麼，在結束時應達到的里程碑是什麼。如果有任務提前達到了這個里程碑，我們可以提前結束迭代，或者順便在剩下的時間內安排其他的任務，但是要注意這種安排的合理性，不要因為這個而使得迭代週期被延長。　在一次迭代到達所設定的結束日期時，就必須審視各項任務是否達到了里程碑的要求，如果有任務沒有達到，原因是什麼，我們是否需要對需求和技術方案做出調整。對於沒有達到里程碑要求的任務，我們可以採取的辦法有兩種：將剩餘的工作列入下一次迭代計劃中去， 將本次迭代的結束時間向後延遲，等待任務的完成 前一種辦法適合於有很大工作量沒有完成的情況，這可能也同時說明計劃的制定有問題，在制定下次迭代計劃時應該考慮對任務完成時間進行調整。後一種辦法適合剩餘工作量不是很大的情況。　通常來說，一次迭代完成以後應該有一個產品的新版本可用。這也就意味著：將整合和釋出分散到每次迭代中去。藉助於一些自動化工具（比如ant），我們甚至可以做到每日構建。　一個迭代週期應該有多長呢？這並沒有一個統一的說法，而是應該視目標和可用的資源而定。但是，迭代週期不宜過長，也不宜過短。迭代週期過長的話，會延緩反饋的時間，可能將許多問題隱藏或是堆積了起來。迭代週期過短，會讓人身心疲勞，事情難有大的成效。一般來說，迭代週期應該在2-6周之間。如果安排的迭代週期超過了兩個月，你可能就必須審視一下迭代計劃的合理性了。　不要認為下一次迭代應該和上次迭代的時間差不多，刻板地把所有迭代規定一個統一的時間是一個很壞的做法。但是你可以把以前迭代週期中的工作效率作為估算下次迭代時間的一個依據。　目標　一次迭代必須有明確的目標：我們希望透過這次迭代達到什麼目的。在制定目標時，應該同時考慮另外一個問題：如何檢查該目標是否已經達成。這就是所謂的“里程碑”。　迭代計劃必須有明確而可行的目標。明確的意思是它應該是可度量的，不能太模糊，因為你很難檢查一個模糊的目標是否達成。比如，我們可以說，這次迭代的目標是對xxx方面的需求作進一步細化和評審，完成xxx模組的開發以加入到軟體的下一版本中去。這樣的目標是明確而且可行的。反過來，如果我們這樣說：我們要透過和使用者的討論明確絕大部分願景，同時要有一個初步的開發。“絕大部分”和“初步”這樣的詞讓人感到困惑：多少是絕大部分呢，在總量尚未明確的前提下，怎麼能夠知道完成的確是“絕大部分”而不是“一小部分”？“初步的開發”似乎告訴我們這次開發量比較小，但是具體開發哪個部分，或者開發到什麼程度，並沒有指出一個明確的概念。　由此產生了一個困惑，軟體專案是一個不斷探索的過程，我們怎麼能夠明確地對未來的事情作安排呢？譬如在專案初始調查使用者願景時，為了實現“明確”的目標，是否這樣定義任務：完成20%的使用者願景調查？　很顯然，使用者願景總量到底有多少我們並不知道，所以在這次迭代完成以後如果我們問：是否真的完成了20%而不是15%？很難得到答案。　為了避免出現這種情況，你必須換個角度來看問題，比如我們可以說：對xxx部門和yyy部門的使用者做願景調查。在迭代完成後，可以檢查是否這兩個部門所有使用者的訪談，調查都已經完成，是否這些部門每個人都認為自己表達了全部的意思。

簡單易用功能強大的勤哲Excel伺服器更易上手，這是一個資訊系統DIY工具，可以幫助企業管理者自主構建資訊系統，不用程式設計，不依賴軟體開發人員，會Excel就能用，使得企業使用者真正成為資訊化程序的設計者、實施者和主導力量。