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。