思步网

标题: 基于CMMI与SCRUM的任务颗粒度划分 [打印本页]

作者: 志存高远 时间: 2012-8-20 18:18
标题: 基于CMMI与SCRUM的任务颗粒度划分
   在产品项目开发实施及准备认证的过程中，项目开发团队与质量管理团队的观点碰撞冲突不断。项目开发团队希望集中精力处理技术细节、研究产品开发，质量管理团队按照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计划会议上同时附加产生格式简洁的风险、成本、估算等文件，积极的减轻项目组文档负担，充分讨论项目组任务列表，与所有成员达成共识。从而可以为项目迭代周期的顺利完成打好可控的项目计划基础。

网络转载

作者: 风清云闲 时间: 2012-8-20 19:19
有点意思，先mark，回头仔细看。

作者: Szerate 时间: 2013-4-25 21:00
看起来不错

作者: 太阳雪下 时间: 2013-5-17 09:11
很有见地的探讨，先收藏着~

作者: 笑烦_lxf 时间: 2013-12-9 14:22
很有借鉴意义，先收藏了，谢谢楼主。

作者: 炎帝 时间: 2014-8-3 18:45
很有借鉴意义，先收藏了，谢谢楼主。

作者: 时橘桅- 时间: 2015-1-23 18:34
有空一起交流一下。

作者: 抑制 时间: 2015-2-2 07:06
没人回帖。。。我来个吧！

作者: 吻泪 时间: 2015-2-24 17:11
这么强,支持楼主，佩服

作者: 暗恋过 时间: 2016-2-24 11:11
路过的帮顶

作者: ζ那场婚礼 时间: 2016-5-25 11:43
很有见地的探讨，先收藏着~

作者: 青年先锋队 时间: 2016-5-25 16:09
学习ing...

作者: 〆╰☆╮King 时间: 2016-6-28 18:48
好帖是需要鼓励的~

作者: 心隨你動。 时间: 2018-2-27 11:37
支持，赞一个

作者: 美国甜心 时间: 2018-4-8 13:27
还不错哦，如果再能多分享一些就perfect了！

作者: 向鈤葵の微笑。 时间: 2018-11-26 09:32
确实不错，顶先

作者: -时光礼记 时间: 2019-7-10 21:52
其实，很多情况下都是这样的，习惯就好。

作者: 炊烟 时间: 2019-9-2 08:37
前排支持下了哦~

作者: dhui_19 时间: 2019-9-18 09:47
好帖是需要鼓励的~

作者: 温暖忧伤 时间: 2019-10-19 16:27
很有借鉴意义，先收藏了，谢谢楼主。

作者: 醉爱i 时间: 2019-10-23 14:28
其实，很多情况下都是这样的，习惯就好。

作者: bt就是b里有个t 时间: 2019-10-27 19:49
这么强,支持楼主，佩服

作者: 心机 时间: 2020-2-23 15:16
看帖要回，回帖才健康，在踩踩，楼主辛苦了！

作者: 没有糖吃的孩子 时间: 2020-4-8 16:42
鼎力支持！！

作者: 正经i 时间: 2020-6-25 19:47
看了LZ的帖子，我只想说一句很好很强大！

作者: 月考不愁！ 时间: 2020-7-24 15:11
很有见地的探讨，先收藏着~

作者: 兰汀 时间: 2021-5-5 21:07
这么强,支持楼主，佩服

作者: 妸嗳のㄝ亾 时间: 2021-8-11 10:42
看起来好像不错的样子

欢迎光临思步网 (http://www.step365.com/)