你們的項目組使用源代碼管理工具了么？
采用ClearCase進行源代碼管理，同時啟用開發，測試，集成三個分支，對于Bug分支根據版本實際情況確認是否啟用。
?
你們的項目組使用缺陷管理系統了么？
使用ClearQuest管理缺陷和變更
?
你們的測試組還在用Word寫測試用例么？
采用TestManager寫測試用例和管理測試用例，必要配合Excel進行。
?
你們的項目組有沒有建立一個門戶網站？
項目有專門的討論工作室。
?
你們的項目組用了你能買到最好的工具么？
能夠買到。主要是VS.Net和PL/SQl Developer.其它輔助工具全部用開源工具。如打包采用Nant，反翻譯采用Reflector，單元測試采用Nunit.
?
你們的程序員工作在安靜的環境里么？
是的，有獨立安靜空間。
?
你們的員工每個人都有一部電話么？
一般兩人一部電話，還可以通過RTX進行溝通。
?
你們每個人都知道出了問題應該找誰么？
知道
?
你遇到過有人說“我以為…”么？
有時候會遇到，但情況不多。
?
你們的項目組中所有的人都坐在一起么？
沒有。全部座來分開，通過RTX即時通訊，郵件，電話進行溝通。
?
你們的進度表是否反映最新開發進展情況？
有及時準確的進度表，但不是每個項目成員都很容易看到。進度表有專門的基線和里程碑的定義。
?
你們的工作量是先由每個人自己估算的么？
不是開發人員自己估算，是有項目的估算小組進行估算。估算時候會適當考慮個體差異。
?
你們的開發人員從項目一開始就加班么？
基本不會。
?
你們的項目計劃中Buffer Time是加在每個小任務后面的么？
不是，總體進度有5-10%的余量。
?
值得再多花一些時間，從95%做到100%好值得，非常值得。
尤其當項目后期人困馬乏的時候，要堅持。這會給產品帶來質的區別。
?
登記新缺陷時，是否寫清了重現步驟？
是的，有明確重現步驟描述，并配合屏幕截圖。
?
寫新代碼前會把已知缺陷解決么？
要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新代碼。
?
你們對缺陷的輕重緩急有事先的約定么？
缺陷有驗證性和解決時限的明確定義。
?
你們對意見不一的缺陷有三國會議么？
有，意見不一致的時候由項目的CCB進行統一討論和決策。
?
所有的缺陷都是由登記的人最后關閉的么？
是的，由BUG提交的測試人員來驗證關閉。
?
你們的程序員厭惡修改老的代碼么？
厭惡是正常的。解決方法是組織Code Review，單獨留出時間來。XP也是一個方法。
?
你們項目組有Team Morale Activity么？
有，一般一兩個月一次，一般在項目版本發布后。
?
你們項目組有自己的Logo么？
有系統的Logo,項目組沒有Logo.
?
你們的員工有印有公司Logo的T-Shirt么？
沒有。
?
總經理至少每月參加次項目組會議要的。
有。一般在需要參加的時候參加。
?
你們是給每個Dev開一個分支么？
沒有，只有一個共有的開發分支，容易管理些。
?
有人長期不Check-In代碼么？
不會，最長不會超過1周，一般要求是當天修改只要能夠編譯通過都要Check In.
?
在Check-In代碼時都填寫注釋了么？
有，Check-In的時候系統會自動對應到相關的活動或變更。
?
有沒有設定每天Check-In的最后期限？
不是特別明確，需要改進。
?
你們能把所有源碼一下子編譯成安裝文件嗎？
是的，通過Nant自動編譯和打包，所以項目很容易進行Daily Build.
?
你們的項目組做每日編譯么？
跟測試策略有關系，當項目計劃選擇的策略是每日構建時候就必須進行。
?
你們公司有沒有積累一個項目風險列表？
有，并在每周例會上對分析進行分析。
?
設計越簡單越好越簡單越好。
設計時候多一句話，將來可能就帶來無窮無盡的煩惱。應該從一開始就勇敢的砍。這叫scope management。
?
盡量利用現有的產品、技術、代碼千萬別什么東西都自己Coding。BizTalk和Sharepoint就是最好的例子，有這兩個作為基礎，可以把起點提高很多。或者可以盡量多用現成的Control之類的。或者盡量用XML，而不是自己去Parse一個文本文件；盡量用RegExp，而不是自己從頭操作字符串，等等等等。這就是“軟件復用”的體現。
?
你們會隔一段時間就停下來夯實代碼么？
沒有，沒有專門的這種時間。
?
你們的項目組每個人都寫Daily Report么？
沒有，當要求項目成員都有工作日志記錄。成員每天工作會反饋到Project的工作日志上面。
?
你們的項目經理會發出Weekly Report么？
有項目周報。內容包括目前進度，可能的風險，質量狀況，各種工作的進展等。
?
你們項目組是否至少每周全體開會一次？
每周項目都召開項目周例會。
?
你們項目組的會議、討論都有記錄么？
有，有專門的會議記錄人員。
?
其他部門知道你們項目組在干什么么？
要發一些Newsflash給整個大組織。Show your team’s value。否則，當你坐在電梯里面，其他部門的人問：“你們在干嘛”，你回答“ABC項目”的時候，別人全然不知，那種感覺不太好。
?
通過Email進行所有正式溝通
是的。Email的好處是免得抵賴。但也要避免矯枉過正，最好的方法是先用電話和當面說，然后Email來確認。
?
為項目組建立多個Mailing Group
郵件只有一個Group,但RTX及時通訊有多個Group.
?
每個人都知道哪里可以找到全部的文檔么？
知道。應該每個人都知道。這叫做知識管理（Knowledge Management）。最方便的就是把文檔放在一個集中的File Share，更好的方法是用Sharepoint。
?
你做決定、做變化時，告訴大家原因了么？
要告訴大家原因。Empower team member的手段之一是提供足夠的information，這是MSF一開篇的幾個原則之一。的確如此，tell me why是人之常情，tell me why了才能有understanding。中國人做事喜歡搞限制，限制信息，似乎能夠看到某一份文件的人就是有身份的人。大錯特錯。權威、權力，不在于是不是能access information/data，而在于是不是掌握資源。
?
Stay agile and expect change 要這樣。
需求一定會變的，已經寫好的代碼一定會被要求修改的。做好心理準備，對change不要抗拒，而是expect change。
?
你們有沒有專職的軟件測試人員？
項目有專門得測試人員，一般配置比例在1比6個左右開發人員。
?
你們的測試有一份總的計劃來規定做什么和怎么做么？這就是Test Plan。要不要做性能測試？要不要做Usability測試？什么時候開始測試性能？測試通過的標準是什么？用什么手段，自動的還是手動的？這些問題需要用Test Plan來回答。
有專門得測試計劃。
?
你是先寫Test Case然后再測試的么？
有專門得測試用例，要求測試必須根據測試用例進行。
?
你是否會為各種輸入組合創建測試用例？
這點項目組強調了測試數據得準備和路徑分支得分析，這塊做得不是很好待改進。
?
你們的程序員能看到測試用例么？
可以，但開發人員不會特別去關注這些測試用例，一般根據軟件需求自測。
?
你們是否隨便抓一些人來做易用性測試？
沒有，需求開發階段已經有標準得DEMO
?
你對自動測試的期望正確么？
不期望自動測試，LoadRunner只用來錄制簡單得冒煙測試腳本。
?
你們的性能測試是等所有功能都開發完才做的么？
是的。需要改進。
?
你注意到測試中的殺蟲劑效應了么？
蟲子有抗藥性，Bug也有。發現的新Bug越來越少是正常的。這時候，最好大家交換一下測試的area，或者用用看其他工具和手法，就又會發現一些新bug了。
?
你們項目組中有人能說出產品的當前整體質量情況么？
要有。當老板問起這個產品目前質量如何，Test Lead/Manager應該負責回答。
?
你們有單元測試么？
有單元測試，但和自測，黑盒測試界限不明確。項目成員自測關注重點放到黑盒測試上了而忽略了百盒的分支，條件和代碼的覆蓋。
?
你們的程序員是寫完代碼就扔過墻的么？
不會必須自測通過。寫好一塊程序以后，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有Test Release Document的說法，程序太爛的話，測試有權踢回去。
?
你們的程序中所有的函數都有輸入檢查么？
不要。雖然說做輸入檢查是write secure code的要點，但不要做太多的輸入檢查，有些內部函數之間的參數傳遞就不必檢查輸入了，省點功夫。同樣的道理，未必要給所有的函數都寫注釋。寫一部分主要的就夠了。
?
產品有統一的錯誤處理機制和報錯界面么？
有，在項目中已經復用。最好能有統一的error message，然后每個error message都帶一個error number。這樣，用戶可以自己根據error number到user manual里面去看看錯誤的具體描述和可能原因，就像SQL Server的錯誤那樣。同樣，ASP.NET也要有統一的Exception處理。可以參考有關的Application Block。
?
你們有統一的代碼書寫規范么？
有專門的編碼規范文檔
?
你們的每個人都了解項目的商業意義么？
要。這是Vision的意思。別把項目只當成工作。有時候要想著自己是在為中國某某行業的信息化作先驅者，或者時不時的告訴team member，這個項目能夠為某某某國家部門每年節省多少多少百萬的納稅人的錢，這樣就有動力了。平凡的事情也是可以有個崇高的目標的。
?
產品各部分的界面和操作習慣一致么？
基本一直，還在不斷改進中。
?
有可以作為宣傳亮點的Cool Feature么？
有。工作流，權限模型，多層分布式架構，隊列使用，自我開發的數據訪問組件都是可以宣傳的亮點。
?
盡可能縮短產品的啟動時間要這樣。
軟件啟動時間（Start-Up time）是客戶對性能好壞的第一印象。
?
不要過于注重內在品質而忽視了第一眼的外在印象程序員容易犯這個錯誤：太看重性能、穩定性、存儲效率，但忽視了外在感受。而高層經理、客戶正相反。這兩方面要兼顧，協調這些是PM的工作。
?
你們根據詳細產品功能說明書做開發么？
要這樣。要有設計才能開發，這是必須的。設計文檔，應該說清楚這個產品會怎么運行，應該采取一些講故事的方法。設計的時候千萬別鉆細節，別鉆到數據庫、代碼等具體實現里面去，那些是后面的事情，一步步來不能著急。
?
開始開發和測試之前每個人都仔細審閱功能設計么？
有專門的同行評審和多人復審。
?
Dev工作的劃分是單純縱向或橫向的么？
不能單純的根據功能模塊分，或者單純根據表現層、中間層、數據庫層分。我推薦這么做：首先根據功能模塊分，然后每個“層”都有一個Owner來Review所有人的設計和代碼，保證consistency。
項目是根據功能來分的，按層來分還需要進一步實踐。
?
你們的程序員寫程序設計說明文檔么？
有設計文檔輸出，但用處不大，更多設計內容直接體現在代碼注釋中。
?
你在招人面試時讓他寫一段程序么？
沒有，一般以問為主。
?
你們有沒有技術交流講座？
有，每個項目版本都有1到2次技術交流，培訓和討論。
?
你們的程序員都能專注于一件事情么？
要讓程序員專注一件事。例如說，一個部門有兩個項目和10個人，一種方法是讓10個人同時參加兩個項目，每個項目上每個人都花50%時間；另一種方法是5個人去項目A，5個人去項目B，每個人都100%在某一個項目上。我一定選后面一種。這個道理很多人都懂，但很多領導實踐起來就把屬下當成可以任意拆分的資源了。
?
你們的程序員會夸大完成某項工作所需要的時間么？
會的，這是常見的，尤其會在項目后期夸大做某個change所需要的時間，以次來抵制change。解決的方法是坐下來慢慢磨，磨掉程序員的逆反心理，一起分析，并把估算時間的顆粒度變小。
比較少跨大的情況，因為跨大必須要說明明確的理由。
?
75. 盡量不要用Virtual Heads 最好不要用Virtual Heads。
Virtual heads意味著resource is not secure，shared resource會降低resource的工作效率，容易增加出錯的機會，會讓一心二用的人沒有太多時間去review spec、review design。一個dedicated的人，要強過兩個只能投入50%時間和精力的人。我是吃過虧的：7個part time的tester，發現的Bug和干的活，加起來還不如兩個full-time的。參見第73條。73條是針對程序員的，75條是針對Resource Manager的。