标签:研发管理 范围与时间 信息透明 多项目 redmine
这是研发范围和时间“信息透明化”系列的第三篇文章,在《研发范围和时间的“信息透明化”之Redmine统一平台》中我们讨论了信息透明化的一种实现平台Redmine,在《研发范围和时间的“信息透明化”之协作与流程》中我们对如何基于一个产品/项目和一套信息管理平台进行信息透明化管理的协作与流程做了详细阐述。对研发信息透明化而言,现实中情况可能会比较复杂:
本文主要针对以上两种情况对现有协作与流程模型进行扩展,还是使用Redmine作为主要实现工具,但基本的思路和模式同样适用于其他各种平台。
多项目多平台下协作流程涉及的角色没有变化,主要包括:
在工具平台上,我们可以使用多个具体的信息化工具来实现团队协作。本文中我们假定使用Redmine和Quality Center作为我们主要的研发过程管理工具:
其中Redmine关注与研发范围的透明,而Quality Center关注与系统缺陷的透明。相较于在《研发范围和时间的“信息透明化”之协作与流程》单独使用Redmine进行研发范围和系统缺陷的透明,这两者通过互相配合构成了研发过程的闭环。使用两种不同平台可能是因为历史原因、对工具专业性的要求,或者是团队组织结构上研发部门、质量保证部门等职能部门内部的考虑,而具体工具可能也不限于Redmine、Quality Center或者其他类如Jira等各种信息平台。
另外,作为整个流程的闭环管理,以下工具通常作为辅助:
在多项目环境下,目标版本面向客户和用户,作为服务交付的阶段性成果和依据推动项目实施,并在院方现场、项目线、产品线、运营线和研发测试线之间达成统一认识。目标版本由项目生命周期下的版本号和发布机制下的版本类别组合以形成唯一的对内/对外版本信息。
1)项目生命周期下的版本号
项目生命周期下版本号的统一格式为X.X.X,其中第一位表示系统主版本号(区分是否正式上线、项目阶段等),第二位表示系统有重大功能调整,第三位表示系统有微小改动和优化。
按项目生命周期,具体可分为两种类型:
2)发布机制下的版本类别
按发布机制,目标版本可以分为三种类型:
多项目环境下涉及的研发线和项目线是一对多的关系,即一个研发团队要面临的是多个项目的并行研发工作。从两条线的协作关系而言,我们要找到一个共同视图确保大家对项目的计划和工作达成统一。我们可以采用一下策略:
1)OneNote
OneNote作为项目线和研发线在时间上的统一视图,采用以下策略进行应用:
2)Redmine
Redmine作为研发线的主视图,采用以下策略进行应用:
2. 工作模式
项目线-研发线的协作从确定项目某个具体目标版本开始,到该目标版本验证完成作为结束,即围绕项目的目标版本的生命周期展开工作。结合OneNote和Redmine两大工具平台,项目线-研发线工作开展模式的流程图如下,通过这一工作模式首先确保项目线和研发线上的信息透明,其中背景为红色的流程需要通过会议进行协商和交互:
1) 根据项目情况确定目标版本(PM)
PM根据项目的具体实施情况确定下一次该项目需要发布的目标版本和范围,并把目标版本和期望完成时间录入OneNote项目日历。
2) OneNote上协商确定目标版本(PM+DEV)
通过OneNote,PM和DEV协商确定目标版本的完成时间,在完成的范围和时间上达成平衡和一致。
3) 针对目标版本召开需求评审会议(PM+DEV+QA)
根据目标版本下的需求范围召开需求评审会议
4) Redmine上创建系统版本号并录入Feature(PM)
根据需求评审会议结果,PM在Redmine上录入系统版本号(格式为VX.X.X),并创建相应的Feature
5) Redmine上创建Task并完成开发(DEV)
DEV把Redmine上Feature拆分成Task并完成开发工作
6) 验证目标版本完成情况(PM/PM+QA)
对于预览版,PM验证目标版本的完成情况;对于提测版,QA根据既定的内部测试标准流程主导目标版本的测试工作,PM进行配合
7) OneNote上更新目标版本完成状态(PM)
PM根据目标版本的验证结果在OneNote上设置目标版本的完成状态上一小节对多项目环境下如何在项目线和研发线之间达成以目标版本为基本粒度的信息透明,本小节针对某个项目中的某一个目标版本的开发过程进行说明,探讨多个平台下的研发信息传递机制及其透明性的具体展现方式。
作为产品交付的依据以及测试流程的源头和目标,多平台下研发流程闭环管理关注Redmine上的Feature,即围绕Feature的生命周期展开工作,以PM创建Feature作为起点,以Feature的关闭作为闭环流程的终点。Quality Center中或其他工具平台下各个缺陷的管理作为测试过程中的中间产物不是闭环流程的目的,但也在其中的一个重要环节,需要站在整个工作流程的角度进行管理。。
一个正常流程下的Feature具有四大基本状态,包含各个状态转变过程的Feature完整生命周期如下:
上图中各个状态的转换责任人如下:
1) 新增Feature到Redmine(PM)
PM根据项目需求将功能分解成Feature并录入到Redmine上
2) Fearure开发(DEV)
DEV将Feature分解成Task并完成Feature下相关Task的开发工作
3) 更新Feature完成状态(Submitter)
当Feature下相关Task都已完成并需要提交测试前,Submitter负责将Feature状态设置成‘已解决’,表示Feature(s)已可提交测试
4) 提交测试请求(Submitter)
Submitter负责整理本次测试的Feature范围并通过一定的媒介告知QA,并提供Jenkins上服务包的下载地址以及本次提测可能包含的注意点。
5) 更新Feature测试状态(QA)
QA收到Submitter的提测请求后更新Redmine上对应点Feature的状态为‘测试中’。
6) Feature测试并在Quality Center上记录缺陷(QA)
QA进行测试,测试过程中的缺陷通过QualityCenter进行管理。
7) 发送测试结果邮件(QA)
QA完成测试并发送Feature级别的测试结果邮件,如果某个Feature已经通过测试,则在Redmine上关闭改Feature;如果未通过测试,则保持Feature状态为‘测试中’,表示该Feature还需要进一步的解决和测试。
至此一个完整的多平台研发流程闭环结束,也意味着下一个闭环流程开始启动。四、小结
对多项目、多平台下研发信息的透明性,本文从两个角度进行了梳理和抽象:首先项目线-研发线协作流程为不同工作线上的团队提供统一的项目研发视图和工作模式,围绕完成目标版本这一项目实施目的展开具体工作,确保信息的透明性和有效传递,避免因项目线和研发线信息不同步造成的项目延期和资源浪费。其次,确立明确的信息闭环管理思想,通过多种工作平台下信息传递和交互使相关干系人明确测试范围、时间节点和结果;明确相关干系人职责和分工,每一步均能定位到责任人,并保证过程的可跟踪和可追溯性,为回顾提供数据依据。
多项目、多平台下的研发信息管理难度很大,本文提供的思路和工作模式很大程度上需要团队具有较强的执行力,而且各个团队的项目、工具等具体情况可能有很大区别,可以根据本文中的一些讨论进行过程的裁剪。
标签:研发管理 范围与时间 信息透明 多项目 redmine
原文地址:http://blog.csdn.net/lantian08251/article/details/40976037