劃分迭代版本的兩個方法

咱們在劃分迭代版本時，常常犯一些錯誤：
1、被時間束縛，固定一個迭代週期，如3周；
2、從功能池中挑些功能，拼出一個版本。
這種操做方式，常常會致使實施時，出現各類問題。本文推薦兩種劃分版本的方法，能夠確保迭代週期更有效的劃分，項目進度更有保障。

1、按「主次」劃分：

產品經理在整理需求的時候，先整理主要業務，再整理輔助業務，就適合用這種方法。

一個迭代週期在兩到三週，若是主要業務在三週內能完成，那第一個迭代時間就出來了，主要業務是多少天，迭代1就是多少天，不要強求必定要二週或者三週。

若是主要業務要超過三週，那就要對主要業務作拆分，把一部分功能放到迭代2中，但要保證迭代1的業務流程要能跑通。

迭代2比較簡單，把其它業務能在兩週左右完成的挑出來，保證業務流程都能跑通，就能夠肯定這個迭代版本。

剩餘的功能都放在迭代3中，可是迭代3的飽和度跟迭代1和迭代2比起來只安排80%左右，若是完不成就把部分功能擠到迭代2裏。要留點時間出來處理突發事件，或協做不順暢的問題。

2個月左右的項目，發3 個迭代版本，迭代3開發完成，全部功能都開發完成，一兩天測試修改以後，立刻進入集成測試。

若是超過3個月的項目，儘可能作成大小版本，兩個月左右發個大版本，一個月左右發個小版本。這樣有兩個好處：

1. 老闆看到兩個月有成果，那你的績效就穩了；
2. 人是有疲性的，超過兩個半月的項目，會越作越沒信心，越作越想偷懶。

2、按「層次」劃分：

有些產品經理整理需求的習慣，是按界面的層級來整理。好比，先設計一級頁面，再設計二級頁面，設計二級的時候，把主要業務跑通，留幾個三級頁面，再去設計其它二級頁面。... ...

這件設計方法，會帶來不肯定性，你搞不清楚哪些功能模塊是完整的，哪些實際完成度是多少，因此會帶來不可控。針對這種狀況，咱們能夠採用「先已知後未知」的原則來劃分迭代版本。

有幾年開發經驗的工程師都知道，一二級頁面都會比較簡單，大部分是一些列表，因此先後端都好開發。

迭代1，開發的內容包括一二級頁面和主要業務的部分功能。這裏有個要點，由於作一二級頁面，感受作了不少功能，實際上他的工做量會比作詳情頁少不少，因此迭代1要多壓些功能進去。
這樣操做有個好處，就是迭代1開發完成，領導一看：「哇，都快作完了」。領導對項目組會有好感。

迭代2，核心業務要所有完成，加上部分次要功能的細節部分。若是能夠的話，也多壓些功能在這裏，由於這種分法，出問題的都在迭代3.

迭代3，剩餘的功能都放在迭代3，可是迭代3的功能分佈很碎，常常會漏掉功能。在編計劃的時候正常作就好，可是，在迭代3開發階段，要尋求測試的幫助，由測試給出功能的完整度，才能保證項目準時。

---

迭代式開發更多的原則和技巧，請參考視頻課程《項目管理從入門到精通：實踐經驗分享，實用套路講解，項目規律實訓》。