明日会

比较早有敏捷开发的概念，或许也是不太正确的概念，是从那本经典的Ruby on Rails的教程上。至少体会到了快速开发的魅力，设计和开发几乎可以同步，包括测试。 ruby on rails的学习告一小小的段落，例子和实际的开发总还是有很大的差距。 最近在做一个不算太大的软件项目，在第一个版本发布后，给自己订下了一个目标，一周发布一个版本。而我需要在每周都完成功能设计、开发、测试、发布这些工作，有时候测试时候发现一些bug或者很好的建议，则流程就变得有所交叉。 很高兴之前基本做到了，连续三周发布了3个版本，目前我已经将周期降到2周一次了，的确软件越来越复杂，需要花费在开发上的时间也越来越多。 我用了以下的方法来保证完整既定的目标： 1 严格的执行特性列表管理，所有本版本要完成的记录在本版本(我用的是build)的特性列表中，然后另外有一个bug and fix来记录可以稍后完成或者还不知道能不能完成的特性。当本版本的特性基本完成后，就可以开始测试了。 2 内部测试小组。自己测试几乎是不太可能发现某些错误的，所以我现在有一个20个人左右由志愿者组成的测试队伍，每次都会有至少几位给我提出不少bug和建议，建议记录到下一个里程碑，bug记录到bug and fix，致命的bug是一定要修改的。这样的测试大概从内部测试版发布后每天一次，修改完错误后，将更新的版本再发布，这时候对于新的特性建议是冻结的，也就是不会进行任何新功能的开发。只有在第一次内部测试和第二次内部测试之间，允许进行新功能的开发，之后所有的时间只能进行bug的纠正。目前来看，最多3个内部测试版本基本就够了。然后就是发布。 3 在内部测试的过程中，我自己也会进行测试，windows软件的麻烦就是在不同的环境下可能会有不一样的表现，在开发环境中正确只能证明正确了一半。我建立了一个由四台电脑组成的测试网络，测试版本的同步是通过在每一台电脑上安装dropbox来容易的做到。我只要在一台电脑上将测试用的安装程序拖放到本机的dropbox文件夹，其他几台电脑就会在开机后的几分钟里同步下载好。当然，我也在本机建立了复杂的测试环境，模拟各个版本的升级操作，这个暂时还没有太好的办法。 4 版本管理是非常重要的事情，永远不要相信硬盘。所以每天将修改过的版本上传svn是必须的。为了保证开发工作的延续，需要准备至少一个后备的开发环境。

相关内容

没有相关内容.