User Stories - 最佳实践 (Best Practices)

在转向敏捷之后，很多团队开始使用“用户故事”一词。用户故事是一种简单而优雅的技术，可以收集客户需求。然而，它需要一定的理解和实践才能用User Stories构建出色的软件。

让我们仔细看看用户故事是什么以及如何使用这种技术取得成功。

什么是用户故事？

用户素材是对功能的简短描述，它为用户或客户带来价值，团队可以在迭代中提供这些功能。

用户故事应该回答3个问题：

我们为谁建造它？ - 作为<用户类型>
我们在建什么？ - 我想<feature>
我们为什么要建造它？ - 这样<值或利益>

在此之后，用户故事的典型格式是：

作为<用户类型>，我想要<feature>，以便<value或benefit>。

用户故事示例：作为注册用户，我希望能够将我的图片下载到我的个人资料中，以便其他用户可以看到我的样子。

有没有创建用户故事的程序？

没有正式的过程来创建用户素材。尽管如此，还是应该遵循一条准则来创建一个好的用户故事。它被称为3 C，由极限编程的创始人之一Ron Jeffries提出。

该卡是用户故事的书面说明。它没有捕获有关应该构建的内容的所有详细信息。相反，它是一个提醒，是对必须进行的后续通信的承诺。
对话用于讨论用户故事的细节。它可能会被一些文档补充。
确认由用户验收测试表示，确保用户故事满足用户/客户的验收标准。

如何撰写高质量的用户故事

确保用户故事具有适当质量的良好做法是遵守Bill Wake的INVEST首字母缩略词的标准。INVEST还有助于确定用户故事是否已被充分理解并为开发团队开始工作做好准备。

独立 - 用户故事不应该依赖于另一个用户故事，因此用户故事可以按任何顺序开发。
可协商 - 用户故事的详细信息通过产品负责人和开发团队之间的口头对话进行协商。
有价值 - 用户故事应该为用户/客户带来所需的价值。
估计 - 开发团队应该很好地理解用户故事来估计它。
小 - 用户故事应足够小，以适应迭代。
可测试 - 应为用户故事编写正确的验收标准，以便进行验证。

什么不是用户故事？

让我们对自己说实话：用户故事不能通过其定义成为“技术用户故事”，因为在这种情况下它不会给用户/客户带来直接价值。不过，许多团队喜欢在需要执行代码重构等技术任务时创建用户故事。我建议将其他工作项用于此类任务，并与您的产品负责人就此类工作达成一致，以便了解为何需要这样做。这同样涉及非功能性需求任务，界面设计任务，复杂的用户交互任务或错误。您可以自由地为这些任务创建其他工作项。例如，Constraint Story可用于表示非功能性需求。用户故事是捕获产品功能的绝佳技术，但我们没有义务将其用于所有目的。

谁是用户？

在编写用户故事之前，应该清楚地了解创建用户素材的用户是谁。有时它被新用户故事技术的团队所忽视，他们最终创建了具有不必要功能的软件。因此，做一个适当的用户研究，让你的所有用户类型或用户角色或角色写下来并描述。可以帮助您解决此问题的两种技术是用户角色建模和角色。

谁负责撰写用户故事？

通常，客户代表（例如产品负责人）负责用户故事。尽管如此，用户故事并不是从顶级到团队的规范，而是产品负责人和团队之间的协作技术。这就是为什么如果用户故事是协作编写的话会更好。一个很好的方法是做一个故事写作研讨会。

细节在哪里？

由于用户故事不是规范，因此详细信息以不同方式传达：

3 C指南中的第二个“C”是Conversation。对话是敏捷最重要的方面之一。因此，大多数细节都是通过客户代表和开发团队之间的口头沟通来传达的。
第三个“C”是确认。用户验收测试确认用户故事满足用户/客户的验收标准，并且它们用作正式的文档详细信息。BDD（行为驱动开发）是一种编写验收测试的好方法。
如果需要，某些用户故事可能包含其他书面详细信息。

你怎么知道用户故事何时完成？

使用“完成定义”技术。简而言之，Done的定义是团队成员之间对工作完成意义的共同理解。完成的定义通常以活动清单的形式创建，其表明商定的价值（用户验收测试以满足用户验收标准）和质量（以满足质量标准）。团队有时会忽略最后一个，在迭代结束时，什么可以使用户故事不可能发送给客户。完成技术的定义有助于避免这种情况。

完成定义的示例：

完成时间：