IT項(xiàng)目開發(fā)的75條管理守則

1、不要用 Word 寫測試用例( Test Case )?？梢允?Test Manager ，也可以是自己1.你們的項(xiàng)目組使用源代碼管理工具了么？應(yīng)該用。 VSS 、CVS 、 PVCS 、ClearCase 、CCC/Harvest 、FireFly 都可以。我的選擇是 VSS。2.你們的項(xiàng)目組使用缺陷管理系統(tǒng)了么？應(yīng)該用。 ClearQuest 太復(fù)雜，我的推薦是 BugZilla 。3.你們的測試組還在用 Word 寫測試用例么？應(yīng)該用一個(gè)專門的系統(tǒng)，開發(fā)一個(gè) ASP.NET 的小網(wǎng)站。主要目的是Track 和 Browse 。4. 你們的項(xiàng)目組有沒有建立一個(gè)門戶網(wǎng)站？ 要有一個(gè)門戶網(wǎng)站，

2、 用來放 Contact Info、Baselined Schedule、News 等等。 推薦 Sharepoint PortalServer 2003 來實(shí)現(xiàn)，15 分鐘就搞定。買不起 SPS 2003 可以用WSS (Windows Sharepoint Service)5. 你們的項(xiàng)目組用了你能買到最好的工具么？應(yīng)該用盡量好的工具來工作。比如，應(yīng)該用VS.NET而不是Note pad 來寫C#。用Note pad 寫程序多半只是一種炫耀。但也要考慮到經(jīng)費(fèi)，所以說是 “你能買到最好的 ”。6. 你們的程序員工作在安靜的環(huán)境里么？ 需要安靜環(huán)境。這點(diǎn)極端重要，而且要保證每個(gè)人的空間大于一定

3、面積。7. 你們的員工每個(gè)人都有一部電話么？ 需要每人一部電話。而且電話最好是帶留言功能的。當(dāng)然，上這么一套帶留言電話系統(tǒng)開銷不小。不過至 少每人一部電話要有，千萬別搞得經(jīng)常有人站起來喊： “某某某電話 ”。人件里面就強(qiáng)烈譴責(zé)這種做法。8. 你們每個(gè)人都知道出了問題應(yīng)該找誰么？應(yīng)該知道。任何一個(gè) Feature 至少都應(yīng)該有一個(gè) Owner ，當(dāng)然， Owner 可以繼續(xù) Dispatch 給其他人。9.你遇到過有人說 我以為么？ 要消滅 我以為” Never assume anything10. 你們的項(xiàng)目組中所有的人都坐在一起么？需要。我反對 Virtual Team ，也反對 Dev 在

4、美國、 Test 在中國這種開發(fā)方式。能坐在一起就最好坐在一起，好處多得不得了。11. 你們的進(jìn)度表是否反映最新開發(fā)進(jìn)展情況？應(yīng)該反映。但是，應(yīng)該用 Baseline 的方法來管理進(jìn)度表：維護(hù)一份穩(wěn)定的 Schedule ，再維護(hù)一份最新更 改。 Baseline 的方法也應(yīng)該用于其它的 Spec 。 Baseline 是變更管理里面的一個(gè)重要手段。12. 你們的工作量是先由每個(gè)人自己估算的么？ 應(yīng)該讓每個(gè)人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務(wù) 工期固定等。13.你們的開發(fā)人員從項(xiàng)目一開始就加班么？ 不要這樣。不要一開始就搞疲勞戰(zhàn)。從項(xiàng)目一開始就加班

5、，只能說明項(xiàng)目進(jìn)度不合理。當(dāng)然，一些對日軟 件外包必須天天加班，那屬于剝削的范疇。14.你們的項(xiàng)目計(jì)劃中 Buffer Time 是加在每個(gè)小任務(wù)后面的么？ 不要。 Buffer Time 加在每個(gè)小任務(wù)后面，很容易輕易的就被消耗掉。Buffer Time 要整段的加在一個(gè)Milestone 或者 checkpoint 前面。15. 值得再多花一些時(shí)間，從 95% 做到 100% 好值得，非常值得。 尤其當(dāng)項(xiàng)目后期人困馬乏的時(shí)候，要堅(jiān)持。這會給產(chǎn)品帶來質(zhì)的區(qū)別。16. 登記新缺陷時(shí)，是否寫清了重現(xiàn)步驟？要。這屬于 Dev 和 Test 之間的溝通手段。面對面溝通需要，詳細(xì)填寫17.寫新代碼前會

