本文篇幅较长，但是对于程序员来说仔细看完肯定会有收获，作者对于开发和项目管理的功力颇深，文中的许多经验办法微软沿用至今。也许读完项目管理需要很长的时间和大量金钱，但是joel的这一套衡量系统，按joel的话说：“三分钟你就可掌握。你可以把省下的时间去读医学院了”（注：美国的医学院可是要读死人的！）。下面我们就开始吧！



　　Joel 衡量法则

　　你们用不用源文件管理系统？
　　你们可以把整个系统从源码到ＣＤ映像文件一步建成吗？
　　你们每天白天都把从系统源码到ＣＤ映像做一遍吗？
　　你们有软件虫管理系统吗？
　　你们在写新程序之前总是把现有程序里已知的虫解决吗？
　　你们的产品开发日程安排是否反映最新的开发进展情况？
　　你们有没有软件开发的详细说明书？
　　你们的程序员是否工作在安静的环境里？
　　你们是否使用现有市场上能买到的最好的工具？
　　你们有没有专职的软件测试人员？
　　你们招人面试时是否让写一段程序？
　　你们是否随便抓一些人来试用你们的软件？

　　“Joel 衡量法则”好就好在你只需照着逐条回答以上问题，然后把所答为“是”的问题算成一分，再加起来就可以了，而不需要去算什么每天写的程序行数或程序虫的平均数等等。但咱丑话说在前面，可别用“Joel 衡量法则”去推算你的核电站管理程序是否可靠。

　　如果你们得了12分，那是最好，得了11分还过得去，但如果只得了10分或低于10分，你们可能就有很严重的问题了。严酷的现实是：大多数的软件开发公司只能得到2到3分。这些公司如果得不到急救可就玄了，因为像微软这样的公司从来就没有低过12分。

　　当然，一个公司成功与否不仅仅只取决于以上标准。比如，让一个管理绝佳的软件公司去开发一个没有人要的软件，那开发出来的软件也只能是没有人要。或反过来，一帮软件痞子以上标准一条也达不到，没准照样也能搞出一个改变世界的伟大软件。但我告诉你，如果不考虑别的因素，你只要能达到以上12条准则，你的团队就是一个可以准时交活的纪律严明的好团队。

　　1. 你们用不用源文件管理系统？
　　我用过商业化的源文件管理系统，我也用过免费的系统，比如CVS，告诉你吧，CVS挺好用。但如果你根本就没有用源文件管理系统，那你就是累死了也没法让你的程序员出活：他们没法知道别人在改动什么源文件，写错了的源文件也没法恢复。

　　使用源文件管理系统还有一大好处是，由于每一位程序员都把源文件从源文件管理系统里提出来放到自己的硬盘里，几乎不会发生丢失源文件的事，最起码我还没听说过。

　　2. 你们可以把整个系统从源码到CD映像文件一步建成吗？
　　这句话问的问题是：从你们最新的源码开始到建立起能够交出去的最后文件，你们有多少步骤要做？ 一个好的团队应该有一个批处理程序一步便可将所有的工作做完，像把源文件提取出来，跟据不同的语言版本要求（英文版，中文版），和各种编译开关（#ifdef）进行编译，联接成可执行文件，标上版本号，打包成CD映像文件或直接送到网站上去，等等等等。

　　如果这些步骤不是一步做完，就有可能出人为差错。而且当你很接近产品开发尾声的时侯，你可能很急于把最后几个虫解决，然后尽快地交活。如果这时候你需要做20步才能把最终文件制出来，你肯定会急得要命，然后犯一些很不该犯的错误。

　　正因为这个原因，我工作的前一个公司从用WISE改用InstallShield：我们必需要让我们的批处理程序完全自动化地，在夜里，被NT scheduler起动把最终文件制成，WISE不能被NT scheduler启动而InstallShield可以，我们只能把WISE扔掉。（WISE的那帮家伙向我保证他们的下一代产品一定支持在夜里自动运行.)

