CMMI与敏捷实践结合之我见-任务细分

2008 我公司通过了 CMMI L3 认证。在准备认证的产品项目开发实施过程中，项目开发团队与质量管理团队的冲突很尖锐，也很集中。项目开发团队希望集中精力处理技术细节、研究产品开发，质量管理团队按照 CMMI L3 对质量管理体系的要求，建立项目管理过程中需要形成的大量文档模板，并跟踪检查项目文档记录，两个团队工作目标、方向及重点不同，成为双方争执的焦点。

从产品项目团队的角度来看：项目组不但要完成待发布版本的软件程序及软件工程文档，还要根据 CMMI L3 对质量管理体系的要求出具项目过程文档，工作范围增加了，又增加了项目管理过程可视化、质量管理文档化的要求，进度和成本也必须进行相应的调整。项目组需要在产品发布的市场压力、有限的资源限制下，减少项目开发的工作内容，按照 CMMI L3 要求做好项目及开发过程资料整理，实现知识的传承、文档的可追踪及度量数据的分析。这个调整本身导致项目经理、度量员、配置管理员、质量保证员在正常软件工程领域之外，必须要有额外的负担，形成项目管理过程域及支持过程域所要求的文档。其中项目管理过程域涉及项目计划、项目检测和控制、风险管理三个过程；支持过程域涉及配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案四个过程。

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

其中，业界热议的敏捷开发一直给项目研发团队带来极大的诱惑，比如 SCRUM ，提倡频繁运用“检查 - 调整”周期，加速创造更具价值的软件。项目管理使用产品 Backlog 和 Sprint Backlog ，按照迭代，以 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 能够满足 CMM L2 的全部 KPA 及 CMM L3 的大部分 KPA ，没有满足的 KPA 主要是处理实践方法制度化的部分。因此 SCRUM 减轻了项目和组织的文档及管理成本。

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