6、把已知缺陷解決么？要。每個(gè)人的缺陷不能超過 bug 才能繼續(xù)寫新代碼。18.你們對缺陷的輕重緩急有事先的約定么？10Repro Steps 也需要。 個(gè)或 15 個(gè)，否則必須先解決老的32.要。你們公司有沒有積累一個(gè)項(xiàng)目風(fēng)險(xiǎn)列表？Risk Inventory 。否則，下個(gè)項(xiàng)目開始的時(shí)候，又只能拍腦袋分析 Risk 了。 設(shè)計(jì)越簡單越好越簡單越好。33.設(shè)計(jì)時(shí) 候多 一句話 ，將 來可 能就帶 來無 窮無盡 的煩 惱。 應(yīng)該從 一開 始就勇 敢的 砍。 這叫 scope必須有定義。 Severity 要分 1 、2 、3，約定好：藍(lán)屏和 Data Lost 算 Sev 1 ，F(xiàn)unction E

7、rror 算 Sev 2 ， 界面上的算 Sev 3 。但這種約定可以根據(jù)產(chǎn)品質(zhì)量現(xiàn)狀適當(dāng)進(jìn)行調(diào)整。19. 你們對意見不一的缺陷有三國會議么？必須要有。 要有一個(gè)明確的決策過程。 這類似于 CCB (ChangeControl Board) 的概念。20.所有的缺陷都是由登記的人最后關(guān)閉的么？Bug 應(yīng)該由 Opener 關(guān)閉。 Dev 不能私自關(guān)閉 Bug 。21.你們的程序員厭惡修改老的代碼么？厭惡是正常的。解決方法是組織 Code Review ，單獨(dú)留出時(shí)間來。 XP 也是一個(gè)方法。22. 你們項(xiàng)目組有 Team Morale Activity 么？每個(gè)月都要搞一次，吃飯、唱歌、 Ou

8、ting 、打球、開卡丁車等等，一定要有。不要剩這些錢。23.你們項(xiàng)目組有自己的 Logo 么？ 要有自己的 Logo 。至少應(yīng)該有自己的 Codename 。24.你們的員工有印有公司 Logo 的 T-Shirt 么？要有。 能增強(qiáng)歸屬感。 當(dāng)然， T-Shirt 要做的好看一些， 最好用 80 支的棉來做。 別沒穿幾次就破破爛爛的。25.總經(jīng)理至少每月參加次項(xiàng)目組會議要的。要讓 team member 覺得高層關(guān)注這個(gè)項(xiàng)目。26.你們是給每個(gè) Dev 開一個(gè)分支么？反對。 Branch 的管理以及 Merge 的工作量太大，而且容易出錯(cuò)。27.有人長期不 Check-In 代碼么？ 不可

9、以。對大部分項(xiàng)目來說，最多兩三天就應(yīng)該 Check-In28.在 Check-In 代碼時(shí)都填寫注釋了么？要寫的，至少一兩句話，比如 “解決了 Bug No.225” 。如果往高處拔，這也算做 “配置審計(jì) ”的一部分。29.有沒有設(shè)定每天 Check-In 的最后期限？ 要的，要明確 Check-In Deadline 。否則會 Build Break 。30.你們能把所有源碼一下子編譯成安裝文件嗎？ 要的。這是每日編譯( Daily Build )的基礎(chǔ)。而且必須要能夠做成自動的。31. 你們的項(xiàng)目組做每日編譯么？當(dāng)然要做。有三樣?xùn)|西是軟件項(xiàng)目 /產(chǎn)品開發(fā)必備的： 1. bug manage

10、ment; 2. source control; 3. dailybuild 。management 。34. 盡量利用現(xiàn)有的產(chǎn)品、 技術(shù)、 代碼千萬別什么東西都自己 Coding 。 BizT alk 和 Sharepoint 就是最好 的例子，有這兩個(gè)作為基礎(chǔ)，可以把起點(diǎn)提高很多?；蛘呖梢员M量多用現(xiàn)成的Control 之類的?；蛘弑M量用 XML ，而不是自己去 Parse 一個(gè)文本文件；盡量用 RegExp ，而不是自己從頭操作字符串，等等等等。 這就是“軟件復(fù)用 ”的體現(xiàn)。35.你們會隔一段時(shí)間就停下來夯實(shí)代碼么？要。最好一個(gè)月左右一次。 傳言去年年初 Windows 組在 Stevb

