约耳测试: 迈向高品质的12个步骤(下)
作者: Joel Spolsky 约耳.斯珀儿斯奇
译： Paul May 梅普华
6. 你有一份最新的时程表吗?
我们在这里要谈谈时程表. 如果你的程序对公司非常重要, 有太多理由可以说明预知程序完成时点有多么重要. 程序人员不爱订定时程可是恶名昭彰. 他们会对业务大叫: "该完成的时候就会完成!"
但是问题不可能就这样算了. 业务人员有太多的计划决策必须远在程序出货之前做决定: 展示, 商展, 广告等等. 而做决定的唯一方法就是定出时程并随时更新.
拥有时程的另一个重点是逼你决定要制作哪些功能, 并且能逼你剔除最不重要的功能而避免功能过度膨胀(featuritis, 又名scope creep).
要维护时程表并不困难. 请参阅我的文章Painless Software Schedules, 文中叙述建立好用时程表的简单方法.
7. 你有规格吗?
写规格像用牙线: 大家都同意这是好事, 却没有人真的在做.
我不知道为什么, 或许是因为大多数程序人员都讨厌写文件吧. 所以当全是程序人员的团体 面对问题时, 自然倾向用程序代码而非文件来表示答案. 他们宁愿跳进去写程序也不愿先写规格.
在设计阶段发现问题时, 只要改几行就能轻易修正. 等程序写出来之后, 修正的代价就高得多了, 代价包含了情感 (人们讨厌块弃程序代码) 和时间, 所以会抗拒修正问题. 通常未依据规格制作的软件 最后的设计都很糟, 而且进度完全无法控制. 这似乎就是发生在Netscape上的问题. 它的前四版变得一团乱, 结果管理阶层愚蠢地决定 把程序丢掉重新开始. 然后他们在Mozilla上又重蹈覆辙, 造出了一个无法控制的怪物, 而且耗了几年才进入alpha测试阶段。
我的拿手方法是把程序人员送去上密集的写作课程, 让他们变得不那么排斥写作就可以解决这个问题. 另一个方法是雇用聪明的项目经理来写规格. 不管用哪一种方法, 你都应该强制执行"没有规格不写程序"这个简单的规则.
你可以由我写的四篇系列文章学到所有关于规格的内容.
8. 程序人员有没有安静的工作环境?
有大量的文件记载, 为知识工作者提供空间安静及隐私可以提升产能. 软件管理经典Peopleware大量记录了这种产能上的增益.
这就是问题所在. 我们都知道知识工作者进入"状况"(flow, 也被称作in the zone)时工作效果最佳, 这时候他们会完全与环境脱离, 全心专注在工作上. 他们忘记时间并透过绝对专注产出极佳成果. 他们所有丰富的产出也都是在这个时候完成的. 作家, 程序人员, 科学家, 甚至篮球球员 都会告诉你进入"状况"的情形.
问题是要进入"状况"不是那么容易. 如果你有试着计时, 平均大概要15分钟才能开始全速工作. 有时如果你累了或是那一天已经有很多创造性的成果, 会根本无法进入"状况", 然后看看网页玩玩俄罗斯方块打混过完一天.
还有一个问题就是很容易脱离"状况". 噪音,电话,同事的中断(特别是这一点)都会让你脱离"状况". 假设有个同事问了一个问题让你中断了1分钟, 实际上却会让你完全脱离"状况", 得再等半个小时才能回复生产力, 结果你的整体产能都出问题了. 如果你身在一个喧闹的 BULLPEN环境中(像那些一窝蜂(caffeinated)网络公司最爱营造的典型), 行销部门在程序人员旁对着电话大喊, 你的产能就像一直被中断的知识工作者一样颠簸, 永远无法进入"状况".
这对程序人员来说更加严重. 生产力多寡在于是否能在短期内存中处理大量的细节. 任何一种中断都会让这些细节完全消失. 等你转回来工作时就完全不记得任何细节 (比如正在使用的区域变量名称或是搜寻算法写到哪了), 必须把刚刚的东西找出来, 于是速度就放慢下来一直到你回复为止.
这里有个简单的算术. 我们可以说(依照陈述所暗示的)虽然仅仅打断程序人员一分钟, 事实上是去掉了15分钟的产能. 以此为例, 假设有两个程序人员Jeff和Mutt, 把他们安排在一个标准呆伯特 (Dilbert – 美国漫画) 养牛场里相邻的开放隔间中. Mutt忘记了strcpy函数的Unicode版本拼法. 他可以花30秒自己查出来, 也可以花15秒问Jeff. 由于人就坐在旁边, 所以他问Jeff. Jeff分心所以就损失了15分钟的产能(替Mutt省了15秒).
现在把他们搬到两间有墙有门的独立房间里. 如果Mutt忘记那个函数的拼法, 他可以花30秒查出来, 也可以花45秒过去问Jeff(就典型程序人员的身裁来说离开位置并不轻松). 结果他就自己查了. 于是Mutt损失30秒的产能, 不过却替Jeff省下15分钟. 哎呀呀呀!
9. 你有没有用市面上最好的工具?
用编译语言撰写程序是一般家用计算机还无法瞬间完成的最后几件事之一. 如果你的编译过程超过数秒, 去找台最新最棒的计算机可以替你省点时间. 如果编译需要超过15秒, 程序人员觉得无聊就会跑去看在线新闻The Onion,, 然后陷在里面耗掉几个钟头的产能.
在单营幕系统上替GUI程序除错并非绝不可能, 不过用起来有够痛苦. 如果你在撰写GUI程序, 弄两台营幕会让你轻松许多.
大部份程序人员到最后都得修整图示或工具列所用的图, 可是大部份人都没有一个好用的图形编辑器. 用微软的小画家修图简直是笑话, 不过却是大多数程序不得不做的事.
在我前一家公司, 系统管理员会一直送些垃圾信给我, 抱怨我在服务器上使用了超过"220 MB"的硬盘空间. 我说依据现在硬盘的价格, 这点空间的费用还远比不上我所用的卫生纸. 即使只花10分钟清理目录也是生产力的极大浪费.
一流的开发团队不会虐待他们的程序人员.即使工具不好所引起的挫败很小, 累积起来都会让程序人员心情不爽脾气暴躁. 而不爽的程序人员就等于无生产力的程序人员.
除此之外...程序人员也是很容易用最酷最新的东西贿赂的. 这可远比再增加薪水叫他们工作 要便宜多了!
10. 你有没有测试人员?
如果你的团队没有专门的测试人员(至少每两到三个程序人员要配一名), 你要不是推出问题很多的产品, 就是浪费钱叫时薪100美元的程序人员去做测试员(时薪30美元)做的事. 省测试员绝对不是真省, 这实在是再明显不过了. 我实在很惊讶很多人却还认不清这一点.
看看Top Five (Wrong) Reasons You Don't Have Testers吧, 这是我针对这个题目所写的文章.
11. 有没有在面试时要求面试对象写程序?
你可能不叫魔术师先表演几招就直接雇用吗?当然不会.
你可能不先尝尝菜就决定自己婚宴的餐厅吗? 我很怀疑. (除非是Marge姑姑, 如果不让她弄一道"顶级"碎牛肝饼, 她会恨你一辈子).
尽管如此, 现在程序人员是否录用都还是要看履历是否突出, 或是因为主试人员面谈聊得很高兴, 或是回答些查文件就知道的琐碎问题 (比如CreateDialog()和DialogBox()间的差异是什么?). 你根本不会管他们能否背出几百条有关程序设计的琐事, 你真正在意的是他们能否写出程序. 更糟的情况是问那种"啊!我懂了!"的问题: 就是那种知道答案时理所当然, 可是不知道答案时却莫名其妙的问题(译注:像是脑筋急转弯).
拜托别再这样做了. 随便你想怎么面试都行, 不过记得一定要让面试者写些程序. (需要更多建议时可以看我写的Guerrilla Guide to Interviewing.)
12. 有没有做走廊使用性(hallway usability)测试?
走廊使用性测试是说到走廊拦住下一位经过的人, 然后逼他试用你刚写好的程序. 如果你做够五个人, 就可以发现程序中95%应注意的使用性问题.
良好的使用者接口设计并没有想象中那么困难, 在吸引客户中意并购买产品时又是极为重要的. 你可以参阅我写的免费在线UI设计书, 是针对程序人员的短篇入门书.
不过处理使用者接口时有一点最重要: 如果你把程序展示给少数几个人看(事实上五或六个就够了), 就能快速地发现一般人会遇到的主要问题.Jakob Nielsen的文章 中有解释原因. 即使你的UI设计技巧不足, 只要强逼自己实行不花什么工夫的走廊使用性测试, 就会让你的UI水准大幅提升.
约耳测试的四种用法：
l 对你自己的软件组织评分, 再把分数给我作为讲八卦的题材.
l 如果你是一个程序设计团队的经理, 可以用它来确保团队能在最佳状态工作. 等拿到12分之后, 就可以把程序人员放着不管, 专心去避免业务的干扰就好了.
l 如果你正在决定是否接受一份程序设计的工作, 可以问问未来可能的雇主他们能拿几分. 如果分数太低时要先确定你有权修正这种问题. 否则你将会灰心丧气而且一事无成.
l 如果你是个正在评估某个程序设计团队价值的投资者, 或是你的公司正考虑与其它公司合并, 这个测试可以提供快速的判断方法.
（完）
