坑3：需求理解不一致
看到这个主题，很多人都会挠头，或者迷惑不解。在工作过程中，需求讨论、需求评审、需求沟通等等，需求的会议一箩筐。还会理解不一致？那么，大家看看在日常工作中，团队有没有如下的情况：
需求沟通会上，产品经理详细讲解了需求，会上也和设计、开发、测试都一一确认了，大家表示没有疑问。可是后面到了具体实现过程中，除去需求变更之外，为什么设计、开发、测试还会频繁要求产品经理进行需求澄清？
这里面有几种可能的原因：
Ÿ 产品、设计、开发、测试有自己的思维方式和理解视角，对同一条需求的理解是存在侧重点差异的。
Ÿ 各种角色在描述自己对需求的理解时，都是基于自身的表达方式，在表达过程中可能存在着信息过滤和偏离。
因此，需要有一些约定和工具能够帮助各种角色对需求的理解达成真正一致。
用户故事方法的“故事点”概念和基于故事点的“计划扑克”估算能够解决这个问题。
“故事点”是对需求条目的规模进行相对度量的一种单位。
请注意，故事点是一种相对度量单位，只有在多个故事存在时，点数才有意义。同时，不同产品需求的故事点数比较没有意义。
图 相对大小的故事点
需求条目的估算可以采用“计划扑克”来估算。
图 计划扑克
计划扑克的估算方式如下：
Ÿ 参加游戏的人每人各拿一叠扑克牌，牌上有不同的数字。
Ÿ 产品负责人为大家挑选一个 Story（Backlog），并简单解释其功能，以供大家讨论。
Ÿ 每个游戏参加者按自己的理解来估计这个 Story 的故事点数，从自己手里的牌中选一张合适数字的牌，同时亮牌。
Ÿ 游戏参加者各自解释自己选择这个数字的原因，数字最大和最小的人必须发言。
Ÿ 根据每个游戏参加者的解释，重新估计时间并再次出牌，直到大家的估计值比较平均为止。
Ÿ 计划扑克估算活动中，重要的是通过多轮次大家对需求不一样的理解来逐渐澄清真正的需求是什么？最后得出的故事点数是大家的共识。
Ÿ 故事点数可以记录在用户故事中。
坑4：需求没有验收标准
需求的验收标准是往往被大家共同忽略的问题。大多数情况下，产品经理会准备大量的PRD，大量的原型设计文件。而设计、研发、测试更关心的是产品经理能不能把需求说清楚，能不能承诺在后面的开发过程中，尽量没有什么需求变化。
所以，很多时候，需求的验收标准就被大家给忽略掉了。
在这里，先给大家说明一下什么是需求的验收标准。这个需求的验收标准来源于敏捷需求方法用户故事中。上文和大家讲过，一个合格的用户故事有六大特征，而最后一项就是“可测试的”，而为了保证用户故事的可测试，一项关键的措施就是每一条用户故事都应该有“验收标准”。
那么什么是验收标准？为了保证沟通的一致性，我们建议用户故事用业务语言来描述，所以用户故事的验收标准也是业务层面的验收标准。如果验收标准是清晰的，那么用户故事在迭代中完成后是否能够通过验证，就有了依据。
同时，用户故事的验收标准也是测试用例的关键输入。
验收标准的可以如下格式：
图验收标准示例
当然，具体的产品、团队，验收标准的格式可以有所差别。
当用户故事有了验收标准，就可以在这个基础之上进行测试用例的编写。
一个即将进入迭代的用户故事，需要有相应的测试用例与其对应，作为验证用户故事是否能够实现完成的依据。
同样，用户故事有了测试用例进行关联，那么由此产生的缺陷也可以进行关联。这样，能够便于进一步的透明化团队需求的实现情况
