版本规划与管理(汉捷)

版本规划与管理

汉捷咨询 Simon

重视研发的企业在经历了一段时间个人英雄主义式的产品开发阶段后，会逐渐意识到了这种开发方式的无序和混乱，因此会考虑推行了IPD、MM、CMM等以期获得改进。

为什么CMM在外国公司能够应用得很好，在中国很多企业却没有发挥出应有的作用呢？原因在于对版本计划如何做缺乏必要的原则指导，导致各个产品在做版本计划时经常顾此失彼，无法做出合理的版本计划。简单打个比方，CMM就好比是AK47步枪，产品组PDT就好比是握着枪的手，而合理的版本计划就好比是指挥手的大脑，很多企业目前的状态是，AK47步枪擦得很亮，握枪的手却有点嫩，而指挥手的大脑则。。。

本文论述的版本计划不是指版本的零级或一级计划，而是指在产品长期开

发、维护过程中，面对不断变化的客户需求和稳定的版本需求之间矛盾的后续版本开发计划，尤其是在客户需求不断刷新的过程中，后续版本开发与维护中的问题。

怎样才能制定出一个合理的版本计划？

我们来看看制定一个版本计划需要考虑哪些方面的问题。从宏观的方面来

讲，软件工程理论提到，任何一个软件产品都是“特性、质量、时间”三个要素的平衡点，如图1所示。

特性特性特性时间（1）质量质量时间（2）时间质量（3）

图1 版本计划的三要素

图1中画了三个示意图，其中（1）汉捷可以认为是理论上的理想图，即在时间许可的情况下，特性和质量都能够达到最优；（2）可以认为是完成更多的特性，在延长了时间的同时，也使质量下降了；（3）可以认为是为了在短时间内推出一个版本，而牺牲一定的质量。单纯地看待这三个图，并没有优劣之分，软件工程理论也说过，我们只要在具体的开发项目中找到一个平衡点就可以了。

产品应该怎样去选择平衡点？或者说，当各个要素之间发生冲突的时候应该如何取舍呢？每个企业的情况也许不同，汉捷认为比较合适的排序应该是“质量、特性、时间”，即当三者发生冲突时，首先考虑是否可以延长一些时间，其次考虑是否可以裁剪掉一些特性，最后不得已时再考虑是否可以降低质量要求。

之所以做出这样的取舍，是因为IT行业目前研发的主要矛盾是不断刷新的客户需求和稳定的版本质量之间的矛盾。

企业在市场上所处的位置决定了这种开发特点。用户可以接受一个新产品或新特性推迟一段时间提供，但是却无法承受产品不稳定所带来的压力。用户为什么希望提供新产品、新特性？因为用户希望通过提供的设备来增强自身的竞争力，尤其是在目前通讯市场竞争激烈的情况下。但是如果我们的产品在提供新技术的同时，却带来了稳定性的巨大缺陷，用户实际上反而降低了自己的竞争力，而这种不稳定性所造成的用户对我们的怀疑，其影响将是深远的，将会影响用户后期设备的选型工作，那时即使我们的产品已经做得很稳定，但是用户在心有余悸的情况下仍然会做出其他的选择。回顾一个产品的发展经历，市场部同仁一致

认为其推出时间晚了整整一年，组网方式的推出时间也晚了半年。不可否认，如果说上述产品的稳定推出时间能够提前半年或一年，那么公司将会在市场上获得更大的利润空间。但是，换一个角度来看，如果说当年研发部门迫于市场的压力，使用一个不稳定的版本去大规模开局，那么我们就不会在后续的销售中底气十足地说出“XXX在网上使用已达1000余套，到目前为止没有发生过一例故障”这样具有震撼力的话来，我们的后续销售也不会那么快地占领如此多的市场份额。在这两种情况下的销售额曲线见图2示意图。从长远角度来看，推迟一段时间推出稳定版本所带来的总销售额比匆忙推出一个版本应付市场的总销售额要高得多。

销售额走势对比示意销售额时间

图2 销售额走势对比示意

当然，新技术新产品必然具有其一定的时效性，而且我们是工程商人，做

