本文篇幅較長，但是對于程序員來說仔細看完肯定會有收獲，作者對于開發(fā)和項目管理的功力頗深，文中的許多經驗辦法微軟沿用至今。也許讀完項目管理需要很長的時間和大量金錢，但是joel的這一套衡量系統(tǒng)，按joel的話說：“三分鐘你就可掌握。你可以把省下的時間去讀醫(yī)學院了”（注：美國的醫(yī)學院可是要讀死人的?。?。下面我們就開始吧！



　　Joel 衡量法則

　　你們用不用源文件管理系統(tǒng)？
　　你們可以把整個系統(tǒng)從源碼到ＣＤ映像文件一步建成嗎？
　　你們每天白天都把從系統(tǒng)源碼到ＣＤ映像做一遍嗎？
　　你們有軟件蟲管理系統(tǒng)嗎？
　　你們在寫新程序之前總是把現有程序里已知的蟲解決嗎？
　　你們的產品開發(fā)日程安排是否反映最新的開發(fā)進展情況？
　　你們有沒有軟件開發(fā)的詳細說明書？
　　你們的程序員是否工作在安靜的環(huán)境里？
　　你們是否使用現有市場上能買到的最好的工具？
　　你們有沒有專職的軟件測試人員？
　　你們招人面試時是否讓寫一段程序？
　　你們是否隨便抓一些人來試用你們的軟件？

　　“Joel 衡量法則”好就好在你只需照著逐條回答以上問題，然后把所答為“是”的問題算成一分，再加起來就可以了，而不需要去算什么每天寫的程序行數或程序蟲的平均數等等。但咱丑話說在前面，可別用“Joel 衡量法則”去推算你的核電站管理程序是否可靠。

　　如果你們得了12分，那是最好，得了11分還過得去，但如果只得了10分或低于10分，你們可能就有很嚴重的問題了。嚴酷的現實是：大多數的軟件開發(fā)公司只能得到2到3分。這些公司如果得不到急救可就玄了，因為像微軟這樣的公司從來就沒有低過12分。

　　當然，一個公司成功與否不僅僅只取決于以上標準。比如，讓一個管理絕佳的軟件公司去開發(fā)一個沒有人要的軟件，那開發(fā)出來的軟件也只能是沒有人要。或反過來，一幫軟件痞子以上標準一條也達不到，沒準照樣也能搞出一個改變世界的偉大軟件。但我告訴你，如果不考慮別的因素，你只要能達到以上12條準則，你的團隊就是一個可以準時交活的紀律嚴明的好團隊。

　　1. 你們用不用源文件管理系統(tǒng)？
　　我用過商業(yè)化的源文件管理系統(tǒng)，我也用過免費的系統(tǒng)，比如CVS，告訴你吧，CVS挺好用。但如果你根本就沒有用源文件管理系統(tǒng)，那你就是累死了也沒法讓你的程序員出活：他們沒法知道別人在改動什么源文件，寫錯了的源文件也沒法恢復。

　　使用源文件管理系統(tǒng)還有一大好處是，由于每一位程序員都把源文件從源文件管理系統(tǒng)里提出來放到自己的硬盤里，幾乎不會發(fā)生丟失源文件的事，最起碼我還沒聽說過。

　　2. 你們可以把整個系統(tǒng)從源碼到CD映像文件一步建成嗎？
　　這句話問的問題是：從你們最新的源碼開始到建立起能夠交出去的最后文件，你們有多少步驟要做？ 一個好的團隊應該有一個批處理程序一步便可將所有的工作做完，像把源文件提取出來，跟據不同的語言版本要求（英文版，中文版），和各種編譯開關（#ifdef）進行編譯，聯接成可執(zhí)行文件，標上版本號，打包成CD映像文件或直接送到網站上去，等等等等。

　　如果這些步驟不是一步做完，就有可能出人為差錯。而且當你很接近產品開發(fā)尾聲的時侯，你可能很急于把最后幾個蟲解決，然后盡快地交活。如果這時候你需要做20步才能把最終文件制出來，你肯定會急得要命，然后犯一些很不該犯的錯誤。

　　正因為這個原因，我工作的前一個公司從用WISE改用InstallShield：我們必需要讓我們的批處理程序完全自動化地，在夜里，被NT scheduler起動把最終文件制成，WISE不能被NT scheduler啟動而InstallShield可以，我們只能把WISE扔掉。（WISE的那幫家伙向我保證他們的下一代產品一定支持在夜里自動運行.)

