在软件企业实施敏捷和CMMI的绩效管理方法(2)

　　在这个过程中，产品项目团队与质量管理团队互相促进和推动，尽力朝着融合产品开发和质量管理的要求前进，最终我们在CMMI认证的最短极限时间内通过了认证。但通过认证不是我们追求产品质量的终极目标，在执行质量管理体系过程中发现的问题、项目组面临的成本、进度、文档压力带来的情绪困惑等。一直推动我们进行更多质量管理方法及工具的研究。

　　其中，业界热议的敏捷开发一直给项目研发团队带来极大的诱惑，比如SCRUM，提倡频繁运用“检查-调整”周期，加速创造更具价值的软件。项目管理使用产品Backlog和 SprintBacklog，按照迭代，以Burndown图管理项目进度，不需要编写繁杂的项目管理过程文档，而是强调从控制到授权、从契约到合作、从文档到代码的工作模式转变，整个项目管理过程由Sprint计划会议、Scrum简会、Sprint评审会议和Sprint回顾会议组成。所有的实践围绕着一个迭代、增量的过程骨架。

　　我个人认为这是项目管理过程域全力围绕工程过程域的过程框架，并没有考虑项目管理过程域的资产追踪、知识传承和数据分析，以及支持过程域。我们需要警惕作为Scrum核心、也是Scrum团队强大生产力的基础-对团队处理和解决问题能力的检验、识别及持续改进。而Scrum是敏捷管理的一种实践框架，只定义了高层次的信息系统开发项目的管理流程，不涉及具体开发方法、人员的有效沟通技巧等，仍然需要其它领域相关理论及技能的补充。

　　关于项目计划，CMMI提出了建立和维护涉及项目范围、估算、项目生命周期、工作量、成本、进度、风险、数据、资源、所需知识和技能、利益相关者的全面的计划;而敏捷开发只聚焦在了产品和Sprint的任务分解及工作量估算，作为项目管理的最小单元-任务：Sprint任务细分标准为每项耗时约4~16 小时，超时视为尚未恰当界定的任务。Scrum提倡使用经验性过程方法控制软件开发项目：经验性过程控制方法的三大支柱是可见性、检查及适应，适用于复杂问题处理;预定义过程控制不适用于复杂问题处理，往往造成对不合格产品进行大量昂贵的返工。

　　CMMI注重前期的计划、设计及跟踪管理，敏捷注重任务细分、迭代快速执行，前者更注重文档，后者更注重软件，在不可能抛开CMMI的前提下，本着求同存异的原则，我个人认为，CMMI与敏捷开发最终都要求有一个详细的任务分解文件，旨在统一项目所有相关人员对项目任务的一致认识。虽然细分任务的要求一致，但CMMI和敏捷对达到细分任务的过程要求不同。

　　在细分任务的过程中，SCRUM提倡召开Sprint计划会议，通过头脑风暴的方式，将一个月左右的迭代任务细化到4~16小时的单个任务颗粒度，形成项目的详细月度迭代任务计划。在这个过程中所有的项目成员应该已经无意识的、但却自然而然的运用了CMMI项目管理过程域的实践要求，考虑了资源、人员技能、项目风险、利益相关者、进度、成本、数据等很多方面，只是不像CMMI要求的必须形成文档。所以不管哪种项目管理模式，团队最终都要形成一个极详细的项目任务计划。这应该是两者的共识。也是项目管理团队极力要达到的目标。

　　因为两者形成项目任务计划采用的方式和流程不同，除了详细任务分解计划，使用CMMI过程框架的质量管理体系必须规定若干附加的计划文档，比如：工作量估算文件、进度估算文件、费用估算文件、进度计划、风险计划、质量保证计划、度量计划、资源计划、培训计划、配置管理计划、测试计划、关键依赖关系、评审计划等等。但CMMI同样没有提供实践这些方面的专业方法及工具。作为实施CMMI的公司来讲，文档的繁简程度要靠公司自己根据组织及项目实际情况制定，并建立一些针对特殊情况免于执行的剪裁偏离指南。这应该是为敏捷之路提供了一个方便之门。

　　而且据SCRUM大师肯.施瓦伯及CMM的开发者之一马克.波尔克的分析，SCRUM能够满足CMML2的全部KPA及CMML3的大部分KPA，没有满足的KPA主要是处理实践方法制度化的部分。因此SCRUM减轻了项目和组织的文档及管理成本。

　　由此看来，在SCRUM提倡将任务颗粒度控制在4-16小时的基础上，通过4-8小时的Sprint计划会议讨论时间，运用CMMI提倡的估算、项目生命周期、工作量、成本、进度、风险、数据、资源、所需知识和技能、利益相关者等多角度考虑问题，制定出项目组为期一个月的迭代周期的任务目标，并在 Sprint计划会议上同时附加产生格式简洁的风险、成本、估算等文件，积极的减轻项目组文档负担，充分讨论项目组任务列表，与所有成员达成共识。从而可以为项目迭代周期的顺利完成打好可控的项目计划基础。

原文转自：http://www.ltesting.net