产品的目的就是要尽快创造利润，所以在实际操作中，并不可能无限制地延长时间。当时间已不能再延长时，这时我们就要考虑是否可以再裁剪一些特性。

微软公司经常提到软件开发中的“八十二十”现象，是指用户常常使用的功能一般仅占全部功能的80%，而在开发过程中，我们往往为这20%不常用的功能耗费了80%的精力。因此，当项目开发的时间要求紧、质量要求高时，我们就可以考虑是否可以从现有的已规划的特性中找出那不常用的20%，予以裁剪。

但是，在现在的新产品中，经常遇到的问题却是，一个已经规划好的版本即将按计划推出，这时某位领导一声令下，说某某特性我已经承诺给某某用户，所以你产品必须在该版本中提供，结果产品的开发人员不得不加班加点去完成这个突发任务。这样的做法恰恰是把特性和质量的关系给颠倒了。

第一个问题是，什么新特性竟如此重要，一定要插队到这个新版本中去完成？没有这个新特性，这个版本就没有办法推向市场使用了吗？如果真的存在这种问题，那只能说原来的版本规划是有问题的。但从实际的情况来看，即使这个特性在该版本中不能实现，那么该版本仍然能够应付至少80%的市场，也许有20%的市场会由于这个新特性而受到影响。但是我们要注意的是，是不是这个特性推迟三个月或半年再推出，这20%的市场就完全丢失了呢？这实际上就涉及到公司承诺管理的问题，就是经理以上的人员在与用户交流的过程中存在随意承诺的现象，而这种随意承诺的危害是相当巨大的，因为这些高级别的人员可以轻易变更产品的版本计划，从而打乱产品的开发节奏，最终造成产品开发的混乱，版本质量的低下。

第二个问题是，这种突发任务会给产品的质量带来什么样的影响？也许有人会说，即使是突发任务，在安排的时候也是考虑到开发人员的实际工作量承受能力的，所以不应该对版本质量造成大的影响。汉捷同意工作量的这个观点，但我们也要注意到开发人员的一般心理，做一个新特性开发的吸引力总是大于维护版本、修改错误的吸引力的。因为新特性的开发是可以量化的，任务是明确的，什么时候要完成设计、什么时候完成编码、什么时候联调都很清楚，所以他必须要按照这个时间点去执行，而查错就不一样了，我们的项目计划里常常只是列出一项任务：“查错，从7月1日到7月31日”，这样在相对较紧张的时间里，开发人员就会把主要精力投到新特性的开发上，而对原版本中的错误定位的力量就少了许多。这样带来的问题就是，老版本的错误没有减少，新特性的开发还由于时间仓促而引入了新的错误，导致最终的版本质量降低。

第三个问题是，在质量降低后，我们还可以有补救措施吗？有些人之所以同意突发任务的进入，其理由往往是“先抓紧做，如果不稳定的话就当做没这个特性发布版本就可以了，把事情做在前面总是好的”。这个理由其实是不成立的，原因就在于质量的降低不仅仅体现在新特性的不稳定，还体现在固有错误的继

续存在；而且谁也不能保证用户永远都不会触发这个新特性的执行，所以这种发布出去的版本常常是会出大问题的，并不能达到“只要不用这个特性就会很稳定”的目标。

最后一个问题是，这种未经详细需求分析仓促进入产品的新特性，其生命周期会有多长？根据决策人的眼光，可能情况各不相同，在这里举的例子是xxx版本，该版本共开发了大小三十余条特性，但最终实际在市场大量应用的特性只有五到六条，大部分特性都是开了几个实验局以后就再不使用，甚至还有些特性在开发完成后都无法找到实验局进行网上验证。

最后在时间和特性都无法牺牲的情况下，我们才能考虑牺牲质量。牺牲质量的方法就是“不能搞教条主义的质量”、“革命性妥协”、“加派人手跟踪”等等。本文不再赘述。

总结：汉捷认为根据企业的实际情况，在版本计划的考虑中，应遵循“质量、特性、时间”的取舍原则也许是一种选择。

在这样的取舍原则下，汉捷认为一个合理的版本计划应该具有如图3的分支式版本计划模型：

