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