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