划分迭代版本的两个方法

咱们在划分迭代版本时，常常犯一些错误：
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开发阶段，要寻求测试的帮助，由测试给出功能的完整度，才能保证项目准时。

---

迭代式开发更多的原则和技巧，请参考视频课程《项目管理从入门到精通：实践经验分享，实用套路讲解，项目规律实训》。