資源描述：
《“走出項(xiàng)目管理的泥沼”之“研發(fā)規(guī)范”.doc》由會員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在應(yīng)用文檔-天天文庫。
1、“走出項(xiàng)目管理的泥沼”之“研發(fā)規(guī)范” 最近讀《IT經(jīng)理世界》，刊登了這樣一篇文章：《下班后你的公司還值多少錢？》，文章開頭講了這么一個小故事：一位軟件公司的老總感慨地說：“做軟件公司，最痛苦的事情是下班之后，你發(fā)現(xiàn)自己的公司除了幾臺電腦外，幾乎什么也沒有了。因?yàn)楣咀钪靛X的資產(chǎn)都在每個程序員的腦子里，這些人一旦離開，公司的資產(chǎn)就等于零”?！ ∵@不是偶爾的現(xiàn)象，目前還有不少公司，時刻擔(dān)心某些員工的流失，直接導(dǎo)致工作的延續(xù)和完善出現(xiàn)斷層，影響公司收益。難道腦力勞動就只存在于頭腦中嗎？如果真是這樣，人員流動率相當(dāng)高的IT行業(yè)，怎么可能做長壽公司？只能是曇花一現(xiàn)而已。不，不應(yīng)該是這樣的
2、?！ ∫陨鲜龅能浖緸槔?，裝在程序員腦子里的公司重要資產(chǎn)有哪些？軟件包括源代碼，發(fā)布版本，和相關(guān)資料，這些資產(chǎn)通過一定的操作，都可以轉(zhuǎn)化成為固化資產(chǎn)。如果研發(fā)人員的文檔與代碼是一致的，那么交接工作會順暢得多；如果前期的設(shè)計文檔足夠詳細(xì)和清晰地表達(dá)了上層設(shè)計的思路，那么下一級設(shè)計或者實(shí)現(xiàn)不會因?yàn)槿藛T變更而受到較大影響；如果隨機(jī)資料與發(fā)布版本一一對應(yīng)，并且完備地描述其細(xì)節(jié)，那么設(shè)計人員的離開并不能增加太多維護(hù)工作的難度。然而，這些都是如果。在一家國內(nèi)知名公司的辦公區(qū)內(nèi)，墻上貼著這樣的條幅：“人人都痛恨別人不寫文檔，人人自己都不愿意寫文檔！”這就是原因，導(dǎo)致腦力勞動成果總是保留于無形
3、?！ ≡趺唇鉀Q這個問題？“沒有規(guī)矩，無以成方圓”，制定研發(fā)規(guī)范，將無形的腦力勞力勞動顯式化。研發(fā)規(guī)范，主要是為了細(xì)化研發(fā)過程，便于流程度量、改進(jìn)和控制。除了上述的留住公司的無形資產(chǎn)之外，另有一個重要的目的：規(guī)范化不同人員的表達(dá)方式，減少不必要的信息溝通，提高交流的效率。 如何制定研發(fā)規(guī)范？各個公司根據(jù)各自的經(jīng)驗(yàn)，和參考國內(nèi)國際相關(guān)標(biāo)準(zhǔn)，都會有自己的一整套系統(tǒng)規(guī)范。如軟件項(xiàng)目，從項(xiàng)目立項(xiàng)階段提交項(xiàng)目立項(xiàng)報告，可行性報告；到系統(tǒng)設(shè)計方案，詳細(xì)設(shè)計報告，測試規(guī)程，以及各種評審報告等等。其模板也多種多樣，很多介紹項(xiàng)目管理的書籍或者文章上，還專門有介紹如何編寫某某報告的指導(dǎo)，不可謂不詳細(xì)
4、?！ ∫?guī)定了這樣的一套研發(fā)規(guī)范，是不是研發(fā)過程真的就規(guī)范起來，總裁不必再擔(dān)心下班后的公司不值錢呢？很多公司不是這樣。這是因?yàn)檠邪l(fā)規(guī)范不僅僅包括這些各種各樣的“文檔模板”，更重要的是操作規(guī)范。例如，不同研發(fā)階段應(yīng)該完成什么樣的操作、出具什么樣的文檔才算結(jié)束？這些操作又有什么樣的要求？這就是流程規(guī)范。所以完善的研發(fā)規(guī)范應(yīng)該由一系列的流程組成，每個流程包括一些相關(guān)操作，和輸入輸出?！ ∪鐖D1所示，我們以軟件中的編碼階段為例，詳細(xì)介紹其研發(fā)規(guī)范?！ ?．?流程輸入 軟件的編碼階段，比學(xué)校里的學(xué)生想象的復(fù)雜得多。首先需要輸入詳細(xì)設(shè)計文檔，這是上一個流程，“詳細(xì)設(shè)計階段”的輸出產(chǎn)物。而編碼
5、規(guī)范，則按照不同的語言組織，規(guī)范某種語言的使用和交流方式，最常見的要求是規(guī)定其注釋的百分比。這兩種規(guī)范一般是公司規(guī)范?！ ?．?復(fù)查 編碼完成之后，需要作者進(jìn)行復(fù)查工作，如果發(fā)現(xiàn)故障，需要立即修復(fù)故障；否則可以進(jìn)入下一步操作?！ ≡诰幋a之后加入的復(fù)查階段，讓很多人不理解，因?yàn)榇蠹覜]有在編譯之前再讀一遍自己代碼的習(xí)慣，總是希望編譯器來代替自己查錯。不錯，已經(jīng)有許多改進(jìn)的編譯器可以查出全部的語法故障，和一部分語義故障；但是最好的編譯器也只能查出85%的故障，所以為了盡量早地發(fā)現(xiàn)故障，作者自己的復(fù)查是有價值的。妄圖借助后續(xù)的同行評審來彌補(bǔ)沒有自己復(fù)查的人，忘記了自己才是作品的構(gòu)思者，
6、才最清楚自己想要表達(dá)什么，這是任何別人代替不了的?！ 〔贿^，如果研發(fā)規(guī)范在操作這一步驟中面臨很大的推進(jìn)困難，也可以調(diào)整此操作到編譯之后，但是取消是不提倡的。 復(fù)查也同樣需要規(guī)范的指導(dǎo)，即代碼復(fù)查表。這張表的制定需要更多的實(shí)時性，它一般是根據(jù)軟件團(tuán)隊(duì)對某一種語言的運(yùn)用程度而定制的，甚至個人也可以根據(jù)個人掌握情況來調(diào)整。檢查表的有效程度，可以用此階段的發(fā)現(xiàn)故障數(shù)量，與整個研發(fā)過程的故障數(shù)量之比度量，因此它依賴于后期的質(zhì)量檢測，如果在前期制定時有經(jīng)驗(yàn)豐富的工程師參與，將會降低延遲修復(fù)故障而造成的成本。 從圖中可以看出，代碼復(fù)查可以進(jìn)行多次，理論上依賴于作者對完成代碼的質(zhì)量信心，不過
7、一般更依賴于作者的勤勉和負(fù)責(zé)程度，需要團(tuán)隊(duì)領(lǐng)導(dǎo)和質(zhì)量經(jīng)理經(jīng)常督促?！ ?．?編譯 這是個沒有爭議的操作，基本上所有的代碼版本庫的入庫要求中，都包括了“代碼編譯通過”。這個階段同時需要提交《程序配置清單》，為了同行評審的方便，有時還需要在每個代碼文件的屬性中標(biāo)明，是新建的文件還是修改的文件。 4．代碼的同行評審 這是CMM的要求，按照PR（同行評審）的流程規(guī)范進(jìn)行，并且修改故障和提交評審報告，以及故障記錄。同行評審一般不需要循環(huán)進(jìn)行，除非代碼質(zhì)量很差，一次評審不能按照要求通過
