登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 行业 > IT > 借鉴SCRUM方法,对软件维护类开发任务进行项目化管理

借鉴SCRUM方法,对软件维护类开发任务进行项目化管理

返回>

2019年01月11日    作者:乔东    来源:微信公众号“IT管理工匠”

A-A+

  维护类开发任务


  在企业中存在着大量这样的开发需求,需求比较简单、软件修改的影响范围比较小、工作量不是很大、开发周期也相对比较短,而且这些需求之间的关联度往往都不高,很分散,每个小需求就解决一个很具体的问题,可以单独完成开发并投产,比如增加一个简单查询的功能、增加一个非关键的数据输入项、改变一下统计计算公式等。在许多企业中往往将此类需求的开发任务称为维护类开发任务,相应的需求称为维护类需求。与之相对的是项目类开发任务,往往相对规模较大、周期较长、复杂度较高,需要按照正式的项目管理流程进行立项及跟踪,管理成本比较高。相比之下,维护类开发任务的管理就会采用成本相对比较低的管理方式。


  维护类开发任务需要相应的管理机制


  尽管如此,大量的、琐碎的的小需求,从数量上往往会大大超过项目类开发任务。这些需求来源分散、每个需求开发任务所涉及的软件系统也各不相同,开发周期也不同,如果把这些散碎的需求强行纳入一个或几个正式的项目进行统一管理,不仅管理成本高,而且面对这些关联度不高的需求,企业的项目管理流程很难发挥应有的作用,但如果对这类开发任务不进行有效的管理、协调,软件开发任务计划、软件版本管理,都将是灾难性的,仅凭技术开发人员的经验和自觉性来保证,沟通起来像在自由市场中吆喝,特别是当存在多对多的“需求-系统”矩阵关系时,管理的难度实际上要比明确的立项项目还要大。同时,开发任务要求的频繁变动也导致软件版本难以维护,那么真的很难保障软件质量、安全生产。“总是处在崩溃的边缘”,一位曾经的银行核心系统维护负责人如是说,而且这方面也确实出现过一些实际问题,所以各机构都非常希望找到一种管理方式,在企业中针对性的建立维护类开发任务的管理机制,对维护类开发任务加强管理,使各项工作能够有序开展,真正做到忙而不乱,同时最大限度地提供灵活性。


  “投产窗口”是重要的基础


  在《运用“投产窗口”掌握需求交付“脉搏”》一文中,详细说明了“投产窗口”对整个研发节奏的影响,每个“投产窗口”实际对应着一个交付批次的业务需求和系统版本,开发、测试、投产等各个阶段的工作都是围绕这个批次的业务需求和目标版本而展开的。“投产窗口”的管理机制,为维护类开发任务的项目化管理提供了重要前提。


  将每个“投产窗口”的目标批次视为一个维护类项目


  针对每个“投产窗口”所要交付的业务需求及相应的系统目标版本作为一个目标批次,将每个批次的交付过程视作一个项目——维护类项目,无论是月度版本还是季度版本抑或每周的版本,确定这个批次将包含的需求范围和所涉及的系统范围作为这个维护类项目的项目范围,将“投产窗口”及其相应的“测试窗口”等时间要求作为这一维护类项目的里程碑时间要求,然后跟踪管理这一维护类项目,直至所有业务需求及相应的软件版本交付完成,该维护类项目即告结束。在这一机制下,各维护类项目对应着各个预设的月度或季度“投产窗口”,例如每年有12个对应月度“投产窗口”的维护类项目,或者是4个对应季度“投产窗口”的维护类项目,为了提高对市场需求的响应速度,也有一些是对应每周“投产窗口”的维护类项目。


  参考SCRUM建立维护类项目管理流程

  

  对于维护类开发任务的管理,是比较适合引入敏捷的。基于按照一定的交付周期设定的维护类项目,按照优先级(不一定是需求提出的顺序)从大量的需求中选择出将要交付实现的需求纳入相应的维护类项目,并对这一批次的需求开发过程按照项目的方式进行跟踪管理,组织多需求、跨系统的开发、测试与投产。


  实践中结合具体实际,只是借鉴了SCRUM的思路,做了一些变通。在各批次目标版本对应的维护类项目中,其结束时间都是由目标版本的交付时间(“投产窗口”)决定的,但其项目起始时间往往会根据情况有很大不同,有些维护类开发任务需要在未来的某个(不是下一个)目标版本中实现,或者有的维护类需求所需的开发周期比较长会跨越一个批次的周期,那么对应未来某个批次目标版本的维护类项目就相当于是提前启动了,而不是一定要等到前一批次的维护类项目结束后才能启动。此时,同一软件系统的不同批次目标版本之间,还是存在着并行开发,需要按照并行开发的分支策略进行管理的。


  不要按照系统维度设置维护类项目


  在一些软件研发部门中,为了利用项目管理的方式来管理维护类开发任务,就采用按软件系统来预设维护类项目的方式,在“系统”维度上,在年初基于每个或每组系统设立一个长期的维护类项目,项目周期是从年初到年底。维护类项目最初没有明确的工作范围,随着开发需求的陆续确定,相应系统的开发任务逐渐增加,维护类项目开始有了工作内容——本系统或本组系统被分配的开发任务。配合着需求排期,维护类项目中的工作任务也就有了相应的时间要求,相应的资源也就可以分配到这些任务上,相应的成本也就可以进行核算。从项目管理角度来说,这种维护类项目也是可以管理的,而且还可以按照项目管理的流程,方便的解决各种预算审批和结算的手续。


  但是从面向需求交付的管理角度来说,这种方式是存在致命问题的。软件研发是面向需求交付的,在立项项目中,项目的主要目标也是交付业务需求,这一点在《矩阵式研发管理中如何加强需求维度的管理》一文中做了反复强调。在这种按照系统维度设立的维护类项目中,需求往往已经不再是完整的业务需求,而主要是分解到该系统上的具体软件需求,对于业务需求交付完整性的保证,对于业务需求导致的跨系统的协同管理,通过基于系统维度的维护类项目是难以达到的。

责任编辑:王兴钊

标签:软件
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3

京公网安备 11010202007990号


PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设