Scrum-需求梳理会-分享

本次需求梳理会流程设计如下：

1.35-1.40 po大需求讲解

1.40-1.52 产品代办列表与清晰度梳理

1.53-2.10 用户故事分解

2.11-2.13 产品代办列表优先级重排

首先大PO对整体需求，和整个 项目需要最终达到的目标进行了讲解，是的整个Scrum团队的成员都获得统一的目标

2，Po对用户故事细节进行澄清，team成员通过复述自己的理解来确保大家对用户故事达成了一致

3.team对用户故事进行分解，并进行工作量评估

4.最后PO对需求进行优先级排序，以备在sprint计划会上挑选出优先级高的用户故事进行开发

整个会议的总结，

1.由于我们人员较少，需求也少，暂时无法想到大型团队间在处理大量的需求该如何处理会议

2.故事梳理会的核心就是用户故事的设计，应该满足INVEST原则：

Independent 独立的：

尽可能避免故事间的相互依赖，因为这会影响到故事优先级和开发计划的编排。

Negotiable 可讨论的：

故事不是合同，它是功能的简短描述，其细节会在客户团队和开发团队的讨论中产生。如果在编写故事的时候已经明确了一些细节，可以把它们写在注释里。

Valuable to Purchasers or Users 对客户或用户有价值的：

首先需要明确一点，客户是软件购买者，而用户是软件使用者，二者关注的价值是有差异的。尽量避免只对开发人员有价值的故事，如“所有的错局处理和记录应该在一系列公共类中完成”，如果改为“所有的错误应以统一的方式呈现给用户并做记录”更好。保证每个故事对客户或用户有价值的最好方法是让客户自己来编写故事，但是需要记住，这些由客户自己编写的故事不是用来甩锅的，而是用来提醒后续需要进行讨论的话题。

Estimable 可估计的：

对于开发人员而言，故事是需要能够估算大小的，否则很难把它们安排到开发计划当中。一般会有如下三个原因导致任务不可估计：

1. 开发人员缺乏领域知识

2. 开发人员缺少技术知识

3. 故事太大了

Small 小的：

正如上文提到，过大的故事需要被拆分成更小的故事以便于估计工作量，而与此同时，如果故事太小，也无助于故事的评估。对于过大的故事，我们需要进行故事的拆分与分割，而过小的故事则需要进行合并。

Testable 可测试的：

故事必须是可测试的。只有成功通过测试才能说明该故事已经被开发完成。

例如“用户绝不需要花很长时间来等到新窗口的打开”就是一个不可测试的故事，其中“绝不”，“很长时间”都是没有明确定义的词汇，为了让这个故事可测试，可以将其改写为“在95%的情况下，新窗口的打开时间不会超过2秒”。如果能够写一个自动化测试脚本来验证这个测试标准就更好了。