寫好軟件的75條 
 
1. 你們的項目組使用源代碼管理工具了么？
應該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的選擇是VSS。

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. 你們的程序員工作在安靜的環境里么？
需要安靜環境。這點極端重要，而且要保證每個人的空間大于一定面積。

7. 你們的員工每個人都有一部電話么？
需要每人一部電話。而且電話最好是帶留言功能的。當然，上這么一套帶留言電話系統開銷不小。不過至少每人一部電話要有，千萬別搞得經常有人站起來喊：“某某某電話”。《人件》里面就強烈譴責這種做法。

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，而不是自己從頭操作字符串，等等等等。這就是“軟件復用”的體現。

35. 你們會隔一段時間就停下來夯實代碼么？
要。最好一個月左右一次。傳言去年年初Windows組在Stevb的命令下停過一個月增強安全。Btw，“夯”這個字念“hang”，第一聲。

36. 你們的項目組每個人都寫Daily Report么？
要寫。五分鐘就夠了，寫10句話左右，告訴自己小組的人今天我干了什么。一則為了溝通，二則鞭策自己（要是游手好閑一天，自己都會不好意思寫的）。

37. 你們的項目經理會發出Weekly Report么？
要。也是為了溝通。內容包括目前進度，可能的風險，質量狀況，各種工作的進展等。

38. 你們項目組是否至少每周全體開會一次？