要。一定要開會(huì)。程序員討厭開會(huì)，但每個(gè)禮拜開會(huì)時(shí)間加起來(lái)至少應(yīng)該有4小時(shí)。包括team meeting, spec review meeting, bug triage meeting。千萬(wàn)別大家悶頭寫code。

39. 你們項(xiàng)目組的會(huì)議、討論都有記錄么？
會(huì)前發(fā)meeting request和agenda，會(huì)中有人負(fù)責(zé)主持和記錄，會(huì)后有人負(fù)責(zé)發(fā)meeting minutes，這都是effective meeting的要點(diǎn)。而且，每個(gè)會(huì)議都要形成agreements和action items。

40. 其他部門知道你們項(xiàng)目組在干什么么？
要發(fā)一些Newsflash給整個(gè)大組織。Show your team’s value。否則，當(dāng)你坐在電梯里面，其他部門的人問：“你們?cè)诟陕铩?，你回答“ABC項(xiàng)目”的時(shí)候，別人全然不知，那種感覺不太好。

41. 通過(guò)Email進(jìn)行所有正式溝通
Email的好處是免得抵賴。但也要避免矯枉過(guò)正，最好的方法是先用電話和當(dāng)面說(shuō)，然后Email來(lái)確認(rèn)。

42. 為項(xiàng)目組建立多個(gè)Mailing Group
如果在AD+Exchange里面，就建Distribution List。比如，我會(huì)建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。這樣發(fā)起Email來(lái)方便，而且能讓該收到email的人都收到、不該收到不被騷擾。

43. 每個(gè)人都知道哪里可以找到全部的文檔么？
應(yīng)該每個(gè)人都知道。這叫做知識(shí)管理（Knowledge Management）。最方便的就是把文檔放在一個(gè)集中的File Share，更好的方法是用Sharepoint。

44. 你做決定、做變化時(shí)，告訴大家原因了么？
要告訴大家原因。Empower team member的手段之一是提供足夠的information，這是MSF一開篇的幾個(gè)原則之一。的確如此，tell me why是人之常情，tell me why了才能有understanding。中國(guó)人做事喜歡搞限制，限制信息，似乎能夠看到某一份文件的人就是有身份的人。大錯(cuò)特錯(cuò)。權(quán)威、權(quán)力，不在于是不是能access information/data，而在于是不是掌握資源。

45. Stay agile and expect change
要這樣。需求一定會(huì)變的，已經(jīng)寫好的代碼一定會(huì)被要求修改的。做好心理準(zhǔn)備，對(duì)change不要抗拒，而是expect change。

46. 你們有沒有專職的軟件測(cè)試人員？
要有專職測(cè)試。如果人手不夠，可以peer test，交換了測(cè)試。千萬(wàn)別自己測(cè)試自己的。

47. 你們的測(cè)試有一份總的計(jì)劃來(lái)規(guī)定做什么和怎么做么？
這就是Test Plan。要不要做性能測(cè)試？要不要做Usability測(cè)試？什么時(shí)候開始測(cè)試性能？測(cè)試通過(guò)的標(biāo)準(zhǔn)是什么？用什么手段，自動(dòng)的還是手動(dòng)的？這些問題需要用Test Plan來(lái)回答。

48. 你是先寫Test Case然后再測(cè)試的么？
應(yīng)該如此。應(yīng)該先設(shè)計(jì)再編程、先test case再測(cè)試。當(dāng)然，事情是靈活的。我有時(shí)候在做第一遍測(cè)試的同時(shí)補(bǔ)上test case。至于先test case再開發(fā)，我不喜歡，因?yàn)椴涣?xí)慣，太麻煩，至于別人推薦，那試試看也無(wú)妨。

49. 你是否會(huì)為各種輸入組合創(chuàng)建測(cè)試用例？
不要，不要搞邊界條件組合。當(dāng)心組合爆炸。有很多test case工具能夠自動(dòng)生成各種邊界條件的組合——但要想清楚，你是否有時(shí)間去運(yùn)行那么多test case。

50. 你們的程序員能看到測(cè)試用例么？
要。讓Dev看到Test Case吧。我們都是為了同一個(gè)目的走到一起來(lái)的：提高質(zhì)量。

51. 你們是否隨便抓一些人來(lái)做易用性測(cè)試？ 
要這么做。自己看自己寫的程序界面，怎么看都是順眼的。這叫做審美疲勞——臭的看久了也就不臭了，不方便的永久了也就習(xí)慣了。

52. 你對(duì)自動(dòng)測(cè)試的期望正確么？
別期望太高。依我看，除了性能測(cè)試以外，還是暫時(shí)先忘掉“自動(dòng)測(cè)試”吧，忘掉WinRunner和LoadRunner吧。對(duì)于國(guó)內(nèi)的軟件測(cè)試的現(xiàn)狀來(lái)說(shuō)，只能“矯枉必須過(guò)正”了。

