4. 要求提交代碼前做Code Review,而開發(fā)人員不做,或敷衍了事,怎么辦?
如果每個開發(fā)人員都是積極主動的,Code Review的作用能落到實處。但如果不是呢?團(tuán)隊管理者需要一些手段促使其有效地進(jìn)行Code Review。首先,我們采用的Code Review有2種形式,一是Over-the-shoulder,也是2個人座在一起,一個人講,另一個人審查。二是用工具Code Collaborator來進(jìn)行。無論哪種形式,在提交代碼時,必須注明關(guān)于審查的信息,比如:審查者(Reviewer)的名字或?qū)彶樘枺≧eview ID,Code Collaborator自動生成),每天由一名專職人員來檢查Checklist中的每一條,看是否有人漏寫這些信息,如果發(fā)現(xiàn)會提醒提交的人補上。另外,某段提交的代碼出問題,提交者和審查者都要一起來解決出現(xiàn)的問題,以大限度避免審查過程敷衍了事。
博主Inovy在某個評論說的很形象:“木(沒)有賞罰的制度,是帶到廁所的報紙,看完可以用來擦屁股了。”沒有獎懲制度作保證,當(dāng)然上面的要求沒有什么效力。所以,當(dāng)有人經(jīng)常不審查提交,或?qū)彶闀r不負(fù)責(zé)任,它的績效評定會因此低一點,而績效的評分是跟每年工資漲落掛鉤的。說白了,可能某個人會因為多次被查出沒有做Code Review提交代碼,而到年底加薪時比別人少漲500塊錢。
5. 軟件研發(fā)到底需不需要文檔?
軟件研發(fā)需要文檔的起原可能有2種,一是比較原始的,需要文檔是為了當(dāng)開發(fā)人員離職后,企業(yè)需要接手的人能根據(jù)文檔了解他所接手的代碼或模塊的設(shè)計。二是較高層次的,企業(yè)遵從ISO9001質(zhì)量管理體系或CMMI。
對于第一種,根源可能來自于兩個方面:
- 原開發(fā)人員設(shè)計編碼水平不高,其代碼可讀性較差。
- 設(shè)計思想和代碼只有一個人了解,此人一旦離職,無人知道其細(xì)節(jié)。
在編碼前寫一些簡單的設(shè)計文檔,有助于理清思路,尤其是輔以一些UML圖,在交流時也是有好處的。但同時,我們也應(yīng)該提高開發(fā)人員的編碼水平增加其代碼的可讀性,比如增強其變量命名的可讀性、用一些被大家所了解的設(shè)計模式來替代按自己某些獨特思路編寫的代碼、增加和改進(jìn)注釋等等,以減少不必要的文檔。另外推行代碼的集體所有權(quán)(Collective Ownership),避免某些代碼只被一個人了解,這樣可以減少以此為目的而編寫的文檔。
對于第二種,情況有些復(fù)雜。接觸過敏捷開發(fā)的人都知道《敏捷宣言》中的“可以工作的軟件勝于面面俱到的文檔”。接觸過CMMI開發(fā)或者ISO9001質(zhì)量管理體系的人知道它們對文檔的要求是多么的高。它們看起來水火不相容。但是,它們的宗旨是一致的,即:構(gòu)建高質(zhì)量的產(chǎn)品。
對于敏捷,使用手寫用戶故事來記錄需求和優(yōu)先級的方法,以及在白板上寫畫的非正式設(shè)計,是不能通過ISO9001的審核的,但當(dāng)把它們復(fù)印、拍照、增加序號、保存后,可以通過審核。每次都是成功的Daily Build和Auto Test報告無法證明它們是否真正被執(zhí)行并真正成功,所以不能通過ISO9001的審核。但添加一個斷言失敗(類似assert(false)的斷言)的測試后,則可以通過審核。
CMMI與敏捷也是互補的,前者告訴組織在總體條款上做什么,但是沒有說如何去做,后者是一套佳實踐。SCRUM之類的敏捷方法也被引入過那些已通過CMMI5級評估的組織。很多企業(yè)忘記了終目標(biāo)是改進(jìn)他們構(gòu)建軟件及遞交產(chǎn)品的方式,相反,它們關(guān)注于填寫按照CMMI文檔描述的假想的缺陷,卻不關(guān)心這些變化是否能改進(jìn)過程或產(chǎn)品。
所以敏捷開發(fā)在過程中只編寫夠用的文檔,和以“信息的溝通、符合性的證據(jù)以及知識共享”作為主要目標(biāo)的質(zhì)量體系文檔要求并不矛盾。在實踐中,我們可以按以下方法做,在實現(xiàn)SCRUM的同時,符合審核和評估的要求:
- 制作格式良好的、被細(xì)化的、被保存的和能跟蹤的Backlog。復(fù)印和照片同樣有效。
- 將監(jiān)管需要的文檔工作也放入Backlog。除了可以確保它們不被忘記,還能使監(jiān)管要求的成本是可見的。
- 使用檢查列表,以向?qū)徍藛T或評估員證明活動已執(zhí)行。團(tuán)隊對“完成”的定義(Definition of “Done”)可以很容易轉(zhuǎn)變?yōu)橐环輽z查列表。
- 使用敏捷項目管理工具。它其實是開發(fā)程序和記錄的電子呈現(xiàn)方式。
總而言之,軟件研發(fā)需要文檔(但文檔的形式可以是多種多樣的,用Word寫的文字式的文件是文檔,用Visio畫的UML圖也是文檔,保存在Quality Center中的測試用例也是文檔),同時我們只需寫夠用的文檔。
6. 當(dāng)有開發(fā)人員在開發(fā)過程中遇到難題,工作無法繼續(xù),因而拖延進(jìn)度,怎么解決?