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