　　3. 你们每天白天都把从系统源码到CD映像做一遍吗？
　　你们有没有遇到过这样的事情：一个程序员不小心把有毛病的源码放进源文件管理系统，结果造成最终文件没法制成。比如，他建立了一个新源文件但忘了把它放进源文件管理系统，然后他高高兴兴锁机回家了，因为在他的机器上整个编译得很好。可是别人却因为这没法工作下去了，也只好闷闷地回家了。

　　这种造成最终文件没法制成的情况很糟糕，但却很常见。如果每天在白天就把最终文件制一遍的话，就可以让这种事不造成太大危害。在一个大的团队里，要想保证有毛病的源码及时得到纠正，最好每天下午（比如午餐时）制一下最终文件。午餐前，每个人都尽可能地把改动的源文件放到源文件管理系统里，午餐后，大家回来，如果最终文件已经制成了，好！这时大家再从源文件管理系统里取出最新的源文件接着干活。如果最终文件制作出错，出错者马上修正，而别人还可接着用原有的没问题的源程序干活。

　　在我以前曾干过的微软Excel开发组里，我们有一条规定：谁造成最终文件制作出错，谁就得被罚去负责监视以后的最终文件制作过程，直到下一位造成最终文件制作出错的人来接任他。这样做不仅可以督促大家少造成最终文件制作出错，而且可以让每个人都有机会去了解最终文件制作过程。

4. 你们有软件虫管理系统吗？
　　不论你有任何借口，只要你写程序，哪怕只是一个人的小组，如果你没有一个系统化的管理软件虫的工具，你写的程序的质量一定高不了。许多程序员觉得自己可以记得自己的软件虫。没门！我从来记不住超过２到３个软件虫。而且第二天早上起床后忙着去买这买那，好不容易记住的软件虫早忘掉了。你绝对需要一个系统来管住你的那些虫。

　　软件虫管理系统功能有多有少。但最少要管理以下几种信息：

　　如何重复软件虫的详细步骤
　　正常情况（无虫）应是怎样
　　现在情况（有虫）又是怎样
　　谁来负责杀虫
　　问题有没有解决
　　如果你觉得用软件虫管理系统太麻烦，可以简化一下，建立一个有以上5列的表来用就行了。

　　5. 你们在写新程序之前总是把现有程序里已知的虫解决吗？
　　微软Windows Word的第一版的开发项目曾被认为是“死亡之旅”项目。好象永远也做不完，永远超时。所有人疯狂地工作，可怎么也完成不了任务。整个项目一拖再拖，大家都觉得压力大得受不了。最后终于做完了这个鬼项目，微软把全组送到墨西哥的Cancun去度假，让大家坐下来好好想想。

　　大家意识到由于项目经理过于强求程序员们按时交活，结果大家只能匆匆地赶活，写出的程序毛病百出。由于项目经理的开发计划并没有考虑杀虫的时间，大家只能把杀虫的任务往后推，结果虫越积越多。有一个程序员负责写计算字体高度的程序，为了图快，居然写一行“return 12;”了事。他指望以后的质检人员发现这段程序有毛病后报告他再改正。项目经理的开发计划事实上已变成一个列写程序功能的清单，而上面列的所谓程序功能迟早都会成为软件虫。在项目总结会上，我们称这种工作方法为“绝对劣质之路”。

　　为了避免再犯这个错误，微软制定了“零缺陷策略”。许多程序员嘲笑这个策略，觉得经理们似乎在指望靠行政命令来提高产品质量。而事实上“零缺陷策略”的真正含义是：在任何时候，都要把解决现有程序里的问题作为首要问题来抓，然后再去写新程序。

　　为什么要这样做呢？

