需求梳理（Refinement）
什么是refinement
Refinement 这个词是加工、提炼的意思，在scrum里，其实就是对下阶段的需求做一个讨论、澄清、细化的一个活动，希望通过这个活动，使得团队能对后续阶段的需求能有一个common understanding，尽量避免团队因为对需求理解的不一致所导致的各类问题，并帮助团队在下个迭代开始的时候更快进入开发状态，它一般是发生在下个迭代开始前的一段时间里。中文一般叫做产品待办列表梳理会议（product backlog refinement）。
其实refinement在之前还有一个名字，叫做grooming，但据说这个词的意思在英国会令人不太舒服，所以后来scrum联盟就改用了refinement这个词。如果你发现还有人在使用grooming，你可以告诉他/她，"你out了,_"
来，我帮你grooming一下
它和传统模式下得需求评审有什么不同
refinement（grooming）并不是一个在scrum下才有的新的概念，它和传统的软件开发流程中的产品需求评审非常像，不过它们还是有些区别：
- 发生的时间不同
- 需求评审往往发生在整体开发之前，一次性的居多；refinement可以分次开展，一般发生在每个迭代中间靠后阶段
- 产生的方法不同
- 需求评审是由产品单方面给出，其他人提意见；refinement是期望所有人一起来完成
- 存在的目的不同
- 需求评审是上下游交接的手段；refinement是让大家达成common understanding的方式
近光灯和远光灯
操作方式
简单的来说，refinement目的就是让我们backlog里的story更加DEEP，DEEP的意思是：
- Detailed appropriately
- Emergent
- Estimated
- Prioritized
具体操作方式如下图。
refinement process
整个refinement的过程也可以简单看成一个发散和收敛的过程。
发散
发散的意思就是在对一个story做梳理的前期，我们需要针对目标story做发散思维的讨论，尽力考虑到各个方面的问题、假设、困难，防止专家思维的局限，这是个脑暴的过程。
发散的过程中有几个小tips：
- 暂缓对别人观点的评论
- 鼓励异想天开的想法
- 借“题”发挥，别人的观点上继续延生
- 专注在story上，不要离题
- 图文并茂，鼓励使用可视化的方式
- 做加法，点子越多越好（先不关注点子的质量）
为了更好的引导这个脑暴的过程，我们常见的指导分析方法有 FURPS+ 和 SQA，这两个方法下面单独介绍。
收敛
在充分发散的基础上我们就要开始收，这样我们才能拿到refinement最终的结果，这就是收敛的过程。
为了帮助收敛，我们常用的手段有：
- 明确产出结果形式
- 投票找到公认的重点
- 时间盒
常见需求分析方法
FURPS+
- Functionality （功能性）
- Usability （可用性）
- Reliability （可靠性）
- Performance （性能相关的）
- Supportability （其它对内部研发支持，比如文档、为了可测性、可扩展性等）
- “+” （其它更多可能的考虑）
- 设计上的限制（比如系统以前的架构局限）
- 实现上得限制（比如语言，人力资源，操作环境等）
- 接口的需求（外部依赖的接口和服务）
- 硬件的需求（物理硬件的限制）
“FURPS+”更像一个checklist，它能提醒我们在发散的时候要从这些角度去思考，避免有大块的遗漏。
SQA
相对于上面的FURPS+的方法，SQA的方法在我遇到的实际中更加常用和易用。
SQA就是通过大家一起回答目标story的"Questions"，"Scope"，"Assumptions"三个问题来澄清我们的需求。
- Question：任何对这个需求不清楚的问题
- Scope：team为了完成这个需求到底要做哪些事，不做哪些事情
- Assumptions：为了做这些事的前提假设，可能是成立的，也可能是不成立的
这里会有很多疑问和假设，PO需要在团队讨论的过程中随时解答团队的疑问和澄清假设，不能当场澄清的，团队和PO需要会后带回去，在下个迭代planning meeting前完成澄清。
注意
分组讨论
发散和收敛的讨论是一个非常费时的过程，那我们该怎么更高效的完成这个refinement呢？
比较推荐的做法就是分组来讨论：
- 把团队随即拆成2-3个group，每个group分到一个高优先级的story来讨论。比如围在一个A0的大纸前，讨论这个story的S、Q、A。
- 团队成员把讨论中能想到的SQA记录在纸上，PO巡视各个小组，并回答纸上的问题。
- 讨论差不多的时候，每个group留一个人，其他人交换到其他group里来，留下的人负责给新加入这个话题的人做介绍，大家讨论并继续完善这个话题
- 最后每个group里找到一个可能对这个story了解最少的人给整个team介绍最终SQA的内容
分组讨论
refinement的范围
refinement并不只是梳理下个迭代的开发内容，而是下个阶段重要的开发需求，refinement梳理的内容范围往往会大于下个迭代能完成的范围。
在某些变化比较快的领域还会出现refinement的内容并没有出现在下个迭代开发列表中的情况。
refinement并不止在会议上发生
需求的梳理其实不仅仅只发生在每个迭代的refinement的会议上，它其实应该是贯彻发生在整个软件开发的全过程中。只是在refinement 会议上做了最大量的需求梳理的工作，然后从sprint的开始，花费在需求梳理上的时间会慢慢减少，花费在软件设计开发上的时间慢慢增加，到了sprint得后期就慢慢没有了需求方面的工作而只剩下开发上面的工作了。
时间花费占比
refinement活动还是比较花费团队时间的，那么对于时间总是不够的开发团队来说，花费多少时间来做refinement是比较合理的呢？
推荐整个迭代花费在refinement会议的时间占总时间的5%，比如一周的迭代，refinement通常在2个小时左右。
