基于JIRA的产品需求全生命周期管理实践

发表于:2018-2-27 11:49

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:杨勇    来源:InfoQ

  本文将以有赞零售产品为例,介绍需求全生命周期的管理实践,包括:商家的原始需求收集、产品设计与评审、研发的需求实现、上线后运营反馈、新一轮迭代优化,构成了需求全生命周期的反馈回路。
  在整个过程中,我们是如何对需求、项目、任务、缺陷、线上质量和功能优化进行有效组织和管理的呢?让我们一起揭开这个神秘面纱吧!
  “1 个项目 +3 块看板”模型
  为了让产品和研发过程更可控,让彼此间协作更顺畅,让共同努力的结果更靠谱,我们设计了“1 个项目 +3 块看板”模型。
  “1 个项目”指有赞零售事业部只使用 1 个 JIRA 项目管理产品需求、技术需求、技术任务和测试 Bug),“3 块看板”指:
  · 给产品经理提供的“有赞零售产品需求看板”;
  · 给研发过程提供的“有赞零售项目看板”;
  · 给测试阶段提供的“有赞零售 Bug 看板”
  其中,“有赞零售项目看板”是 Scrum Board,而另外两块看板是 Kanban Board,它们通过不同的 JIRA 过滤器来实现。由于我们需要对产品需求和技术需求做拆分、估算和迭代规划,所以“有赞零售项目看板”设计成 Scrum Board,该看板提供了两种视图:整体视图和局部视图,我们可以通过该看板的活跃 Sprint 视图查看当前正在进行中的所有 Sprints(包括项目迭代和日常迭代)的需求和技术任务,同时也支持单个 Sprint 查看视图。在正式进入“1+3 模型”之前,让我们先从需求的源头入手,介绍下商家原始需求的管理方式。
  商家原始需求管理
  商家反馈的需求主要来源于客满、商家服务、渠道销售、用户研究同学和 BBS 需求帖,BBS 需求帖由产品同学定期处理和反馈,而其他来源的需求会统一提交到共同的 JIRA 看板“客户服务需求反馈/同步看板”中。
  该看板提供多种视角查看各产品线的需求,同时,提供“用户体验问题”和“大客户需求”的专属泳道。每张需求卡片上会显示其产品名称、预处理结果和预计发布日期。商家反馈的需求为原始需求,无法直接用于生产,由产品经理来跟进处理,所以,该看板不需要技术同学介入。
  选择 JIRA 看板工具做管理的好处是:
  1、通过搜索查询类似需求是否已被提交,以减少不同来源需求的重复提交;
  2、能捕捉需求经过的每个过程;
  3、邮件通知机制,需求卡片的更新(如:备注、状态更新等)会以邮件形式通知到报告人和关注人等需求干系人。
  产品经理过滤出与自己相关的需求,如果是新提交的需求,那么会对其进行预处理:
  1、判断价值很低或肯定不会做的需求,直接将需求卡片拖动到“已完成”列,选择解决结果“不会被修复”,并备注原因;
  2、判断有一定价值或需要再分析的需求,将需求卡片拖动到“产品需求池”列,在弹窗中选择“预处理结果”为需要再分析、可以很快开始或已规划到项目。
  3、我们会以报表形式展示多种统计结果,用于管理决策,比如:“产品需求池”列中需求的预处理结果和不同产品线的需求累积流图。接下来,我们介绍下“已规划到项目”中的需求管理方式,该类需求来源于“客户服务需求反馈/同步看板”,经过产品同学设计后,以“功能”粒度在各事业部的产品需求看板中以“Story”类型来管理。
  产品需求管理
  产品经理使用产品 PRD 文档将需求输出给研发同学,产品 PRD 的标准模板可在 Confluence 的“创建”右侧的“…”中找到。该模板主要包括:需求的基本信息(作者、优先级、来源和期望上线时间)、需求的背景、简介、目标、总体需求(功能列表、业务流程和业务规则)、原型和视觉稿、详细需求(各功能的详细说明)、数据需求、其他说明和风险。
  “总体需求→功能列表”会罗列出需求所涉及的所有产品功能点,这种“将大需求拆分成功能点”的需求管理方式叫需求条目化。通过条目化的功能列表可以让需求干系人简要了解到要做的功能,同时,细粒度的功能清单也方便需求在研发阶段的管理。
  我们使用 JIRA 来管理产品功能列表,需求根据大小可以分为两类:a)史诗级需求、大需求或产品特性使用 JIRA 问题类型 Epic(史诗);b)产品功能点、用户故事或日常需求使用 Story(故事),它们使用如下统一的 JIRA 工作流。该工作流看起来有点复杂,其实它主要由两个阶段组成:a)产品阶段:需求池【Open】 → 设计中 【Product-In Design】→ 评审中【In Review】 → 待开发【Product-Waiting for Development】 ···> b)研发阶段:···> 开发中【In Progress】 → 已完成【Resolved|Closed】。
  为了让需求的过程管理更直观,我们使用“产品需求看板”来管理功能 Story(如下图所示)。一个 Story 既可以表示产品 PRD 中的一个功能,也可以表示一个线上待优化的功能。前者将规划到某个项目中完成,而后者将规划到日常需求周迭代中完成。
  由于有赞零售产品包含了多条业务线,我们使用 JIRA“模块”来区分来自不同业务线的 Story,跨多个业务线的 Story 需要标记为多个模块,通过“业务模块快速过滤器”查看仅该模块的需求。需求看板上每张 Story 卡片可以显示 Story 的描述信息、所属史诗名和被规划到的发布版本名。
  我们通常直接从 PRD 文档中批量创建产品功能点 Story 到产品需求看板中,方法是:在功能列表中点击三次某个功能名称,会弹出 2 个“快捷菜单”,右侧那个为“创建 JIRA 问题”菜单(如下图所示) → 点击“Create JIRA issue"后进入”创建问题“弹框 → 选择“从表格创建多个问题” → 选择相应项目和问题类型:Story → 选择“总结”(JIRA 主题)为:功能列表的“名称”列,描述(JIRA 描述)为:功能列表的“说明”列 → 点击“创建”即可完成“从 PRD 文档批量创建产品需求到 JIRA”。
  在每个功能名称右侧插入了“JIRA 链接及状态”,以后 Story 状态的任何更新都会在产品 PRD 中同步更新,JIRA 中也自动添加了产品 PRD 的链接,实现了 JIRA 与 Confluence 之间的数据互通。我们在“有赞零售产品需求看板”的“需求池”列将显示这 2 个 Stories。
  在每个月月末,有赞会召开月度规划会,主要由各产品线的产品负责人和技术负责人参加,旨在就需要下一个月做的需求的优先级顺序达成一致。
  当产品 PRD 文档通过了产品内部的方案评审后,产品经理会给研发同学做产品需求宣讲。待 UI 设计和交互稿完成后,设计师还会给产品经理和前端同学做 UI 设计评审,以确保传递的信息有效性和完整性,避免后期产生不必要的沟通浪费。
  技术需求管理
  像 PHP 转 Java 这种技术改造型需求,不会对线上产品功能产生影响,我们简称为“技术需求”。为了与功能型需求 Story 区分开,我们使用 JIRA 问题类型 Feature 表示技术型需求(注:官方对 Feature 的解释为产品特性,也属于功能型需求)。其工作流比较简单:待办【To Do】|【Reopened】→ 进行中(开发 / 测试中)【In Progress】→ 已完成【Resolved】|【Closed】(挂起【On Hold】暂时没使用),如下图所示:
  为了简化研发同学的使用姿势,技术需求的管理与产品需求使用同样的数据存储结构,即:Epic → Feature → Technical Task(产品需求为:Epic → Story → Technical Task)。创建好的技术需求 Feature 会直接显示在 Scrum Board 的 Backlog 中,而创建好的产品需求 Story 必须流转到研发阶段(即:待开发或之后的状态)才会显示在 Backlog 中。
  我们在系统分析阶段会使用统一的技术方案模板进行技术评审,包括不同系统之间的依赖分析、业务流程分析和系统接口约定等。
  技术任务管理
  技术任务的工作流与技术需求的工作流类似,不管是产品需求(包括产品日常需求),还是技术需求(包括技术优化)在开发前将被拆分为可分配给单个研发同学执行的技术任务,且每个任务的原预估时间为 8H 左右(最多不超过 16H),技术任务的类型包括前端、后端、数据、Android、iOS、小程序、开发自测、用例编写和用例执行等。
  至此,我们形成了需求拆分的三层模型,即:史诗 Epic->功能 Story/ 技术需求 Feature → 技术任务 Technical Task。产品经理只需关注业务需求 Story,而研发同学除了要关注 Story,还需要关注技术需求 Feature。我们配置了 Backlog 的卡片布局,显示了三个扩展字段:Σ 原预估时间、Σ 进度和到期日,可以很容易看到需求的预估工作量、当前完成进度以及完成日期,如下图的项目看板 Backlog 所示。
  当迭代 Sprint 启动后,我们可以在项目看板的“活跃 Sprint”中跟踪技术任务的执行,常用操作有:a)通过拖动任务卡片来更新状态;b)给被阻塞的任务卡片增加 Flag(右键点击卡片→增加 flag),提醒项目成员注意。待风险解除后再删除标识;c)将任务卡片分配给自己,选中卡片,然后点击键盘”I”键;d)每日登记工作日志或在将任务拖到“已完成"列时记录工作日志。
  我们使用 Sprint 燃尽图和定期站会对 Sprint 整体进度进行评估和风险识别,在实践中,我们需要了解到每个人在该 Sprint 中的进度情况。为了满足这个需求,我们设计了 Sprint Task Completion by Assignee 报表,展示每个人的原预估时间、实际花费时间、任务的完成率和时间的消耗率等信息。
  在 Sprint 完成后,我们会使用“海星图”、“KISS”或“做的不错的/应该做的更好的”方法进行复盘,复盘的改进措施会被录入到“有赞零售复盘 Action 跟进看板”,每个 Action 必须是可执行的具体措施,且有一个主要负责人(JIRA 经办人)和完成日期(JIRA 到期日)。
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。 
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号