　　3. 你們每天白天都把從系統(tǒng)源碼到CD映像做一遍嗎？
　　你們有沒有遇到過這樣的事情：一個程序員不小心把有毛病的源碼放進源文件管理系統(tǒng)，結果造成最終文件沒法制成。比如，他建立了一個新源文件但忘了把它放進源文件管理系統(tǒng)，然后他高高興興鎖機回家了，因為在他的機器上整個編譯得很好?？墒莿e人卻因為這沒法工作下去了，也只好悶悶地回家了。

　　這種造成最終文件沒法制成的情況很糟糕，但卻很常見。如果每天在白天就把最終文件制一遍的話，就可以讓這種事不造成太大危害。在一個大的團隊里，要想保證有毛病的源碼及時得到糾正，最好每天下午（比如午餐時）制一下最終文件。午餐前，每個人都盡可能地把改動的源文件放到源文件管理系統(tǒng)里，午餐后，大家回來，如果最終文件已經制成了，好！這時大家再從源文件管理系統(tǒng)里取出最新的源文件接著干活。如果最終文件制作出錯，出錯者馬上修正，而別人還可接著用原有的沒問題的源程序干活。

　　在我以前曾干過的微軟Excel開發(fā)組里，我們有一條規(guī)定：誰造成最終文件制作出錯，誰就得被罰去負責監(jiān)視以后的最終文件制作過程，直到下一位造成最終文件制作出錯的人來接任他。這樣做不僅可以督促大家少造成最終文件制作出錯，而且可以讓每個人都有機會去了解最終文件制作過程。

4. 你們有軟件蟲管理系統(tǒng)嗎？
　　不論你有任何借口，只要你寫程序，哪怕只是一個人的小組，如果你沒有一個系統(tǒng)化的管理軟件蟲的工具，你寫的程序的質量一定高不了。許多程序員覺得自己可以記得自己的軟件蟲。沒門！我從來記不住超過２到３個軟件蟲。而且第二天早上起床后忙著去買這買那，好不容易記住的軟件蟲早忘掉了。你絕對需要一個系統(tǒng)來管住你的那些蟲。

　　軟件蟲管理系統(tǒng)功能有多有少。但最少要管理以下幾種信息：

　　如何重復軟件蟲的詳細步驟
　　正常情況（無蟲）應是怎樣
　　現在情況（有蟲）又是怎樣
　　誰來負責殺蟲
　　問題有沒有解決
　　如果你覺得用軟件蟲管理系統(tǒng)太麻煩，可以簡化一下，建立一個有以上5列的表來用就行了。

　　5. 你們在寫新程序之前總是把現有程序里已知的蟲解決嗎？
　　微軟Windows Word的第一版的開發(fā)項目曾被認為是“死亡之旅”項目。好象永遠也做不完，永遠超時。所有人瘋狂地工作，可怎么也完成不了任務。整個項目一拖再拖，大家都覺得壓力大得受不了。最后終于做完了這個鬼項目，微軟把全組送到墨西哥的Cancun去度假，讓大家坐下來好好想想。

　　大家意識到由于項目經理過于強求程序員們按時交活，結果大家只能匆匆地趕活，寫出的程序毛病百出。由于項目經理的開發(fā)計劃并沒有考慮殺蟲的時間，大家只能把殺蟲的任務往后推，結果蟲越積越多。有一個程序員負責寫計算字體高度的程序，為了圖快，居然寫一行“return 12;”了事。他指望以后的質檢人員發(fā)現這段程序有毛病后報告他再改正。項目經理的開發(fā)計劃事實上已變成一個列寫程序功能的清單，而上面列的所謂程序功能遲早都會成為軟件蟲。在項目總結會上，我們稱這種工作方法為“絕對劣質之路”。

　　為了避免再犯這個錯誤，微軟制定了“零缺陷策略”。許多程序員嘲笑這個策略，覺得經理們似乎在指望靠行政命令來提高產品質量。而事實上“零缺陷策略”的真正含義是：在任何時候，都要把解決現有程序里的問題作為首要問題來抓，然后再去寫新程序。

　　為什么要這樣做呢？

