28、 你們每個(gè)人都知道出了問題應(yīng)該找誰么？
應(yīng)該知道。任何一個(gè)特性至少都應(yīng)該有一個(gè)所有者，當(dāng)然，所有者可以繼續(xù)指派給其他人。
29、你遇到過有人說“我以為…”么？
要消滅“我以為”。這個(gè)其實(shí)很復(fù)雜，也很難辦。但是這是在出現(xiàn)問題的時(shí)候推卸責(zé)任的一種說辭。既然不明確，那就讓問題或者責(zé)任明確起來。
30、 你們的進(jìn)度表是否反映最新開發(fā)進(jìn)展情況？
應(yīng)該反映。但是，應(yīng)該用Baseline的方法來管理進(jìn)度表：維護(hù)一份穩(wěn)定的Schedule，再維護(hù)一份最新更改。Baseline的方法也應(yīng)該用于其它的Spec。Baseline是變更管理里面的一個(gè)重要手段。
31、你們的工作量是先由每個(gè)人自己估算的么？
應(yīng)該讓每個(gè)人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務(wù)工期固定等。
32、 你們的開發(fā)人員從項(xiàng)目一開始就加班么？
不要這樣。不要一開始就搞疲勞戰(zhàn)。從項(xiàng)目一開始就加班，只能說明項(xiàng)目進(jìn)度不合理。當(dāng)然，一些對(duì)日軟件外包必須天天加班，那屬于剝削的范疇。
33、你們的項(xiàng)目計(jì)劃中Buffer Time是加在每個(gè)小任務(wù)后面的么？
不要。Buffer Time加在每個(gè)小任務(wù)后面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個(gè)Milestone或者checkpoint前面。這個(gè)緩沖對(duì)夯實(shí)代碼、總結(jié)、補(bǔ)充士氣都有作用。
34、寫新代碼前會(huì)把已知缺陷解決么？
要。每個(gè)人的缺陷不能超過10個(gè)或15個(gè)，否則必須先解決老的bug才能繼續(xù)寫新代碼。
35、你們的程序員厭惡修改老的代碼么？
厭惡是正常的。解決方法是組織Code Review，單獨(dú)留出時(shí)間來。XP也是一個(gè)方法。
36、你們會(huì)隔一段時(shí)間就停下來夯實(shí)代碼么？
要。最好一個(gè)月左右一次。這個(gè)需要拿出專門時(shí)間來進(jìn)行，消滅代碼中的一些隱藏的問題和一些不符合代碼規(guī)范的地方。