11、的命令下停過一個(gè)月增強(qiáng)安全。 Btw ，“夯 ” 這個(gè)字念“hang” ,第一聲。36.你們的項(xiàng)目組每個(gè)人都寫 Daily Report 么？要寫。五分鐘就夠了，寫 10 句話左右，告訴自己小組的人今天我干了什么。一則為了溝通，二則鞭策自 己(要是游手好閑一天，自己都會不好意思寫的) 。37. 要。你們的項(xiàng)目經(jīng)理會發(fā)出 Weekly Report 么？也是為了溝通。內(nèi)容包括目前進(jìn)度，可能的風(fēng)險(xiǎn)，質(zhì)量狀況，各種工作的進(jìn)展等。38.要。你們項(xiàng)目組是否至少每周全體開會一次？一定要開會。 程序員討厭開會， 但每個(gè)禮拜開會時(shí)間加起來至少應(yīng)該有 4 小時(shí)。包括 team meeting, 。千萬別大家悶頭

12、寫 code 。spec review meeting, bug triage meeting39. 你們項(xiàng)目組的會議、討論都有記錄么？會前發(fā) meeting request 和 agenda ，會中有人負(fù)責(zé)主持和記錄，會后有人負(fù)責(zé)發(fā) meeting minutes 的要點(diǎn)。而且，每個(gè)會議都要形成 agreements 和 action items 。這都是 effective meeting40. 其他部門知道你們項(xiàng)目組在干什么么？要發(fā)一些 Newsflash 給整個(gè)大組織。 Show your team s value 。否則，當(dāng)你坐在電梯里面，其他部門的 人問：你們在干嘛”你回答“ABC

13、項(xiàng)目”的時(shí)候，別人全然不知，那種感覺不太好。41. 通過 Email 進(jìn)行所有正式溝通Email 的好處是免得抵賴。但也要避免矯枉過正，最好的方法是先用電話和當(dāng)面說，然后Email 來確認(rèn)。42. 為項(xiàng)目組建立多個(gè) Mailing Group如果在 AD+Exchange 里面，就建 Distribution List 。比如，我會建 ABC Project Core Team ， ABCProject Dev Team ， ABC Project All Testers ， ABC Project Extended Team 來方便，而且能讓該收到 email 的人都收到、不該收到不被騷擾。

14、等等。這樣發(fā)起 Email43.每個(gè)人都知道哪里可以找到全部的文檔么？應(yīng)該每個(gè)人都知道。這叫做知識管理( Knowledge Management )。最方便的就是把文檔放在一個(gè)集中 的 File Share ，更好的方法是用 Sharepoint 。44.你做決定、做變化時(shí)，告訴大家原因了么？ 要告訴大家原因。 Empower team member 的手段之一是提供足夠的 的幾個(gè)原則之一。的確如此， tell me why 是人之常情， tell me why 人做事喜歡搞限制，限制信息，似乎能夠看到某一份文件的人就是有身份的人。 不在于是不是能 access information/da

15、ta ，而在于是不是掌握資源。information ，這是 MSF 一開篇了才能有大錯(cuò)特錯(cuò)。understanding 。中國 權(quán)威、權(quán)力，不要抗拒，而是 expect45. Stay agile and expect change 要這樣。需求一定會變的， 已經(jīng)寫好的代碼一定會被要求修改的。 做好心理準(zhǔn)備， 對 change change 。46.你們有沒有專職的軟件測試人員？ 要有專職測試。如果人手不夠，可以 peer test ，交換了測試。千萬別自己測試自己的。47.你們的測試有一份總的計(jì)劃來規(guī)定做什么和怎么做么？這就是Test Plan 。要不要做性能測試？要不要做 Usabili

