ThreeMergeOne迭代项目经验

在面临需求众多，短时间无法完成所有功能且交付用户的话，迭代的开发方式就是我们的首选开发方式：主要功能排前，次要功能排后，而且迭代一完成后立马在线更新，交付用户使用。我所在的公司是一家七层网络供应商，基于第三方厂家硬件的七层软件开发的性质，前段时间公司在TMO中就采用了迭代的开发方式。

由公司的产品属性决定了迭代开发的产品的交付属性，相比互联网公司快速迭代(那是真正的快速)开发、快速上线、快速交付客户使用相比，因为基于硬件的产品开发，就限制了迭代开发产品的快速交付客户使用的速度。所以互联网公司快速的迭代式开发并不是毫无保留的套用。

参与了这样的迭代项目开发，总结一下减缓项目开发进度的原因：

1.项目成员的技术参差不齐，大多数对产品的业务、功能并不是特别熟悉，甚至之前没有接触过

2.整个大项目开发过程中，分了五六个迭代，每个迭代都需要把人员投入到不同的模块中，导致每个迭代开始都需要一定的熟悉成本，然后就出现了每个迭代落后的问题

3.区别于互联网产品的迭代方式不同的时，TMO每个迭代的结束提交的产品并不是可交互用户使用的，相反只是研发的模块编码完成、BVT案例，并无完整的测试案例执行， 所以导致测试和研发的进度总是差一个迭代，导致研发每个迭代总是一边编码一边处理上个迭代的遗留问题。所有迭代走下来研发的压力其实是很大的

类似这样的迭代开发其实对组员开发人员的技能要求、产品业务逻辑场景都要求比较高。其实总的来看这样的迭代其实并不是真正的迭代，我们就称呼其为伪迭代吧！也算是一种本土化的迭代方式，不同的时我们交互的对象不是客户，而是测试；不是可使用，而是可测试；不过话说回来，从某种转换的角度来说，测试人员和客户，可使用和可测试恐怕也是等价的吧