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就是最好的例子，有這兩個作為基礎，可以把起點提高很多�；蛘呖梢员M量多用現成的Control之類的�；蛘弑M量用XML，而不是自己去Parse一個文本文件；盡量用RegExp，而不是自己從頭操作字符串，等等等等。這就是“軟件復用”的體現。
35. 你們會隔一段時間就停下來夯實代碼么？
要。最好一個月左右一次。傳言去年年初Windows組在Stevb的命令下停過一個月增強安全。Btw，“夯”這個字念“hang”，第一聲。
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了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