16、ty 測試？什么時(shí)候開始測試性能？測試通過的標(biāo)準(zhǔn)是什么？用什么手段，自動的還是手動的？這些問題需要用 Test Plan 來回答。48. 你是先寫 Test Case 然后再測試的么？ 應(yīng)該如此。應(yīng)該先設(shè)計(jì)再編程、先 test case 再測試。當(dāng)然，事情是靈活的。我有時(shí)候在做第一遍測試的 同時(shí)補(bǔ)上 test case 。至于先 test case 再開發(fā)，我不喜歡，因?yàn)椴涣?xí)慣，太麻煩，至于別人推薦，那試 試看也無妨。49. 你是否會為各種輸入組合創(chuàng)建測試用例？不要，不要搞邊界條件組合。 當(dāng)心組合爆炸。 有很多 test case 工具能夠自動生成各種邊界條件的組合 但要想清楚，你是否有時(shí)間去

17、運(yùn)行那么多 test case 50. 你們的程序員能看到測試用例么？要。讓 Dev 看到 Test Case 吧。我們都是為了同一個(gè)目的走到一起來的：提高質(zhì)量。51.你們是否隨便抓一些人來做易用性測試？ 臭的看久了也就不臭了，area ， 可能是SQL要這么做。自己看自己寫的程序界面，怎么看都是順眼的。這叫做審美疲勞 不方便的永久了也就習(xí)慣了。52.你對自動測試的期望正確么？別期望太高。 依我看，除了性能測試以外， 還是暫時(shí)先忘掉 “自動測試 ”吧，忘掉 WinRunner 和 LoadRunner 吧。對于國內(nèi)的軟件測試的現(xiàn)狀來說，只能 “矯枉必須過正 ”了。53.你們的性能測試是等所有功

18、能都開發(fā)完才做的么？ 不能這樣。性能測試不能被歸到所謂的 “系統(tǒng)測試 ”階段。早測早改正，早死早升天。54.你注意到測試中的殺蟲劑效應(yīng)了么？蟲子有抗藥性， Bug 也有。發(fā)現(xiàn)的新 Bug 越來越少是正常的。這時(shí)候，最好大家交換一下測試的 或者用用看其他工具和手法，就又會發(fā)現(xiàn)一些新 bug 了。55.你們項(xiàng)目組中有人能說出產(chǎn)品的當(dāng)前整體質(zhì)量情況么？ 要有。當(dāng)老板問起這個(gè)產(chǎn)品目前質(zhì)量如何， Test Lead/Manager 應(yīng)該負(fù)責(zé)回答。56. 你們有單元測試么？ 單元測試要有的。不過沒有單元測試也不是不可以，我做過沒有單元測試的項(xiàng)目，也做成功了 僥幸，可能是大家都是熟手的關(guān)系。還是那句話，軟件

19、工程是非常實(shí)踐、非常工程、非常靈活的一套方法， 某些方法在某些情況下會比另一些方法好，反之亦然。57. 你們的程序員是寫完代碼就扔過墻的么？ 大忌。寫好一塊程序以后，即便不做單元測試，也應(yīng)該自己先跑一跑。雖然有了專門的測試人員，做開發(fā) 的人也不可以一點(diǎn)測試都不做。微軟還有 Test Release Document 的說法，程序太爛的話，測試有權(quán)踢 回去。58. 你們的程序中所有的函數(shù)都有輸入檢查么？ 不要。雖然說做輸入檢查是 write secure code 的要點(diǎn)，但不要做太多的輸入檢查，有些內(nèi)部函數(shù)之間的 參數(shù)傳遞就不必檢查輸入了，省點(diǎn)功夫。同樣的道理，未必要給所有的函數(shù)都寫注釋。寫一

20、部分主要的就 夠了。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ò)誤的具體描述和可能原因，就像Server的錯(cuò)誤那樣。同樣，ASP .NET也要有統(tǒng)一的Exce ption 處理。可以參考有關(guān)的 AppI ication Block60. 你們有統(tǒng)一的代碼書寫規(guī)范么？要有。 Code Convention 很多，搞一份來發(fā)給大家就可以了。當(dāng)然，要是有 FxCop 這種工具來檢查