系统测试系统测试回归测试M20B01M20B02设计、编码、联调系统测试M20B03系统测试M20B04回归测试M21B01M21B02设计、编码、联调M21B03M21B04M22B01。。。。。。

图3 分支式版本计划模型

假定：增加或修改规格需修改M级版本号，改错后的版本发布需修改B级版本号。图3中兰色字体的版本是指新加入特性的版本，红色字体的版本是指发布市场的版本。

图3所表达的思想如下：

1，当一个规划好的增加新特性的版本M20B01刚刚发布测试时，这个版本必然是不稳定的，这时还立足未稳，一定不要急于去开发新特性，而应该踏踏实实地去做系统测试，去查问题，出一个相对比较稳定的版本M20B02。这其间的过程根据新增特性开发工作量的大小及开发的质量，可能需要经过一到两轮系统测试，图中仅经过一次系统测试仅是为了示意方便，M20B02版本的版本级别应至少达到测试部定义的C级版本水平。

2，在一个相对稳定的M20B02版本推出后，以该版本作为基础产生分支，其中一个分支继续做系统测试和回归测试，直到版本的大部分严重问题已被查清、未能重现的问题也大部分找到了规避方法、版本级别至少达到B级版本水平后，此时的M20B04版本即可发布市场使用；在另一个分支上开始新特性的开发，并形成新的M21B01基线版本，该基线版本重复1、2步骤继续开发。

3，从新特性合入的M20B01版本到最终发布市场的M20B04版本应严格控制新特性合入，无特殊情况应坚决控制只改错、不合入新特性。

4，从新特性合入的M20B01版本到下一批特性合入的M21B01版本之间，应有一个中间过渡的M20B02版本，该版本的作用类似于老板所说的“撒一层土，夯实，再撒一层土”中“夯实”的作用。

5，最后发布市场的M20B04版本质量一定要保证，一定要能够顶住市场，这样才能保证后续开发工作不被打乱，才能保证产品开发的节奏性。

各产品比较典型的不甚合理的版本计划归纳起来有如图4的并行开发版本计划模型、图5的突发任务版本计划模型、图6的从容开发版本计划模型三种形式。

系统测试系统测试回归测试M20B01M20B02M20B03系统测试M20B04回归测试设计、编码、联调系统测试M21B01设计、编码、联调M21B02M21B03M21B04M22B01。。。。。。

图4 并行开发版本计划模型

图4所示的版本计划是指，产品组迫于市场的压力，决定同时开发多个特性，但由于某些特性开发的工作量比较大，所以采取一部分人主攻M20B01版本系列的稳定，另一部分同时主攻M21B01版本系列的开发和稳定等。

系统测试系统测试回归测试M20B01M20B02设计、编码、联调系统测试M20B03系统测试M20B04回归测试M21B01M21B02设计、编码、联调M21B03M21B04M22B01。。。。。。

图5 突发任务版本计划模型

图5所示的版本计划是指，产品组迫于市场的压力，在已经经过一轮系统测试的M20B02版本中又突然加入新的特性，而版本推出市场的时间又已经做过承诺，因此不得不把尚未稳定的M20B04版本仓促推向市场，而该版本由于其稳定性太差又起不到顶住市场的作用，于是市场、用服、中研的兄弟又一起翘首期待下一个版本的发布，而下一个版本依然如此，如此往复造成恶性循环。有些情况下有些产品甚至直接就使用M20B03这样的版本在市场上使用，情况就更糟糕了。

系统测试系统测试回归测试M20B01M20B02系统测试M20B03系统测试M20B04回归测试设计、编码、联调M21B01M21B02M21B03M21B04设计、编码、联调M22B01。。。

图6 从容开发版本计划模型

图6是一种比较理想的模型，在这种情况下，产品组能够顶住市场压力，努力做好一个版本并稳定推出后，再启动下一个特性版本的开发，这样做是最从容的，但是也带来客户需求响应时间较长、人力资源使用曲线不合理等一系列问题。

每种模板的特点是什么？哪种问题最大？如何进行管理？这是应该思考的问题。对这四种版本计划模型进行对比分析另文阐述。