CSDN博客

img laughsky

约耳测试: 迈向高品质的12个步骤(上)

发表于2003/4/19 9:44:00  745人阅读

约耳测试迈向高品质的12个步骤(上)

作者: Joel Spolsky 约耳.斯珀儿斯奇

译: Paul May 梅普华 

 听说过SEMA这是一套相当深奥的系统可以测量软件团队的好坏等一下不要急着连过去看光是要搞懂那东西大概就要花上六年了所以我自己有一套无责任的简易方法来衡量软件团队的品质这套方法的好处是只要花3分钟左右省下的时间足够让你念趟医学院.

The Joel Test

l         你有使用原始码控制系统吗

l         你能用一个步骤建出所有结果吗

l         你有没有每天都重新编译建立(daily builds)

l         你有没有问题追踪数据库(bug database)? 

l         你会先把问题都修好之后才写新的程序吗

l         你有一份最新的时程表吗

l         你有规格吗

l         程序人员有没有安静的工作环境

l         你有没有用市面上最好的工具

l         你有没有测试人员

l         有没有在面试时要求面试对象写程序

l         有没有做走廊使用性(hallway usability)测试

约耳测试 (Joel Test) 的好处是每个问题都很容易回答是或否你不必计算每天写的程序行数或是每个转折点的平均问题数量只要答""就加1约耳测试的缺点是绝对不能用来确保核电厂的安全性.

12分是完美, 11分勉强可接受不过10分以下(10)就表示问题大了事实上大部份软件组织都只拿到23这些组织都岌岌可危因为微软随时都是以12分的水准运作

当然啦这些并不是决定成败的唯一因素特别是当你的优秀团队做些没人要的产品时(没人要). 另外也可能有那种"高手"团队即使完全不鸟这些东西却还是能做出改变世界的梦幻软件不过除此之外其它人都一样如果你能把这12件事做好就能建立一个能稳定出货的纪律团队.

1. 你有使用原始码控制系统吗?

我用过一些商用原始码制系统也用过免费的CVS, 我可以告诉你CVS相当不错不过如果你没有原始码控制系统当需要程序人员合作时你就会被压垮了程序人员没法子知道其它人做了些什么也不能轻易恢复成出错前的状态原始码控制系统还有另一个优点就是原始码会被注销(check out)到各个程序人员的硬盘里 -- 我还没看过哪个用了原始码控制的项目会遗失大量程序.

2. 你能用一个步骤建出所有结果吗?