53. 你們的性能測(cè)試是等所有功能都開發(fā)完才做的么？
不能這樣。性能測(cè)試不能被歸到所謂的“系統(tǒng)測(cè)試”階段。早測(cè)早改正，早死早升天。

54. 你注意到測(cè)試中的殺蟲劑效應(yīng)了么？
蟲子有抗藥性，Bug也有。發(fā)現(xiàn)的新Bug越來(lái)越少是正常的。這時(shí)候，最好大家交換一下測(cè)試的area，或者用用看其他工具和手法，就又會(huì)發(fā)現(xiàn)一些新bug了。

55. 你們項(xiàng)目組中有人能說(shuō)出產(chǎn)品的當(dāng)前整體質(zhì)量情況么？
要有。當(dāng)老板問起這個(gè)產(chǎn)品目前質(zhì)量如何，Test Lead/Manager應(yīng)該負(fù)責(zé)回答。

56. 你們有單元測(cè)試么？
單元測(cè)試要有的。不過(guò)沒有單元測(cè)試也不是不可以，我做過(guò)沒有單元測(cè)試的項(xiàng)目，也做成功了——可能是僥幸，可能是大家都是熟手的關(guān)系。還是那句話，軟件工程是非常實(shí)踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會(huì)比另一些方法好，反之亦然。

57. 你們的程序員是寫完代碼就扔過(guò)墻的么？
大忌。寫好一塊程序以后，即便不做單元測(cè)試，也應(yīng)該自己先跑一跑。雖然有了專門的測(cè)試人員，做開發(fā)的人也不可以一點(diǎn)測(cè)試都不做。微軟還有Test Release Document的說(shuō)法，程序太爛的話，測(cè)試有權(quán)踢回去。

58. 你們的程序中所有的函數(shù)都有輸入檢查么？
不要。雖然說(shuō)做輸入檢查是write secure code的要點(diǎn)，但不要做太多的輸入檢查，有些內(nèi)部函數(shù)之間的參數(shù)傳遞就不必檢查輸入了，省點(diǎn)功夫。同樣的道理，未必要給所有的函數(shù)都寫注釋。寫一部分主要的就夠了。

59. 產(chǎn)品有統(tǒng)一的錯(cuò)誤處理機(jī)制和報(bào)錯(cuò)界面么？
要有。最好能有統(tǒng)一的error message，然后每個(gè)error message都帶一個(gè)error number。這樣，用戶可以自己根據(jù)error number到user manual里面去看看錯(cuò)誤的具體描述和可能原因，就像SQL Server的錯(cuò)誤那樣。同樣，ASP.NET也要有統(tǒng)一的Exception處理?？梢詤⒖加嘘P(guān)的Application Block。

60. 你們有統(tǒng)一的代碼書寫規(guī)范么？
要有。Code Convention很多，搞一份來(lái)發(fā)給大家就可以了。當(dāng)然，要是有FxCop這種工具來(lái)檢查代碼就更好了。

61. 你們的每個(gè)人都了解項(xiàng)目的商業(yè)意義么？
要。這是Vision的意思。別把項(xiàng)目只當(dāng)成工作。有時(shí)候要想著自己是在為中國(guó)某某行業(yè)的信息化作先驅(qū)者，或者時(shí)不時(shí)的告訴team member，這個(gè)項(xiàng)目能夠?yàn)槟衬衬硣?guó)家部門每年節(jié)省多少多少百萬(wàn)的納稅人的錢，這樣就有動(dòng)力了。平凡的事情也是可以有個(gè)崇高的目標(biāo)的。

62. 產(chǎn)品各部分的界面和操作習(xí)慣一致么？
要這樣。要讓用戶覺得整個(gè)程序好像是一個(gè)人寫出來(lái)的那樣。

63. 有可以作為宣傳亮點(diǎn)的Cool Feature么？
要。這是增強(qiáng)團(tuán)隊(duì)凝聚力、信心的。而且，“一俊遮百丑”，有亮點(diǎn)就可以掩蓋一些問題。這樣，對(duì)于客戶來(lái)說(shuō)，會(huì)感覺產(chǎn)品從質(zhì)量角度來(lái)說(shuō)還是acceptable的?；蛘哒f(shuō)，cool feature或者說(shuō)亮點(diǎn)可以作為質(zhì)量問題的一個(gè)事后彌補(bǔ)措施。

64. 盡可能縮短產(chǎn)品的啟動(dòng)時(shí)間
要這樣。軟件啟動(dòng)時(shí)間（Start-Up time）是客戶對(duì)性能好壞的第一印象。

