互联网项目开发版本划分

前述，本是安排5月份完成的博客任务，推迟到了现在。哈，需要坚持下。

引子

关于版本的话题，很多很广泛。版本啊，版本号啊，版本控制啊，版本管理啊，等，一大箩筐。这次，只单单对之前的遇到印象深刻教训的一次，说说一点自己的看法。

项目开发，也都有流程可循。一般公司做到流程化的较少。但大体的还是有的。只能说不同的项目，在不同的公司，具体到某些流程任务上，安排的有所差别。

说到版本划分，自然就要说到版本管理上面来了。项目立项启动以后，谁来承担这样的工作。架构师?项目经理?技术经理？测试经理? 抑或是CTO，妹的，有没有CEO做这个的？换种方式来问吧，谁更适合做这项工作？这项工作有什么特点呢？当然，套用老板常常说的那句话，也就是你所认为的，是的，就是我所认为的，特点是什么呢？要回答这个问题，就需要知道版本是什么，为什么要采用它。当然是个工具，是个辅助软件项目管理，乃至最后成功的工具。应该在软件行业可能叫版本，其他行业的项目是不是叫阶段，或是周期？或是 phase？行业是不同的。愿景也有远近，也有个阶段；产品有个产品管理，也有版本号；文档也需要管理，也有号，好像牵涉到里面的都有号。号，就是

项目管理那根线的一个个珠子。小珠子环绕几个就会有个大珠子。大珠子绕几个还有更大的珠子。草绳编结记事古已有之。

几个概念（百度百科）

版本

版本，拼音 bǎn běn，最初指一种书籍经过多次传抄、刻印或以其他方式而形成的各种不同本子。随着时代的发展，版本也开始应用于影视、软件等事物上。

版本号

版本号(version number)是版本的标识号， 每一个版本号可以分为主版本号与次版本号两部分。

版本控制

版本控制(Revision control)是一种软体工程技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。

版本控制透过文档控制（documentation control）记录程序各个模组的改动，并为每次改动编上序号。这种方法是工程图（engineering drawings）维护（maintenance）的标准做法， 它伴随着工程图从图的诞生一直到图的定型。 一种简单的版本控制形式，例如，赋给图的初版一个版本等级“A”。当做了第一次改变后，版本等级改为“B”，以此类推等等。

版本管理

版本管理是软件配置管理的基础，它管理并保护开发者的软件资源。

它的主要功能有：

(1) 集中管理档案，安全授权机制：档案集中地存放在服务器上，经系统管理员授权给各个用户。用户通过check in和check out的方式访问服务器上的文件，未经授权的用户则无法访问服务器上的文件。

(2) 软件版本升级管理：每次登入时，在服务器上都会生成新的版本，任何版本都可以随时检出编辑。

(3) 加锁功能：在文件更新时保护文件，避免不同的用户更改同一文件时发生冲突。

(4) 提供不同版本源程序的比较。

开发版本划分

划分原则

1）项目范围

项目有大有小，开始周期有长有短，项目实现的难易程度等。

2）团队组织

团队是否具备完整的生物链，由产品---开发---测试等。单兵独占还是团队协作？

3）开发模式

是否采用传统的瀑布开发模型，还是迭代开发？

版本号

由架构师确定主版本号（技术架构师只是其中的一种，架构师也有种类及层次的）

既然说到是开发，当然只是开发相关这部分。无关产品，业务，或是市场，运营等。谈划分之前，先借用代码大全里面的几句话：架构吃掉需求，设计吃掉架构，开发吃掉设计。多么好的生物链条，类似大鱼吃小鱼，小鱼吃红虫儿，红虫吃泥巴。这当然是有道理的，也是自然的，符合自然规律啊。

那位问了，需求那么多，架构吃得完么？那还不撑死了？是的，问题是需要吃这么多么？需求也是有级别的，比如，业务级，用户级，开发级；也是有不同属性的，比如，功能，质量，约束等。一般来到架构师手中的资料，包括了一个项目中的业务需求，或是产品需求。一般是比较豪放型的，不拘小节。这就需要架构师分辨出一个项目系统中的关键功能，关键质量和相关约束。进而分析需要多少个阶段完成，是否需要大的架构调整。不时跟进后续需求变更等。从这个意义上讲，由架构师确定开发中的版本主版本号是合理的。

由技术经理确定次版本号

既然说到技术经理，就多说一点，一般公司很少设置技术经理这个岗位，大都是由行政管理方式的小组长。上面就是部门经理。当然，技术经理不一定是明确任职的，高程也可以胜任。只是技术经理需要比高程具有更对需求业务深入骨髓的理解。有人出来反对了，这个不是BA了么？事实上，国内一般公司谁搞这些，就是技术经理也很少见啊。技术经理需要参与数据模型的设计，处理流程设计，当然知道哪个模块，哪块业务有牵连，有嵌套，有耦合，等。特别是使用版本管理工具SVN，CVS等，合并分支代码，这有可能是个很大的坑啊，灰常灰常深，经历的那一夜，记忆幽深啊。

这不是绝对的，不同的公司，不同的角色定义不同，但共同点是相似的。那就是对项目整体的把握和深入的理解。也有的公司配有项目管理委员会，具有专职的配置人员，共同讨论决定，等不一一而语。

小结

大多规模不大的公司，出现很多一人多职的情况。但大都具有需求，开发，测试独立出来的团队。而互联网项目时间性要求很紧迫，开发压力大，大都采用迭代开发。这样第一个版本交付测试的同时，开发团队就可以直接进入下一个版本的开发；预留人员修改第一个版本的BUG，再进入第三个版本的时候，一般采用合并版本。当然这只是一般情况，在具有多个产品线开发时，往往是有独立子系统的单独版本。各个子系统又有所区别。但内部一般采用相似的模式。