用户故事和需求到底啥关系？

做敏捷就是绕不过用户故事，我们以前已经有需求了，为啥还要用户故事，用意何在呢？用户故事和需求到底啥关系？听我慢慢道来！

1、用户故事是需求收集的一个手段

用户故事不是需求，它只是需求收集的一个手段。

用户故事是一个约定，约定了我们要和相关的人员一起来讨论和澄清需求。

2、用户故事的格式解决了什么问题

通常我们写用户故事的格式为

作为<用户>，我想要<做什么>，以便<价值>。

这不是用户故事的唯一格式，但它是一个非常有效非常推荐的格式！

作用一：

这种表达方式虽然像八股文，但它迫使你去思考：

此项功能的用户是谁？
我们要做的功能是什么？
做这个功能的价值何在，能为用户解决什么问题？

注意：很多情况下，我们因为没有认真考虑我们的用户，没有关注究竟为用户解决了什么问题，花了大量的时间做了没人用的功能，造成浪费！

这可不是随便说说，我指导过的一个PO告诉我说，很多时候当他们问业务为什么提出某个需求，业务根本答不上来！你想想，提需求的人都不知道为啥要提出这个需求，那我们还急于开始做吗？

作用二：

我辅导的一个SM告诉我说，以前业务不知道开发团队在做什么，开发团队说的东西业务听不懂！

现在业务看到用户故事，直接秒懂！

这样开发团队的工作对于业务来说更加透明了，业务也能够给予更多更恰当的反馈，而且业务和开发的沟通更加顺畅了！

作用三：

很多时候，我们从业务或用户那里拿到的所谓的需求并不是能够解决痛点的真正需求，而是业务或用户脑子里以为的需求！

是的，你没有听错！

你可以深入问一下给你提“需求”的小伙伴，他为什么提出这样的需求，是为了解决用户什么问题和痛点，你很有可能得到超乎想象的答案！

我辅导的一个团队，他们在实施敏捷之前，业务说要怎么做，他们就怎么做。实施敏捷之后，他们有意识去询问“需求”背后的真正需求，究竟要解决什么问题。他们突然意识到，现有的架构能够非常好支撑到这个真正的需求，额外代码量并不大。相比之下，以前机械按照业务的要求来做，在已有的架构之上，要绕很多的弯，做大量的代码工作！

多么痛的领悟！

这还算是好的！如果业务给的“需求”根本不能解决真正的问题，那么你就只能欲哭无泪了！

3、我们以前的需求往哪放？

我们说，用户故事是需求收集的一个手段！

我们可以想象，我们把写有用户故事的卡片贴在一个大空瓶子的外面，带着这个瓶子和相关的人做沟通（Conversation），获取需求，把需求装在瓶子里。

那么如何做沟通呢？站在那里背着手说？No！人的记忆力和理解力只有使用可视化手段才能最大限度的发挥作用！于是我们就需要如下工具做辅助：

线框图
低保真原型图
高层级设计（HLD）
等等

注意：这些工具的使用，不是为了使用而使用！它们都是为了澄清需求而是用的！达到了澄清需求的目的，你使用的工具再少都是恰当的；达不到澄清需求的目的，你使用的工具再多都是不恰当的！

比如有些团队有时就是因为没有能够在需求梳理阶段提供足够明确的UI相关的图，导致在迭代开发过程中出现不小的额外沟通成本甚至是返工。这种情况就是需求澄清不到位！我们要及时调整DoR（Definition of Ready）标准，确保要求所有进入迭代的需求都已经和业务/客户做充分沟通，开发团队有充分的理解。

这样，我们的瓶子里就装满了某个用户故事对应的需求澄清的所有结果。这个结果是各角色共同讨论的结果！

关于瓶子：

这个瓶子可以是JIRA/TFS/禅道等电子系统中的一个用户故事条目，瓶子里一堆的东西，就是该用户故事中的一堆附件。

4、故事的验收标准解决了什么问题？

每个用户故事一定要有明确的验收标准！

我在辅导团队的时候，有一个PO就直接站出来挑战我，说写验收标准就是走形式！浪费时间！以前不写验收标准也一样干活！

真的是这样吗？

我们以前没有写验收标准，并不代表没有！只是这些验收标准都在大家的脑子里！

对于同一个需求，业务、开发和测试对于这个需求做到什么样算合格都有自己的观点，如果不白纸黑字写出来，大家脑子里的验收标准肯定是有所差别的。

如果不是在开始就对验收标准明确达成一致，那么就一定会在功能开发完毕之后，遭到测试人员的挑战，业务人员甚至会说“这不是我想要的”。这样的情况比比皆是！结果就是大量的返工，大量的额外讨论！浪费的时间更多！

所以验收标准一定要在梳理阶段，由所有角色共同认可和明确。验收标准要达到测试人员看了会写测试用例，开发人员看了知道做到什么程度，业务人员看了说这就是我想要的！