21、代碼 就更好了。61. 你們的每個(gè)人都了解項(xiàng)目的商業(yè)意義么？要。這是 Vision 的意思。 別把項(xiàng)目只當(dāng)成工作。 有時(shí)候要想著自己是在為中國某某行業(yè)的信息化作先驅(qū)者， 或者時(shí)不時(shí)的告訴 team member ，這個(gè)項(xiàng)目能夠?yàn)槟衬衬硣也块T每年節(jié)省多少多少百萬的納稅人的錢， 這樣就有動力了。平凡的事情也是可以有個(gè)崇高的目標(biāo)的。62. 產(chǎn)品各部分的界面和操作習(xí)慣一致么？ 要這樣。要讓用戶覺得整個(gè)程序好像是一個(gè)人寫出來的那樣。63. 有可以作為宣傳亮點(diǎn)的 Cool Feature 么？要。這是增強(qiáng)團(tuán)隊(duì)凝聚力、信心的。而且， “一俊遮百丑 ”，有亮點(diǎn)就可以掩蓋一些問題。這樣，對于客戶 來說，會感覺

22、產(chǎn)品從質(zhì)量角度來說還是 acceptable 的?；蛘哒f， cool feature 或者說亮點(diǎn)可以作為質(zhì)量 問題的一個(gè)事后彌補(bǔ)措施。64. 盡可能縮短產(chǎn)品的啟動時(shí)間要這樣。軟件啟動時(shí)間( Start-Up time )是客戶對性能好壞的第一印象。65.不要過于注重內(nèi)在品質(zhì)而忽視了第一眼的外在印象程序員容易犯這個(gè)錯(cuò)誤：太看重性能、穩(wěn)定性、存PM 的工作。70. 要。 的。你在招人面試時(shí)讓他寫一段程序么？API 。儲效率，但忽視了外在感受。而高層經(jīng)理、客戶正相反。這兩方面要兼顧，協(xié)調(diào)這些是66.你們根據(jù)詳細(xì)產(chǎn)品功能說明書做開發(fā)么？ 要這樣。要有設(shè)計(jì)才能開發(fā)，這是必須的。設(shè)計(jì)文檔，應(yīng)該說清楚這個(gè)產(chǎn)

23、品會怎么運(yùn)行，應(yīng)該采取一些講 故事的方法。設(shè)計(jì)的時(shí)候千萬別鉆細(xì)節(jié)，別鉆到數(shù)據(jù)庫、代碼等具體實(shí)現(xiàn)里面去，那些是后面的事情，一 步步來不能著急。67.開始開發(fā)和測試之前每個(gè)人都仔細(xì)審閱功能設(shè)計(jì)么？要做。 Function Spec review是用來統(tǒng)一思想的。而且， review 過以后形成了一致意見，將來再也沒有人可以說你看，當(dāng)初我就是反對這么設(shè)計(jì)的，現(xiàn)在吃苦頭了吧”68.所有人都始終想著 The Whole Image 么？要這樣。項(xiàng)目里面每個(gè)人雖然都只是在制造一片葉子，但 每個(gè)人都應(yīng)該知道自己在制造的那片葉子所在的樹是怎么樣子的。我反對軟件藍(lán)領(lǐng)，反對過分的把軟件制 造看成流水線、車間。參見

24、第 61 條。69. Dev 工作的劃分是單純縱向或橫向的么？ 不能單純的根據(jù)功能模塊分，或者單純根據(jù)表現(xiàn)層、中間層、數(shù)據(jù)庫層分。我推薦這么做：首先根據(jù)功能 模塊分，然后每個(gè)“層”都有一個(gè) Owner 來 Review 所有人的設(shè)計(jì)和代碼，保證 consistency 。你們的程序員寫程序設(shè)計(jì)說明文檔么？不過我聽說微軟的程序員 1999 年以前也不寫。所以說，寫不寫也不是絕對的，偷懶有時(shí)候也是可以 參見第 56 條。71. 要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多循環(huán)、判斷、指針、遞歸等，既不偏向 過于考算法，也不偏向過于考特定的72.你們有沒有技術(shù)交流講座？要的。每一兩個(gè)禮拜搞一次內(nèi)部的 Tech Talk 或者 Chalk Talk 吧。讓組員之間分享技術(shù)心得，這筆花錢 送到外面去培訓(xùn)劃算。73.你們的程序員都能專注于一件事情么？ 要讓程序員專注一件事。 例如說，一個(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í)踐起來就把屬下當(dāng)成可以任意 拆分的資源了。74.你們的程序員會夸大完成某項(xiàng)工作所需要的時(shí)間么？ 會的，