基于CMMI与SCRUM的任务颗粒度划分

志存高远 · 发表于 2012-8-20 18:18:59

   在产品项目开发实施及准备认证的过程中，项目开发团队与质量管理团队的观点碰撞冲突不断。项目开发团队希望集中精力处理技术细节、研究产品开发，质量管理团队按照CMMIL3对质量管理体系的要求，建立项目管理过程中需要形成的大量项目文档模板，并跟踪检查项目文档记录，两个团队工作目标、方向及重点不同，成为双方讨论的焦点。
   从产品项目团队的角度来看：项目组不但要完成待发布版本的软件程序及软件工程文档，还要根据CMMIL3对质量管理体系的要求出具项目过程文档，工作范围增加了，又增加了项目管理过程可视化、质量管理文档化的要求，进度和成本也必须进行相应的调整。项目组需要在产品发布的市场压力、有限的资源限制下，减少项目开发的工作内容，按照CMMIL3要求做好项目及开发过程资料整理，实现知识的传承、文档的可追踪及度量数据的分析。这个调整本身导致项目经理、度量员、配置管理员、质量保证员在正常软件工程领域之外，必须要有额外的负担，形成项目管理过程域及支持过程域所要求的文档。其中项目管理过程域涉及项目计划、项目监督和控制、风险管理三个过程；支持过程域涉及配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案四个过程。
   在这个过程中，产品项目团队与质量管理团队互相促进和推动，尽力朝着融合产品开发和质量管理的要求前进，最终我们在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计划会议上同时附加产生格式简洁的风险、成本、估算等文件，积极的减轻项目组文档负担，充分讨论项目组任务列表，与所有成员达成共识。从而可以为项目迭代周期的顺利完成打好可控的项目计划基础。

网络转载

上一篇：升级产品的研发流程
下一篇：改进与模型无关，与内心相连