本来打算这次10月份北京的年会的时候讲这个话题的，但是由于出入境手续的一些问题，这次可能参加不了。 所以就把内容简单在这里分享一下，收集一下意见，以后有机会再讲
和去年一样，我的主题还是如何高效管理
软件工程以达到输出一流品质的产品。 去年的内容比较偏重于具体的编码测试， 这次的内容则侧重于工程的时间计划安排，版本周期管理。
前几天在论坛里面做了一个
调查，发现多数软件的版本升级周期都是不确定的。 其实一个
稳定的版本周期是非常重要的：
1）给客户一种很强的信任感， 让他们觉得你的团队是高效而且认真负责的。
2）给客户跟踪你产品发展一个线索，比如他们知道你2个月后有新品发布，会下意识去你
网站看看。
3）稳定的版本周期等于给自己的工作制定了一个计划， 保证了进度。
这里的
版本指的是重大版本升级（比如1.0 升级到2.0)，功能上的重大改进。 我一般称小版本（比如 1.1 升级到1.2 ）为
补丁。 我发现有不少软件并不是很区分这种大小版本， 小版本也会加入新功能，大版本也有只是做Bug fix的。 我还是
建议小版本只做Bug fix， 而把要增加的新功能放到大版本里面去。 这样大版本和大版本之间才有显著的差异， 才能诱惑用户去掏钱升级。 不要做什么终生免费升级的承诺，那就等于挥刀自宫。如果你的软件是按月收服务费另当别论。
一些中大型的软件版本周期一般是18个月甚至更长。但是
共享软件应该短一些，因为那些下载网站或者软件新闻网站会每天向用户报告升级软件列表， 所以每当你升级会吸引眼球，达到广告的目的。 这里我以
6个月（24个星期）为例子谈谈具体整个周期应该如何管理， 各位可以结合自己具体实例来做相应的缩放。
产品的设计 4个星期： 千万不要忽略了设计文档的重要性，它绝对是让你事半功倍的武器。 这里的设计文档(specification)包括功能设计和软件架构设计(architecture)， 如果你有专门测试人员，还要有测试计划文档（test plan)。 功能设计决定你在这个新版本里面要加入什么新的功能，改进那些地方等。 另外在功能设计文档里面一定要写2～3个User Scenario（用户使用案例）。通过Use scenario ，你经常可以发现你的功能设计里面忽略了那些东西，界面设计不人性化的地方）。 拿建筑做例子，如果忽略了功能设计，很有可能在大楼施工结束之后发现少了通风或者排水系统。 软件架构设计就是具体的软件模块的划分、流程图， 它的重要性我想大家都很清楚了，所以我就不用赘言了。 如果有条件的话，还可以和别人讨论一下收集建议。 修改设计文档比后期修改代码要容易很多，所以设计文档是防止做无用功的一个重要手段。
具体开发编码 10个星期：等设计做好之后，具体的施工就比较直观简单了。 按部就班一个一个模块完成再进行整合。 这里要强调就是你要在上个发布版本的代码（比如1.0) 上开发你的新版本。 所以你要维护2代码， 一份用于修复上一个版本的bug，可以称之为 1.0bugfix 分支; 另外一份就是这个正在开发中的2.0版本，可以称之为2.0 分支。
与旧版本bug fix整合 1个星期： 刚才说了，你的所有2.0版本的代码都在2.0分支， 而你1.0 版本的bug修复代码都在1.0 bugfix分支 ，所以你要整合他们。 如果你使用CVS,SVN来管理的你的代码的话，它们都有自动整合2个分支代码的功能，不妨试试。
测试以及修复Bug 7 个星期： 本来按道理测试的时间一般要等于编码的时间。 但由于
共享软件作者的资源有限， 所以我把编码时间延长一点，测试时间缩短一点。 其实测试和编码是一样重要的，甚至更重要！ 一流质量的软件不是靠一般牛B 程序员写漂亮代码搞出来的，而是靠一群测试人员辛辛苦苦测出来的。 质量稳定的过程其实就是一个不断发现bug、修复bug的迭代过程。说什么无bug free的编码都是痴人说梦。 如何做测试？ 这时候第一个月写的设计文档又在这里发挥重要作用了。 根据设计文档里面描述的功能一个一个尝试，并且从各种不同角度去思考用户会如何使用这个功能，然后做相应的测试。 其实开发人员是不应该做测试人员的，因为他们会下意识避开软件中的潜在Bug。所以有条件还是找其他人来做测试。如果设计文档写得好，他们自然会理解如何去测。
文档编写、打包、更新网站 2个星期：这个就是最后阶段的编写
帮助文档、 做安装包、上传到下载网站、更新自己网站。 都是体力活， 没有什么技巧可以分享。 唯一一个tip就是尽量把这个过程自动化，这样下次做同样事情的时候就可以节省很多时间了。
上面讲的是大版本的周期， 小版本（补丁）周期的更新就相对比较随意。 一般在软件发布之后的最初那段时间内会发现比较多Bug，所以可以考虑在发布大版本后
2~3星期左右发布一个小版本，之后bug越来越少，时间间隔可以适当拖长（1个月甚至更久）。 建议在软件里面加入 Autodupate， 方便你的客户升级小版本。 各个大版本可以考虑采用不同的autoupdate 网址，这样可以限制用户autoupdate 到大版本。
最后讲产品的客服周期，一般的做法是只对当前版本和上一个版本做客服。 比如现在发布出去是5.0版本，那么3.x的版本就不再做客服了。 当然你可以可以根据自己情况, 客服更早的版本。 一般来说，共享软件作者的资源都很有限，终身客服会把自己拖垮的。
以上就是我个人经验的分享， 给大家参考一下。可能有不少疏漏的地方，请批评指正。 也请各位分享一下各自的经验， 共同提高。
WinHack
2007.09
[
本帖最后由 WinHack 于 2007-9-16 14:34 编辑 ]
