基于CMMI的敏捷开发过程文档裁剪

最近一直在忙，今天对于上次说的问题做补充。纯属个人一点小看法，只抛砖而已，希望能引玉。文章只针对于中小型企业，且没有成熟的开发过程企业来说，所以裁剪的文档参考CMMI3级的标准文档。

 

关于敏捷开发和CMMI的管理大家都各有心得，我就不在对各自具体管理做阐述了，紧紧针对文档裁剪说点看法，首先敏捷开发强调的核心的东西是交流，但对于当今的项目开发来说，个人交流恰恰是个难点，做开发的基本上都是能不交流就不交流，开发进度紧张时更是如此，在项目中开发和测试交流起来更加困难，这两部分人员有部分工作在某种意义上是敌对的。更何况再把客户加入交流的名单之内，因此适当的文档可以避免项目资源流失和踢皮球的做法。

 

1.       项目开始的估算是需要的，但可以简化估算的过程和文档，例如各种估算标准和报告。

 

测试计划可以简化，不必给出详细的项目过程计划，因为敏捷开发的项目过程几乎是没法计划的。

 

2.       Walkthrough的会议要经常开，里程碑会议文档可以裁剪，项目监督控制文档可以裁剪。但项目周报需要。

 

3.       集成项目管理文档可以裁剪。因为很多项目coding完成后，基本上也就完成了，集成的观念在很多项目过程中都被忽略，基本上很少有集成管理，集成测试的具体实施，结项报告需要。可以作为经验总结放到公司的配置管理服务器上作为以后对该项目查询问题的一个文件材料。

 

4.       基线建立文档可以裁剪，配置审计等相关配置管理文档可以裁剪。

 

5.       风险管理相关文档可以裁剪为一个风险管理一览表文档进行跟踪管理。

 

6.       如果公司有独立的PPQA人员，过程和产品质量保证的检查可以保持不变，但如果没有独立人员，该部分可以裁剪，但概要设计，和详细设计不能裁剪，最少也要出来一个文档，虽然需求变化对这两个文档改变较大，这两个文档可以避免开发人员流动带来的项目交接问题，还能为测试提供依据，需求变更如果管理得当，总的来有利大于弊，还需要对开发概要设计，详细设计文档，编码进行Review和交叉审查。

 

7.       度量部分可以裁剪，因为度量项需要根据项目开发过程中的各种文档和人员来搜集度量的数据，没有了文档度量数据可靠性没有可信度，所以可以裁剪。

 

8.       决策分析和解决方案可以裁剪，决策和解决方案可以放到walkthrough会议中讨论。

 

9.       需求变更相关文档不能裁剪，并且应该加大需求变更管理力度，因为敏捷开发强调的是对变化的快速反应，而实际项目中因为各种原因客户和项目人员交流不够，而测试人员和开发人员，客户交流更不够，所以难以达到敏捷开发的对变化快速响应这一核心价值。因此应加大需求变更的管理力度，相关文档不能裁剪。

 

10.   需求管理相关文档可以裁剪，例如需求开发指南，需求开发文件等。敏捷开发的核心价值就包含与客户的交流重于合同约束，而与客户交流就涉及到方方面面的问题，所以要注重多交流，迭代的需求调研，不断挖掘潜在需求。因此需求调研的各种文档可以裁剪，但应该清晰记录客户访谈记录分析表，最后必须给出一份基本需求规格说明书。

 

11.   产品集成的计划，环境检查列表，报告可以裁剪，但接口列表不能裁剪，且应该对其进行交叉审查。

 

12.   测试阶段，测试计划可以裁剪为一个简单的文档，测试用例不要裁剪，因为如果项目都是一个人做测试可以考虑将测试用例裁剪，改为测试操作过程记录。但如果多个人参与，同一个人的测试操作记录重用性很差，所以多人参与测试的项目测试用例最好不要裁剪，Bug跟踪管理可以用Bug管理工具实现，测试报告不可以裁剪。

 

13.   OPF，OPD过程域相关文档可以裁剪，因为没有任何可靠数据可以追寻，文档没有实在意义。

 

14.   OT和SM相关的文档可以根据实际情况适当裁剪。

转载于:https://www.cnblogs.com/hliq/archive/2011/05/06/2087170.html