?1.
你們的項(xiàng)目組使用源代碼管理工具了么？
???
應(yīng)該用。
VSS
、
CVS
、
PVCS
、
ClearCase
、
CCC/Harvest
、
FireFly
都可以。我的選擇是
VSS
。
?2.
你們的項(xiàng)目組使用缺陷管理系統(tǒng)了么？
???
應(yīng)該用。
ClearQuest
太復(fù)雜，我的推薦是
BugZilla
。
?3.
你們的測(cè)試組還在用
Word
寫(xiě)測(cè)試用例么？
?
不要用
Word
寫(xiě)測(cè)試用例（
Test Case
）。應(yīng)該用一個(gè)專門(mén)的系統(tǒng)，可以是
Test Manager
，也可以是自己開(kāi)發(fā)一個(gè)
ASP.NET
的小網(wǎng)站。主要目的是
Track
和
Browse
。
?4.
你們的項(xiàng)目組有沒(méi)有建立一個(gè)門(mén)戶網(wǎng)站？
要有一個(gè)門(mén)戶網(wǎng)站，用來(lái)放
Contact Info
、
Baselined Schedule
、
News
等等。推薦
Sharepoint Portal Server 2003
來(lái)實(shí)現(xiàn)，
15
分鐘就搞定。買不起
SPS 2003
可以用
WSS (Windows Sharepoint Service)
。
?5.
你們的項(xiàng)目組用了你能買到最好的工具么？
應(yīng)該用盡量好的工具來(lái)工作。比如，應(yīng)該用
VS.NET
而不是
Notepad
來(lái)寫(xiě)
C#
。用
Notepad
寫(xiě)程序多半只是一種炫耀。但也要考慮到經(jīng)費(fèi)，所以說(shuō)是
"
你能買到最好的
"
。
?
?6.
你們的程序員工作在安靜的環(huán)境里么？
需要安靜環(huán)境。這點(diǎn)極端重要，而且要保證每個(gè)人的空間大于一定面積。
?7.
你們的員工每個(gè)人都有一部電話么？需要每人一部電話。而且電話最好是帶留言功能的。當(dāng)然，上這么一套帶留言電話系統(tǒng)開(kāi)銷不小。不過(guò)至少每人一部電話要有，千萬(wàn)別搞得經(jīng)常有人站起來(lái)喊：
"
某某某電話
"
。《人件》里面就強(qiáng)烈譴責(zé)這種做法。
?8.
你們每個(gè)人都知道出了問(wèn)題應(yīng)該找誰(shuí)么？
應(yīng)該知道。任何一個(gè)
Feature
至少都應(yīng)該有一個(gè)
Owner
，當(dāng)然，
Owner
可以繼續(xù)
Dispatch
給其他人。
?9.
你遇到過(guò)有人說(shuō)
"
我以為
…"
么？
要消滅
"
我以為
"
。
Never assume anything
。
10.
你們的項(xiàng)目組中所有的人都坐在一起么？
需要。我反對(duì)
Virtual Team
，也反對(duì)
Dev
在美國(guó)、
Test
在中國(guó)這種開(kāi)發(fā)方式。能坐在一起就最好坐在一起，好處多得不得了。
11.
你們的進(jìn)度表是否反映最新開(kāi)發(fā)進(jìn)展情況？
應(yīng)該反映。但是，應(yīng)該用
Baseline
的方法來(lái)管理進(jìn)度表：維護(hù)一份穩(wěn)定的
Schedule
，再維護(hù)一份最新更改。
Baseline
的方法也應(yīng)該用于其它的
Spec
。
Baseline
是變更管理里面的一個(gè)重要手段。
12.
你們的工作量是先由每個(gè)人自己估算的么？
應(yīng)該讓每個(gè)人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務(wù)工期固定等。
13.
你們的開(kāi)發(fā)人員從項(xiàng)目一開(kāi)始就加班么？
不要這樣。不要一開(kāi)始就搞疲勞戰(zhàn)。從項(xiàng)目一開(kāi)始就加班，只能說(shuō)明項(xiàng)目進(jìn)度不合理。當(dāng)然，一些對(duì)日軟件外包必須天天加班，那屬于剝削的范疇。
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)持。這會(huì)給產(chǎn)品帶來(lái)質(zhì)的區(qū)別。
16.
登記新缺陷時(shí)，是否寫(xiě)清了重現(xiàn)步驟？
要。這屬于
Dev
和
Test
之間的溝通手段。面對(duì)面溝通需要，詳細(xì)填寫(xiě)
Repro Steps
也需要。
17.
寫(xiě)新代碼前會(huì)把已知缺陷解決么？
???
要。每個(gè)人的缺陷不能超過(guò)
10
個(gè)或
15
個(gè)，否則必須先解決老的
bug
才能繼續(xù)寫(xiě)新代碼。
18.
你們對(duì)缺陷的輕重緩急有事先的約定么？
必須有定義。
Severity
要分
1
、
2
、
3
，約定好：藍(lán)屏和
Data Lost
算
Sev 1
，
Function Error
算
Sev 2
，界面上的算
Sev 3
。但這種約定可以根據(jù)產(chǎn)品質(zhì)量現(xiàn)狀適當(dāng)進(jìn)行調(diào)整。
19.
你們對(duì)意見(jiàn)不一的缺陷有三國(guó)會(huì)議么？
???
必須要有。要有一個(gè)明確的決策過(guò)程。這類似于
CCB (Change Control Board)
的概念。
20.
所有的缺陷都是由登記的人最后關(guān)閉的么？
Bug
應(yīng)該由
Opener
關(guān)閉。
Dev
不能私自關(guān)閉
Bug
。
21.
你們的程序員厭惡修改老的代碼么？
厭惡是正常的。解決方法是組織
Code Review
，單獨(dú)留出時(shí)間來(lái)。
XP
也是一個(gè)方法。
22.
你們項(xiàng)目組有
Team Morale Activity
么？
每個(gè)月都要搞一次，吃飯、唱歌、
Outing
、打球、開(kāi)卡丁車等等，一定要有。不要剩這些錢(qián)。
23.
你們項(xiàng)目組有自己的
Logo
么？
要有自己的
Logo
。至少應(yīng)該有自己的
Codename
。
24.
你們的員工有印有公司
Logo
的
T-Shirt
么？
要有。能增強(qiáng)歸屬感。當(dāng)然，
T-Shirt
要做的好看一些，最好用
80
支的棉來(lái)做。別沒(méi)穿幾次就破破爛爛的。
25.
總經(jīng)理至少每月參加次項(xiàng)目組會(huì)議要的。
要讓
team member
覺(jué)得高層關(guān)注這個(gè)項(xiàng)目。
26.
你們是給每個(gè)
Dev
開(kāi)一個(gè)分支么？
反對(duì)。
Branch
的管理以及
Merge
的工作量太大，而且容易出錯(cuò)。
27.
有人長(zhǎng)期不
Check-In
代碼么？
不可以。對(duì)大部分項(xiàng)目來(lái)說(shuō)，最多兩三天就應(yīng)該
Check-In
。
28.
在
Check-In
代碼時(shí)都填寫(xiě)注釋了么？
要寫(xiě)的，至少一兩句話，比如
"
解決了
Bug No.225
（給
bug
編號(hào)）
"
。如果往高處拔，這也算做
"
配置審計(jì)
"
的一部分。
29.
有沒(méi)有設(shè)定每天
Check-In
的最后期限？
要的，要明確
Check-In Deadline
。否則會(huì)
Build Break
。
30.
你們能把所有源碼一下子編譯成安裝文件嗎？
要的。這是每日編譯（
Daily Build
）的基礎(chǔ)。而且必須要能夠做成自動(dòng)的。
31.
你們的項(xiàng)目組做每日編譯么？
當(dāng)然要做。有三樣?xùn)|西是軟件項(xiàng)目
/
產(chǎn)品開(kāi)發(fā)必備的：
1. bug management; 2. source control; 3. daily build
。
32.
你們公司有沒(méi)有積累一個(gè)項(xiàng)目風(fēng)險(xiǎn)列表？
要。
Risk Inventory
。否則，下個(gè)項(xiàng)目開(kāi)始的時(shí)候，又只能拍腦袋分析
Risk
了。
33.
設(shè)計(jì)越簡(jiǎn)單越好越簡(jiǎn)單越好。
設(shè)計(jì)時(shí)候多一句話，將來(lái)可能就帶來(lái)無(wú)窮無(wú)盡的煩惱。應(yīng)該從一開(kāi)始就勇敢的砍。這叫
scope management
。
34.
盡量利用現(xiàn)有的產(chǎn)品、技術(shù)、代碼千萬(wàn)別什么東西都自己
Coding
。
BizTalk
和
Sharepoint
就是最好的例子，有這兩個(gè)作為基礎(chǔ)，可以把起點(diǎn)提高很多。或者可以盡量多用現(xiàn)成的
Control
之類的。或者盡量用
XML
，而不是自己去
Parse
一個(gè)文本文件；盡量用
RegExp
，而不是自己從頭操作字符串，等等等等。這就是
"
軟件復(fù)用
"
的體現(xiàn)。
35.
你們會(huì)隔一段時(shí)間就停下來(lái)夯實(shí)代碼么？
要。最好一個(gè)月左右一次。傳言去年年初
Windows
組在
Stevb
的命令下停過(guò)一個(gè)月增強(qiáng)安全。
Btw
，
"
夯
"
這個(gè)字念
"hang"
，第一聲。
36.
你們的項(xiàng)目組每個(gè)人都寫(xiě)
Daily Report
么？
要寫(xiě)。五分鐘就夠了，寫(xiě)
10
句話左右，告訴自己小組的人今天我干了什么。一則為了溝通，二則鞭策自己（要是游手好閑一天，自己都會(huì)不好意思寫(xiě)的）。
37.
你們的項(xiàng)目經(jīng)理會(huì)發(fā)出
Weekly Report
么？
要。也是為了溝通。內(nèi)容包括目前進(jìn)度，可能的風(fēng)險(xiǎn)，質(zhì)量狀況，各種工作的進(jìn)展等。
38.
你們項(xiàng)目組是否至少每周全體開(kāi)會(huì)一次？
要。一定要開(kāi)會(huì)。程序員討厭開(kāi)會(huì)，但每個(gè)禮拜開(kāi)會(huì)時(shí)間加起來(lái)至少應(yīng)該有
4
小時(shí)。包括
team meeting, spec review meeting, bug triage meeting
。千萬(wàn)別大家悶頭寫(xiě)
code
。
39.
你們項(xiàng)目組的會(huì)議、討論都有記錄么？
會(huì)前發(fā)
meeting request
和
agenda
，會(huì)中有人負(fù)責(zé)主持和記錄，會(huì)后有人負(fù)責(zé)發(fā)
meeting minutes
，這都是
effective meeting
的要點(diǎn)。而且，每個(gè)會(huì)議都要形成
agreements
和
action items
。
40.
其他部門(mén)知道你們項(xiàng)目組在干什么么？
要發(fā)一些
Newsflash
給整個(gè)大組織。
Show your team's value
。否則，當(dāng)你坐在電梯里面，其他部門(mén)的人問(wèn)：
"
你們?cè)诟陕?/span>
"
，你回答
"ABC
項(xiàng)目
"
的時(shí)候，別人全然不知，那種感覺(jué)不太好。
41.
通過(guò)
Email
進(jìn)行所有正式溝通
Email
的好處是免得抵賴。但也要避免矯枉過(guò)正，最好的方法是先用電話和當(dāng)面說(shuō)，然后
Email
來(lái)確認(rèn)。
42.
為項(xiàng)目組建立多個(gè)
Mailing Group
如果在
AD+Exchange
里面，就建
Distribution List
。比如，我會(huì)建
ABC Project Core Team
，
ABC Project Dev Team
，
ABC Project All Testers
，
ABC Project Extended Team
等等。這樣發(fā)起
Email
來(lái)方便，而且能讓該收到
email
的人都收到、不該收到不被騷擾。
43.
每個(gè)人都知道哪里可以找到全部的文檔么？
應(yīng)該每個(gè)人都知道。這叫做知識(shí)管理（
Knowledge Management
）。最方便的就是把文檔放在一個(gè)集中的
File Share
，更好的方法是用
Sharepoint
。
44.
你做決定、做變化時(shí)，告訴大家原因了么？
要告訴大家原因。
Empower team member
的手段之一是提供足夠的
information
，這是
MSF
一開(kāi)篇的幾個(gè)原則之一。的確如此，
tell me why
是人之常情，
tell me why
了才能有
understanding
。中國(guó)人做事喜歡搞限制，限制信息，似乎能夠看到某一份文件的人就是有身份的人。大錯(cuò)特錯(cuò)。權(quán)威、權(quán)力，不在于是不是能
access information/data
，而在于是不是掌握資源。
45. Stay agile and expect change
要這樣。
需求一定會(huì)變的，已經(jīng)寫(xiě)好的代碼一定會(huì)被要求修改的。做好心理準(zhǔn)備，對(duì)
change
不要抗拒，而是
expect change
。
46.
你們有沒(méi)有專職的軟件測(cè)試人員？
要有專職測(cè)試。如果人手不夠，可以
peer test
，交換了測(cè)試。千萬(wàn)別自己測(cè)試自己的。
47.
你們的測(cè)試有一份總的計(jì)劃來(lái)規(guī)定做什么和怎么做么？
???
這就是
Test Plan
。要不要做性能測(cè)試？要不要做
Usability
測(cè)試？什么時(shí)候開(kāi)始測(cè)試性能？測(cè)試通過(guò)的標(biāo)準(zhǔn)是什么？用什么手段，自動(dòng)的還是手動(dòng)的？這些問(wèn)題需要用
Test Plan
來(lái)回答。
48.
你是先寫(xiě)
Test Case
然后再測(cè)試的么？
應(yīng)該如此。應(yīng)該先設(shè)計(jì)再編程、先
test case
再測(cè)試。當(dāng)然，事情是靈活的。我有時(shí)候在做第一遍測(cè)試的同時(shí)補(bǔ)上
test case
。至于先
test case
再開(kāi)發(fā)，我不喜歡，因?yàn)椴涣?xí)慣，太麻煩，至于別人推薦，那試試看也無(wú)妨。
49.
你是否會(huì)為各種輸入組合創(chuàng)建測(cè)試用例？
不要，不要搞邊界條件組合。當(dāng)心組合爆炸。有很多
test case
工具能夠自動(dòng)生成各種邊界條件的組合
--
但要想清楚，你是否有時(shí)間去運(yùn)行那么多
test case
。
50.
你們的程序員能看到測(cè)試用例么？
要。讓
Dev
看到
Test Case
吧。我們都是為了同一個(gè)目的走到一起來(lái)的：提高質(zhì)量。
51.
你們是否隨便抓一些人來(lái)做易用性測(cè)試？
要這么做。自己看自己寫(xiě)的程序界面，怎么看都是順眼的。這叫做審美疲勞
--
臭的看久了也就不臭了，不方便的永久了也就習(xí)慣了。
52.
你對(duì)自動(dòng)測(cè)試的期望正確么？
別期望太高。依我看，除了性能測(cè)試以外，還是暫時(shí)先忘掉
"
自動(dòng)測(cè)試
"
吧，忘掉
WinRunner
和
LoadRunner
吧。對(duì)于國(guó)內(nèi)的軟件測(cè)試的現(xiàn)狀來(lái)說(shuō)，只能
"
矯枉必須過(guò)正
"
了。
53.
你們的性能測(cè)試是等所有功能都開(kāi)發(fā)完才做的么？
不能這樣。性能測(cè)試不能被歸到所謂的
"
系統(tǒng)測(cè)試
"
階段。早測(cè)早改正，早死早升天。
54.
你注意到測(cè)試中的殺蟲(chóng)劑效應(yīng)了么？
蟲(chóng)子有抗藥性，
Bug
也有。發(fā)現(xiàn)的新
Bug
越來(lái)越少是正常的。這時(shí)候，最好大家交換一下測(cè)試的
area
，或者用用看其他工具和手法，就又會(huì)發(fā)現(xiàn)一些新
bug
了。
55.
你們項(xiàng)目組中有人能說(shuō)出產(chǎn)品的當(dāng)前整體質(zhì)量情況么？
要有。當(dāng)老板問(wèn)起這個(gè)產(chǎn)品目前質(zhì)量如何，
Test Lead/Manager
應(yīng)該負(fù)責(zé)回答。
56.
你們有單元測(cè)試么？
單元測(cè)試要有的。不過(guò)沒(méi)有單元測(cè)試也不是不可以，我做過(guò)沒(méi)有單元測(cè)試的項(xiàng)目，也做成功了
--
可能是僥幸，可能是大家都是熟手的關(guān)系。還是那句話，軟件工程是非常實(shí)踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會(huì)比另一些方法好，反之亦然。
57.
你們的程序員是寫(xiě)完代碼就扔過(guò)墻的么？
大忌。寫(xiě)好一塊程序以后，即便不做單元測(cè)試，也應(yīng)該自己先跑一跑。雖然有了專門(mén)的測(cè)試人員，做開(kāi)發(fā)的人也不可以一點(diǎn)測(cè)試都不做。微軟還有
Test Release Document
的說(shuō)法，程序太爛的話，測(cè)試有權(quán)踢回去。
58.
你們的程序中所有的函數(shù)都有輸入檢查么？
不要。雖然說(shuō)做輸入檢查是
write secure code
的要點(diǎn)，但不要做太多的輸入檢查，有些內(nèi)部函數(shù)之間的參數(shù)傳遞就不必檢查輸入了，省點(diǎn)功夫。同樣的道理，未必要給所有的函數(shù)都寫(xiě)注釋。寫(xiě)一部分主要的就夠了。
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ò)誤的具體描述和可能原因，就像
SQL Server
的錯(cuò)誤那樣。同樣，
ASP.NET
也要有統(tǒng)一的
Exception
處理。可以參考有關(guān)的
Application Block
。
60.
你們有統(tǒng)一的代碼書(shū)寫(xiě)規(guī)范么？
要有。
Code Convention
很多，搞一份來(lái)發(fā)給大家就可以了。當(dāng)然，要是有
FxCop
這種工具來(lái)檢查代碼就更好了。
61.
你們的每個(gè)人都了解項(xiàng)目的商業(yè)意義么？
要。這是
Vision
的意思。別把項(xiàng)目只當(dāng)成工作。有時(shí)候要想著自己是在為中國(guó)某某行業(yè)的信息化作先驅(qū)者，或者時(shí)不時(shí)的告訴
team member
，這個(gè)項(xiàng)目能夠?yàn)槟衬衬硣?guó)家部門(mén)每年節(jié)省多少多少百萬(wàn)的納稅人的錢(qián)，這樣就有動(dòng)力了。平凡的事情也是可以有個(gè)崇高的目標(biāo)的。
62.
產(chǎn)品各部分的界面和操作習(xí)慣一致么？
要這樣。要讓用戶覺(jué)得整個(gè)程序好像是一個(gè)人寫(xiě)出來(lái)的那樣。
63.
有可以作為宣傳亮點(diǎn)的
Cool Feature
么？
要。這是增強(qiáng)團(tuán)隊(duì)凝聚力、信心的。而且，
"
一俊遮百丑
"
，有亮點(diǎn)就可以掩蓋一些問(wèn)題。這樣，對(duì)于客戶來(lái)說(shuō)，會(huì)感覺(jué)產(chǎn)品從質(zhì)量角度來(lái)說(shuō)還是
acceptable
的。或者說(shuō)，
cool feature
或者說(shuō)亮點(diǎn)可以作為質(zhì)量問(wèn)題的一個(gè)事后彌補(bǔ)措施。
64.
盡可能縮短產(chǎn)品的啟動(dòng)時(shí)間要這樣。
軟件啟動(dòng)時(shí)間（
Start-Up time
）是客戶對(duì)性能好壞的第一印象。
65.
不要過(guò)于注重內(nèi)在品質(zhì)而忽視了第一眼的外在印象程序員容易犯這個(gè)錯(cuò)誤：太看重性能、穩(wěn)定性、存儲(chǔ)效率，但忽視了外在感受。而高層經(jīng)理、客戶正相反。這兩方面要兼顧，協(xié)調(diào)這些是
PM
的工作。
66.
你們根據(jù)詳細(xì)產(chǎn)品功能說(shuō)明書(shū)做開(kāi)發(fā)么？
要這樣。要有設(shè)計(jì)才能開(kāi)發(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)不能著急。
67.
開(kāi)始開(kāi)發(fā)和測(cè)試之前每個(gè)人都仔細(xì)審閱功能設(shè)計(jì)么？
要做。
Function Spec review
是用來(lái)統(tǒng)一思想的。而且，
review
過(guò)以后形成了一致意見(jiàn)，將來(lái)再也沒(méi)有人可以說(shuō)
"
你看，當(dāng)初我就是反對(duì)這么設(shè)計(jì)的，現(xiàn)在吃苦頭了吧
"
68.
所有人都始終想著
The Whole Image
么？要這樣。項(xiàng)目里面每個(gè)人雖然都只是在制造一片葉子，但每個(gè)人都應(yīng)該知道自己在制造的那片葉子所在的樹(shù)是怎么樣子的。我反對(duì)軟件藍(lán)領(lǐng)，反對(duì)過(guò)分的把軟件制造看成流水線、車間。參見(jiàn)第
61
條。
69. Dev
工作的劃分是單純縱向或橫向的么？
不能單純的根據(jù)功能模塊分，或者單純根據(jù)表現(xiàn)層、中間層、數(shù)據(jù)庫(kù)層分。我推薦這么做：首先根據(jù)功能模塊分，然后每個(gè)
"
層
"
都有一個(gè)
Owner
來(lái)
Review
所有人的設(shè)計(jì)和代碼，保證
consistency
。
70.
你們的程序員寫(xiě)程序設(shè)計(jì)說(shuō)明文檔么？
要。不過(guò)我聽(tīng)說(shuō)微軟的程序員
1999
年以前也不寫(xiě)。所以說(shuō)，寫(xiě)不寫(xiě)也不是絕對(duì)的，偷懶有時(shí)候也是可以的。參見(jiàn)第
56
條。
71.
你在招人面試時(shí)讓他寫(xiě)一段程序么？
要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多循環(huán)、判斷、指針、遞歸等，既不偏向過(guò)于考算法，也不偏向過(guò)于考特定的
API
。
72.
你們有沒(méi)有技術(shù)交流講座？
要的。每一兩個(gè)禮拜搞一次內(nèi)部的
Tech Talk
或者
Chalk Talk
吧。讓組員之間分享技術(shù)心得，這筆花錢(qián)送到外面去培訓(xùn)劃算。
73.
你們的程序員都能專注于一件事情么？
要讓程序員專注一件事。例如說(shuō)，一個(gè)部門(mén)有兩個(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)成可以任意拆分的資源了。
74.
你們的程序員會(huì)夸大完成某項(xiàng)工作所需要的時(shí)間么？
會(huì)的，這是常見(jiàn)的，尤其會(huì)在項(xiàng)目后期夸大做某個(gè)
change
所需要的時(shí)間，以次來(lái)抵制
change
。解決的方法是坐下來(lái)慢慢磨，磨掉程序員的逆反心理，一起分析，并把估算時(shí)間的顆粒度變小。
75.
盡量不要用
Virtual Heads
最好不要用
Virtual Heads
。
Virtual heads
意味著
resource is not secure
，
shared resource
會(huì)降低
resource
的工作效率，容易增加出錯(cuò)的機(jī)會(huì)，會(huì)讓一心二用的人沒(méi)有太多時(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
的。參見(jiàn)第
73
條。
73
條是針對(duì)程序員的，
75
條是針對(duì)
Resource Manager
的。