
你有源代码控制系统吗?如果没有,那就是个大问题了。你得赶紧添置一个。没有源代码控制,你就跟玩俄式轮盘一样:你不能恢复已做出的更改,你没有源代码的备份,你没有历史记录,这样你也几乎不可能建立合适的"持续集成"的服务装置。
2、持续集成(Continuous Integration)
你有一个持续集成的服务器装置吗?设想一下:生成器是根据导入的代码进行编译,如果你每次导入的代码,都让生成器来编译,这就足以使整个过程变得复杂了,更不用说有很多人导入各种各样的代码。但是,持续集成装置将自动地编译你的软件项目,并且能给你编译的结果。你甚至能添加Unit Tests、Coding Standards Tests等等。但是为了让你更容易明白还是不要搞的太复杂。
3、软件缺陷跟踪系统(Bug Tracking System)
如果没有软件缺陷跟踪系统你就无法方便地衡量软件的质量。在任何时候你都应该能够看到哪些功能模块正在被构建、被测试、被通过以及哪些模块出现问题了等等。如果你还在依靠excel表或是笔记做这项工作,那么赶快投资一点钱添置一个(程序)错误跟踪系统吧!
4、补丁系统(Patching System)
这里我并不是要谈论installer的问题,我要说的是你需要一个补丁系统。你肯定不想经常重装你的testers.
5、删减未测试的功能模块(Disable Untested Features)
删减你的软件中所有未完整地经过软件缺陷测试以及未被使用者认可的功能模块。如果你的软件陷入困境,你很可能会觉得其中还有90%-95%的功能模块能够执行,而实际上却只有80%.
6、列出主要的功能模块(List Major Features)
列出软件项目中涉及到的所有主要功能模块。从这些高水平的功能模块入手,这是开始挽救整个项目的关键步骤。如果将软件的开发比作战争的话,列出主要的功能模块可以让你避免一场与成千个功能模块无止境的恶战,你的战争规模会相对较小并且更容易获胜。
7、提炼重中之重
好的,你已经列出了所有主要的功能模块,现在从这个列表中再提炼出20%的功能模块(这部分应该是所有主要功能模块中最突出的),将其做成另一个列表。这20%的功能模块是软件发布之前,在最终测试版本中都应该能实现的。
8、详述20%的高水平功能模块(Detail Out Top 20%)
参照这个20%的功能模块列表,做另一个明细表,在明细表中详述为完成这20%部件所需实现的各项功能。另外将这些功能按其重要程度进行排序。我比较倾向于把最复杂的排在首位,最后才是简单的。借助这个表只是为了使你的项目进行的更有条理(如先完成简单的功能模块),而不是让你透过这个表来看你的工作量有多大。
9、制定周计划(Plan The Week)
仔细地合计出下一周你能完成哪些功能模块并把这些功能模块分配给团队里的程序员。你在分配时最好把类似的功能模块放到一块分配。要保证每位程序员都有规则地导入代码。如果他们导入代码导致构建失败,那他们必须立刻对这个构建做出修正。
10、创建子系统(Create Branch)
使用你所选择的源代码控制系统创建一个子系统。在这一步骤中,你需要创建一个等待测试的子系统,然后在下一步中建一个补丁系统。接下来测试人员进行测试,而你则规划下一周的工作。
11、为测试人员建立测试版(Build Release for Testers)
让你的生成器加把劲,让他为你的内部质量保障团队建立补丁程序。
12、测试阶段(Testers Take Flight)
希望你已经有了一个质量保障团队,如果没有那你就要着手建一个至少有一人的质量保障团队,并给团队的人配备程序缺陷追踪系统。让他们尽快拿到补丁程序,并且开始测试。顺便说一句,如果你能把客户或终端用户纳入你的质量保障团队那就再好不过了。只要你的测试人员发现错误(如有关功能模块执行的问题),要保证他们能把这些错误报告给软件程序员。如果你有一个好的软件缺陷跟踪系统的话,当你的测试员给出反馈或是改变了错误软件的状态,这个系统应该会自动发送E-mail给程序员。
13、软件开发人员致力于主干开发工作(Software Developers Work on Trunk)
当你的测试员在做测试时,你的程序员在继续着下一周要做的功能模块。当软件出现错误时,程序员返回子系统,解决问题,然后再回到主干的开发中。
14、验收补丁
你的测试员已经完成测试了吗?所有的事情看上去顺利吗?别着急!你仅仅是完成了第一套可以安装的功能模块罢了。从技术上讲,如果你的工作是按照上边列出的步骤进行的,在这个阶段,客户