65. 不要過(guò)于注重內(nèi)在品質(zhì)而忽視了第一眼的外在印象
程序員容易犯這個(gè)錯(cuò)誤：太看重性能、穩(wěn)定性、存儲(chǔ)效率，但忽視了外在感受。而高層經(jīng)理、客戶正相反。這兩方面要兼顧，協(xié)調(diào)這些是PM的工作。

66. 你們根據(jù)詳細(xì)產(chǎn)品功能說(shuō)明書做開發(fā)么？
要這樣。要有設(shè)計(jì)才能開發(fā)，這是必須的。設(shè)計(jì)文檔，應(yīng)該說(shuō)清楚這個(gè)產(chǎn)品會(huì)怎么運(yùn)行，應(yīng)該采取一些講故事的方法。設(shè)計(jì)的時(shí)候千萬(wàn)別鉆細(xì)節(jié)，別鉆到數(shù)據(jù)庫(kù)、代碼等具體實(shí)現(xiàn)里面去，那些是后面的事情，一步步來(lái)不能著急。

67. 開始開發(fā)和測(cè)試之前每個(gè)人都仔細(xì)審閱功能設(shè)計(jì)么？
要做。Function Spec review是用來(lái)統(tǒng)一思想的。而且，review過(guò)以后形成了一致意見，將來(lái)再也沒有人可以說(shuō)“你看，當(dāng)初我就是反對(duì)這么設(shè)計(jì)的，現(xiàn)在吃苦頭了吧”

68. 所有人都始終想著The Whole Image么？
要這樣。項(xiàng)目里面每個(gè)人雖然都只是在制造一片葉子，但每個(gè)人都應(yīng)該知道自己在制造的那片葉子所在的樹是怎么樣子的。我反對(duì)軟件藍(lán)領(lǐng)，反對(duì)過(guò)分的把軟件制造看成流水線、車間。參見第61條。

69. Dev工作的劃分是單純縱向或橫向的么？
不能單純的根據(jù)功能模塊分，或者單純根據(jù)表現(xiàn)層、中間層、數(shù)據(jù)庫(kù)層分。我推薦這么做：首先根據(jù)功能模塊分，然后每個(gè)“層”都有一個(gè)Owner來(lái)Review所有人的設(shè)計(jì)和代碼，保證consistency。 

70. 你們的程序員寫程序設(shè)計(jì)說(shuō)明文檔么？
要。不過(guò)我聽說(shuō)微軟的程序員1999年以前也不寫。所以說(shuō)，寫不寫也不是絕對(duì)的，偷懶有時(shí)候也是可以的。參見第56條。

71. 你在招人面試時(shí)讓他寫一段程序么？
要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多循環(huán)、判斷、指針、遞歸等，既不偏向過(guò)于考算法，也不偏向過(guò)于考特定的API。

72. 你們有沒有技術(shù)交流講座？
要的。每一兩個(gè)禮拜搞一次內(nèi)部的Tech Talk或者Chalk Talk吧。讓組員之間分享技術(shù)心得，這筆花錢送到外面去培訓(xùn)劃算。

73. 你們的程序員都能專注于一件事情么？
要讓程序員專注一件事。例如說(shuō)，一個(gè)部門有兩個(gè)項(xiàng)目和10個(gè)人，一種方法是讓10個(gè)人同時(shí)參加兩個(gè)項(xiàng)目，每個(gè)項(xiàng)目上每個(gè)人都花50%時(shí)間；另一種方法是5個(gè)人去項(xiàng)目A，5個(gè)人去項(xiàng)目B，每個(gè)人都100%在某一個(gè)項(xiàng)目上。我一定選后面一種。這個(gè)道理很多人都懂，但很多領(lǐng)導(dǎo)實(shí)踐起來(lái)就把屬下當(dāng)成可以任意拆分的資源了。

74. 你們的程序員會(huì)夸大完成某項(xiàng)工作所需要的時(shí)間么？
會(huì)的，這是常見的，尤其會(huì)在項(xiàng)目后期夸大做某個(gè)change所需要的時(shí)間，以次來(lái)抵制change。解決的方法是坐下來(lái)慢慢磨，磨掉程序員的逆反心理，一起分析，并把估算時(shí)間的顆粒度變小。

75. 盡量不要用Virtual Heads
最好不要用Virtual Heads。Virtual heads意味著resource is not secure，shared resource會(huì)降低resource的工作效率，容易增加出錯(cuò)的機(jī)會(huì)，會(huì)讓一心二用的人沒有太多時(shí)間去review spec、review design。一個(gè)dedicated的人，要強(qiáng)過(guò)兩個(gè)只能投入50%時(shí)間和精力的人。我是吃過(guò)虧的：7個(gè)part time的tester，發(fā)現(xiàn)的Bug和干的活，加起來(lái)還不如兩個(gè)full-time的。參見第73條。73條是針對(duì)程序員的，75條是針對(duì)Resource Manager的。