專案管理摘要

1. 你們的項目組使用原始程式碼控制工具了嗎？

應該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly、SVN都可以。我的選擇是CVS。svn（TortoiseSVN）也還蠻不錯的。

2. 你們的項目組使用缺陷管理系統了嗎？

應該用。ClearQuest太複雜，我的推薦是BugZilla。

3. 你們的測試組還在用Word寫測試案例嗎？

不要用Word寫測試案例（Test Case）。使用jbuilder運行junit測試架構。

4. 你們的項目組有沒有建立一個門戶網站？

要有一個門戶網站，用來放Contact Info、Baselined Schedule、News等等。

5. 你們每個人都知道出了問題應該找誰嗎？

應該知道。任何一個Feature至少都應該有一個Owner，當然，Owner可以繼續Dispatch給其他人。

6. 你遇到過有人說“我以為…”嗎？

要消滅“我以為”。Never assume anything。

7. 你們的項目組中所有的人都坐在一起嗎？

需要。反對Virtual Team，能坐在一起就最好坐在一起，好處多得不得了。

8. 你們的進度表是否反映最新開發進展情況？

應該反映。MS的project上的進度條。

9. 你們的工作量是先由每個人自己估算的嗎？

應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下指派。除非有其他原因，比如政治任務工期固定等。

10. 你們的開發人員從項目一開始就加班嗎？

不要這樣。不要一開始就搞疲勞戰。從項目一開始就加班，只能說明項目進度不合理。

11. 你們的專案計劃中Buffer Time是加在每個小任務後面的嗎？

不要。Buffer Time加在每個小任務後面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個Milestone或者checkpoint前面。

12. 值得再多花一些時間，從95%做到100%好值得，非常值得。

尤其當項目後期人困馬乏的時候，要堅持。這會給產品帶來質的區別。

13. 登記新缺陷時，是否寫清了重現步驟？

要。這屬於Dev和Test之間的溝通手段。面對面溝通需要，詳細填寫Repro Steps也需要。 所以規定了bugzilla上bug書寫的格式。

14. 你們對缺陷的輕重緩急有事先的約定嗎？

必須有定義。bugzilla可以協助我們達到這個目的。

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

Bug應該由BugAdmin關閉。現在由mulder負責。Dev不能私自關閉Bug。

16. 你們的程式員厭惡修改老的代碼嗎？

厭惡是正常的。解決方案是組織Code Review，單獨留出時間來。XP也是一個方法。

17. 你們項目組有自己的Logo嗎？

要有自己的Logo。至少應該有自己的Codename，CVS上的model名。

18. 有人長期不Check-In代碼嗎？

不可以。對大部分項目來說，最多兩三天就應該Check-In。

19. 在Check-In代碼時都填寫注釋了嗎？

要寫的，至少一兩句話，比如“解決了Bug No.225”。如果往高處拔，這也算做“配置審計”的一部分。

20. 你們能把所有源碼一下子編譯成安裝檔案嗎？

要的，參考realserver上的zhanhua項目。這是每日編譯（Daily Build）的基礎。而且必須要能夠做成自動的。有三樣東西是軟體項目/產品開發必備的：1. bug management; 2. source control; 3. daily build。

21. 設計越簡單越好越簡單越好。

設計時候多一句話，將來可能就帶來無窮無盡的煩惱。應該從一開始就勇敢的砍。這叫scope management。

22. 盡量利用現有的產品、技術、代碼千萬別什麼東西都自己Coding。我們用進階語言來開發就站在了一個很高的起點。

23. 項目組每個人都寫Weekly Report，也就是我們的工作周報。一則為了溝通，二則鞭策自己。

24. 專案經理還需要負責發出Weekly Report，內容包括目前進度，可能的風險，品質狀況，各種工作的進展等。

25. 你們項目組是否至少每周全體開會一次？

要。一定要開會。程式員討厭開會。包括team meeting, spec review meeting, bug triage meeting。千萬別大家悶頭寫code。 會中有人負責主持和記錄。

26. 其他部門知道你們項目組在幹什麼嗎？

要發一些Newsflash給整個大組織。Show your team’s value。否則，當你坐在電梯裡面，其他部門的人問：“你們在幹嘛”，你回答“ABC項目”的時候，別人全然不知，那種感覺不太好。

27. 通過MSN進行及時溝通，通過Email進行正式溝。

28. 每個人都知道哪裡可以找到全部的文檔嗎？

應該每個人都知道。通常情況下項目相關文檔都放在${cvs}\{項目}\doc檔案夾下。

29. 你做決定、做變化時，告訴大家原因了嗎？

要告訴大家原因。Empower team member的手段之一是提供足夠的information，這是MSF一開篇的幾個原則之一。的確如此，tell me why是人之常情，tell me why了才能有understanding。中國人做事喜歡搞限制，限制資訊，似乎能夠看到某一份檔案的人就是有身份的人。大錯特錯。權威、權力，不在於是不是能access information/data，而在於是不是掌握資源。

