「不要从产品开始，从故事开始」。
需求不明确？
在项目推进过程中，将需求转化为开发团队可操作的东西是一项非常具有挑战性的任务。很多时候用户或者客户的需求是这样的：
「我需要一个登录功能」
「我希望能拉黑别人」
……
但假如向开发者这样提需求，往往会得到这样的回复：「为什么要这样做？这么做的意义是什么？」。仅仅从这些需求来看，由于需求的不完整性，不但难以实现开发，同时也无法成为最终需求验收的标准。
遇到这种情况，可以试着讲一讲「用户故事」。
用户故事
目前用户故事作为需求的基本形态，应用于产品的敏捷开发过程中。用户故事的典型格式是：
作为 < 用户 >，我想要 < 愿望 >，这样我就可以 < 收益 >。
我们再回到上面「拉黑」的例子中，按照用户故事的格式，就可以这样对需求进行描述：
作为 < 社区成员 >，我想要 < 增加一个拉黑的按钮 >，这样我就可以 < 屏蔽那些我不喜欢的用户 >
很明显可以看出，在一个用户故事中包含如下这几个部分：
- 角色主体，即谁要使用这个功能
- 功能，也就是经典格式中的「愿望」，它具体描述了整个需求需要实现的内容。愿望是用户故事的核心
- 收益，即完成这个需求后能给角色主体带来的价值
以往我们只关注需求的「功能」，忽视了功能主体和预期用法，而用户故事很好地弥补了这一缺陷，将需求放到实际场景中，有助于避免需求提供者和实际开发者之间的误解。
怎么写用户故事
用户故事应该能清晰地体现需求的具体内容和对使用者带来的价值，因此最好的方法是让一线人员，如客户团队或商业团队来描述故事，产品管理者或测试者对故事进行总结和后续的拆分。《用户故事与敏捷方法》一书中提到了用户故事的 INVEST 原则，可以作为用户故事的编写指导。
- 独立的（Independent）：所讲述的故事应该独立并且完整，相互之间应没有依赖关系。
比如说一个故事中会使用到微信和支付宝两种支付方式，则「使用微信支付账单」不是一个独立的故事结构，正确的说法应该是「使用支付功能支付账单」。
- 可谈判的（Negotiable）：需要明确一点，用户故事其实是「讨论需求」，而不是「下达指令」，它需要小组内成员对用户故事的需求讨论达成一致，如果没有，则用户故事是失败的。
- 有价值的（Valuable）：明确当前需求的价值，为后续迭代做准备
需注意这里的价值主体为「用户」。比如说技术人员希望对管理后台进行优化，这种优化的价值普通用户是无法感知的，不需要体现在以普通用户为「用户」的故事里。
- 可估算的（Estimable）：用户故事需要可以被估算，这就要求用户故事不能太大，同时讨论人员需要具备一定的技术知识。
这里有一点需要明确，有时候用户故事中的需求被驳回，并不是因为需求不合理或无法实现，可能是技术团队目前的技术债没有偿还，因此估算时需要技术人员对当前涉及的技术方案进行评估，综合考虑是立即执行还是对以往技术债修补后再开展，甚至可以单独拉出一个版本进行技术重构，否则会导致技术债越堆越多，反而影响后续迭代。
- 小规模的（Small）：好的工作故事不能太大，最好能保证在一个迭代内可以完成。如果用户故事过大，则违反了上述可估算性，在后续开发安排上就会有较大风险。
继续说上面「拉黑」的例子，「需要一个拉黑功能」看起来是一个需求，但其中还有很多细节没有说清楚：
- 用户如果不想拉黑对方了，是否可以解除拉黑？
- 拉黑有没有期限？
- 拉黑之后能不能给对方发消息，如果不能应该怎么提示？
- ……
以上的这些问题都是所谓的「需求坑」，如果不能很好地进行识别，那这样的用户故事会对后面的讨论或者开发带来很大的障碍，无形中增加了很高的成本。
- 可测试的（Testable）：用户故事必须清晰地界定验收测试标准。
比如说「用户觉得很满意」，这是一个较为主观的概念，无法实际进行测试，不应该在用户故事中体现。可以在产品上线后进行满意度问卷调研。
举个栗子？
团队之前曾经接过一个需求，要求在应用中实现慢性病智慧医疗场景，覆盖用户从查询就医到后续护理的全流程。团队在讨论的过程中，做了这几件事：
- 抽取场景中的关键流程
- 丰富关键流程的分支
- 抽取出用户故事，并进行拆分
上图红框部分即为每一个流程节点的用户故事，但需要注意的是，这仍是大粒度的用户故事，需要做进一步的拆分。例如在购药的环节，又将其拆成了以下几个故事：
如上图，这样就使得用户故事的工作流、业务规则都已经足够详尽。
最后，当把用户故事抽提出来后，最好团队成员可以对着故事卡片再复述一遍故事，做到对故事和其中的需求充分理解，有一个完整的例子之后就可以开始迭代，避免后续在实现上出现偏差。
