我們在劃分迭代版本時，經常犯一些錯誤：
一、被時間束縛，固定一個迭代週期，如3周；
二、從功能池中挑些功能，拼出一個版本。
這種操作方式，經常會導致實施時，出現各種問題。本文推薦兩種劃分版本的方法，可以確保迭代週期更有效的劃分，項目進度更有保障。一、按“主次”劃分：
產品經理在整理需求的時候，先整理主要業務，再整理輔助業務，就適合用這種方法。
一個迭代週期在兩到三週，如果主要業務在三週內能完成，那第一個迭代時間就出來了，主要業務是多少天，迭代1就是多少天，不要強求一定要二週或者三週。
如果主要業務要超過三週，那就要對主要業務做拆分，把一部分功能放到迭代2中，但要保證迭代1的業務流程要能跑通。
迭代2比較簡單，把其它業務能在兩週左右完成的挑出來，保證業務流程都能跑通，就可以確定這個迭代版本。
剩餘的功能都放在迭代3中，但是迭代3的飽和度跟迭代1和迭代2比起來只安排80%左右，如果完不成就把部分功能擠到迭代2裏。要留點時間出來處理突發事件，或協作不暢的問題。
2個月左右的項目，發3 個迭代版本，迭代3開發完成，所有功能都開發完成，一兩天測試修改之後，馬上進入集成測試。
如果超過3個月的項目，儘量做成大小版本，兩個月左右發個大版本，一個月左右發個小版本。這樣有兩個好處：
1. 老闆看到兩個月有成果，那你的績效就穩了；
2. 人是有疲性的，超過兩個半月的項目，會越做越沒信心，越做越想偷懶。
二、按“層次”劃分：
有些產品經理整理需求的習慣，是按界面的層級來整理。比如，先設計一級頁面，再設計二級頁面，設計二級的時候，把主要業務跑通，留幾個三級頁面，再去設計其它二級頁面。... ...
這件設計方法，會帶來不確定性，你搞不清楚哪些功能模塊是完整的，哪些實際完成度是多少，所以會帶來不可控。針對這種情況，我們可以採用“先已知後未知”的原則來劃分迭代版本。
有幾年開發經驗的工程師都知道，一二級頁面都會比較簡單，大部分是一些列表，所以前後端都好開發。
迭代1，開發的內容包括一二級頁面和主要業務的部分功能。這裏有個要點，因爲做一二級頁面，感覺做了很多功能，實際上他的工作量會比做詳情頁少很多，所以迭代1要多壓些功能進去。
這樣操作有個好處，就是迭代1開發完成，領導一看：“哇，都快做完了”。領導對項目組會有好感。
迭代2，核心業務要全部完成，加上部分次要功能的細節部分。如果可以的話，也多壓些功能在這裏，因爲這種分法，出問題的都在迭代3.
迭代3，剩餘的功能都放在迭代3，但是迭代3的功能分佈很碎，經常會漏掉功能。在編計劃的時候正常做就好，但是，在迭代3開發階段，要尋求測試的幫助，由測試給出功能的完整度，才能保證項目準時。
迭代式開發更多的原則和技巧，請參考視頻課程《項目管理從入門到精通：實踐經驗分享，實用套路講解，項目規律實訓》。