　　一般說來，你越不及時地殺蟲，殺蟲的代價（時間和金錢）就會越高。比如，你寫程序時打錯了一個字，編譯器馬上告訴你，你很容易就把它改正。你剛寫好的程序在第一次運行時發(fā)現了一個問題，你也很快就能解決它，因為你對你剛寫的程序還記憶猶新。如果你運行你的程序時發(fā)現了一個問題，可這個程序是幾天以前寫的，你可能就需要折騰一會兒，還好，你還大致記得，所以不會花太長時間。但如果你在你幾個月以前寫的程序里發(fā)現了問題，就比較難解決了，因為你已經忘了許多細節(jié)。這時候，你還沒準兒正忙著殺別人程序里的蟲吶，因為這家伙到加勒比海阿魯巴島度假去了。這時候，解決這一堆問題的難度不亞于從事尖端科學研究。你一定得小心翼翼地，非常系統(tǒng)化地從事，而且你很難知道多長時間你才能把問題解決。還有更糟糕的，你的程序已交到用戶手里了，才發(fā)現問題，那你就等著掏腰包吧。

總結起來，就一條：越早解決問題，越容易解決。

　　另外還有一個原因，剛寫的程序里發(fā)現問題，你能夠比較容易地估算解決它的時間。舉個例子，如果我問你寫一段程序去把一個列表排序需要花多長時間，你可以給我一個比較確切的估計。如果你的程序，在Internet Explorer 5.5安裝以后，工作不正常。我問你要多長時間把這個問題解決，你恐怕都估計不出來，因為你根本就不知道是什么原因造成了這個問題。你可能要花三天時間才能解決，也有可能只花兩分鐘。

　　這個例子告訴我們，如果你的開發(fā)過程中有許多蟲沒有及時解決，那你的開發(fā)計劃肯定不可靠。反過來，如果你們已經把已知的蟲全部解決了，要做的事只是寫新的程序，那你的開發(fā)計劃就會比較準確。

　　把已知的蟲全部解決，這樣做還有一個好處：你可以對競爭對手快速反擊。有些人把這叫著“讓開發(fā)中的產品隨時處在可以交給用戶的狀態(tài)”。如果你的競爭對手推出一個新的功能想把你的客戶搶走，你可以馬上在你的產品里加上這個功能，立刻將新產品交付用戶，因為你沒有一大堆積累下來的問題要解決。

　　6. 你們的產品開發(fā)日程安排是否反映最新的開發(fā)進展情況？
　　為什么我們需要開發(fā)日程安排？如果你的程序對公司的業(yè)務很重要，那公司就必須知道你的程序何時能寫完。滿世界的程序員都有一個通病，那就是他們都搞不清自己何時才能寫完要寫的程序。他們都只會對管理人員嚷嚷：“等我做好了就做好了！”

　　不幸的是，程序寫完了，事遠遠沒完。作為一個公司，在發(fā)行產品之前，還有許許多多的事情要做：何時做產品演示？何時參加展覽會？何時發(fā)廣告？等等。所有的這一且都依賴于產品的開發(fā)日程安排。

　　定下產品開發(fā)日程安排，還有一個很關鍵的好處：它逼著你只做叫你做的功能，甩掉那些可要可不要的功能，否則這些可要可不要的東西有可能把你纏住。請看featuritis 。

　　定下產品開發(fā)日程安排，按照它開發(fā)，這并不難做，請看我的另一篇文章 Painless Software Schedules ，這篇文章告訴你一種制訂產品開發(fā)日程的好方法。

　　7. 你們有沒有軟件開發(fā)的詳細說明書？
　　寫軟件開發(fā)的詳細說明書就像是繡花：人人皆知是好東西，可沒誰愿意去做。

　　我不知道這是為什么，也許是因為多數程序員天生就不喜歡寫文章。其結果是，一個開發(fā)組里的程序員們，寧可用程序來溝通，也不愿寫文章來表達自己。他們喜歡上來就寫程序，而不是寫什么詳細說明書。

　　在產品的前期設計過程中，如果你發(fā)現了一些問題，你可以輕易地在說明書里該幾行字就行了。一旦進入了寫程序的階段，解決問題的代價就要高得多了，不僅僅是時間上的代價，而且也有感情上的代價，因為沒人愿意將自己做成的東西扔掉。所以這時候解決問題總有一些阻力。

　　沒有產品開發(fā)詳細說明書就開始寫程序，往往會導致程序寫的亂七八糟，而且左拖右拖不能交付使用。我覺得這就是Netscape遇到的問題。前四個版本的程序越寫越亂，以至管理人員作出一個愚蠢的決定：把以前的程序統(tǒng)統(tǒng)扔掉，重新寫。后來他們在開發(fā)Mozilla時又犯了同樣的錯誤。產品越做越亂，完全失控，花了幾年的時間才進入內部測試階段。

　　我最得意的理論是：如果讓程序員們接受一些寫文章的訓練如an intensive course in writing，他們就可能會改變一下不寫說明書的壞習慣，而以上所說的糟糕的例子就有可能少發(fā)生。