研发范围和时间的“信息透明化”之协作与流程

这是《研发范围和时间的“信息透明化”》的第二部分，主要阐述基于Redmine确保信息透明的协作和流程，关于研发范围和时间的基本概念及其在Redmine这一特定平台上的表现形式请参考第一部分《研发范围和时间的“信息透明化”之Redmine统一平台》。

一. 关于协作和流程

研发范围和时间的透明来自于团队的相互协作，这些协作需要以一定的流程和模式作为基础。

1. 角色和数据流

要想做到信息透明，个人认为首当其冲的是要明确团队角色和职责。研发团队中通常包含的核心角色有：

• PM：项目经理，负责用户沟通、需求收集
• PO：产品经理，负责产品规划、方案设计
• DEV：研发人员，负责功能实现、进度控制
• QA：测试人员，负责产品质量控制、服务发布

DEV和QA的角色比较好区分和理解，这里说明一下DEV一般分成表现端和服务器端两种细分角色，分别以C-DEV和S-DEV表示。

PM和PO的角色所担负的需求开发和管理部分工作有时候比较难划分界限，而且可能在一定场景下两者是同一个人，但即便是同一个人，其工作范围是需要明确区分的：PM的需求面向用户（用户需求），而PO的需求面向产品（产品需求），也即DEV通常是跟PO进行需求方面的沟通，而不是和PM，PO作为项目线和产品线的接口人最终把控产品的方向。团队协作的流程图如下，大家可以看到PM和DEV之间没有直接交互：

2. Issue状态

团队成员和角色都已明确，PO手上也已经有了研发的需求说明，也就是范围，PO和DEV就可以使用分解技术将这个范围分解成Issue（包括Feature和Task）；后续随着测试工作的展开，QA也需要对Bug和Defect在Redmine上进行统一维护，每个Issue的状态以及状态之间的转换参考：

以上状态可能各个团队会有所不同，大家可以灵活添加、删除或修改名称，但需确保状态从“新建”到“已关闭”形成一个闭环。

3. Issue与角色

Issue的状态转换和角色是一个强映射，即Issue的每个状态的转变都需要有明确的角色执行。状态转换是一个端到端的过程，Issue的创建和关闭只能由特定的角色进行，本文建议的角色映射方案参考下图：

上图角色映射的一个基本原则是：PO是面向用户功能的负责人，而服务器端S-DEV是系统内部服务的提供者，这两个角色分别负责Feature（面向用户功能）和Task（面向内部服务）的创建。因为面向用户功能最终需要由QA进行测试，所以Feature将由QA关闭；而Task用来在DEV之间进行开发信息的传递，对PO和QA是透明的，故由DEV自身关闭即可。

4. 范围和时间的组合

下面是范围和时间组合的象限图，大家会选哪个？

A和D首先排除，范围和时间都固定不现实，而范围和时间都可变也就无所谓信息透明了。关键是B和C，个人认为都是合理的，但需要根据具体场景具体分析。本文结合第一部分中时间要素中的版本概念，认为C是进行研发范围和时间透明化时的最佳组合选择。

5. 版本从何而来？

有了“范围可变、时间固定”的组合，我们就可以确定版本。本文第一部分中提到”一定时间”加上”一定活动”就等于版本，现在时间固定，所以“一定时间”有了（可以考虑以一周为单位进行短周期迭代），“一定活动”通常需要团队进行协商和讨论以达成最终在范围和时间上的统一认识。版本等式以及版本中包含的范围和时间的确定方式参考下图：

二. 工作流

一个完备的工作流程运转需要三方面：步骤内容、责任人和时机。围绕Redmine平台进行研发范围和时间管理的主工作流如下，该主工作流程围绕一个目标版本内容进行展开，通过控制Redmine上Issue状态转换推动流程的运转：

下面我们对该主工作流进行拆分，从PO、DEV和QA三个核心角色的视角出发围绕日常开发工作进行工作流梳理。

1. PO工作流

PO是产品需求的负责人，日常工作流程包括以下几个方面：

