需求全生命周期管理活动
BA+产品经理侧的几个会议目标描述
业务需求梳理会：每两周业务方和产品经理共同梳理业务需求池中各需求的优先级，沟通需求的背景、业务场景、期望实现的功能等基础内容，初步沟通交付范围
产品方案评审会：业务需求梳理会后五个工作日，产品经理提供产品设计原型，确保计划实现的产品功能、界面、逻辑等与业务方预期一致，初步确定交付范围
线上产品演示会：双周冲刺结束后，产品经理向业务方演示线上产品，确保线上产品功能符合业务方的定义。
如下的需求管理描述主要是产品经理+产研侧的需求管理。
主要有如下两种方法
1、Backlog
1.1、创建故事
故事创建的责任人通常是产品经理
所创建的故事应当满足的特征
1 从业务逻辑角度拆分 2有独立价值 3 与其它需求依赖少 4 工作量可评估并尽可能小 5 尽可能可独立测试。
即INVEST原则 independent negation valuable estimation small testable
所创建的故事应该包含的内容：功能概要、功能详细描述、优先级，相关的PRD链接，PRD描述位置，原型地址，UI设计地址，版本规划等。这些内容可以逐步完善，但是在需求澄清会之前必须补充完整。
1.2、史诗关联
之前我们讲到了，史诗用于组织工作和创建层次结构，可根据客户或最终用户的需求分为较小的用户故事。史诗可以跨越多个冲刺和版本。
我们可以创建几个史诗，与故事关联起来。
1.3、版本管理
详细内容参考JIRA之版本管理
1.3、Sprint管理
Sprint也可以称作为迭代 ，冲刺。 是用2到4周的时间来完成一定量的工作。Sprint有助于将项目范围分解为更容易管理的故事和任务，并频繁地交付正常运行的软件。Sprint管理也是敏捷开发核心价值观的体现，响应变更，快速交付。
一个项目需求池可以分为三段，Backlog，预备sprint，活跃的sprint
1.3.1、项目需求池
1.3.2、创建sprint
1 点击创建sprint
2 给新创建的sprint命名
Sprint 命名规则：项目名+冲刺数（可选）+起止时间
实际上启动sprint是可以填写开始和完成时间的，但是我们设定时间的目的，是为了整个团队对于目标时间的对齐。根据实践结果来看，还是直接把时间写在标题上，更容易引起团队对时间的关注。
3 从Backlog里把准备要做的需求拖动到刚创建好的sprint里。
1.3.2、启动sprint
启动sprint 通常在产品澄清完需求之后，研发开启冲刺评审会之前。启动的目标是大家对冲刺的时间，范围，优先级等达成共识。
冲刺计划会上，我们往往还会确定2周冲刺中间的一些关键节点，比如 测试用例评审时间，接口文档提供时间，联调时间，接口提测时间，演示时间等等，这些节点可以填写在项目目标里。虽然这和项目目标的的定义有一些区别，实践来看这是时时刻刻提醒团队时间节点最好的方式。项目的目标永远都会显示在面板的最上方。
到此为止从JIRA-backlog里管理需求已经介绍完毕了。
2、用户故事地图（StoryMap）
用户故事地图是一门在需求拆分过程中保持全景图的需求管理方式。
用户故事地图实现的功能和Backlog是一致的，但是它的展示效果和编辑便捷性要比Backlog好，它是需要购买的一个插件，以如下图所示的方式来管理需求。
这是一个很好的示例，以便于大家理解用户故事地图。
把N个大的需求拆解若干了小需求，这些小需求分5个批次发布。
2.1 创建故事
2.2 史诗关联
2.3 sprint管理
1创建冲刺
2 启动冲刺
3 关闭冲刺
方法与backlog管理雷同
2.4 版本管理
切换到版本管理界面
拖动需求到指定的版本里
