[zt]IT專案開發的75條管理守則

pharos發表於2019-07-05

1. 你們的專案組使用原始碼管理工具了麼？
應該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的選擇是VSS。

2. 你們的專案組使用缺陷管理系統了麼？
應該用。ClearQuest太複雜，我的推薦是BugZilla。


3. 你們的測試組還在用Word寫測試用例麼？
不要用Word寫測試用例（Test Case）。應該用一個專門的系統，可以是Test Manager，也可以是自己開發一個ASP.NET的小網站。主要目的是Track和Browse。

4. 你們的專案組有沒有建立一個入口網站？
要有一個入口網站，用來放Contact Info、Baselined Schedule、News等等。推薦Sharepoint Portal Server 2003來實現，15分鐘就搞定。買不起SPS 2003可以用WSS (Windows Sharepoint Service)。

5. 你們的專案組用了你能買到最好的工具麼？
應該用盡量好的工具來工作。比如，應該用VS.NET而不是Notepad來寫C#。用Notepad寫程式多半隻是一種炫耀。但也要考慮到經費，所以說是“你能買到最好的”。

6. 你們的程式設計師工作在安靜的環境裡麼？
需要安靜環境。這點極端重要，而且要保證每個人的空間大於一定面積。

7. 你們的員工每個人都有一部電話麼？
需要每人一部電話。而且電話最好是帶留言功能的。當然，上這麼一套帶留言電話系統開銷不小。不過至少每人一部電話要有，千萬別搞得經常有人站起來喊：“某某某電話”。《人件》裡面就強烈譴責這種做法。

8. 你們每個人都知道出了問題應該找誰麼？
應該知道。任何一個Feature至少都應該有一個Owner，當然，Owner可以繼續Dispatch給其他人。

9. 你遇到過有人說“我以為…”麼？
要消滅“我以為”。Never assume anything。

10. 你們的專案組中所有的人都坐在一起麼？
需要。我反對Virtual Team，也反對Dev在美國、Test在中國這種開發方式。能坐在一起就最好坐在一起，好處多得不得了。

11. 你們的進度表是否反映最新開發進展情況？
應該反映。但是，應該用Baseline的方法來管理進度表：維護一份穩定的Schedule，再維護一份最新更改。Baseline的方法也應該用於其它的Spec。Baseline是變更管理裡面的一個重要手段。

12. 你們的工作量是先由每個人自己估算的麼？
應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務工期固定等。

13. 你們的開發人員從專案一開始就加班麼？
不要這樣。不要一開始就搞疲勞戰。從專案一開始就加班，只能說明專案進度不合理。當然，一些對日軟體外包必須天天加班，那屬於剝削的範疇。

14. 你們的專案計劃中Buffer Time是加在每個小任務後面的麼？
不要。Buffer Time加在每個小任務後面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個Milestone或者checkpoint前面。

15. 值得再多花一些時間，從95%做到100%好值得，非常值得。
尤其當專案後期人困馬乏的時候，要堅持。這會給產品帶來質的區別。

16. 登記新缺陷時，是否寫清了重現步驟？
要。這屬於Dev和Test之間的溝通手段。面對面溝通需要，詳細填寫Repro Steps也需要。

17. 寫新程式碼前會把已知缺陷解決麼？要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新程式碼。

18. 你們對缺陷的輕重緩急有事先的約定麼？
必須有定義。Severity要分1、2、3，約定好：藍屏和Data Lost算Sev 1，Function Error算Sev 2，介面上的算Sev 3。但這種約定可以根據產品質量現狀適當進行調整。

19. 你們對意見不一的缺陷有三國會議麼？必須要有。要有一個明確的決策過程。這類似於CCB (Change Control Board)的概念。

20. 所有的缺陷都是由登記的人最後關閉的麼？

Bug應該由Opener關閉。Dev不能私自關閉Bug。

