交付有价值的产品，先澄清用户故事吧！

摘要：多变的需求推动着我们要加强与客户的沟通交流，通过用户故事来澄清客户需求，帮助客户打造对他们来说有价值的产品。所以我们该怎样澄清用户故事呢？

在当下，处于VUCA时代的我们也在面临着来自客户的易变、不确定、复杂化、模糊化的需求。这种多变的需求推动着我们要加强与客户的沟通交流，通过用户故事来澄清客户需求，帮助客户打造对他们来说有价值的产品。所以我们该怎样澄清用户故事呢？

一、谁来编写用户故事？

用户故事是由谁来写呢？一般情况下， 一定是最接近用户的角色来负责编写用户故事，这个角色一般情况下是客户或者产品负责人。通常客户写出来的需求也不能称为严格意义上的用户故事，这就需要产品负责人在与客户确认的基础上再加工，形成一个完整的用户故事。

如果在某个团队中，用户故事是由测试人员或开发人员编写的，那我们也同样需要明确这个用户故事是经过客户和产品负责人确认过的。同样，用户故事优先级的排序也是需要最贴近用户侧的人员来进行确定，如果研发团队自行决定用户故事的优先级，那么就有可能出现最先实现的用户故事有可能不是最重要的，而是最好实现的。

那如何编写用户故事呢？可以通过对用户的访谈、市场调查等方式来发掘用户需求，然后按照INVEST原则来合理编写用户故事。

在这个阶段，我们要注意的一个事情是，为了达成敏捷团队的自组织，提高团队成员的积极性与参与感，我们可以不明确到底是谁来编写用户故事，而是让每一位团队成员都参与编写用户故事。这样的话能够激发团队成员的责任意识，减少成员之间的互相推诿。

二、什么时候使用用户故事？

用户故事明确了什么角色想要什么功能，以便于实现什么价值或目的。所以在每实现一个功能之前，我们 要明确为什么要做这个功能以及怎样才能达成这个目的或价值。

但我们需要注意的是，不是所有的任务都需要用用户故事来表达，比如团队的一些事务性的功能就可以以任务的形式而非用户故事的形式来表达，因为这类事项不能产生对客户有益的价值。对于能够直接对客户产生价值的需求，我们可以用用户故事来表达。

因此，我们要真正弄清楚真正面对用户的用户需求（用户反馈的Bug、撰写用户手册的需求、产品功能性需求等），我们通过用户故事来表达；而一些团队内部的改进问题（如进行结对编程、内部发现的代码规范、某一部分的代码重构等），我们可以用团队达成共识的表述方式来呈现。

三、用户是谁？

在做项目管理的时候，我们一定要与用户接触、沟通，了解用户的真实需求和实际的使用场景。在一般情况下，很多公司只有销售人员在接触客户，研发侧人员以及产品负责人等离客户非常远，那在这种情况下，团队很容易出现“闭门造车”的现象，最终交付的东西无法投入到实际应用环境中，也不是用户真正需要的。

所以整个技术团队需要搞清楚用户是谁、用户在哪以及用户有什么需求这几个问题。而在这个时候，我们可以用用户画像、影响地图、用户故事地图、同理心地图、客户旅程地图等实践（这些实践可以在融·软件项目管理推荐库中进行了解）找出真正的用户，进行精准的需求获取。而针对一些中间件、微服务等，我们可以通过将这些中间件及微服务的上下游系统定义为系统用户，也能够比较轻松地编写出这些系统用户的用户故事。

四、用户故事规范

用户故事的规范其实也是一个常见问题，我们可以通过一个小视频来详细了解如何来编写用户故事： 如何写好用户故事？

五、勿以唯故事点论

虽然我们在估算用户故事的时候会使用故事点估算，但过度地关注故事点也会让我们适得其反。首先我们要明确的是 故事点估算没有一个统一的标准，每个团队都可以根据自身的实际情况确定自己的基准故事点。

这里有几个关键环节我们要注意：在实际完成某一迭代的时候，我们要关注这个迭代交付了多少功能，而不是完成了多少故事点；不要做团队与团队之间的故事点横向对比，因为两组并不是完全一样的条件，所以没法进行直观地对比；我们只用故事点来执行迭代计划，不应该将故事点与绩效管理挂钩。

六、定义“就绪”“完成”与“验收标准”

在用户故事被放入迭代计划之前，我们要确认用户故事的“就绪”状态。团队之间要就“就绪定义”达成共识，比如共同制定出一个检查列表，通过此检查列表的用户故事即为“就绪”，可以排进迭代计划中。同时，可以根据用户故事的类型来制定不同类型的用户故事“就绪定义”。此外，还有一个关键点在于，“就绪定义”需要定期检查更新。

既然明确了用户故事的“就绪”，那么我们也要明确用户故事的完成标准。如果我们对用户故事完成没有一个统一的标准，那么就会出现研发人员觉得写完代码就算完成了，而测试人员认为编码后自测、然后通过功能测试之后才算完成的情况，这种情况会大大增加沟通成本，降低工作效率。

所以 团队需要给用户故事一个完成的定义，比如通过自测、功能测试、集成测试才能算用户故事的“完成”，也就是我们所说的“DoD”。

那用户故事完成了，它能达到用户的满意吗？这里就牵扯出了一个细节问题，团队制定的用户故事的“完成定义”只是确认了这个用户故事或这个功能做完了，但是并不能明确这个功能可以满足用户的需求。那为了解决满足用户需求这一问题，我们可以设置用户故事的验收标准。

验收标准的设置需要用户、产品负责人及团队一起来讨论完成，它能够满足最初的用户故事的内容。也就是说，如果我们要做一个网站注册功能，最终做出来了一个通过邮箱号完成注册的功能，这个功能是通过自测、功能测试后明确完成了的功能，但是用户希望能够通过手机号直接注册，这个完成了的功能并未满足用户的需求。那这样的话我们做出来的功能并不是用户所期望的，所以我们要通过验收标准来满足用户的期望。

我们可以通过“Given/When/Then格式”来编写验收标准，举个例子： 用户故事是“作为一个没有在这个网站上注册的用户，我希望能够开发一个网站注册功能，以便于我能在网站上发表自己的言论。”那么该用户故事的验收标准则是：
场景：网站用户注册登录；