• 与UED确认方案，召开需求会议：产品需求是PO的武器，通常包括系统原型、功能描述、数据模型和约束条件等。个人认为在召开需求会议之前， PO和UED进行需求确定是一项最佳实践，因为很多用户需求和体验上的“look and feel”的内容通过PO和UED的联合过滤会比直接抛给开发之后进行需求反复更加有效，这也是非正式技术评审的一种体现。通过这一轮非正式技术评审，PO组织需求会议，与团队成员在需求上达成一致。
  
• 将Feature记录在Redmine上：PO根据需求会议最终确定的产品需求，在范围上进行分解以形成面向表现端和面向UED的两部分Feature并把它们录入到Redmine系统上。这一步需要把控的是Feature的数量和粒度。
  
• 定期检查或者通过邮件通知：随着产品研发的演进，PO需要定期检查Redmine上Feature的完成状况，并在有需求更新和变更时通过Issue更新和正式的邮件通知确保团队对范围的理解始终保持一致。
  
• 如有不明确，与PM/DEV沟通：如果团队对产品需求和范围有任何异议，PO负责与PM和DEV进行沟通和协调，其中从产品角度出发与PM达成在项目需求和产品需求之间的一致是PO所面临的挑战，对任何沟通和协商结果需要通过Redmine平台进行统一更新确保信息透明。
  
• 与DEV协商范围和开发计划：开发计划由DEV负责制定，但需要满足产品整体战略计划，PO与DEV进行协商并最终形成开发计划。

其中需求会议是PO需要主持的主要流程性会议，需求会议召开方式如下：

需求会议的产出是一份研发团队成员都认可的产品需求。

2. DEV工作流

DEV泛指产品的开发团队，日常工作流程包括以下几个方面：

• 与PO就需求和方案进行沟通：需求会议的主要议程就是DEV与PO进行产品需求的讨论和确认。
• 召开设计/计划会议确定开发Task：获取产品需求之后，DEV负责召开设计/计划会议以确定开发的任务和计划。其中S-DEV需要根据系统的设计方案确定面向内部服务的开发范围，分解成Task并维护在Redmine上，确保产品中面向用户需求和面向内部服务的开发范围都能在Redmine上得到体现。
• 根据Redmine上计划进行开发：DEV根据Redmine上计划进行开发。
• 如有不明确，与PO/QA沟通：开发过程中对需求、范围和时间上任何异议，DEV需要和PO/QA进行协调和沟通，确保在最新的认知水平上团队达成新的一致。
• 确认功能完成：无论是产品需求还是系统缺陷，DEV都应该定期/不定期关注功能的完成情况以便形成研发过程的可视化动态视图。

其中设计/计划会议是PO需要主持的主要流程性会议，设计/计划会议召开方式如下：

设计/计划会议的产出是根据系统的设计方案以及根据该方案所进行的开发计划。

3. QA工作流

QA是产品质量的负责人，日常工作流程包括以下几个方面：

QA与DEV之间的互动基于上图中描述的一次完整提测流程，QA通过以下两个方面进行信息的透明化管理：

• Redmine上Issue状态管理：Feature最终由QA进行关闭，同时QA需要维护Feature和Bug/Defect之间的映射关系，确保团队进行研发范围的跟踪和管理
• 测试流程管理：QA作为测试流程的执行者，通过邮件等工具监督和记录流程每一步的结果和状态，确保团队对开发进展的统一认识

三. 小结 

最后，梳理日常工作中的几项最佳实践作为本文的总结：

1. 关注我的工作台和最近版本

示例图如下：

2. 使用统一视图

下图是Redmine上使用Task Board进行团队信息同步的效果图，Redmine平台为我们进行信息透明化管理提供了一些插件和功能，关于Checklist功能、Eclipse与Redmine集成方法以及更多Redmine插件可参考我的博客：《工具系列之Redmine插件与工作效率》

3. 技巧和注意点

• 随时进行问题的提炼
• 及时的分发问题
• 关注时间点和优先级
• 不要把事情或者问题堆起来解决
• 版本计划有变动第一时间通知Team
• 随时就某一（些）问题召开小会
• 具体信息都同步在Redmine上
• 定期/不定期的回顾和总结

本文中提交的思路和理念是通用的，但具体的工具平台、工程实践等可根据具体的团队现状和研发管理水平做调整，以找到研发团队的最合适工作流程。