最近一直在忙，今天對于上次說的問題做補充。純屬個人一點小看法，只拋磚而已，希望能引玉。文章只針對于中小型企業(yè)，且沒有成熟的開發(fā)過程企業(yè)來說，所以裁剪的文檔參考CMMI3級的標(biāo)準(zhǔn)文檔。

關(guān)于敏捷開發(fā)和CMMI的管理大家都各有心得，我就不在對各自具體管理做闡述了，緊緊針對文檔裁剪說點看法，首先敏捷開發(fā)強調(diào)的核心的東西是交流，但對于當(dāng)今的項目開發(fā)來說，個人交流恰恰是個難點，做開發(fā)的基本上都是能不交流就不交流，開發(fā)進度緊張時更是如此，在項目中開發(fā)和測試交流起來更加困難，這兩部分人員有部分工作在某種意義上是敵對的。更何況再把客戶加入交流的名單之內(nèi)，因此適當(dāng)?shù)奈臋n可以避免項目資源流失和踢皮球的做法。

1.       項目開始的估算是需要的，但可以簡化估算的過程和文檔，例如各種估算標(biāo)準(zhǔn)和報告。

測試計劃可以簡化，不必給出詳細的項目過程計劃，因為敏捷開發(fā)的項目過程幾乎是沒法計劃的。

2.       Walkthrough的會議要經(jīng)常開，里程碑會議文檔可以裁剪，項目監(jiān)督控制文檔可以裁剪。但項目周報需要。

3.       集成項目管理文檔可以裁剪。因為很多項目coding完成后，基本上也就完成了，集成的觀念在很多項目過程中都被忽略，基本上很少有集成管理，集成測試的具體實施，結(jié)項報告需要?？梢宰鳛榻?jīng)驗總結(jié)放到公司的配置管理服務(wù)器上作為以后對該項目查詢問題的一個文件材料。

4.       基線建立文檔可以裁剪，配置審計等相關(guān)配置管理文檔可以裁剪。

5.       風(fēng)險管理相關(guān)文檔可以裁剪為一個風(fēng)險管理一覽表文檔進行跟蹤管理。

6.       如果公司有獨立的PPQA人員，過程和產(chǎn)品質(zhì)量保證的檢查可以保持不變，但如果沒有獨立人員，該部分可以裁剪，但概要設(shè)計，和詳細設(shè)計不能裁剪，最少也要出來一個文檔，雖然需求變化對這兩個文檔改變較大，這兩個文檔可以避免開發(fā)人員流動帶來的項目交接問題，還能為測試提供依據(jù)，需求變更如果管理得當(dāng)，總的來有利大于弊，還需要對開發(fā)概要設(shè)計，詳細設(shè)計文檔，編碼進行Review和交叉審查。

7.       度量部分可以裁剪，因為度量項需要根據(jù)項目開發(fā)過程中的各種文檔和人員來搜集度量的數(shù)據(jù)，沒有了文檔度量數(shù)據(jù)可靠性沒有可信度，所以可以裁剪。

8.       決策分析和解決方案可以裁剪，決策和解決方案可以放到walkthrough會議中討論。

9.       需求變更相關(guān)文檔不能裁剪，并且應(yīng)該加大需求變更管理力度，因為敏捷開發(fā)強調(diào)的是對變化的快速反應(yīng)，而實際項目中因為各種原因客戶和項目人員交流不夠，而測試人員和開發(fā)人員，客戶交流更不夠，所以難以達到敏捷開發(fā)的對變化快速響應(yīng)這一核心價值。因此應(yīng)加大需求變更的管理力度，相關(guān)文檔不能裁剪。

10.   需求管理相關(guān)文檔可以裁剪，例如需求開發(fā)指南，需求開發(fā)文件等。敏捷開發(fā)的核心價值就包含與客戶的交流重于合同約束，而與客戶交流就涉及到方方面面的問題，所以要注重多交流，迭代的需求調(diào)研，不斷挖掘潛在需求。因此需求調(diào)研的各種文檔可以裁剪，但應(yīng)該清晰記錄客戶訪談記錄分析表，最后必須給出一份基本需求規(guī)格說明書。

11.   產(chǎn)品集成的計劃，環(huán)境檢查列表，報告可以裁剪，但接口列表不能裁剪，且應(yīng)該對其進行交叉審查。

12.   測試階段，測試計劃可以裁剪為一個簡單的文檔，測試用例不要裁剪，因為如果項目都是一個人做測試可以考慮將測試用例裁剪，改為測試操作過程記錄。但如果多個人參與，同一個人的測試操作記錄重用性很差，所以多人參與測試的項目測試用例最好不要裁剪，Bug跟蹤管理可以用Bug管理工具實現(xiàn)，測試報告不可以裁剪。

13.   OPF，OPD過程域相關(guān)文檔可以裁剪，因為沒有任何可靠數(shù)據(jù)可以追尋，文檔沒有實在意義。

14.   OT和SM相關(guān)的文檔可以根據(jù)實際情況適當(dāng)裁剪。