这是研发范围和时间“信息透明化”系列的第三篇文章,在《研发范围和时间的“信息透明化”之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还须要进一步的解决和測试。
至此一个完整的多平台研发流程闭环结束。也意味着下一个闭环流程開始启动。
四、小结
对多项目、多平台下研发信息的透明性,本文从两个角度进行了梳理和抽象:首先项目线-研发线协作流程为不同工作线上的团队提供统一的项目研发视图和工作模式。环绕完毕目标版本号这一项目实施目的展开详细工作。确保信息的透明性和有效传递,避免因项目线和研发线信息不同步造成的项目延期和资源浪费。其次。确立明白的信息闭环管理思想,通过多种工作平台下信息传递和交互使相关干系人明白測试范围、时间节点和结果;明白相关干系人职责和分工,每一步均能定位到责任人。并保证过程的可跟踪和可追溯性。为回想提供数据根据。
多项目、多平台下的研发信息管理难度非常大,本文提供的思路和工作模式非常大程度上须要团队具有较强的运行力,并且各个团队的项目、工具等详细情况可能有非常大差别。能够依据本文中的一些讨论进行过程的裁剪。
原文:http://www.cnblogs.com/lcchuguo/p/5140502.html