21. 你們的程式設計師厭惡修改老的程式碼麼？
厭惡是正常的。解決方法是組織Code Review，單獨留出時間來。XP也是一個方法。

22. 你們專案組有Team Morale Activity麼？
每個月都要搞一次，吃飯、唱歌、Outing、打球、開卡丁車等等，一定要有。不要剩這些錢。

23. 你們專案組有自己的Logo麼？
要有自己的Logo。至少應該有自己的Codename。

24. 你們的員工有印有公司Logo的T-Shirt麼？
要有。能增強歸屬感。當然，T-Shirt要做的好看一些，最好用80支的棉來做。別沒穿幾次就破破爛爛的。

25. 總經理至少每月參加次專案組會議要的。
要讓team member覺得高層關注這個專案。

26. 你們是給每個Dev開一個分支麼？
反對。Branch的管理以及Merge的工作量太大，而且容易出錯。

27. 有人長期不Check-In程式碼麼？
不可以。對大部分專案來說，最多兩三天就應該Check-In。

28. 在Check-In程式碼時都填寫註釋了麼？
要寫的，至少一兩句話，比如“解決了Bug No.225”。如果往高處拔，這也算做“配置審計”的一部分。

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就是最好的例子，有這兩個作為基礎，可以把起點提高很多。或者可以儘量多用現成的Control之類的。或者儘量用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了。

55. 你們專案組中有人能說出產品的當前整體質量情況麼？
要有。當老闆問起這個產品目前質量如何，Test Lead/Manager應該負責回答。

56. 你們有單元測試麼？
單元測試要有的。不過沒有單元測試也不是不可以，我做過沒有單元測試的專案，也做成功了——可能是僥倖，可能是大家都是熟手的關係。還是那句話，軟體工程是非常實踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會比另一些方法好，反之亦然。

57. 你們的程式設計師是寫完程式碼就扔過牆的麼？
大忌。寫好一塊程式以後，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有Test Release Document的說法，程式太爛的話，測試有權踢回去。

58. 你們的程式中所有的函式都有輸入檢查麼？
不要。雖然說做輸入檢查是write secure code的要點，但不要做太多的輸入檢查，有些內部函式之間的引數傳遞就不必檢查輸入了，省點功夫。同樣的道理，未必要給所有的函式都寫註釋。寫一部分主要的就夠了。

59. 產品有統一的錯誤處理機制和報錯介面麼？
要有。最好能有統一的error message，然後每個error message都帶一個error number。這樣，使用者可以自己根據error number到user manual裡面去看看錯誤的具體描述和可能原因，就像SQL Server的錯誤那樣。同樣，ASP.NET也要有統一的Exception處理。可以參考有關的Application Block。

60. 你們有統一的程式碼書寫規範麼？
要有。Code Convention很多，搞一份來發給大家就可以了。當然，要是有FxCop這種工具來檢查程式碼就更好了。

61. 你們的每個人都瞭解專案的商業意義麼？
要。這是Vision的意思。別把專案只當成工作。有時候要想著自己是在為中國某某行業的資訊化作先驅者，或者時不時的告訴team member，這個專案能夠為某某某國家部門每年節省多少多少百萬的納稅人的錢，這樣就有動力了。平凡的事情也是可以有個崇高的目標的。

62. 產品各部分的介面和操作習慣一致麼？
要這樣。要讓使用者覺得整個程式好像是一個人寫出來的那樣。

63. 有可以作為宣傳亮點的Cool Feature麼？
要。這是增強團隊凝聚力、信心的。而且，“一俊遮百醜”，有亮點就可以掩蓋一些問題。這樣，對於客戶來說，會感覺產品從質量角度來說還是acceptable的。或者說，cool feature或者說亮點可以作為質量問題的一個事後彌補措施。

64. 儘可能縮短產品的啟動時間要這樣。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-142357/，如需轉載，請註明出處，否則將追究法律責任。

相關文章