你是否聽過SEMA？SEMA是一個晦澀難懂的衡量軟體團隊好壞的系統。等等，你千萬別點這個連結，因為你會發現你理解不了SEMA系統裡面的內容。
因此，我提出了自己的看法，粗略的，不是很精確的，衡量一個軟體開發團隊及其專案好壞的準則。這個準則的最大優點是簡單易懂，且得到的結果真實。相比與SEMA你可以節省很多時間。

下面是12個測試題：
1、原始碼是否有版本控制？
2、專案是否可以一鍵編譯並構件？
3、是否有每日構件？
4、是否有bug庫？
5、開發新功能前所有bug是否已經得到了修正？
6、開發計劃是否一直保持更新？
7、所有功能是否有具體規格？
8、程式設計師是否有安靜的工作環境？
9、是否買了最好的工具（即使花錢也不吝嗇）？
10、是否有測試人員？
11、招聘新員工面試時候是否測試過編碼能力？
12、“走廊可用性測試”？

測試題的簡潔之處在於你只需要回答yes或no即可，而不需要去統計每天的程式碼量，程式碼的缺陷率等繁瑣的指標。當然這個是粗略的，假如你開發一個核反應堆的控制程式，我想這些規則不適用。

我們給每個題目回答為yes為1分，no為0分。
得分12分是完美的，11分是可接受的，其他得分就表明你專案中有比較嚴重的問題了。
現狀是很多軟體開發團隊的得分是2、3分，可想他們的問題有多嚴重。象微軟這種公司，他們一直保持在12分。

當然，這12條準則不能算是聖經，並不能說不沒有得到12分的團隊就一定不能開發出好的產品。但是反過來看，一直保持準訓這12條準則的團隊，一定是一個可以持續戰鬥交付出好的軟體產品的團隊。

1、原始碼是否有版本控制？

2、專案是否可以一鍵編譯並構件？
一鍵編譯並構件的意思是需要花多少步驟多少時間，能從最新的原始碼編譯併發布出可用的產品？在好的團隊裡面，一個指令碼可以完成程式碼check out、編譯每一行程式碼、連結成可執行檔案，即使專案中有不同語言開發的程式碼也是一樣，同時還製作最後的釋出包形勢（如CD-ROM）。
如果需要很多指令碼才可以完成上面的釋出流程（假如執行20個指令碼），那麼在你臨近專案釋出的日子裡，就會倍受煎熬，因為你總是會需要編譯出最新的版本，來驗證修正的bug。執行20個指令碼是很容易出錯的，這就意味著你在版本構件上需要花費很多時間。

3、是否有每日構件？
軟體開發過程中，可能會有一些程式設計師check in的程式碼存在問題，導致編譯構件失敗。今天要出版本，但是他已經下班回家了，沒有其他人能修改。（當然你可以打電話叫他過來公司修正這個問題，但是這會讓他很不爽，當然你也可以不用考慮他的感受）。
因此在大型的專案中，都會採取每日構件的措施（有的更精細化的是每次check in程式碼都會觸發編譯構件），每日構件通常在下午，如中午午飯之前啟動。吃完午飯後編譯完成（專案的編譯構件的時間不能超過30分鐘，否則就有點不可接受），如果沒有錯誤，那麼大家基於新的程式碼繼續開發，否則就找到問題責任人修正，大家基於之前的程式碼繼續開發，不阻塞。
每日構件的文章可以參考 Daily Builds Are Your Friend

4、是否有bug庫？
如果你在開發程式碼，即使是一個團隊，如果沒有bug庫，開發出的程式碼也是低質量的。很多程式設計師認為自己可以記住所有的bug，但是隻是自己認為，並不是每個人都可以。我只能記住2～3個bug，且很容易就忘記了。
bug庫可以簡單也可以複雜，但是必須包含下面的要素：
1）復現問題的詳細步驟；
2）期望的結果；
3）實際的結果（有bug的結果）；
4）bug被分配給誰了；
5）是否已經修正了；
如果你因為複雜的bug跟蹤軟體而不想維護bug庫，你做一個簡單的包含上面5列的excel檔案，即可做到bug庫的效果。
關於更多的bug庫維護，參考 Painless Bug Tracking

5、開發新功能前所有bug是否已經得到了修正？
微軟Word第一個版本的開發專案，被認為是“死亡進行曲”，專案好像一直拖著永遠不會結束。整個團隊成員每天工作的小時數說出來都可笑（沒日沒夜），專案進度延遲，延遲再延遲，壓力是難以想象的大。當專案結束大概一年後，微軟將整個團隊送到一個風景優美的地方度假，靜下來討論一些靈魂深處的問題（當然，我們社會主義只能吃吃瓜子在黑暗的會議室總結一下）。
討論過程中他們意識到專案經理曾經是如此的堅持按照計劃時間點進行，導致程式設計師只顧往前衝，增加新功能，然後就導致程式碼質量極差，因為修正bug的時間不在專案經理的計劃中。他們沒有機會將bug數量降下來，更甚的是，有的程式設計師為了實現計算文字高度，居然直接return 12，當然，bug就過來了。實現的功能越多程式碼越多，這個後來被稱為“無盡缺陷方法”（在敏捷開發中這個也被稱為 帶病迭代）。
為了解決這個問題，微軟後來提出了“零缺陷方法”，很多程式設計師聽到這個後都開心的傻笑起來，因為這個好像是在說決策者已經要求管理者必須把bug消滅掉。實際上，“零缺陷方法”意思是在任何時間，解決bug都要比開發新功能的優先順序高。
我們解釋一下為什麼。通常地，一個bug放置的時間越長，解決它的耗費（包括時間和金錢）越多。舉個例子：

