软件开发成功12法则2

6. 你们的产品开发日程安排是否反映最新的开发进展情况？ 为什么我们需要开发日程安排？如果你的程序对公司的业务很重要，那公司就必须知道你的程序何时能写完。满世界的程序员都有一个通病，那就是他们都搞不清自己何时才能写完要写的程序。他们都只会对管理人员嚷嚷：“等我做好了就做好了！” 不幸的是，程序写完了，事远远没完。作为一个公司，在发行产品之前，还有许许多多的事情要做：何时做产品演示？何时参加展览会？何时发广告？等等。所有的这一且都依赖于产品的开发日程安排。 定下产品开发日程安排，还有一个很关键的好处：它逼着你只做叫你做的功能，甩掉那些可要可不要的功能，否则这些可要可不要的东西有可能把你缠住。请看featuritis 。 定下产品开发日程安排，按照它开发，这并不难做，请看我的另一篇文章 Painless Software Schedules ，这篇文章告诉你一种制订产品开发日程的好方法。 7. 你们有没有软件开发的详细说明书？ 写软件开发的详细说明书就像是绣花：人人皆知是好东西，可没谁愿意去做。 我不知道这是为什么，也许是因为多数程序员天生就不喜欢写文章。其结果是，一个开发组里的程序员们，宁可用程序来沟通，也不愿写文章来表达自己。他们喜欢上来就写程序，而不是写什么详细说明书。 在产品的前期设计过程中，如果你发现了一些问题，你可以轻易地在说明书里该几行字就行了。一旦进入了写程序的阶段，解决问题的代价就要高得多了，不仅仅是时间上的代价，而且也有感情上的代价，因为没人愿意将自己做成的东西扔掉。所以这时候解决问题总有一些阻力。 没有产品开发详细说明书就开始写程序，往往会导致程序写的乱七八糟，而且左拖右拖不能交付使用。我觉得这就是Netscape遇到的问题。前四个版本的程序越写越乱，以至管理人员作出一个愚蠢的决定：把以前的程序统统扔掉，重新写。后来他们在开发Mozilla时又犯了同样的错误。产品越做越乱，完全失控，花了几年的时间才进入内部测试阶段。 我最得意的理论是：如果让程序员们接受一些写文章的训练，如an intensive course in writing，他们就可能会改变一下不写说明书的坏习惯，而以上所说的糟糕的例子就有可能少发生。 另一个解决问题的办法是：雇一些能干的项目主任，专职写产品开发详细说明书。 不论采用以上哪种方法，道理只有一个：在没有产品开发详细说明书之前，决不可写程序。 如果想更多了解这个话题，可以读我的四篇文章。 8. 你们的程序员是否工作在安静的环境里？ 当你让你的智囊们工作在安静，宽敞，不受人打扰的环境里，他们往往能更快地出活，这已是不争的事实。有一本经典的讲软件开发管理的书Peopleware（人件） 把这个问题阐述得很清楚。 问题在于，我们都知道最好不要打断这些智囊们的思路，让他们一直处于他们的最佳状态中，这样他们就能全神贯注，废寝忘食地工作，充分发挥他们的作用。作家，程序员，科学家，甚至篮球运动员都有他们的最佳状态。 问题还在于，进入这个最佳状态不容易。我觉得平均起来，需要15分钟才能进入最佳状态，达到最高工作效率。有时侯，当你疲劳了或已经高效率地干了许多工作了，你就很难再进入这个状态，只好干点杂事打发时间，或上网，玩游戏等。 问题更在于，你很容易就被各种各样的事打扰，被拽出你的最佳状态：噪音啦，电话啦，吃午饭啦，喝杯咖啡啦，被同事打扰啦，等等。如果一个同事问你一个问题，只花你一分钟，可你却被拽出你的最佳工作状态，重新回到这个状态需要花半小时。你的工作效率因此而受到很大影响。如果让你在一个嘈杂的大房间里工作（那帮搞网站的家伙还就喜欢这样），边上的推销员在电话里大叫大嚷，你就很难出活，因为你进入不了你的最佳工作状态。 作为程序员，进入最佳工作状态更难。你先要把方方面面的细节装在脑子里， 任何一种干扰都可能让你忘掉其中某些东西。你重新回来工作时，发现好些东西记不起来了（如你刚用的局部变量名，或你刚才的搜索程序写到哪里了等），你只好看看刚写的程序，回忆一下，慢慢地回到你刚才的最佳工作状态。 我们来做一个简单的算数。假设一个程序员被打扰一下，哪怕只有一分钟，他却需要花15分钟才能回到最佳工作状态（统计资料显示如此）。我们有两个程序员：杰夫和愚夫， 坐在一个大办公区里工作。愚夫想不起来用什么函数去进行Unicode 字符串复制。他可以花30秒查一下，或者花15秒问杰夫。由于他坐在杰夫的旁边，他就选择去问杰夫。杰夫被打扰了一下，耽误了他15分钟，节省了愚夫15秒钟。 现在，我们把他们俩用墙和门隔开，让他们俩分坐在不同的办公室里，愚夫又想不起来什么函数名，自己查一下要花30秒；问杰夫，要花45秒，因为他要站起来走过去问（对这帮程序员来说，这可不是件简单的事，看看他们的体质就知道为什么了）。所以他选择自己去查。愚夫损失了30秒钟，可是杰夫少损失了15分钟。哈哈！ 9. 你们是否使用现有市场上能买到的最好的工具？ 用可编译语言写程序恐怕是这世界上为数不多的还不能随便抓一个破计算机就可以做的事。如果你用于编译的时间超过几秒钟，你就应该换一台最新最快的计算机了。因为如果编译时间超过15秒，程序员们就会不耐烦，转而去上网看一些无关的东西比如The Onion，弄不好一看就是好几个小时。 调试图形界面软件时，用只有一个显示器的计算机不仅不方便，有时甚至是不可能。用有两个显示器的计算机，要方便许多。 程序员们经常不可避免地要去画一些图标或工具栏图。多数程序员没有一个好的图形编辑器可用。用微软的“画笔”软件去画图标简直是笑话，可事实上大家还就在这样做。 在我的前一个工作，系统管理员成天给我发来自动警告，说我在服务器上使用了超过220兆的空间。我告诉他，按现在硬盘的价钱，超出这点空间的价钱远低于我用的厕纸的价钱。让我花10分钟去清理我的文件绝对是我工作效率的莫大浪费。 一流的开发组绝不折腾它的程序员。工具落后会让人用起来觉得难受，一点点积累起来，会让程序员们成天叫苦，而一个成天叫苦的程序员绝对不会是一个高消率的程序员。 再添一句，要想使你的程序员高兴，最好的办法就是给他们买一些最新最棒的工具软件。用这种方法可以让他们乖乖地为你工作，这可比用高薪吸引他们来得便宜得多。 10. 你们有没有专职的软件测试人员？ 如果你的开发组里没有专职的测试人员，或没有足够的测试人员（两到三个程序员就应该配一个测试员），那你的产品就一定是毛病百出。想在测试员身上省钱，绝对是打错了算盘。我真不明白为什么这么多人算不过来这笔帐。 我有另一篇文章专门讲这个，请看Top Five (Wrong) Reasons You Don't Have Testers。 11. 你们招人面试时是否让写一段程序？ 我问你，让你去招一个魔术师，你是否连看都不看一眼他的魔术玩得怎样就要他？当然不会！ 你举办婚宴，要请一个厨师，你是不是连嚐也不嚐他做的菜好吃不好吃就要他？我想也不会。 奇怪的是，几乎每天都有这样的事发生：在面试一个程序员时，简历写得漂亮，谈得热火朝天，问几个简单的问题（如CreateDialog()和DialogBox()有什么区别？这种问题，查一下帮助文件就知道了），人就招进来了。你真正应该关心的不是这人记不记得这些写程序的边边角角的东西，而是他能否出产品！更糟糕的是，许多问题是知道就知道，不知道，想死也不知道的问题。 不能这样下去了！在面试时，请一定要让写一段程序。在我的这篇文章里Guerrilla Guide to Interviewing，我有许多好建议。 12. 你们是否随便抓一些人来试用你们的软件？ 这句话的意思是，让你从走道里走过的人中，随便抓几个人来，让他们试用你的软件。如果你抓五个人来用你的软件，那你就可能把你的程序中95%的不方便使用的地方找出来。 要想让用户去买你的软件，你必须要设计好你的用户界面。这其实并不难。你可以读我的free online book on UI design打打基础。 用户界面设计的关键是，如果你让几个人去用你的软件（五六人可能就够了），你可能很快就找出最大的问题。想知道为什么吗，请读Jakob Nielsen's article。只要你坚持随便抓一些人来试用你的软件，你就能将你的用户界面设计得越来越好。 -------------------------------------------------------------------------------- The Joel Test 软件开发成功12法则的四个实用领域： 1. 用该法则来衡量你的软件开发组，告诉我你得的分数，让我来品头论足。 2. 如果你是开发组的经理，用该法则来使你的组提高效率。如果你们一上来就能得12分，你就别再打扰你的程序员了，专心致志别让公司的管理人员来烦你的程序员吧。 3. 如果你在找一份程序员工作，问问你未来的老板他能得几分，如果分数很低，你一定要确信你进去后有足够的权力来改变这一切，否则，最好躲远点，不然，你在那儿会很难受的。 4. 如果你是投资者，正在决定是否向一个软件公司投资，或者你的软件公司正在决定是否兼并另一个软件公司，该法则可以帮你做决定。