　　一般说来，你越不及时地杀虫，杀虫的代价（时间和金钱）就会越高。比如，你写程序时打错了一个字，编译器马上告诉你，你很容易就把它改正。你刚写好的程序在第一次运行时发现了一个问题，你也很快就能解决它，因为你对你刚写的程序还记忆犹新。如果你运行你的程序时发现了一个问题，可这个程序是几天以前写的，你可能就需要折腾一会儿，还好，你还大致记得，所以不会花太长时间。但如果你在你几个月以前写的程序里发现了问题，就比较难解决了，因为你已经忘了许多细节。这时候，你还没准儿正忙着杀别人程序里的虫呐，因为这家伙到加勒比海阿鲁巴岛度假去了。这时候，解决这一堆问题的难度不亚于从事尖端科学研究。你一定得小心翼翼地，非常系统化地从事，而且你很难知道多长时间你才能把问题解决。还有更糟糕的，你的程序已交到用户手里了，才发现问题，那你就等着掏腰包吧。

总结起来，就一条：越早解决问题，越容易解决。

　　另外还有一个原因，刚写的程序里发现问题，你能够比较容易地估算解决它的时间。举个例子，如果我问你写一段程序去把一个列表排序需要花多长时间，你可以给我一个比较确切的估计。如果你的程序，在Internet Explorer 5.5安装以后，工作不正常。我问你要多长时间把这个问题解决，你恐怕都估计不出来，因为你根本就不知道是什么原因造成了这个问题。你可能要花三天时间才能解决，也有可能只花两分钟。

　　这个例子告诉我们，如果你的开发过程中有许多虫没有及时解决，那你的开发计划肯定不可靠。反过来，如果你们已经把已知的虫全部解决了，要做的事只是写新的程序，那你的开发计划就会比较准确。

　　把已知的虫全部解决，这样做还有一个好处：你可以对竞争对手快速反击。有些人把这叫着“让开发中的产品随时处在可以交给用户的状态”。如果你的竞争对手推出一个新的功能想把你的客户抢走，你可以马上在你的产品里加上这个功能，立刻将新产品交付用户，因为你没有一大堆积累下来的问题要解决。

　　6. 你们的产品开发日程安排是否反映最新的开发进展情况？
　　为什么我们需要开发日程安排？如果你的程序对公司的业务很重要，那公司就必须知道你的程序何时能写完。满世界的程序员都有一个通病，那就是他们都搞不清自己何时才能写完要写的程序。他们都只会对管理人员嚷嚷：“等我做好了就做好了！”

　　不幸的是，程序写完了，事远远没完。作为一个公司，在发行产品之前，还有许许多多的事情要做：何时做产品演示？何时参加展览会？何时发广告？等等。所有的这一且都依赖于产品的开发日程安排。

　　定下产品开发日程安排，还有一个很关键的好处：它逼着你只做叫你做的功能，甩掉那些可要可不要的功能，否则这些可要可不要的东西有可能把你缠住。请看featuritis 。

　　定下产品开发日程安排，按照它开发，这并不难做，请看我的另一篇文章 Painless Software Schedules ，这篇文章告诉你一种制订产品开发日程的好方法。

　　7. 你们有没有软件开发的详细说明书？
　　写软件开发的详细说明书就像是绣花：人人皆知是好东西，可没谁愿意去做。

　　我不知道这是为什么，也许是因为多数程序员天生就不喜欢写文章。其结果是，一个开发组里的程序员们，宁可用程序来沟通，也不愿写文章来表达自己。他们喜欢上来就写程序，而不是写什么详细说明书。

　　在产品的前期设计过程中，如果你发现了一些问题，你可以轻易地在说明书里该几行字就行了。一旦进入了写程序的阶段，解决问题的代价就要高得多了，不仅仅是时间上的代价，而且也有感情上的代价，因为没人愿意将自己做成的东西扔掉。所以这时候解决问题总有一些阻力。

　　没有产品开发详细说明书就开始写程序，往往会导致程序写的乱七八糟，而且左拖右拖不能交付使用。我觉得这就是Netscape遇到的问题。前四个版本的程序越写越乱，以至管理人员作出一个愚蠢的决定：把以前的程序统统扔掉，重新写。后来他们在开发Mozilla时又犯了同样的错误。产品越做越乱，完全失控，花了几年的时间才进入内部测试阶段。

　　我最得意的理论是：如果让程序员们接受一些写文章的训练如an intensive course in writing，他们就可能会改变一下不写说明书的坏习惯，而以上所说的糟糕的例子就有可能少发生。