1、如果你程式碼中有一個編譯錯誤，那麼編譯器很快可以給你找出來，你很快可以修正它。
2、如果你在第一次執行程式碼前發現了一個bug，那麼很快就可以修復它，因為這時候你對程式碼還是很熟悉，不怎麼耗費時間。
3、如果有一個bug在你幾天前寫的程式碼中，那麼你需要花費一些時間來定位，你重讀一遍程式碼，還是可以找出問題。
4、如果有一個bug在你幾個月前寫的程式碼中，那麼你就不那麼容易定位出來了。
5、再假設你定位別人程式碼中的問題，這個人可能去度假了，這種情況，定位bug就像推理：必須慢慢地，有條不紊地，仔細地去讀程式碼去推斷邏輯，並且你不能確定多長時間可以修正它。

立刻修正bug的第一個理由是節省時間。
第二個理由是估計新開發程式碼的時間比修正bug的時間要準確（簡單說是可以是計劃更準確）。這個意思是說，加入你有一個bug列表需要修正，要計劃這些bug完成的時間，幾乎是不可能的。假設所有的bug都已經修正了，只需要開發一個新功能列表，那計劃就會精確很多。
“零缺陷方法”的另外一個好處是你可以比競爭對手響應更快，因為你隨時可以釋出版本。

6、開發計劃是否一直保持更新？
如果你的程式碼對客戶來說非常重要，客戶有很多原因要求知道你寫的程式碼什麼時候可以交付，所以計劃是重要的。程式設計師對計劃的反感是眾所周知的：我的程式碼在該完成的時候就會完成。他們總是這麼對客戶咆哮。

不幸的是，這並不能消滅計劃。太多的商業計劃需要月選計劃好什麼時候交付demo，什麼時候展示，什麼時候做宣傳，等等。支撐商業計劃的只有做開發計劃，並時刻保持更新。
計劃的另外一個好處是逼迫你哪些特性優先開發，哪些無價值的特性可以不交付或延遲交付。
做計劃並不難，可以參考 Painless Software Schedules

7、所有功能是否有具體規格？
編寫規格說明書就像用牙線清潔牙齒，每個人都知道需要這麼做，但是就是沒有人願意做。我不知道根因，我猜是大部分程式設計師都討厭寫文件。結果就是，當團隊成員全部是為了解決某些問題的程式設計師時，他們更願意用程式碼表達他們的解決方法，而不是文件。
這設計階段，如果你發現方案存在問題，則通過改幾行文字就可以解決。當方案轉化為了程式碼，修正問題的成本就急劇上升，無論從情感上還是時間上，程式設計師都不願意把自己程式碼刪除了重寫的，因此他們會產生抵觸情緒，就是不解決這個問題。

在Netscape就有上面說的問題，當他們的前4個版本很混亂問題很多的時候，愚蠢的管理者決策將現在的程式碼廢棄而重新開發（想必這個大家都知道）。

我的解決這個問題的理論是：給程式設計師們上一堂“寫作的精讀課程”。
另外一個解決方法是聘請一個管理者，他自己能夠寫規格書。
兩種方法都需要你在團隊中明確：沒有清楚規格不能寫程式碼。

8、程式設計師是否有安靜的工作環境？
給程式設計師一個有自己空間的，安靜的，能保護隱私的工作環境，他們的產出能夠大幅度的提高。這個對其他職業如作家科學家也同樣適用。
經典的軟體書籍“人件”中很詳細地闡明瞭這一點。

9、是否買了最好的工具（即使花錢也不吝嗇）？
使用編譯語言（如Java，C）開發專案是唯一一個不能在自家花園完成開發的工作，如果編寫的程式碼編譯需要花費很多秒，那麼買一臺最新的，效能強勁的電腦會節省你很多時間。
如果編譯時長超過15秒，那麼程式設計師將會變的煩躁，然後去做其他事情（比如讀其他文章），那麼效率就會變得異常低下。
除錯GUI程式碼，如果你只有一個顯示器那會非常痛苦，多買一個顯示器如果可以的話。

10、是否有測試人員？
如果專案中沒有專職的測試人員（每3個程式設計師需要一個測試人員），那麼你會交付出佈滿bug的產品，或者浪費程式設計師的時間去做測試。
可以參考Top Five (Wrong) Reasons You Don’t Have Testers

11、招聘新員工面試時候是否測試過編碼能力？
招聘新員工到專案中來，一定要在面試時候讓其寫一段程式碼，就像你婚禮中請的廚師一樣，一定要先品嚐一下他做的菜如何。
只是理論上的測試有時候會遺漏很多知識面沒有觀察到，畢竟軟體開發是一項工程，動手的活，不是純理論的。

12、是否有做過“走廊可用性測試”？
“走廊可用性測試”，這個名稱的意思是：將你的產品放在走廊中，遇到路過的人，喊其停住，邀請他來使用你的軟體。這樣測試過後，你就很快能夠發現你程式碼中易用性的問題了。