多个用户登录数据错误_5个常见的用户故事错误

多个用户登录数据错误

用户故事是传达用户或客户如何使用产品的简单但有效的方法。 但是编写帮助团队构建出色软件的用户案例可能具有挑战性。 以下列表总结了五个常见的用户故事错误，以帮助您改善故事。

故事狂

一些产品所有者和团队非常喜欢用户故事，以至于一切都表达为故事。 这要么导致一些比较奇怪的故事，要么就是捕获用户界面设计，复杂的用户交互和技术要求的故事； 或这些方面都被忽略了。

像任何技术一样，用户故事编写也有其优势和局限性。 我发现故事特别适合捕获产品功能以及正确应用时的非功能需求 。 但是，通过其他技术（包括设计草图 ，实体模型， 场景和情节提要）可以更好地描述用户界面设计和复杂的用户交互。 因此，可以使用其他技术来补充用户故事，而不必只使用故事。

用户隐身

用户故事讲述了有关用户与产品进行交互的故事。 但是，有些故事完全忽略了受益人，或者说它们是关于“作为用户，我想……”中的神秘用户的。但是，如果不清楚用户是谁，为什么要发展这个故事？ 我们怎么能相信这个故事将使某人受益？

确保您所有的故事都有明确的用户或客户。 因为我喜欢使用角色 ，所以我在故事中使用角色（而不是用户角色）。 这使每个故事都与正确的角色相关联，并且使我能够理解故事是否满足角色的需求或目标以及扩展到哪个角色。 为此，我使用以下模板：作为<角色>，我想要<something>，以便使用<benefit>。

灾难详情

细节在于魔鬼：有些故事太大而模糊，团队无法理解和实施。 其他人则包含太多细节，甚至规定了解决方案。 正确了解细节似乎是产品所有者只能松懈的战斗。

我的建议是：从大而粗的故事开始，这些故事称为史诗，特别是对于所有新功能。 通过史诗，您可以在不承诺细节的情况下捕捉创意。 然后将史诗分解为更详细的用户故事。 新的用户案例取代了史诗，它们提供了有关产品功能的更多信息。 要特别注意拉入冲刺的用户故事。 这些故事必须准备就绪 ：清晰，可行且可测试。 （您可以在我的文章“ 史诗和现成的故事 ”中了解有关将史诗分解为现成故事的更多信息。）

逐步完善您的故事可以使您的产品画布或积压订单保持简洁，可以更轻松地集成新见解，并且可以减少库存初始画布或积压订单所需的工作量。 这对于新产品和新功能特别有价值。 确保您没有在故事中规定解决方案。 而是关注“什么”或“如何”。 后者最好在体系结构图中捕获。

故事移交

一些产品负责人会认真地编写用户案例，并在sprint计划会议中将其交给开发团队。 这种交接通常是次优的，因为它浪费了团队的想法和知识。 因此，故事可能是不合适的，难以理解的，不可行的和可检验的。

但是，用户故事并不意味着是独立的文档。 产品所有者和团队之间应该进行对话 ，或者甚至更好地通过协作编写来补充它们。 一个故事想抓住要点，而不是要详细说明每个细节：后者对于新功能来说很困难，而在敏捷/精益环境中太慢且太昂贵。

用户故事编写应由团队共同努力，产品所有者和开发团队应共同创建故事。 分配时间参加协作的Product Canvas研讨会或积压的梳理会议 ，尤其是在开发新产品或新功能时。 相信我：更好的故事和更好的产品将是您的回报。

标准危机

接受标准可能是用户故事中最容易被误解的部分。 我看过没有接受标准的详细故事，没有叙述叙述的标准，有隐藏新故事甚至包含整个工作流程的标准。 最后两个错误的例子如下（叙述在左边的卡片上，右边是“接受标准”）：

接受标准背后的想法很简单：它们使您能够描述必须满足的条件才能完成故事，使故事可以暴露给用户和其他利益相关者。 这样可以确保您收集反馈和/或发布功能，并帮助团队计划和跟踪他们的工作：标准丰富了故事并使其更加精确和可测试。 （所有条件必须满足的标准，例如“可以提供在线帮助”，未在接受标准中说明，而是在“完成的定义”中说明。）

根据经验，我喜欢每个故事使用三到五个条件，而且我不担心我的史诗没有开头的接受条件。 但是， 准备好的故事必须提供有意义的标准。 您可以在我的帖子“ Epic and Ready Stories ”和“ Nonfunctional Requirements ”中找到样本接受标准。

摘要

“我不恨你失败，我爱你尝试，” Marge对荷马·辛普森说。 我们都可以讲述和编写良好的用户故事； 我们只需要练习它。 正如他们所说，实践是完美的。

参考：在Pichler博客博客上，我们的JCG合作伙伴 Roman Pichler的5个常见用户故事错误 。

翻译自: https://www.javacodegeeks.com/2013/06/5-common-user-story-mistakes.html

多个用户登录数据错误