软件产品中的版本控制策略讨论

我们公司一直是做软件产品的，这个产品在市场上也做了有10多年了。那么必定在产品的版本上就要有很好的控制才行。

 

作为一个不是很大的软件企业来说，当然不能像微软的Windows或者是Apple的Mac OS。Windows的版本策略，原则上当维护成本大于版本更替成本时，就可以考虑更换版本。一般来说，每一个版本3-5年的有效期。5年以后不再维护。而我们公司以前的策略是，有一个主线版本也就是大版本，还有很多的支线版本也就是补丁版本。多个版本并行一起开发维护。当支线版本有普遍应用的需求或者功能点时，可以考虑移植到主线版本中。这样既保持了主线版本的通用性和稳定性，又比较灵活有一定的延续性。

 

而目前存在的问题是，大版本需求已经开发完善，很少会有大的变动了。但是现在实施的项目却很多，而项目当中也有许多个性需求需要开发。可以移植到主线版本的东西可能不是太多。但是如果减缓大版本的步伐。那么分支版本何时收口呢？何时才到主线版本呢？分支版本怎样很好的控制质量呢？这些都是凸显的问题。

 

分析问题：

如果尽量采取1对1的方式，1个分支版本对应1个项目。那么用户的满意度应该是最高的，但是同时，成本也是最高的。

如果采取1对n的方式，就有可能有一个问题，当某个项目要的需求可能其他项目不要，这个需求又可能会引发一些列缺陷，而这些缺陷本不应该发生在其他项目中。这样势必就会影响到用户的满意度了。但是这样做的开发成本会降低。

 

解决方案大胆设想：

那么最佳方案应该是，让尽量类似的项目归为一个支线版本，完全不一样的项目做1对1。这样的话对产品经理的能力要求就比较高了。

同时，对于1对n的项目一定需要有一个策划文档说明各个项目的名称以及归并到一个支线版本中的理由。最好这个策划的变更要走变更流程评审。而且当多个项目中的某一个项目结项时，需要对支线版本做结项操作，并行以此支线版做基线再产生新的支线版本做剩下的项目的继续开发。

 

对于主线版本的策略：

因为主线版本已经趋近稳定，已无大的变动。可以考虑这么几个策略：

1、以时间点来控制，比如1年时间发布一个大版本。时间点严格控制不能延误，但是范围可以灵活调节。但是必须要保证足够的测试时间，保证大版本发行的质量。这样做的好处是，需求或者缺陷可以随时加入，不受项目边界的约束（项目边界变更不需要变更申请）。缺点是项目周期长，项目边界未知（完全由项目经理控制）。

2、用正规的项目管理来走，收集需求，确定边界。当边界满足一定条件是（比如开发工作量达到6个人月）就进行版本开发。这样做的好处是，项目边界固定，项目完成时间可控，坏处是项目变更困难。

以目前产品特点来看，我建议用策略1。

 

自己瞎写了一大堆。感觉就像在自言自语。呵呵，还望大家有更好的意见和建议。互相交流学习。