我的意思是从最新的原始码快照开始要花多少步骤才能建立出货用的软件好的团队会有单个脚本档案只要执行这个档案就会从头注销所有档案编译每一行程序建立执行文件(包含所有不同版本,语言以及 #ifdef组合), 制作安装程序并且产生出最后要用的媒体形式 -- 光盘片编排网站下载或是其它各种形式.

如果这个程序不只一个步骤就会容易出错另外当出货时程紧逼时修正"最后的"问题,制作最终执行档等等的过程要能飞快地完成如果程序编译和安装文件制作等动作要20个步骤才能完成你一定会急疯掉并且做出一些蠢事.

就是为了这一点我前一家公司把原本用的WISE换成InstallShield: 我们需要能透过NT工作排程器在晚上用描述档自动执行的安装制作程序由于WISE不能透过工作排程器半夜执行所以我们就把它丢掉了. (亲切的WISE员工跟我保证他们的最新版一定会支持夜间执行.)

3. 你有没有每天都重新编译建立(daily builds)?

在使用原始码控制工具时有时候程序人员会不慎登入(check in)某些内容而导致编译失败举例来说某人新增加了一个原始程序文件整个程序在他的机器上都能正常编译可是却忘记把新增的程序文件加到原始码控制程序库中结果这位仁兄健忘并快乐地锁上机器回家了其它人都不能做事所以也只好很不爽地回家.

导致编译失败非常糟糕(又经常发生), 这时每天重新编译建立就很有帮助了它能保证不会有漏网之鱼在大型的团队中要确保能立即修正编译失败的最佳方法就是每天下午(像是午餐时间)重新编译大家在午餐前尽可能的登入档案等大家回来的时候已经编译完毕如果结果正常很好大家可以注销最新版的原始码继续工作如果有问题就去把它搞定而其它人还可以用前一版没问题的程序继续干活.

我们Excel团队有个规定导致编译失败的人必须从此负责重新编译的动作(作为处罚), 一直到有其它人出错为止这是个让人不要导致编译失败的好诱因同时是个让大家轮流处理重新编译的好方法这样大家都会知道怎么做

我这篇文章里有更多每日重新编译的数据:Daily Builds are Your Friend.

4. 你有没有问题追踪数据库(bug database)?

不管你说什么只要你在写程序(只有一个人写也一样), 如果没有一套良好的数据库列出程序中所有的问题一定会产生品质低劣的程序代码很多程序人员自认能把问题清单记在脑里才怪我从来没法子一次记住超过二或三个问题而且会在第二天早上或是赶着出货时把它们全部忘掉你一定要正式的记录问题.

问题数据库可大可小一个最简化的有效问题数据库必须包含每个问题的下列数据:

l         重现问题的完整步骤 

l         应该看到的行为 

l         实际看到的(有问题的)行为 

l         被指派的负责人 

l         是否已修正 

如果你是觉得问题追踪软件太复杂才不追踪问题建个5栏的表填上这些重要字段然后开始用吧.

想深入了解问题追踪, 请参阅无痛错误追踪.

5. 你会先把问题都修好之后才写新的程序吗?

古早第一版的Microsoft Word for Windows 被视作为"死亡行军"型项目进度一直落后整个团队的工作时间长得离谱项目却一延再延三延大家都承受到无比的压力拖了几年后那个鬼东西终于上市了微软就把整个团队送到Cancun (墨西哥著名海滩渡假然后再坐下来做些深度反省.

他们发现项目经理过度坚持要保持"进度", 结果程序人员只能赶工写出烂程序而且正式的时程并没有包含错误修正的阶段没有人试图要减少问题数量而且实际上刚好相反有个程序人员要写程序计算一行文字的高度结果他只写了"return 12;" 并等问题报告出炉说这个函数功能不对时程表变成一份等着被转换成问题的功能列表事后检讨时称之为"无穷错误法".

为了修正这个问题微软全面采用所谓的"零错误作法". 很多公司里的程序人员都不禁窃笑因为听起来像是管理阶层认为能用行政命令降低错误数量实际上"零错误"是指无论何时都要先修正错误才能写新程序原因如下

一般来说愈晚修正错误修正所付出的成本(时间及金钱)愈高.

举例来说当你打错字或出现编译器会发现的语法错误要修正只是小事一件.

当你的程序第一次执行出错时应该也能立即改正因为整个程序还在你脑海里.

如果要为几天前写的程序除错应该需要回想好一阵子不过当里重读所写的程序之后就会记起所有细节并在适当时间内把问题修好.

不过如果你要为几个月前写的程序除错很可能已经忘掉了一大半要修正就是难上加难你也可能正在替别人的程序除错而当事人可能正在阿卢巴渡假这时候除错就像科学一样你得条理分明小心翼翼地慢慢来而且也无法确定要多久时间才能解决.

另外如果要为已出货的程序除错要修正问题的代价可是难以估算的.

要立即修正问题的理由之一就是因为这样做能少花点时间另一个理由是写新程序的时间比修正现有错误的时间较易估计举例来说如果要你估计写个串行排序的程序需要多久你应该能估算得相当准确不过如果说你的程序在装了Internet Explorer 5.5之后有问题要估计需要多久才能修好这个问题恐怕你连猜都不会因为你不知道(当然不知道)问题哪儿来的要找出问题可能要花3也可能只花2分钟。

我的意思是如果你的计划时程里有很多错误待修正这种时程是不太可靠的不过如果把已知的错误都修好了所剩的就只要新程序了那么你的时程就会变得非常准确.

把错误数量维持在零还有另外一个优点就是面对竞争时反应更快有些程序人员认为这样做能让产品随时能推出所以如果竞争者推出某个杀手级新功能来抢客户你只要把那个功能加上去就可以立即出货不必去修正累积下来的大量问题.(待续)

0 0

相关博文

我的热门文章

img
取 消
img