軟體產品中的版本控制策略討論

我們公司一直是做軟體產品的，這個產品在市場上也做了有10多年了。那麼必定在產品的版本上就要有很好的控制才行。

 

作為一個不是很大的軟體企業來說，當然不能像微軟的Windows或者是Apple的Mac OS。Windows的版本原則，原則上當維護成本大於版本更替成本時，就可以考慮更換版本。一般來說，每一個版本3-5年的有效期間。5年以後不再維護。而我們公司以前的策略是，有一個主線版本也就是大版本，還有很多的支線版本也就是補丁版本。多個版本並行一起開發維護。當支線版本有普遍應用的需求或者功能點時，可以考慮移植到主線版本中。這樣既保持了主線版本的通用性和穩定性，又比較靈活有一定的延續性。

 

而目前存在的問題是，大版本需求已經開發完善，很少會有大的變動了。但是現在實施的項目卻很多，而項目當中也有許多個性需求需要開發。可以移植到主線版本的東西可能不是太多。但是如果減緩大版本的步伐。那麼分支版本何時收口呢？何時才到主線版本呢？分支版本怎樣很好的控制品質呢？這些都是凸顯的問題。

 

分析問題：

如果盡量採取1對1的方式，1個分支版本對應1個項目。那麼使用者的滿意度應該是最高的，但是同時，成本也是最高的。

如果採取1對n的方式，就有可能有一個問題，當某個項目要的需求可能其他項目不要，這個需求又可能會引發一些列缺陷，而這些缺陷本不應該發生在其他項目中。這樣勢必就會影響到使用者的滿意度了。但是這樣做的開發成本會降低。

 

解決方案大膽設想：

那麼最佳方案應該是，讓盡量類似的項目歸為一個支線版本，完全不一樣的項目做1對1。這樣的話對產品經理的能力要求就比較高了。

同時，對於1對n的項目一定需要有一個策劃文檔說明各個項目的名稱以及歸併到一個支線版本中的理由。最好這個策劃的變更要走變更流程評審。而且當多重專案中的某一個項目結項時，需要對支線版本做結項操作，並行以此支線版做基準再產生新的支線版本做剩下的項目的繼續開發。

 

對於主線版本的策略：

因為主線版本已經趨近穩定，已無大的變動。可以考慮這麼幾個策略：

1、以時間點來控制，比如1年時間發布一個大版本。時間點嚴格控制不能延誤，但是範圍可以靈活調節。但是必須要保證足夠的測試時間，保證大版本發行的品質。這樣做的好處是，需求或者缺陷可以隨時加入，不受項目邊界的約束（項目邊界變更不需要變更申請）。缺點是項目周期長，項目邊界未知（完全由專案經理控制）。

2、用正規的專案管理來走，收集需求，確定邊界。當邊界滿足一定條件是（比如開發工作量達到6個人月）就進行版本開發。這樣做的好處是，項目邊界固定，項目完成時間可控，壞處是項目變更困難。

以目前產品特點來看，我建議用策略1。

 

自己瞎寫了一大堆。感覺就像在自言自語。呵呵，還望大家有更好的意見和建議。互相交流學習。