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. 你們會隔一段時間就停下來夯實代碼麼?
要。最後一個月左右一次。增強代碼安全。
36. 你們的項目組每個人都寫Daily report麼?
要寫。五分鐘就夠﹐寫10句話左右﹐告訴自己小組的人
今天我幹了什麼。一則為了勾通﹐二則鞭策自己。
(要是遊手好閑一天﹐自己都會不好意思寫的)。
37. 你們的項目經理會發出weekly report麼?
要。也是為了勾通。內容包括目前進度﹐
可能的風險﹐質量狀況﹐各種工作的進展等。
38. 你們項目組是否至少每週全體開會一次?
要。一定要開會。程序員討厭開會，
但每個禮拜開會時間加起來至少應該有4小時。
包括team meeting, spec review meeting, bug triage meeting。
千萬別大家悶頭寫code。
39. 你們項目組的會議、討論都有記錄麼？
會前發meeting request和agenda，會中有人負責主持和記錄，
會後有人負責發meeting minutes，這都是effective meeting的要點。
而且，每個會議都要形成agreements和action items。
40. 其他部門知道你們項目組在幹什麼麼？
要發一些Newsflash給整個大組織。Show your team’s value。
否則，當你坐在電梯裏面，其他部門的人問：“你們在幹嘛”，
你回答“ABC項目”的時候，別人全然不知，那種感覺不太好。
41. 通過Email進行所有正式溝通
Email的好處是免得抵賴。但也要避免矯枉過正，
最好的方法是先用電話和當面說，然後Email來確認。
42. 爲項目組建立多個Mailing Group
如果在AD+Exchange裏面，就建Distribution List。比如，
我會建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，
ABC Project Extended Team等等。這樣發起Email來方便，
而且能讓該收到email的人都收到、不該收到不被騷擾。
43. 每個人都知道哪裏可以找到全部的文檔麼？
應該每個人都知道。這叫做知識管理（Knowledge Management）。
最方便的就是把文檔放在一個集中的File Share，更好的方法是用Sharepoint。
44. 你做決定、做變化時，告訴大家原因了麼？
要告訴大家原因。Empower team member的手段之一是提供足夠的information，
這是MSF一開篇的幾個原則之一。的確如此，tell me why是人之常情，
tell me why了纔能有understanding。中國人做事喜歡搞限制，
限制信息，似乎能夠看到某一份文件的人就是有身份的人。
大錯特錯。權威、權力，不在於是不是能access information/data，
而在於是不是掌握資源。
45. Stay agile and expect change 要這樣。
需求一定會變的，已經寫好的代碼一定會被要求修改的。
做好心理準備，對change不要抗拒，而是expect change。
46. 你們有沒有專職的軟件測試人員？
要有專職測試。如果人手不夠，可以peer test，
交換了測試。千萬別自己測試自己的。
47. 你們的測試有一份總的計劃來規定做什麼和怎麼做麼？
這就是Test Plan。要不要做性能測試？要不要做Usability測試？
什麼時候開始測試性能？測試通過的標準是什麼？用什麼手段，
自動的還是手動的？這些問題需要用Test Plan來回答。
48. 你是先寫Test Case然後再測試的麼？
應該如此。應該先設計再編程、先test case再測試。
當然，事情是靈活的。我有時候在做第一遍測試的同時補上test case。
至於先test case再開發，我不喜歡，因爲不習慣，太麻煩，至於別人推薦，那試試看也無妨。
49. 你是否會爲各種輸入組合創建測試用例？
不要，不要搞邊界條件組合。當心組合爆炸。
有很多test case工具能夠自動生成各種邊界條件的組合——
但要想清楚，你是否有時間去運行那麼多test case。
50. 你們的程序員能看到測試用例麼？
要。讓Dev看到Test Case吧。我們都是爲了同一個目的走到一起來的：提高質量。
51. 你們是否隨便抓一些人來做易用性測試？
要這麼做。自己看自己寫的程序界面，怎麼看都是順眼的。
這叫做審美疲勞——臭的看久了也就不臭了，不方便的永久了也就習慣了。
52. 你對自動測試的期望正確麼？
別期望太高。依我看，除了性能測試以外，還是暫時先忘掉“自動測試”吧，
忘掉WinRunner和LoadRunner吧。對於國內的軟件測試的現狀來說，只能“矯枉必須過正”了。
53. 你們的性能測試是等所有功能都開發完才做的麼？
不能這樣。性能測試不能被歸到所謂的“系統測試”階段。早測早改正，早死早昇天。
54. 你注意到測試中的殺蟲劑效應了麼？
蟲子有抗藥性，Bug也有。發現的新Bug越來越少是正常的。
這時候，最好大家交換一下測試的area，或者用用看其他工具和手法，就又會發現一些新bug了。
55. 你們項目組中有人能說出產品的當前整體質量情況麼？
要有。當老闆問起這個產品目前質量如何，Test Lead/Manager應該負責回答。
56. 你們有單元測試麼？
單元測試要有的。不過沒有單元測試也不是不可以，
我做過沒有單元測試的項目，也做成功了——可能是僥倖，
可能是大家都是熟手的關係。還是那句話，軟件工程是非常實踐、非常工程、
非常靈活的一套方法，某些方法在某些情況下會比另一些方法好，反之亦然。
57. 你們的程序員是寫完代碼就扔過牆的麼？
大忌。寫好一塊程序以後，即便不做單元測試，也應該自己先跑一跑。
雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。
微軟還有Test Release Document的說法，程序太爛的話，測試有權踢回去。
58. 你們的程序中所有的函數都有輸入檢查麼？
不要。雖然說做輸入檢查是write secure code的要點，
但不要做太多的輸入檢查，有些內部函數之間的參數傳遞就不必檢查輸入了，
省點功夫。同樣的道理，未必要給所有的函數都寫註釋。寫一部分主要的就夠了。
59. 產品有統一的錯誤處理機制和報錯界面麼？
要有。最好能有統一的error message，然後每個error message
都帶一個error number。這樣，用戶可以自己根據error number
到user manual裏面去看看錯誤的具體描述和可能原因，
就像SQL Server的錯誤那樣。同樣，ASP.NET也要有統一的Exception處理。
可以參考有關的Application Block。
60. 你們有統一的代碼書寫規範麼？
要有。Code Convention很多，搞一份來發給大家就可以了。
當然，要是有FxCop這種工具來檢查代碼就更好了。
61. 你們的每個人都瞭解項目的商業意義麼？
要。這是Vision的意思。別把項目只當成工作。有時候要想着自己是
在爲中國某某行業的信息化作先驅者，或者時不時的告訴team member，
這個項目能夠爲某某某國家部門每年節省多少多少百萬的納稅人的錢，
這樣就有動力了。平凡的事情也是可以有個崇高的目標的。
62. 產品各部分的界面和操作習慣一致麼？
要這樣。要讓用戶覺得整個程序好像是一個人寫出來的那樣。
63. 有可以作爲宣傳亮點的Cool Feature麼？
要。這是增強團隊凝聚力、信心的。而且，“一俊遮百醜”，
有亮點就可以掩蓋一些問題。這樣，對於客戶來說，
會感覺產品從質量角度來說還是acceptable的。或者說，
cool feature或者說亮點可以作爲質量問題的一個事後彌補措施。
64. 儘可能縮短產品的啓動時間
要這樣。 軟件啓動時間（Start-Up time）是客戶對性能好壞的第一印象。
65. 不要過於注重內在品質而忽視了第一眼的外在印象
程序員容易犯這個錯誤：太看重性能、穩定性、存儲效率，
但忽視了外在感受。而高層經理、客戶正相反。
這兩方面要兼顧，協調這些是PM的工作。
66. 你們根據詳細產品功能說明書做開發麼？
要這樣。要有設計才能開發，這是必須的。
設計文檔，應該說清楚這個產品會怎麼運行，應該採取一些講故事的方法。
設計的時候千萬別鑽細節，別鑽到數據庫、代碼等具體實現裏面去，
那些是後面的事情，一步步來不能着急。
67. 開始開發和測試之前每個人都仔細審閱功能設計麼？
要做。Function Spec review是用來統一思想的。
而且，review過以後形成了一致意見，將來再也沒有人可以說“你看，
當初我就是反對這麼設計的，現在喫苦頭了吧”
68. 所有人都始終想着The Whole Image麼？
要這樣。項目裏面每個人雖然都只是在製造一片葉子，
但每個人都應該知道自己在製造的那片葉子所在的樹是怎麼樣子的。
我反對軟件藍領，反對過分的把軟件製造看成流水線、車間。參見第61條。
69. Dev工作的劃分是單純縱向或橫向的麼？
不能單純的根據功能模塊分，或者單純根據表現層、中間層、數據庫層分。
我推薦這麼做：首先根據功能模塊分，然後每個“層”都有一個Owner來
Review所有人的設計和代碼，保證consistency。
70. 你們的程序員寫程序設計說明文檔麼？
要。不過我聽說微軟的程序員1999年以前也不寫。所以說，
寫不寫也不是絕對的，偷懶有時候也是可以的。參見第56條。
71. 你在招人面試時讓他寫一段程序麼？
要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多
循環、判斷、指針、遞歸等，既不偏向過於考算法，也不偏向過於考特定的API。
72. 你們有沒有技術交流講座？
要的。每一兩個禮拜搞一次內部的Tech Talk或者Chalk Talk吧。
讓組員之間分享技術心得，這筆花錢送到外面去培訓划算。
73. 你們的程序員都能專注於一件事情麼？
要讓程序員專注一件事。例如說，一個部門有兩個項目和10個人，
一種方法是讓10個人同時參加兩個項目，每個項目上每個人都花50%時間；
另一種方法是5 個人去項目A，5個人去項目B，每個人都100%在某一個項目上。
我一定選後面一種。這個道理很多人都懂，
但很多領導實踐起來就把屬下當成可以任意拆分的資源了。
74. 你們的程序員會誇大完成某項工作所需要的時間麼？
會的，這是常見的，尤其會在項目後期誇大做某個change所需要的時間，
以次來抵制change。解決的方法是坐下來慢慢磨，磨掉程序員的逆反心理，
一起分析，並把估算時間的顆粒度變小。
75. 儘量不要用Virtual Heads 最好不要用Virtual Heads。
Virtual heads意味着resource is not secure，shared resource
會降低resource的工作效率，容易增加出錯的機會，會讓一心二用的人
沒有太多時間去review spec、review design。一個dedicated的人，
要強過兩個只能投入50%時間和精力的人。我是喫過虧的：7個part time的tester，
發現的Bug和乾的活，加起來還不如兩個full-time的。參見第73條。
73條是針對程序員的，75條是針對 Resource Manager的。
我現在做的項目是採用如下方法管理的：
BD：基礎設計。在這個文檔裏，我們把程序的界面全部畫出來；
界面上的功能全部描述完整。如：一個查詢界面的條件是什麼，
查詢出來的結果如何顯示等等。
FD：功能設計。在這個文檔裏，對BD階段的各個頁面裏包含的
數據邏輯處理做說明。如：查詢時調用的數據處理函數該如何設計，
入口參數，返回參數，關聯的表等等各方面的說明。
因爲程序的界面已經定了，數據處理邏輯也定了。所以，就開始編碼階段。
當編碼過程中發生什麼問題，程序的整個功能還是必須滿足BD和FD設計文檔中的要求。
程序中的各種疑問，都以BD和FD文檔中的說明爲準。
基本上我們一個小項目的開發週期爲2個月，BD爲2-3周，FD1周，PG（編程）2-3周，CT(測試)2周。
測試完畢後交出去的就是成品，基本上不會再有系統要求變更的問題了。
如果有變更，且不在BD設計範圍內，那就是新增需求。就是一個新項目了。