国产v亚洲v日韩v欧美v中文_国产一区亚洲二区_欧美女人一级黄色录像_真实的国产乱xxxx在线

軟件百科
聯(lián)系我們
聯(lián)系電話

135 2295 6919

135 2295 6919

公司主站W(wǎng)ebsite:

www.controlmeasurement.com

公司主站
電子郵箱

電子郵箱:

qykh2009@163.com

公司地址

公司地址:

北京市朝陽(yáng)區(qū)亞運(yùn)村天創(chuàng)世緣B2座30整層

Software     軟件百科

北京軟件開(kāi)發(fā)公司:不可忽視的細(xì)節(jié)

分享到:

類(lèi)別:軟件開(kāi)發(fā)訪問(wèn)量:1737編輯:admin 日期:2024-11-01 20:58:00

    


來(lái)源:   北京軟件開(kāi)發(fā)公司

    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è)專(zhuān)門(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分鐘就搞定。買(mǎi)不起SPS 2003可以用WSS (Windows Sharepoint Service)。
  5. 你們的項(xiàng)目組用了你能買(mǎi)到最好的工具么?
  應(yīng)該用盡量好的工具來(lái)工作。比如,應(yīng)該用VS.NET而不是Notepad來(lái)寫(xiě)C#。用Notepad寫(xiě)程序多半只是一種炫耀。但也要考慮到經(jīng)費(fèi),所以說(shuō)是“你能買(mǎi)到最好的”。
  6. 你們的程序員工作在安靜的環(huán)境里么?
  需要安靜環(huán)境。這點(diǎn)極端重要,而且要保證每個(gè)人的空間大于一定面積。
  7. 你們的員工每個(gè)人都有一部電話么?
  需要每人一部電話。而且電話最好是帶留言功能的。當(dāng)然,上這么一套帶留言電話系統(tǒng)開(kāi)銷(xiāo)不小。不過(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,F(xiàn)unction 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ò)程。這類(lèi)似于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)卡丁車(chē)等等,一定要有。不要剩這些錢(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”。如果往高處拔,這也算做“配置審計(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之類(lèi)的。或者盡量用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è)诟陕铩?,你回答“ABC項(xiàng)目”的時(shí)候,別人全然不知,那種感覺(jué)不太好。
  41. 通過(guò)Email進(jìn)行所有正式溝通
  Email的好處是免得抵賴(lài)。但也要避免矯枉過(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)有專(zhuān)職的軟件測(cè)試人員?
  要有專(zhuān)職測(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)該自己先跑一跑。雖然有了專(zhuān)門(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處理??梢詤⒖加嘘P(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ò)分的把軟件制造看成流水線、車(chē)間。參見(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ě)一段程序么?
  要的。我最喜歡讓人做字符串和鏈表一類(lèi)的題目。這種題目有很多循環(huán)、判斷、指針、遞歸等,既不偏向過(guò)于考算法,也不偏向過(guò)于考特定的API。
  72. 你們有沒(méi)有技術(shù)交流講座?
  要的。每一兩個(gè)禮拜搞一次內(nèi)部的Tech Talk或者Chalk Talk吧。讓組員之間分享技術(shù)心得,這筆花錢(qián)送到外面去培訓(xùn)劃算。
  73. 你們的程序員都能專(zhuān)注于一件事情么?
  要讓程序員專(zhuān)注一件事。例如說(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的。

來(lái)源:北京乾元坤和,北京軟件開(kāi)發(fā)公司,北京網(wǎng)站建設(shè)公司,OA系統(tǒng)開(kāi)發(fā),ERP系統(tǒng)開(kāi)發(fā) ,CRM系統(tǒng)制作 QQ號(hào):2725110947    聯(lián)系電話:010-51246210 ; 15699913471