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