用户故事 | 需求分析

需求分析也可以简单看成一个发散和收敛的过程。

发散

发散的意思就是在对一个Story做梳理的前期，我们需要针对目标Story做发散思维的讨论，尽力考虑到各个方面的问题、假设、困难，防止专家思维的局限，这是个脑暴的过程。
发散的过程中有几个小Tips：

• 暂缓对别人观点的评论
• 鼓励异想天开的想法
• 借“题”发挥，别人的观点上继续延生
• 专注在Story上，不要离题
• 图文并茂，鼓励使用可视化的方式
• 做加法，点子越多越好（先不关注点子的质量）

为了更好的引导这个脑暴的过程，我们常见的指导分析方法有 FURPS+ 和 SQA，这两个方法下面单独介绍。

1. FURPS+

• Functionality （功能性）
• Usability （可用性）
• Reliability （可靠性）
• Performance （性能相关的）
• Supportability （其它对内部研发支持，比如文档、为了可测性、可扩展性等）
• “+” （其它更多可能的考虑）
  • 设计上的限制（比如系统以前的架构局限）
  • 实现上得限制（比如语言，人力资源，操作环境等）
  • 接口的需求（外部依赖的接口和服务）
  • 硬件的需求（物理硬件的限制）

“FURPS+”更像一个checklist，它能提醒我们在发散的时候要从这些角度去思考，避免有大块的遗漏。

2. SQA

相对于上面的FURPS+的方法，SQA的方法在我遇到的实际中更加常用和易用。 SQA就是通过大家一起回答目标Story的"Questions"，“Scope”，"Assumptions"三个问题来澄清我们的需求。

• Question：任何对这个需求不清楚的问题
• Scope：team为了完成这个需求到底要做哪些事，不做哪些事情
• Assumptions：为了做这些事的前提假设，可能是成立的，也可能是不成立的

这里会有很多疑问和假设，PO需要在团队讨论的过程中随时解答团队的疑问和澄清假设，不能当场澄清的，团队和PO需要会后带回去，在下个迭代planning meeting前完成澄清。

收敛

在充分发散的基础上我们就要开始收，这样我们才能拿到Refinement最终的结果，这就是收敛的过程。
为了帮助收敛，我们常用的手段有：

• 明确产出结果形式
• 投票找到公认的重点
• 时间盒

高效梳理

发散和收敛的讨论是一个非常费时的过程，那我们该怎么更高效的完成这个Refinement呢？
比较推荐的做法就是分组讨论：

把团队随即拆成2-3个group，每个group分到一个高优先级的Story来讨论。比如围在一个A0的大纸前，讨论这个Story的S、Q、A。
团队成员把讨论中能想到的SQA记录在纸上，PO巡视各个小组，并回答纸上的问题。
讨论差不多的时候，每个group留一个人，其他人交换到其他group里来，留下的人负责给新加入这个话题的人做介绍，大家讨论并继续完善这个话题
最后每个group里找到一个可能对这个Story了解最少的人给整个team介绍最终SQA的内容