“Joel 衡量法則”好就好在你只需照著逐條回答以上問題，然后把所答為“是”的問題算成一分，再加起來就可以了，而不需要去算什么每天寫的程序行數(shù)或程序蟲的平均數(shù)等等。但咱丑話說在前面，可別用“Joel 衡量法則”去推算你的核電站管理程序是否可靠。
如果你們得了１２分，那是最好，得了１１分還過得去，但如果只得了１０分或低于１０分，你們可能就有很嚴重的問題了。嚴酷的現(xiàn)實是：大多數(shù)的軟件開發(fā)公司只能得到２到３分。這些公司如果得不到急救可就玄了，因為像微軟這樣的公司從來就沒有低過１２分。
當然，一個公司成功與否不僅僅只取決于以上標準。比如，讓一個管理絕佳的軟件公司去開發(fā)一個沒有人要的軟件，那開發(fā)出來的軟件也只能是沒有人要。或反過來，一幫軟件痞子以上標準一條也達不到，沒準照樣也能搞出一個改變世界的偉大軟件。但我告訴你，如果不考慮別的因素，你只要能達到以上１２條準則，你的團隊就是一個可以準時交活的紀律嚴明的好團隊。
1. 你們用不用源文件管理系統(tǒng)？
我用過商業(yè)化的源文件管理系統(tǒng)，我也用過免費的系統(tǒng)，比如CVS，告訴你吧，CVS挺好用。但如果你根本就沒有用源文件管理系統(tǒng)，那你就是累死了也沒法讓你的程序員出活：他們沒法知道別人在改動什么源文件，寫錯了的源文件也沒法恢復。
使用源文件管理系統(tǒng)還有一大好處是，由于每一位程序員都把源文件從源文件管理系統(tǒng)里提出來放到自己的硬盤里，幾乎不會發(fā)生丟失源文件的事，最起碼我還沒聽說過。
2. 你們可以把整個系統(tǒng)從源碼到ＣＤ映像文件一步建成嗎？
這句話問的問題是：從你們最新的源碼開始到建立起能夠交出去的最后文件，你們有多少步驟要做？ 一個好的團隊應該有一個批處理程序一步便可將所有的工作做完，像把源文件提取出來，跟據(jù)不同的語言版本要求（英文版，中文版），和各種編譯開關（#ifdef）進行編譯，聯(lián)接成可執(zhí)行文件，標上版本號，打包成ＣＤ映像文件或直接送到網(wǎng)站上去，等等等等。
如果這些步驟不是一步做完，就有可能出人為差錯。而且當你很接近產品開發(fā)尾聲的時侯，你可能很急于把最后幾個蟲解決，然后盡快地交活。如果這時候你需要做２０步才能把最終文件制出來，你肯定會急得要命，然后犯一些很不該犯的錯誤。
正因為這個原因，我工作的前一個公司從用WISE改用InstallShield：我們必需要讓我們的批處理程序完全自動化地，在夜里，被NT scheduler起動把最終文件制成，WISE不能被NT scheduler啟動而InstallShield可以，我們只能把WISE扔掉。（WISE的那幫家伙向我保證他們的下一代產品一定支持在夜里自動運行.)
3. 你們每天白天都把從系統(tǒng)源碼到ＣＤ映像做一遍嗎？
你們有沒有遇到過這樣的事情：一個程序員不小心把有毛病的源碼放進源文件管理系統(tǒng)，結果造成最終文件沒法制成。比如，他建立了一個新源文件但忘了把它放進源文件管理系統(tǒng)，然后他高高興興鎖機回家了，因為在他的機器上整個編譯得很好。可是別人卻因為這沒法工作下去了，也只好悶悶地回家了。
這種造成最終文件沒法制成的情況很糟糕，但卻很常見。如果每天在白天就把最終文件制一遍的話，就可以讓這種事不造成太大危害。在一個大的團隊里，要想保證有毛病的源碼及時得到糾正，最好每天下午（比如午餐時）制一下最終文件。午餐前，每個人都盡可能地把改動的源文件放到源文件管理系統(tǒng)里，午餐后，大家回來，如果最終文件已經(jīng)制成了，好！這時大家再從源文件管理系統(tǒng)里取出最新的源文件接著干活。如果最終文件制作出錯，出錯者馬上修正，而別人還可接著用原有的沒問題的源程序干活。
在我以前曾干過的微軟Excel開發(fā)組里，我們有一條規(guī)定：誰造成最終文件制作出錯，誰就得被罰去負責監(jiān)視以后的最終文件制作過程，直到下一位造成最終文件制作出錯的人來接任他。這樣做不僅可以督促大家少造成最終文件制作出錯，而且可以讓每個人都有機會去了解最終文件制作過程。
如果想更多了解這個話題，可以讀我的另一篇文章 Daily Builds are Your Friend.
4. 你們有軟件蟲管理系統(tǒng)嗎？
不論你有任何借口，只要你寫程序，哪怕只是一個人的小組，如果你沒有一個系統(tǒng)化的管理軟件蟲的工具，你寫的程序的質量一定高不了。許多程序員覺得自己可以記得自己的軟件蟲。沒門！我從來記不住超過２到３個軟件蟲。而且第二天早上起床后忙著去買這買那，好不容易記住的軟件蟲早忘掉了。你絕對需要一個系統(tǒng)來管住你的那些蟲。
軟件蟲管理系統(tǒng)功能有多有少。但最少要管理以下幾種信息：
- 如何重復軟件蟲的詳細步驟
- 正常情況（無蟲）應是怎樣
- 現(xiàn)在情況（有蟲）又是怎樣
- 誰來負責殺蟲
- 問題有沒有解決
如果你覺得用軟件蟲管理系統(tǒng)太麻煩，可以簡化一下，建立一個有以上５列的表來用就行了。
如果想更多了解這個話題，可以讀我的另一篇文章Painless Bug Tracking.
5. 你們在寫新程序之前總是把現(xiàn)有程序里已知的蟲解決嗎？
微軟Windows Word的第一版的開發(fā)項目曾被認為是“死亡之旅”項目。好象永遠也做不完，永遠超時。所有人瘋狂地工作，可怎么也完成不了任務。整個項目一拖再拖，大家都覺得壓力大得受不了。最后終于做完了這個鬼項目，微軟把全組送到墨西哥的Cancun去度假，讓大家坐下來好好想想。
大家意識到由于項目經(jīng)理過于強求程序員們按時交活，結果大家只能匆匆地趕活，寫出的程序毛病百出。由于項目經(jīng)理的開發(fā)計劃并沒有考慮殺蟲的時間，大家只能把殺蟲的任務往后推，結果蟲越積越多。有一個程序員負責寫計算字體高度的程序，為了圖快，居然寫一行“return 12;”了事。他指望以后的質檢人員發(fā)現(xiàn)這段程序有毛病后報告他再改正。項目經(jīng)理的開發(fā)計劃事實上已變成一個列寫程序功能的清單，而上面列的所謂程序功能遲早都會成為軟件蟲。在項目總結會上，我們稱這種工作方法為“絕對劣質之路”。
為了避免再犯這個錯誤，微軟制定了“零缺陷策略”。許多程序員嘲笑這個策略，覺得經(jīng)理們似乎在指望靠行政命令來提高產品質量。而事實上“零缺陷策略”的真正含義是：在任何時候，都要把解決現(xiàn)有程序里的問題作為首要問題來抓，然后再去寫新程序。
為什么要這樣做呢？
一般說來，你越不及時地殺蟲，殺蟲的代價（時間和金錢）就會越高。比如，你寫程序時打錯了一個字，編譯器馬上告訴你，你很容易就把它改正。你剛寫好的程序在第一次運行時發(fā)現(xiàn)了一個問題，你也很快就能解決它，因為你對你剛寫的程序還記憶猶新。如果你運行你的程序時發(fā)現(xiàn)了一個問題，可這個程序是幾天以前寫的，你可能就需要折騰一會兒，還好，你還大致記得，所以不會花太長時間。但如果你在你幾個月以前寫的程序里發(fā)現(xiàn)了問題，就比較難解決了，因為你已經(jīng)忘了許多細節(jié)。這時候，你還沒準兒正忙著殺別人程序里的蟲吶，因為這家伙到加勒比海阿魯巴島度假去了。這時候，解決這一堆問題的難度不亞于從事尖端科學研究。你一定得小心翼翼地，非常系統(tǒng)化地從事，而且你很難知道多長時間你才能把問題解決。還有更糟糕的，你的程序已交到用戶手里了，才發(fā)現(xiàn)問題，那你就等著套腰包吧。
總結起來，就一條：越早解決問題，越容易解決。
另外還有一個原因，剛寫的程序里發(fā)現(xiàn)問題，你能夠比較容易地估算解決它的時間。舉個例子，如果我問你寫一段程序去把一個列表排序需要花多長時間，你可以給我一個比較確切的估計。如果你的程序，在Internet Explorer 5.5安裝以后，工作不正常。我問你要多長時間把這個問題解決，你恐怕都估計不出來，因為你根本就不知道是什么原因造成了這個問題。你可能要花三天時間才能解決，也有可能只花兩分鐘。
這個例子告訴我們，如果你的開發(fā)過程中有許多蟲沒有及時解決，那你的開發(fā)計劃肯定不可靠。反過來，如果你們已經(jīng)把已知的蟲全部解決了，要做的事只是寫新的程序，那你的開發(fā)計劃就會比較準確。
把已知的蟲全部解決，這樣做還有一個好處：你可以對競爭對手快速反擊。有些人把這叫著“讓開發(fā)中的產品隨時處在可以交給用戶的狀態(tài)”。如果你的競爭對手推出一個新的功能想把你的客戶搶走，你可以馬上在你的產品里加上這個功能，立刻將新產品交付用戶，因為你沒有一大堆積累下來的問題要解決。
6. 你們的產品開發(fā)日程安排是否反映最新的開發(fā)進展情況？
為什么我們需要開發(fā)日程安排？如果你的程序對公司的業(yè)務很重要，那公司就必須知道你的程序何時能寫完。滿世界的程序員都有一個通病，那就是他們都搞不清自己何時才能寫完要寫的程序。他們都只會對管理人員嚷嚷：“等我做好了就做好了！”
不幸的是，程序寫完了，事遠遠沒完。作為一個公司，在發(fā)行產品之前，還有許許多多的事情要做：何時做產品演示？何時參加展覽會？何時發(fā)廣告？等等。所有的這一且都依賴于產品的開發(fā)日程安排。
定下產品開發(fā)日程安排，還有一個很關鍵的好處：它逼著你只做叫你做的功能，甩掉那些可要可不要的功能，否則這些可要可不要的東西有可能把你纏住。請看featuritis 。
定下產品開發(fā)日程安排，按照它開發(fā)，這并不難做，請看我的另一篇文章 Painless Software Schedules ，這篇文章告訴你一種制訂產品開發(fā)日程的好方法。
7. 你們有沒有軟件開發(fā)的詳細說明書？
寫軟件開發(fā)的詳細說明書就像是繡花：人人皆知是好東西，可沒誰愿意去做。
我不知道這是為什么，也許是因為多數(shù)程序員天生就不喜歡寫文章。其結果是，一個開發(fā)組里的程序員們，寧可用程序來溝通，也不愿寫文章來表達自己。他們喜歡上來就寫程序，而不是寫什么詳細說明書。
在產品的前期設計過程中，如果你發(fā)現(xiàn)了一些問題，你可以輕易地在說明書里該幾行字就行了。一旦進入了寫程序的階段，解決問題的代價就要高得多了，不僅僅是時間上的代價，而且也有感情上的代價，因為沒人愿意將自己做成的東西扔掉。所以這時候解決問題總有一些阻力。
沒有產品開發(fā)詳細說明書就開始寫程序，往往會導致程序寫的亂七八糟，而且左拖右拖不能交付使用。我覺得這就是Netscape遇到的問題。前四個版本的程序越寫越亂，以至管理人員作出一個愚蠢的決定：把以前的程序統(tǒng)統(tǒng)扔掉，重新寫。后來他們在開發(fā)Mozilla時又犯了同樣的錯誤。產品越做越亂，完全失控，花了幾年的時間才進入內部測試階段。
我最得意的理論是：如果讓程序員們接受一些寫文章的訓練如an intensive course in writing，他們就可能會改變一下不寫說明書的壞習慣，而以上所說的糟糕的例子就有可能少發(fā)生。
另一個解決問題的辦法是：雇一些能干的項目主任，專職寫產品開發(fā)詳細說明書。
不論采用以上哪種方法，道理只有一個：在沒有產品開發(fā)詳細說明書之前，決不可寫程序。
如果想更多了解這個話題，可以讀我的四篇文章。
8. 你們的程序員是否工作在安靜的環(huán)境里？
當你讓你的智囊們工作在安靜，寬敞，不受人打擾的環(huán)境里，他們往往能更快地出活，這已是不爭的事實。有一本經(jīng)典的講軟件開發(fā)管理的書Peopleware 把這個問題闡述得很清楚。
問題在于，我們都知道最好不要打斷這些智囊們的思路，讓他們一直處于他們的最佳狀態(tài)中，這樣他們就能全神貫注，廢寢忘食地工作，充分發(fā)揮他們的作用。作家，程序員，科學家，甚至籃球運動員都有他們的最佳狀態(tài)。
問題還在于，進入這個最佳狀態(tài)不容易。我覺得平均起來，需要１５分鐘才能進入最佳狀態(tài)，達到最高工作效率。有時侯，當你疲勞了或已經(jīng)高效率地干了許多工作了，你就很難再進入這個狀態(tài)，只好干點雜事打發(fā)時間，或上網(wǎng)，玩游戲等。
問題更在于，你很容易就被各種各樣的事打擾，被拽出你的最佳狀態(tài)：噪音啦，電話啦，吃午飯啦，喝杯咖啡啦，被同事打擾啦，等等。如果一個同事問你一個問題，只花你一分鐘，可你卻被拽出你的最佳工作狀態(tài)，重新回到這個狀態(tài)需要花半小時。你的工作效率因此而受到很大影響。如果讓你在一個嘈雜的大房間里工作（那幫搞網(wǎng)站的家伙還就喜歡這樣），邊上的推銷員在電話里大叫大嚷，你就很難出活，因為你進入不了你的最佳工作狀態(tài)。
作為程序員，進入最佳工作狀態(tài)更難。你先要把方方面面的細節(jié)裝在腦子里， 任何一種干擾都可能讓你忘掉其中某些東西。你重新回來工作時，發(fā)現(xiàn)好些東西記不起來了（如你剛用的局部變量名，或你剛才的搜索程序寫到哪里了等）你只好看看剛寫的程序，回憶一下，慢慢地回到你剛才的最佳工作狀態(tài)。
我們來做一個簡單的算數(shù)。假設一個程序員被打擾一下，哪怕只有一分鐘，他卻需要花１５分鐘才能回到最佳工作狀態(tài)（統(tǒng)計資料顯示如此）。我們有兩個程序員：杰夫和愚夫， 坐在一個大辦公區(qū)里工作。愚夫想不起來用什么函數(shù)去進行Unicode 字符串復制。他可以花３０秒查一下，或者花１５秒問杰夫。由于他坐在杰夫的旁邊，他就選擇去問杰夫。杰夫被打擾了一下，耽誤了他１５分鐘，節(jié)省了愚夫１５秒鐘。
現(xiàn)在，我們把他們倆用墻和門隔開，讓他們倆分坐在不同的辦公室里，愚夫又想不起來什么涵數(shù)名，自己查一下要花３０秒；問杰夫，要花４５秒，因為他要站起來走過去問（對這幫程序員來說，這可不是件簡單的事，看看他們的體質就知道為什么了）。所以他選擇自己去查。愚夫損失了３０秒鐘，可是杰夫少損失了１５分鐘。哈哈！
9. 你們是否使用現(xiàn)有市場上能買到的最好的工具？
用可編譯語言寫程序恐怕是這世界上為數(shù)不多的還不能隨便抓一個破計算機就可以做的事。如果你用于編譯的時間超過幾秒鐘，你就應該換一臺最新最快的計算機了。因為如果編譯時間超過１５秒，程序員們就會不耐煩，轉而去上網(wǎng)看一些無關的東西比如The Onion，弄不好一看就是好幾個小時。
調試圖形界面軟件時，用只有一個顯示器的計算機不僅不方便，有時甚至是不可能。用有兩個顯示器的計算機，要方便許多。
程序員們經(jīng)常不可避免地要去畫一些圖標或工具欄圖。多數(shù)程序員沒有一個好的圖形編輯器可用。用微軟的“畫筆”軟件去畫圖標簡直是笑話，可事實上大家還就在這樣做。
在我的前一個工作，系統(tǒng)管理員成天給我發(fā)來自動警告，說我在服務器上使用了超過２２０兆的空間。我告訴他，按現(xiàn)在硬盤的價錢，超出這點空間的價錢遠低于我用的廁紙的價錢。讓我花１０分鐘去清理我的文件絕對是我工作效率的莫大浪費。
一流的開發(fā)組絕不折騰它的程序員。工具落后會讓人用起來覺得難受，一點點積累起來，會讓程序員們成天叫苦，而一個成天叫苦的程序員絕對不會是一個高消率的程序員。
再添一句，要想使你的程序員高興，最好的辦法就是給他們買一些最新最棒的工具軟件。用這種方法可以讓他們乖乖地為你工作，這可比用高薪吸引他們來得便宜得多。
10. 你們有沒有專職的軟件測試人員？
如果你的開發(fā)組里沒有專職的測試人員，或沒有足夠的測試人員（兩到三個程序員就應該配一個測試員），那你的產品就一定是毛病百出，或者你在花１００美元一小時的代價去雇你的程序員去做３０美元一小時就可以雇到的測試員的工作。想在測試員身上省錢，絕對是打錯了算盤。我真不明白為什么這么多人算不過來這筆帳。
我有另一篇文章專門講這個，請看Top Five (Wrong) Reasons You Don't Have Testers。
11. 你們招人面試時是否讓寫一段程序？
我問你，讓你去招一個魔術師，你是否連看都不看一眼他的魔術玩得怎樣就要他？當然不會！
你舉辦婚宴，要請一個廚師，你是不是連嚐也不嚐他做的菜好吃不好吃就要他？我想也不會。
奇怪的是，幾乎每天都有這樣的事發(fā)生：在面試一個程序員時，簡歷寫得漂亮，談得熱火朝天，問幾個簡單的問題（如CreateDialog()和DialogBox()有什么區(qū)別？這種問題，查一下幫助文件就知道了），人就招進來了。你真正應該關心的不是這人記不記得這些寫程序的邊邊角角的東西，而是他能否出產品！更糟糕的是，許多問題是知道就知道，不知道，想死也不知道的問題。
不能這樣下去了！在面試時，請一定要讓寫一段程序。在我的這篇文章里Guerrilla Guide to Interviewing，我有許多好建議。
12. 你們是否隨便抓一些人來試用你們的軟件？
這句話的意思是，讓你從走道里走過的人中，隨便抓幾個人來，讓他們試用你的軟件。如果你抓五個人來用你的軟件，那你就可能把你的程序中９５％的不方便使用的地方找出來。
要想讓用戶去買你的軟件，你必須要設計好你的用戶界面。這其實并不難。你可以讀我的free online book on UI design打打基礎。
用戶界面設計的關鍵是，如果你讓幾個人去用你的軟件（五六人可能就夠了），你可能很快就找出最大的問題。想知道為什么嗎，請讀Jakob Nielsen's article。只要你堅持隨便抓一些人來試用你的軟件，你就能將你的用戶界面設計得越來越好。
The Joel Test 軟件開發(fā)成功12法則的四個實用領域
- 用該法則來衡量你的軟件開發(fā)組，告訴我你得的分數(shù)，讓我來品頭論足。
- 如果你是開發(fā)組的經(jīng)理，用該法則來使你的組提高效率。如果你們一上來就能得１２分，你就 別再打擾你的程序員了， 專心致志別讓公司的管理人員來煩你的程序員吧。
- 如果你在找一份程序員工作，問問你未來的老板他能得幾分，如果分數(shù)很低，你一定要確信你進去后有足夠的權力來改變這一切，否則，最好躲遠點，不然，你在那兒會很難受的。
- 如果你是投資者，正在決定是否向一個軟件公司投資，或者你的軟件公司正在決定是否兼并另一個軟件公司，該法則可以幫你做決定。