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