VM曾經發了篇題為《
如何用正確的方法來寫出質量好的軟件的75條體會》的blog，后來他又給出了相應的回答：
《七十五條》的解釋?。而我亦給出了我自己的答案，有些不錯，有些差強人意，有些則非常不足了。為便于比較，我的答案附在了MVM答案的后面。
1. 你們的項目組使用源代碼管理工具了么？
MVM : 應該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的選擇是VSS。
郁也風 : 公司使用的是VSS，在網上與朋友玩的就是CVS了。
2. 你們的項目組使用缺陷管理系統了么？
MVM : 應該用。ClearQuest太復雜，我的推薦是BugZilla。
郁也風 : 嫌BugZilla安裝太費事，界面太簡陋，我選擇的是Jira的破解版。
3. 你們的測試組還在用Word寫測試用例么？
MVM : 不要用Word寫測試用例（Test Case）。應該用一個專門的系統，可以是Test Manager，也可以是自己開發一個ASP.NET的小網站。主要目的是Track和Browse。
郁也風 : 用Word，而且測試工作很是不上臺面（中國軟件的通病，所以我們公司也沒少得了犯）。
4. 你們的項目組有沒有建立一個門戶網站？
MVM : 要有一個門戶網站，用來放Contact Info、Baselined
Schedule、News等等。推薦Sharepoint Portal Server 2003來實現，15分鐘就搞定。買不起SPS
2003可以用WSS (Windows Sharepoint Service)。
郁也風 : 沒有，不過看你這么介紹，回頭試試去。
5. 你們的項目組用了你能買到最好的工具么？
MVM : 應該用盡量好的工具來工作。比如，應該用VS.NET而不是Notepad來寫C#。用Notepad寫程序多半只是一種炫耀。但也要考慮到經費，所以說是“你能買到最好的”。
郁也風 : 我一向認為所謂的Notepad開發是自虐狂的不良嗜好。我們使用Eclipse，不要錢的，但我認為是java開發最好的工具了。
6. 你們的程序員工作在安靜的環境里么？
MVM : 需要安靜環境。這點極端重要，而且要保證每個人的空間大于一定面積。
郁也風 : 看來這位兄臺是看過人件了，可惜我們公司的辦公環境只能說是一般，極為一般。
7. 你們的員工每個人都有一部電話么？
MVM : 需要每人一部電話。而且電話最好是帶留言功能的。當然，上這么一套帶留言電話系統開銷不小。不過至少每人一部電話要有，千萬別搞得經常有人站起來喊：“某某某電話”。《人件》里面就強烈譴責這種做法。
郁也風 : 你果然看了人件了，但請認清形式吧，那是美國，這是中國，“中國國情”四個字會噎死你的，現在的實際情況是很多公司都不讓用QQ，MSN（肯定包括我們公司了）。
8. 你們每個人都知道出了問題應該找誰么？
MVM : 應該知道。任何一個Feature至少都應該有一個Owner，當然，Owner可以繼續Dispatch給其他人。
郁也風 : 我們知道去找誰，但這不代表就能解決問題。
9. 你遇到過有人說“我以為…”么？
MVM : 要消滅“我以為”。Never assume anything。
郁也風 : 我也經常說“我認為”，尤其在我驗證之前。當然，我會考慮改正。
10. 你們的項目組中所有的人都坐在一起么？
MVM : 需要。我反對Virtual Team，也反對Dev在美國、Test在中國這種開發方式。能坐在一起就最好坐在一起，好處多得不得了。
郁也風 : 需要，很多問題不是面對面的話，還真無法解決，或是有時候面對面更能開拓思路，也能更好地交互。
11. 你們的進度表是否反映最新開發進展情況？
MVM : 應該反映。但是，應該用Baseline的方法來管理進度表：維護一份穩定的Schedule，再維護一份最新更改。Baseline的方法也應該用于其它的Spec。Baseline是變更管理里面的一個重要手段。
郁也風 : 這是我一直很頭疼的問題，如何維護一個有效的進度表不亞于任何一個模塊的開發啊。
12. 你們的工作量是先由每個人自己估算的么？
MVM : 應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務工期固定等。
郁也風 : 可惜我們的任務多是政治任務，工期固定的就像螺絲釘。
13. 你們的開發人員從項目一開始就加班么？
MVM : 不要這樣。不要一開始就搞疲勞戰。從項目一開始就加班，只能說明項目進度不合理。當然，一些對日軟件外包必須天天加班，那屬于剝削的范疇。
郁也風 : 我們加班是很多是因為資源的到位晚導致的，無可奈何。誰都知道問題的所在，誰都找不到解決問題的方法。
14. 你們的項目計劃中Buffer Time是加在每個小任務后面的么？
MVM : 不要。Buffer Time加在每個小任務后面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個Milestone或者checkpoint前面。
郁也風 : 我們盡量這么做了。
15. 值得再多花一些時間，從95%做到100%好
MVM : 值得，非常值得。尤其當項目后期人困馬乏的時候，要堅持。這會給產品帶來質的區別。
郁也風 : 我們多是在客戶的逼迫下完成那最后的5%的。而且100%并不代表Over，而是另一個100%的開始，成就了一個完美的惡性循環。
16. 登記新缺陷時，是否寫清了重現步驟？
MVM : 要。這屬于Dev和Test之間的溝通手段。面對面溝通需要，詳細填寫Repro Steps也需要。
郁也風 : 絕對要，理由同上。
17. 寫新代碼前會把已知缺陷解決么？
MVM : 要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新代碼。
郁也風 : 沒別的說的，一定要。
18. 你們對缺陷的輕重緩急有事先的約定么？
MVM : 必須有定義。Severity要分1、2、3，約定好：藍屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但這種約定可以根據產品質量現狀適當進行調整。
郁也風 : 知道需要，但是做的相當不夠，需要努力改進。
19. 你們對意見不一的缺陷有三國會議么？
MVM : 必須要有。要有一個明確的決策過程。這類似于CCB (Change Control Board)的概念。
郁也風 : 要由最后拍板的。而且不能陷入爭論的泥淖。
20. 所有的缺陷都是由登記的人最后關閉的么？
MVM : Bug應該由Opener關閉。Dev不能私自關閉Bug。
郁也風 : 同意。
21. 你們的程序員厭惡修改老的代碼么？
MVM : 厭惡是正常的。解決方法是組織Code Review，單獨留出時間來。XP也是一個方法。
郁也風 : Code Review？我們老板不喜歡。
22. 你們項目組有Team Morale Activity么？
MVM : 每個月都要搞一次，吃飯、唱歌、Outing、打球、開卡丁車等等，一定要有。不要剩這些錢。
郁也風 : 這點絕對不會少的，至少我帶過的團隊的凝聚力還是不錯的。
23. 你們項目組有自己的Logo么？
MVM : 要有自己的Logo。至少應該有自己的Codename。
郁也風 : 沒想過，今天頭要搞個我們部門的文化衫，我強烈反對了。不過Logo可以考慮。
24. 你們的員工有印有公司Logo的T-Shirt么？
MVM : 要有。能增強歸屬感。當然，T-Shirt要做的好看一些，最好用80支的棉來做。別沒穿幾次就破破爛爛的。
郁也風 : 哦，前一個我說了，我反對了。我不喜歡千人一面的感覺。
25. 總經理至少每月參加次項目組會議
MVM : 要的。要讓team member覺得高層關注這個項目。
郁也風 : 好像是個不可能完成的任務。不知別的公司如何。
26. 你們是給每個Dev開一個分支么？
MVM : 反對。Branch的管理以及Merge的工作量太大，而且容易出錯。
郁也風 : 反對，管理困難，也沒有必要，可以加Lable。
27. 有人長期不Check-In代碼么？
MVM : 不可以。對大部分項目來說，最多兩三天就應該Check-In。
郁也風 : 不可以，我每天都監控VSS的。
28. 在Check-In代碼時都填寫注釋了么？
MVM : 要寫的，至少一兩句話，比如“解決了Bug No.225”。如果往高處拔，這也算做“配置審計”的一部分。
郁也風 : 要寫！
29. 有沒有設定每天Check-In的最后期限？
MVM : 要的，要明確Check-In Deadline。否則會Build Break。
郁也風 : 沒有，整合就是個明確的Deadline了。
30. 你們能把所有源碼一下子編譯成安裝文件嗎？
MVM : 要的。這是每日編譯（Daily Build）的基礎。而且必須要能夠做成自動的。
郁也風 : 當然，我不喜歡出現源碼和類文件不匹配。
31. 你們的項目組做每日編譯么？
MVM : 當然要做。有三樣東西是軟件項目/產品開發必備的：1. bug management; 2. source control; 3. daily build。
郁也風 : 至少項目負責人要做。
32. 你們公司有沒有積累一個項目風險列表？
MVM : 要。Risk Inventory。否則，下個項目開始的時候，又只能拍腦袋分析Risk了。
郁也風 : 沒有。也是一個需要考慮的內容。
33. 設計越簡單越好
MVM : 越簡單越好。設計時候多一句話，將來可能就帶來無窮無盡的煩惱。應該從一開始就勇敢的砍。這叫scope management。
郁也風 : 不同意，過度簡單就成了簡陋了。而且什么樣的叫簡單？沒有一個量的界定。設計是需要讓別人看明白的。
34. 盡量利用現有的產品、技術、代碼
MVM :
千萬別什么東西都自己Coding。BizTalk和Sharepoint就是最好的例子，有這兩個作為基礎，可以把起點提高很多。或者可以盡量多用現成
的Control之類的。或者盡量用XML，而不是自己去Parse一個文本文件；盡量用RegExp，而不是自己從頭操作字符串，等等等等。這就是“軟
件復用”的體現。
郁也風 : 同意，我的原則是：有穩定的，經過實踐驗證的開源組件或產品的話，絕對不再自己搭爐灶。
35. 你們會隔一段時間就停下來夯實代碼么？
MVM : 要。最好一個月左右一次。傳言去年年初Windows組在Stevb的命令下停過一個月增強安全。Btw，“夯”這個字念“hang”，第一聲。
郁也風 : 肯定做了，不過可能并不是有意識地去做的。
36. 你們的項目組每個人都寫Daily Report么？
MVM : 要寫。五分鐘就夠了，寫10句話左右，告訴自己小組的人今天我干了什么。一則為了溝通，二則鞭策自己（要是游手好閑一天，自己都會不好意思寫的）。
郁也風 : 這是公司的規定。也是少有的能讓我支持的規定。
37. 你們的項目經理會發出Weekly Report么？
MVM : 要。也是為了溝通。內容包括目前進度，可能的風險，質量狀況，各種工作的進展等。
郁也風 : 也是公司的規定。
38. 你們項目組是否至少每周全體開會一次？
MVM : 要。一定要開會。程序員討厭開會，但每個禮拜開會時間加起來至少應該有4小時。包括team meeting, spec review meeting, bug triage meeting。千萬別大家悶頭寫code。
郁也風 : 要，至少這點我們實施的還可以。
39. 你們項目組的會議、討論都有記錄么？
MVM : 會前發meeting request和agenda，會中有人負責主持和記錄，會后有人負責發meeting minutes，這都是effective meeting的要點。而且，每個會議都要形成agreements和action items。
郁也風 : 有記錄，最后要形成會議紀要的。
40. 其他部門知道你們項目組在干什么么？
MVM : 要發一些Newsflash給整個大組織。Show your team’s value。否則，當你坐在電梯里面，其他部門的人問：“你們在干嘛”，你回答“ABC項目”的時候，別人全然不知，那種感覺不太好。
郁也風 : 我們公司的項目開始時要求所有的技術骨干坐在一起評審的，別人想不知道都難。
41. 通過Email進行所有正式溝通
MVM : Email的好處是免得抵賴。但也要避免矯枉過正，最好的方法是先用電話和當面說，然后Email來確認。
郁也風 : 很少使用Email，更多是當面解決問題，畢竟都在一個辦公室。
42. 為項目組建立多個Mailing Group
MVM : 如果在AD+Exchange里面，就建Distribution
List。比如，我會建ABC Project Core Team，ABC Project Dev Team，ABC Project All
Testers，ABC Project Extended
Team等等。這樣發起Email來方便，而且能讓該收到email的人都收到、不該收到不被騷擾。
郁也風 : 沒有這個條件，這個更應該根據項目組的規模來進行吧。
43. 每個人都知道哪里可以找到全部的文檔么？
MVM : 應該每個人都知道。這叫做知識管理（Knowledge Management）。最方便的就是把文檔放在一個集中的File Share，更好的方法是用Sharepoint。
郁也風 : 所有需要的開發文檔都放在一個統一的地方，這是規定。
44. 你做決定、做變化時，告訴大家原因了么？
MVM : 要告訴大家原因。Empower team
member的手段之一是提供足夠的information，這是MSF一開篇的幾個原則之一。的確如此，tell me why是人之常情，tell
me
why了才能有understanding。中國人做事喜歡搞限制，限制信息，似乎能夠看到某一份文件的人就是有身份的人。大錯特錯。權威、權力，不在于
是不是能access information/data，而在于是不是掌握資源。
郁也風 : 對我們來說，需做變化時，也就是臨時會議的需要進行的時候。
45. Stay agile and expect change
MVM : 要這樣。需求一定會變的，已經寫好的代碼一定會被要求修改的。做好心理準備，對change不要抗拒，而是expect change。
郁也風 : 這點只能說談何容易。希望能做到吧。
46. 你們有沒有專職的軟件測試人員？
MVM : 要有專職測試。如果人手不夠，可以peer test，交換了測試。千萬別自己測試自己的。
郁也風 : 我們都知道需要，可是往往實際情況差強人意。
47. 你們的測試有一份總的計劃來規定做什么和怎么做么？
MVM : 這就是Test Plan。要不要做性能測試？要不要做Usability測試？什么時候開始測試性能？測試通過的標準是什么？用什么手段，自動的還是手動的？這些問題需要用Test Plan來回答。
郁也風 : 知道需要，可實際情況同46。
48. 你是先寫Test Case然后再測試的么？
MVM : 應該如此。應該先設計再編程、先test case再測試。當然，事情是靈活的。我有時候在做第一遍測試的同時補上test case。至于先test case再開發，我不喜歡，因為不習慣，太麻煩，至于別人推薦，那試試看也無妨。
郁也風 : 至少目前的習慣和你類似，將來打算試試TDD。
49. 你是否會為各種輸入組合創建測試用例？
MVM : 不要，不要搞邊界條件組合。當心組合爆炸。有很多test case工具能夠自動生成各種邊界條件的組合——但要想清楚，你是否有時間去運行那么多test case。
郁也風 : 不會，沒那個精力先。
50. 你們的程序員能看到測試用例么？
MVM : 要。讓Dev看到Test Case吧。我們都是為了同一個目的走到一起來的：提高質量。
郁也風 : 當然能夠，項目中所有的東西都是對大家透明的。
51. 你們是否隨便抓一些人來做易用性測試？
MVM : 要這么做。自己看自己寫的程序界面，怎么看都是順眼的。這叫做審美疲勞——臭的看久了也就不臭了，不方便的永久了也就習慣了。
郁也風 : 我是非常推薦這樣的測試的，很多時候，客戶也會參與進來。
52. 你對自動測試的期望正確么？
MVM : 別期望太高。依我看，除了性能測試以外，還是暫時先忘掉“自動測試”吧，忘掉WinRunner和LoadRunner吧。對于國內的軟件測試的現狀來說，只能“矯枉必須過正”了。
郁也風 : 從不期望。
53. 你們的性能測試是等所有功能都開發完才做的么？
MVM : 不能這樣。性能測試不能被歸到所謂的“系統測試”階段。早測早改正，早死早升天。
郁也風 : 同意，非常同意。
54. 你注意到測試中的殺蟲劑效應了么？
MVM : 蟲子有抗藥性，Bug也有。發現的新Bug越來越少是正常的。這時候，最好大家交換一下測試的area，或者用用看其他工具和手法，就又會發現一些新bug了。
郁也風 : 同意。
55. 你們項目組中有人能說出產品的當前整體質量情況么？
MVM : 要有。當老板問起這個產品目前質量如何，Test Lead/Manager應該負責回答。
郁也風 : 這當然是TL/PM的活了。
56. 你們有單元測試么？
MVM : 單元測試要有的。不過沒有單元測試也不是不可以，我做過沒有單元測試的項目，也做成功了——可能是僥幸，可能是大家都是熟手的關系。還是那句話，軟件工程是非常實踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會比另一些方法好，反之亦然。
郁也風 : 我同意，雖然我們做的很不好。
57. 你們的程序員是寫完代碼就扔過墻的么？
MVM : 大忌。寫好一塊程序以后，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有Test Release Document的說法，程序太爛的話，測試有權踢回去。
郁也風 : 這樣的選手是要挨罵的。
58. 你們的程序中所有的函數都有輸入檢查么？
MVM : 不要。雖然說做輸入檢查是write secure code的要點，但不要做太多的輸入檢查，有些內部函數之間的參數傳遞就不必檢查輸入了，省點功夫。同樣的道理，未必要給所有的函數都寫注釋。寫一部分主要的就夠了。
郁也風 : 更多的時候是在最外面進行檢查。太多的檢查沒有意義。
59. 產品有統一的錯誤處理機制和報錯界面么？
MVM : 要有。最好能有統一的error message，然后每個error
message都帶一個error number。這樣，用戶可以自己根據error number到user
manual里面去看看錯誤的具體描述和可能原因，就像SQL
Server的錯誤那樣。同樣，ASP.NET也要有統一的Exception處理。可以參考有關的Application Block。
郁也風 : 有，這也是j2ee 的規范了。
60. 你們有統一的代碼書寫規范么？
MVM : 要有。Code Convention很多，搞一份來發給大家就可以了。當然，要是有FxCop這種工具來檢查代碼就更好了。
郁也風 : 有，首先是IDE的format工具，然后是Checkstyle之類的檢查工具在每天的day build之前使用。
61. 你們的每個人都了解項目的商業意義么？
MVM :
要。這是Vision的意思。別把項目只當成工作。有時候要想著自己是在為中國某某行業的信息化作先驅者，或者時不時的告訴team
member，這個項目能夠為某某某國家部門每年節省多少多少百萬的納稅人的錢，這樣就有動力了。平凡的事情也是可以有個崇高的目標的。
郁也風 : 剛才說了，我們的項目的每個部分對每個人都是透明的。
62. 產品各部分的界面和操作習慣一致么？
MVM : 要這樣。要讓用戶覺得整個程序好像是一個人寫出來的那樣。
郁也風 : 需要，這也是規范的一部分。
63. 有可以作為宣傳亮點的Cool Feature么？
MVM : 要。這是增強團隊凝聚力、信心的。而且，“一俊遮百丑”，有亮點就可以掩蓋一些問題。這樣，對于客戶來說，會感覺產品從質量角度來說還是acceptable的。或者說，cool feature或者說亮點可以作為質量問題的一個事后彌補措施。
郁也風 : 同意，我前一個項目的界面風格，被客戶定為其它項目的參考標準了^_^。
64. 盡可能縮短產品的啟動時間
MVM : 要這樣。軟件啟動時間（Start-Up time）是客戶對性能好壞的第一印象。
郁也風 : 需要，另外一方面，等待對我們開發方也是一種折磨。
65. 不要過于注重內在品質而忽視了第一眼的外在印象
MVM : 程序員容易犯這個錯誤：太看重性能、穩定性、存儲效率，但忽視了外在感受。而高層經理、客戶正相反。這兩方面要兼顧，協調這些是PM的工作。
郁也風 : 這也是我在最近的項目中轉變最大的方面。
66. 你們根據詳細產品功能說明書做開發么？
MVM : 要這樣。要有設計才能開發，這是必須的。設計文檔，應該說清楚這個產品會怎么運行，應該采取一些講故事的方法。設計的時候千萬別鉆細節，別鉆到數據庫、代碼等具體實現里面去，那些是后面的事情，一步步來不能著急。
郁也風 : 我更喜歡迭代，你的設計是根據需求，而需求是來自客戶，而客戶。。。永遠不變的是變化。
67. 開始開發和測試之前每個人都仔細審閱功能設計么？
MVM : 要做。Function Spec review是用來統一思想的。而且，review過以后形成了一致意見，將來再也沒有人可以說“你看，當初我就是反對這么設計的，現在吃苦頭了吧”
郁也風 : 要做，而且要求每個人都提出意見，這是開發工作開始之前，開始之后，我更傾向于“一言堂”了。
68. 所有人都始終想著The Whole Image么？
MVM : 要這樣。項目里面每個人雖然都只是在制造一片葉子，但每個人都應該知道自己在制造的那片葉子所在的樹是怎么樣子的。我反對軟件藍領，反對過分的把軟件制造看成流水線、車間。參見第61條。
郁也風 : 我也同樣反對“軟件藍領”，一向唾棄這個學院派制造的名詞。我們采取的方式也同樣可以參加61。
69. Dev工作的劃分是單純縱向或橫向的么？
MVM : 不能單純的根據功能模塊分，或者單純根據表現層、中間層、數據庫層分。我推薦這么做：首先根據功能模塊分，然后每個“層”都有一個Owner來Review所有人的設計和代碼，保證consistency。
郁也風 : 同意。
70. 你們的程序員寫程序設計說明文檔么？
MVM : 要。不過我聽說微軟的程序員1999年以前也不寫。所以說，寫不寫也不是絕對的，偷懶有時候也是可以的。參見第56條。
郁也風 : 做的不夠，我們從來沒寫過。
71. 你在招人面試時讓他寫一段程序么？
MVM : 要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多循環、判斷、指針、遞歸等，既不偏向過于考算法，也不偏向過于考特定的API。
郁也風 : 我認為交流更能看出一個人的實際情況。
72. 你們有沒有技術交流講座？
MVM : 要的。每一兩個禮拜搞一次內部的Tech Talk或者Chalk Talk吧。讓組員之間分享技術心得，這筆花錢送到外面去培訓劃算。
郁也風 : 同意，也在著手準備啟動。
73. 你們的程序員都能專注于一件事情么？
MVM :
要讓程序員專注一件事。例如說，一個部門有兩個項目和10個人，一種方法是讓10個人同時參加兩個項目，每個項目上每個人都花50%時間；另一種方法是5
個人去項目A，5個人去項目B，每個人都100%在某一個項目上。我一定選后面一種。這個道理很多人都懂，但很多領導實踐起來就把屬下當成可以任意拆分的
資源了。
郁也風 : 我也懂，可實際情況是，現在有4個項目和我有關聯。
74. 你們的程序員會夸大完成某項工作所需要的時間么？
MVM : 會的，這是常見的，尤其會在項目后期夸大做某個change所需要的時間，以次來抵制change。解決的方法是坐下來慢慢磨，磨掉程序員的逆反心理，一起分析，并把估算時間的顆粒度變小。
郁也風 : 會的，就算我在上報工作量的時候也會夸大的。對下，我采取的措施同你；上面對我，采取的措施是打折。
75. 盡量不要用Virtual Heads
MVM : 最好不要用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的。
郁也風 : 我想說的同73。