随着越来越多的企业进行敏捷转型，用户故事的概念也越来越多的为大家所熟知，与此同时对用户故事的曲解和误用也时有发生，用对、用好用户故事已经是很多团队转型敏捷需要跨越的第一个门槛。好多项目只是简单的把之前的需求改了个名字叫用户故事而已，剩下的做法与之前写PRD并_没有什么本质的变化。
经常可以看到产品经理虽然不再为出PRD而头疼了，但是还是在闷头在写用户故事。如果你的故事是一个或几个产品闷头编写出来然后拿到计划会上的，那一定要小心了。
为什么使用用户故事？
用户故事最早是由Kent Beck提出的，最开始只是叫故事，后来为了突出用户参与及用户视角又改叫用户故事。Kent发现过去处理需求的方式存在很多问题，没有起到很好的效果，他的想法很简单，团队在一起讲述用户故事，通过讲故事的方式获得对产品愿景的一致理解，然后共同创建更好的产品解决方案。随着Scrum 、极限编程等敏捷方法对流行，用户故事也逐步开始流行起来。
我们该如何生产用户故事呢？
-
首先讨论并理解业务目标讨论过程并关注关键干系人的业务目标，而不是他想要开发什么功能，用卡片记录下来，然后排出业务目标的优先级顺序。我们得到了什么我们得到了经过排序的业务目标清单，将这些目标手写或者打印出来，后续的讨论都是围绕这个目标进行的，要不断检视后面所做的决定是否服务于要达成的目标.
-
识别用户/用户画像在理清业务目标的前提下，讨论哪些用户会使用我们的系统，分别罗列出不同类型的用户，并讨论他们使用系统的动机、能获得的好处、需要的功能，记录到卡片上。这轮讨论过后每个用户应该都对应一大串卡片。这个过程之后，你会发现得到了远超团队所能负担的工作项，不过这是正常的，我们想要的总比我们能负担的多，我们的目标从来不应该是开发所有功能，而应该是开发尽可能少的功能来达成业务目标。这时候你需要问一个问题：如果这些用户中只能满足一个用户的需求，会选哪个？为什么？不断的问以上问题，给用户排出优先级。
我们得到了什么我们得到了经过排序的目标用户清单及对应的关键用户故事列表.
- 开始讲故事经过以上步骤后，你们应该已经选择了一个或多个需要满足的用户，这时候拿起关于她的卡片开始讲述关于她的故事吧：“我们假设系统上线了，用户会在什么时候如何使用我们的系统呢？她会先这样做，然后那样做...”，这个过程中需要边讲边调整卡片的顺序，最终得到经过排序的一系列用户的关键活动，讨论过程如果发现遗漏的故事就写一张新卡片插入进去，一定要确保用户关键活动的完整性。讨论过程中我们会对每个关键活动卡片的细节考虑的更深了一步，当讨论清楚一个细节时候，记录到一个卡片上，放到对应对关键活动卡片的下方。这个过程让我们可以提前识别产品创意中可能存在的风险，同时我们还得到了一个更重要的东西：对所要开发的系统的一致理解。另外需要注意避免过早陷入细节对讨论（争论），这个时候还需要更聚焦于整体，优先确保故事的完整性。
我们得到了什么我们得到了用户故事地图你一定看到了自己熟悉的词：用户故事地图，没错，实际上面的过程就是使用用户故事地图达成共识并生产用户故事的过程，同时我们还得了业务目标、产品的全景图、核心的用户故事。
- 接下来你可以基于这个图来进行划分MVP，准备资源，划分团队等一系列活动总结
- 用户故事并不是另一种写需求的方式，讲述用户故事，在过程中用文字和图片结合的方式辅助讨论，以此来建立共识。用户故事是一个沟通工具，不是记录工具。重要的不是我们在用户故事里写了什么，而是我们看到用户故事时能想起什么？
- 用户故事也不是需求，用户故事是关于问题解决方案的讨论，解决的事用户面临的问题，让我们对要开发的功能达成共识。
- 我们的最终目标是最小化输出，最大化成果和影响，我们需要投入精力到那些可以使成果最大化的功能上去。
更多文章请关注 @敏捷新视界
原文链接
网友评论