1. 你們的專案組使用源**管理工具了麼？
應該用。vss、cvs、pvcs、clearcase、ccc/harvest、firefly都可以。我的選擇是cvs。
2. 你們的專案組使用缺陷管理系統了麼？
應該用。clearquest太複雜，我的推薦是bugzilla。
3. 你們的測試組還在用word寫測試用例麼？
不要用word寫測試用例（test case）。應該用乙個專門的系統，可以是test manager，也可以是自己開發乙個asp.net的小**。主要目的是track和browse。
4. 你們的專案組有沒有建立乙個門戶**？
要有乙個門戶**，用來放contact info、baselined schedule、news等等。推薦sharepoint portal server 2003來實現，15分鐘就搞定。買不起sps 2003可以用wss (windows sharepoint service)。
5. 你們的專案組用了你能買到最好的工具麼？
應該用盡量好的工具來工作。比如，應該用vs.net而不是notepad來寫c#。用notepad寫程式多半只是一種炫耀。但也要考慮到經費，所以說是「你能買到最好的」。
6. 你們的程式設計師工作在安靜的環境裡麼？
需要安靜環境。這點極端重要，而且要保證每個人的空間大於一定面積。
8. 你們每個人都知道出了問題應該找誰麼？
應該知道。任何乙個feature至少都應該有乙個owner，當然，owner可以繼續dispatch給其他人。
9. 你遇到過有人說「我以為…」麼？
要消滅「我以為」。never assume anything。
10. 你們的專案組中所有的人都坐在一起麼？
需要。我反對virtual team，也反對dev在美國、test在中國這種開發方式。能坐在一起就最好坐在一起，好處多得不得了。
11. 你們的進度表是否反映最新開發進展情況？
應該反映。但是，應該用baseline的方法來管理進度表：維護乙份穩定的schedule，再維護乙份最新更改。baseline的方法也應該用於其它的spec。baseline是變更管理裡面的乙個重要手段。
12. 你們的工作量是先由每個人自己估算的麼？
應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務工期固定等。
13. 你們的開發人員從專案一開始就加班麼？
不要這樣。不要一開始就搞疲勞戰。從專案一開始就加班，只能說明專案進度不合理。當然，一些對日軟體外包必須天天加班，那屬於剝削的範疇。
14. 你們的專案計畫中buffer time是加在每個小任務後面的麼？
不要。buffer time加在每個小任務後面，很容易輕易的就被消耗掉。buffer time要整段的加在乙個milestone或者checkpoint前面。
15. 值得再多花一些時間，從95%做到100%好值得，非常值得。
尤其當專案後期人困馬乏的時候，要堅持。這會給產品帶來質的區別。
16. 登記新缺陷時，是否寫清了重現步驟？
要。這屬於dev和test之間的溝通手段。面對面溝通需要，詳細填寫repro steps也需要。
17. 寫新**前會把已知缺陷解決麼？
要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新**。
18. 你們對缺陷的輕重緩急有事先的約定麼？
必須有定義。severity要分1、2、3，約定好：藍屏和data lost算sev 1，function error算sev 2，介面上的算sev 3。但這種約定可以根據產品質量現狀適當進行調整。
19. 你們對意見不一的缺陷有三國會議麼？
必須要有。要有乙個明確的決策過程。這類似於ccb (change control board)的概念。
20. 所有的缺陷都是由登記的人最後關閉的麼？
bug應該由opener關閉。dev不能私自關閉bug。
21. 你們的程式設計師厭惡修改老的**麼？
厭惡是正常的。解決方法是組織code review，單獨留出時間來。xp也是乙個方法。
22. 你們專案組有team morale activity麼？
每個月都要搞一次，吃飯、唱歌、outing、打球、開卡丁車等等，一定要有。不要省這些錢。
23. 你們專案組有自己的logo麼？
要有自己的logo。至少應該有自己的codename。
24. 你們的員工有印有公司logo的t-shirt麼？
要有。能增強歸屬感。當然，t-shirt要做的好看一些，最好用80支的棉來做。別沒穿幾次就破破爛爛的。
25. 總經理至少每月參加次專案組會議要的。
要讓team member覺得高層關注這個專案。
26. 你們是給每個dev開乙個分支麼？
反對。branch的管理以及merge的工作量太大，而且容易出錯。
27. 有人長期不check-in**麼？
不可以。對大部分專案來說，最多兩三天就應該check-in。
28. 在check-in**時都填寫注釋了麼？
要寫的，至少一兩句話，比如「解決了bug no.225」。如果往高處拔，這也算做「配置審計」的一部分。
29. 有沒有設定每天check-in的最後期限？
要的，要明確check-in deadline。否則會build break。
30. 你們能把所有原始碼一下子編譯成安裝檔案嗎？
要的。這是每日編譯（daily build）的基礎。而且必須要能夠做成自動的。
31. 你們的專案組做每日編譯麼？
當然要做。有三樣東西是軟體專案/產品開發必備的：1. bug management; 2. source control; 3. daily build。
32. 你們公司有沒有積累乙個專案風險列表？
要。risk inventory。否則，下個專案開始的時候，又只能拍腦袋分析risk了。
33. 設計越簡單越好越簡單越好。
設計時候多一句話，將來可能就帶來無窮無盡的煩惱。應該從一開始就勇敢的砍。這叫scope management。
34. 盡量利用現有的產品、技術、**千萬別什麼東西都自己coding。biztalk和sharepoint就是最好的例子，有這兩個作為基礎，可以把起點 提高很多。或者可以盡量多用現成的control之類的。或者盡量用xml，而不是自己去parse乙個文字檔案；盡量用regexp，而不是自己從頭操 作字串，等等等等。這就是「軟體復用」的體現。
防止專案延遲的18條軍規
防止專案延遲的18條軍規 1 詳盡的需求分析 2 當面臨專案開始時的問題時，您需要正視並處理這些困難和有爭議的問題而不應該逃避 3 選擇正確的技術 正確的技術能夠使您有最大的機會在現有的人力條件下以最短時間按質量要求完成工作，選擇乙個搶眼的新技術並沒有什麼好處，尤其當您不能保證它是否有好處或者找不到...
防止專案延遲的18條軍規
1 詳盡的需求分析 2 當面臨專案開始時的問題時，您需要正視並處理這些困難和有爭議的問題而不應該 逃避 3 選擇正確的技術 正確的技術能夠使您有最大的機會在現有的人力條件下以最短時間按質量要求完成工作，選擇乙個搶眼的新技術並沒有什麼好處，尤其當您不能保證它是否有好處或者找 不到正確應用新技術的人的時...
防止IT專案延遲的18條軍規
1 詳盡的需求分析 2 當面臨專案開始時的問題時，您需要正視並處理這些困難和有爭議的問題而不應該逃避 3 選擇正確的技術。正確的技術能夠使您有最大的機會在現有的人力 條件下以最短時間按質量要求完成工作，選擇乙個搶眼的新技術並沒有什麼好處，尤其當您不能保證它是否有好處或者找不到正確應用新技術的人的時候...