一、按“主次”划分：
产品经理在整理需求的时候，先整理主要业务，再整理辅助业务，就适合用这种方法。
一个迭代周期在两到三周，如果主要业务在三周内能完成，那第一个迭代时间就出来了，主要业务是多少天，迭代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开发阶段，要寻求测试的帮助，由测试给出功能的完整度，才能保证项目准时。
迭代开发更多的原则和技巧，请参考《项目管理从入门到精通：实践经验分享，实用套路讲解，项目规律实训》。
