分享

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

 ekylin 2012-04-10

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

作者:刘维秀
2010-07-27

中间件公司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计划会议上同时附加产生格式简洁的风险、成本、估算等文件,积极的减轻项目组文档负担,充分讨论项目组任务列表,与所有成员达成共识。从而可 以为项目迭代周期的顺利完成打好可控的项目计划基础。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多