30. Stay agile and expect change 要這樣。

需求一定會變的，已經寫好的代碼一定會被要求修改的。做好心理準備，對change不要抗拒，而是expect change。

31. 你們有沒有專職的軟體測試人員？

要有專職測試。如果人手不夠，可以peer test，交換了測試。千萬別自己測試自己的。

32. 你們的程式員能看到測試案例嗎？

要。讓Dev看到Test Case吧。我們都是為了同一個目的走到一起來的：提高品質。只對需要的業務寫Test Case，不要Test Case滿天飛，是不是都加一個。還是那句話，軟體工程是非常實踐、非常工程、非常靈活的一套方法，某些方法在某些情況下是好方法，過尤不及。

33. 你們是否隨便抓一些人來做易用性測試？

要這麼做。自己看自己寫的程式介面，怎麼看都是順眼的。這叫做審美疲勞??臭的看久了也就不臭了，不方便的永久了也就習慣了。

34. 你對自動化的測試的期望正確嗎？

別期望太高。依我看，除了效能測試以外，還是暫時先忘掉“自動化的測試”吧，忘掉WinRunner和LoadRunner吧。

35. 你們的效能測試是等所有功能都開發完才做的嗎？

不能這樣。效能測試不能被歸到所謂的“系統測試”階段。早測早改正，早死早升天。

36. 你注意到測試中的殺蟲劑效應了嗎？

蟲子有抗藥性，Bug也有。發現的新Bug越來越少是正常的。這時候，最好大家交換一下測試的area，或者用用看其他工具和手法，就又會發現一些新bug了。

37. 你們項目組中有人能說出產品的當前整體品質情況嗎？

要有。當老闆問起這個產品目前品質如何，Test Lead/Manager應該負責回答。

38. 你們的程式員是寫完代碼就扔過牆的嗎？

大忌。寫好一塊程式以後，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有Test Release Document的說法，程式太爛的話，測試有權踢回去。

39. 你們的程式中所有的函數都有輸入檢查嗎？

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

40. 產品有統一的錯誤處理機制和報錯介面嗎？

要有。最好能有統一的error message，也就是tomcat中聲明的errorpage。

41. 需要有統一的代碼書寫規範。

42. 你們的每個人都瞭解項目的商業意義嗎？

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

43. 產品各部分的介面和操作習慣一致嗎？

要這樣。要讓使用者覺得整個程式好像是一個人寫出來的那樣。

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

軟體啟動時間（Start-Up time）是客戶對效能好壞的第一印象。所以發布版本要帶有jsp的先行編譯功能。

45. 不要過於注重內在品質而忽視了第一眼的外在印象程式員容易犯這個錯誤：太看重效能、穩定性、儲存效率，但忽視了外在感受。而高層經理、客戶正相反。

46. 你們根據詳細產品功能說明書做開發嗎？

要這樣。所以我們有了RED（需求文檔）和SDD（設計文檔）。

47. 測試之前每個人都仔細審閱功能設計嗎？

要做。所以除了測試計劃中附帶項目的簡易功能說明文檔，相當於簡化版的使用者手冊。

48. 所有人都始終想著The Whole Image嗎？要這樣。項目裡面每個人雖然都只是在製造一片葉子，但每個人都應該知道自己在製造的那片葉子所在的樹是怎麼樣子的。我反對軟體藍領，反對過分的把軟體製造看成流水線、車間。

49. Dev工作的劃分是單純縱向或橫向的嗎？

我們現在是按功能模組劃分的。

50. 你在招人面試時讓他寫一段程式嗎？

要的。我最喜歡讓人做字串和鏈表一類的題目。這種題目有很多迴圈、判斷、指標、遞迴等，既不偏向過於考演算法，也不偏向過於考特定的API。

51. 你們有沒有技術交流講座？

要的。周會時進行內部的Tech Talk或者Chalk Talk，讓組員之間分享技術心得。分享是一種快樂。這方面huson就做得很好。

52. 你們的程式員都能專註於一件事情嗎？

要讓程式員專註一件事。例如說，一個部門有兩個項目和10個人，一種方法是讓10個人同時參加兩個項目，每個項目上每個人都花50%時間；另一種方法是5個人去項目A，5個人去項目B，每個人都100%在某一個項目上。我一定選後面一種。這個道理很多人都懂。

53. 你們的程式員會誇大完成某項工作所需要的時間嗎？

會的，這是常見的，尤其會在項目後期誇大做某個change所需要的時間，以次來抵制change。解決的方法是坐下來慢慢磨，磨掉程式員的逆反心理，一起分析，並把估算時間的顆粒度變小。