真的需要用户故事模板吗？
内容列表
这篇文章写在上一篇用户故事101 后，对上一篇的内容进行一些扩展，让大家可以更加客观的看待用户故事模板。
用户故事模板的三大元素的背后逻辑
相信大家对三大元素一定都能信手拈来，但是这里我们依然要过一遍三大元素，并且对三大元素进行逐一讲解。
作为XX用户，我想要YY功能，以便于实现ZZZZ价值
从常见的5W1H模式来看，模板对应的是如下内容：
- Who，该用户故事是写给谁的，也就是谁会来用这个功能
- What，我们需要做什么，也就是需要交付的需求，要完成怎样的任务。
- 很多时候，“想要”并不确切，也会有“被迫”、“被要求”等情况发生。为了简单，此处统一为“想要”
- Why，我们为什么需要该功能（What）
我们通过这个模板，比较好的阐述了功能的使用者、想要达到的目标以及背后的商业逻辑，为进一步的用户故事细化或者实例化，做了比较充足的准备，并预留了足够多的待讨论细节，从而引导在后续的过程中，大家对该需求进行讨论、补充并最终达成理解的一致（对应3C原则中的Conversation和Confirmation）
到这里，对该模板本身的作用，已经非常明显了——它以一种较为平衡的方式，将用户所需要的需求讲解清楚，请预留进一步沟通确认的口子，确保大家在动手之前，一定要进行沟通、核实，确保功能开发前的一致性，避免后续因为理解层面导致的返工等浪费。
模板背后的逻辑
研发人员一定会对“编码规范”不陌生。这项技术是什么我们就不再进一步赘述，但是其带来的优势我们都是很清楚的。编码规范的目的就是为了“让所有人代码看起来像一个人写的”，从而避免“换了一个人就看不懂”的情况发生。
如果你能理解上面这个，那么模板背后的逻辑是一样的。给了模板，目的是为了避免不同人写出来的东西不一样，从而大家都看不懂。这是一种降低成本的行为，尤其是在团队协作时，尤为重要。
所以，模板就是在编写用户故事时的“编码规范”，帮助我们可以以最低的成本来读懂用户故事。
总结
用户故事模板，不论是在三个部分还是在模板技术本身，都能满足我们对需求（其实用户故事不是需求，后续文章会有讲解）的描述、沟通、讨论等诉求。
所以，如果可以，请尽情在敏捷中使用模板来编写你的用户故事吧。
