解，這樣可以減少以此為目的而編寫(xiě)的文檔。
對(duì)于第二種，情況有些復(fù)雜。接觸過(guò)敏捷開(kāi)發(fā)的人都知道《敏捷宣言》中的“可以工作的軟件勝于面面俱到的文檔”。接觸過(guò)CMMI開(kāi)發(fā)或者ISO9001質(zhì)量管理體系的人知道它們對(duì)文檔的要求是多么的高。它們看起來(lái)水火不相容。但是，它們的宗旨是一致的，即：構(gòu)建高質(zhì)量的產(chǎn)品。
對(duì)于敏捷，使用手寫(xiě)用戶(hù)故事來(lái)記錄需求和優(yōu)先級(jí)的方法，以及在白板上寫(xiě)畫(huà)的非正式設(shè)計(jì)，是不能通過(guò)ISO9001的審核的，但當(dāng)把它們復(fù)印、拍照、增加序號(hào)、保存后，可以通過(guò)審核。每次都是成功的Daily Build和Auto Test報(bào)告無(wú)法證明它們是否真正被執(zhí)行并真正成功，所以不能通過(guò)ISO9001的審核。但添加一個(gè)斷言失敗(類(lèi)似assert(false)的斷言)的測(cè)試后，則可以通過(guò)審核。
CMMI與敏捷也是互補(bǔ)的，前者告訴組織在總體條款上做什么，但是沒(méi)有說(shuō)如何去做，后者是一套最佳實(shí)踐。SCRUM之類(lèi)的敏捷方法也被引入過(guò)那些已通過(guò)CMMI5級(jí)評(píng)估的組織。很多企業(yè)忘記了最終目標(biāo)是改進(jìn)他們構(gòu)建軟件及遞交產(chǎn)品的方式，相反，它們關(guān)注于填寫(xiě)按照CMMI文檔描述的假想的缺陷，卻不關(guān)心這些變化是否能改進(jìn)過(guò)程或產(chǎn)品。
所以敏捷開(kāi)發(fā)在過(guò)程中只編寫(xiě)夠用的文檔，和以“信息的溝通、符合性的證據(jù)以及知識(shí)共享”作為主要目標(biāo)的質(zhì)量體系文檔要求并不矛盾。在實(shí)踐中，我們可以按以下方法做，在實(shí)現(xiàn)SCRUM的同時(shí)，符合審核和評(píng)估的要求：
- 制作格式良好的、被細(xì)化的、被保存的和能跟蹤的Backlog。復(fù)印和照片同樣有效。
- 將監(jiān)管需要的文檔工作也放入Backlog。除了可以確保它們不被忘記，還能使監(jiān)管要求的成本是可見(jiàn)的。
- 使用檢查列表，以向?qū)徍藛T或評(píng)估員證明活動(dòng)已執(zhí)行。團(tuán)隊(duì)對(duì)“完成”的定義(Definition of “Done”)可以很容易轉(zhuǎn)變?yōu)橐环輽z查列表。
- 使用敏捷項(xiàng)目管理工具。它其實(shí)就是開(kāi)發(fā)程序和記錄的電子呈現(xiàn)方式。
總而言之，軟件研發(fā)需要文檔(但文檔的形式可以是多種多樣的，用Word寫(xiě)的文字式的文件是文檔，用Visio畫(huà)的UML圖也是文檔，保存在Quality Center中的測(cè)試用例也是文檔)，同時(shí)我們只需寫(xiě)夠用的文檔。
6. 當(dāng)有開(kāi)發(fā)人員在開(kāi)發(fā)過(guò)程中遇到難題，工作無(wú)法繼續(xù)，因而拖延進(jìn)度，怎么解決?
這也是個(gè)常遇到的問(wèn)題。如果管理者對(duì)于某個(gè)工程師的具體問(wèn)題進(jìn)行指導(dǎo)，就會(huì)陷入過(guò)度微觀管理的境地。我們需要找到宏觀解決辦法。
一，我們基于Scrum的“團(tuán)隊(duì)有共同的目標(biāo)”這一規(guī)則，利用前面提到的集體所有權(quán)，當(dāng)出現(xiàn)這些問(wèn)題時(shí)，用團(tuán)隊(duì)中所有可以使用的力量來(lái)幫助其擺脫困境，而不是任其他人袖手旁觀。當(dāng)然這里會(huì)牽扯到績(jī)效評(píng)定的問(wèn)題，比如：提供幫助的人會(huì)覺(jué)得，他的幫助無(wú)助于自己績(jī)效評(píng)定的提高，為什么要提供幫助。這需要人力資源部門(mén)在使用Scrum開(kāi)發(fā)的團(tuán)隊(duì)的績(jī)效評(píng)估中，盡量消除那些傾向個(gè)人的因素，還要包含團(tuán)隊(duì)協(xié)作的因素，廣泛聽(tīng)取個(gè)方面的意見(jiàn)，更頻繁地評(píng)估績(jī)效等等。
二，即使動(dòng)用所有可以使用的力量，如果某個(gè)難題真的無(wú)法逾越，為了減少不能按時(shí)交付的風(fēng)險(xiǎn)，產(chǎn)品負(fù)責(zé)人應(yīng)當(dāng)站出來(lái)，并有所作為。要么重新評(píng)估Backlog的優(yōu)先級(jí)，使無(wú)法繼續(xù)的Backlog遲一點(diǎn)交付，先做一些相對(duì)較低優(yōu)先級(jí)的Backlog，以保證整體交付時(shí)間不至于延長(zhǎng);要么減少部分功能，給出更多的時(shí)間去攻克難題?？傊庠郊夹g(shù)上難關(guān)會(huì)使團(tuán)隊(duì)的生產(chǎn)率下降，產(chǎn)品負(fù)責(zé)人必須作出取舍。
7. 有些開(kāi)發(fā)人員水平相對(duì)不高，如何保證他們的代碼質(zhì)量?
當(dāng)然首先讓較有經(jīng)驗(yàn)的人Review其要提交的代碼，這幾乎是所有管理者會(huì)做的事。除此之外，