部门角色 用户角色_从角色到用户故事

部门角色 用户角色

摘要

用户故事是一种从用户或客户的角度捕获产品功能的强大技术。 但是，我们如何发现正确的故事呢？ 应何时写，应写得详细些？ 阅读这篇文章，以找出我对这些问题的答案。

1.从角色开始

编写正确的用户故事的第一步是了解您的目标用户和客户。 毕竟，用户故事要讲一个有关用户使用该产品的故事。 如果您不知道用户是谁，我们想解决什么问题，那么就不可能写出正确的故事，最终您会得到长长的愿望清单，而不是对相关产品功能的描述。

角色提供了一种捕获用户和客户需求的好方法。 它们是虚构的人物，带有名称和图片。 相关特征，例如角色，活动，行为和态度； 目标，这是必须解决的问题或应提供的利益。

让我们来看一个例子。 假设我们要为儿童创建一个游戏，玩起来很有趣，并且可以教育孩子们音乐和舞蹈的知识。 然后，我们将至少创建两个角色，一个代表孩子，一个代表父母，如下图所示。

上面的两个示例角色使用了我简单但有效的角色模板。 它鼓励您保持人物形象的简洁，专注于真正重要的方面，而忽略其余部分。 您可以从romanpichler.com/tools/persona-template下载该模板，其中提供了有关编写角色和使用模板的更多信息。

创建角色转换后，请选择主要角色，即主要为其设计和构建产品的角色。 这有助于您做出正确的产品决策并获得正确的用户体验（UX）。 在上面的示例中，我选择Yasmin作为主要角色。

2.从角色角色目标衍生史诗

创建角色之后，请使用其目标角色来标识产品功能。 问问自己该产品应如何解决角色问题或为他们创造所需的收益，如下图所示。

从主要角色开始，并以史诗，粗粒度的高层故事形式捕获功能。 写下满足角色目标所需的所有史诗，但在此阶段保持粗糙和粗略。

对于舞蹈游戏，假设游戏最初将作为iPad应用程序启动，我们可以在下面编写史诗：

如上述史诗所示，游戏应允许玩家选择不同的角色，使其跳舞，选择不同的舞池和音乐曲目，与朋友一起玩游戏以及在Facebook上发布其游戏快照。

尽管史诗可以很好地勾勒出产品的功能，但您的产品不仅仅具有史诗和故事：您还应该捕获用户交互以及史诗的使用顺序，产品的视觉设计以及重要的非功能性质量例如互操作性和性能。 例如，使用工作流程图 ，故事地图， 情节提要 ，草图，模型和约束卡来描述它们。 您可以在我的文章“ 用户故事不足以创造出色的用户体验 ”中找到有关描述不同产品方面的更多信息。

3.逐步将史诗分解为用户故事

通过对您的产品进行全面但粗粒度的描述，开始逐步分解您的史诗。 您无需一步一步地详细介绍所有史诗和编写所有用户故事，而是逐步获取故事，如下图所示。

只要存在一些重大风险，并且您正在弄清楚该产品的外观和功能，最好及时获取足够的用户故事，以便下一次冲刺。 如下图所示，使用冲刺目标或假设确定要分解的史诗和要编写的故事。

上面描述的方法可以最大程度地减少产品积压中的详细项目数量。 这样可以更轻松地整合通过向用户和客户展示产品增量或最低可行产品（MVP）而获得的新见解。

假设我们想通过开发可执行的原型来解决创建错误游戏角色的风险，该原型使我们能够对选定的子代进行可用性测试。 然后，我们可以编写以下用户故事：

上面的故事来自史诗“选择角色”和“玩角色”。 最终的原型仅部分实现了这两个史诗-达到了能够测试角色是否与用户产生共鸣的程度。

一旦更好地了解了如何满足客户和用户需求，就可以开始编写用户案例，并在产品积压中拥有更多的详细项目清单，因为您不太可能对史诗和整体积压进行较大的更改。

4.准备故事

在开发团队开始编写故事之前，请检查每个用户故事是否准备就绪 ：清晰，可行且可测试。

如果产品所有者和团队之间对其含义有共同的了解，那么故事就很清楚。 如果可以根据完成的定义在下一个冲刺中交付它，则是可行的。 这意味着故事足够小以适合sprint，而且意味着可以进行必要的用户界面设计，测试和文档编制工作。

对于上面的示例故事，我们必须添加接受标准，确保故事足够小以适合下一个冲刺，并考虑创建一些非常粗糙的设计草图以指示角色的外观。 例如，为了准备好故事“是的，她选择了小女孩”，我们可以绘制以下草图：

上面的草图补充了用户故事，并允许团队在下一个Sprint中实施整个故事，包括视觉设计。

有了适当的用户故事，开发团队就可以有效地开发产品。 有关准备用户故事的更多详细信息，请查看我的文章“ Scrum中Ready的定义 ”。

翻译自: https://www.javacodegeeks.com/2014/08/from-personas-to-user-stories.html

部门角色 用户角色