2019年5月23日星期四13:59

写用户故事's No User

Written by
当我们向敏捷业务分析转型时,我们大多数人都学习的第一件事之一就是如何编写用户故事。
如果您开始了敏捷之旅,您可能熟悉格式:“作为一个<role>, I want to <action> so that I can <实现一些商业目标>”
但是,如果您没有用户,而是正在处理系统?当我开始在敏捷中工作时,我没有用户编写用户故事,我有API和文件转移。我的案例中的用户是将从其他进程中消耗输出并创建其他进程使用的输出的系统。 
我不得不提出一种不同的思考用户故事的方式。用户并不直接参与过程,或者在过程中如此初步涉及,因此它们对其没有太大的输入或影响。我发现很难确定角色或用户配置文件以包括通常的格式。本文是关于我如何学会以不同的方式工作以解决这个问题。
当没有用户时,故事的目的或价值必须成为焦点。系统应始终给出相同的输入相同,因此您将在人类用户中看到任何变体。更重要的是故事所存在的原因:系统表现出某种方式的原因。授予的,故事的价值是重要人类用户是否存在的重要性,但在这种情况下变得更加重要。
在我的世界中,大多数要求来自国家法律或立法的变化,因此故事的原因是经常遵守法规,或向国家提供所需信息。在其他情况下,处理来自国家的报告和查询的部门需要以某种方式处理的信息,但仍然没有与处理处理的系统的直接交互。

广告

为了解决这个问题,我使用几种不同的格式来编写我的用户故事,当用户不是故事的主题时:“为了/ for<实现这一营业目标>, the system <执行此功能>。“我试图在第一个条款中包含具有目标的业务部门或实体,因为它使故事更清晰的价值。
例如,我可能会写入“为了使状态适当地处理车辆记录并提供有效的传输,系统将有效的驾驶员的许可证号与每个记录一起发送。”在这种情况下,故事的价值是该状态能够正确地处理车辆记录。如果我想,我可以更详细地了解这一点,但由于我团队中的所有人都知道为什么这是有价值的,这不是必需的。 
我可以和经常这样做,提供关于作为故事讨论的一部分或作为验收标准的一部分而无法实现的目标的详细信息。这个故事可能是描述该状态的有效记录手段的更大史诗的一部分,列出了在可以发送记录之前需要验证的所有字段。我可能包含关于在该级别发送的无效记录的后果的详细信息,因为它适用于记录中的所有数据。这个故事是史诗的一部分,但是只关注一个数据元素。我喜欢这样做的事情作为史诗,因为它在像这样的情况下更容易结合故事或将它们分开以组织工作。
写这些的另一种方式,如果你愿意,就是说“因为<requirement>, the system <does this action>。同样,我试图包括谁在初始条款中提出了必要的要求,以使事情非常清楚为什么这个故事是有价值的。
有人讨论了这篇文章之后,一个人说,为什么不使系统制作用户,以便您可以使用通常的格式?例如“作为一个<name of system>, I need to <do this action>, so I can <实现这一目标>。这是一种完全可接受的事情方式。我确实认为它强调了故事的价值,这就是我更喜欢前两种格式的原因。
一旦我们写了用户故事,我们大多数人都知道下一步是写接受标准并提供开发人员可能需要实现故事的其他信息。在这种情况下,我需要提供识别有关状态的有效驾驶执照号的规则。我还需要提供一套验收标准,以便为开发人员提供一种了解故事何时完成的方式。 
大多数情况下,这是用例的形式或描述传入数据的业务规则列表,以及在对数据的错误消息,日志记录或其他响应方面完成的。这可能实际上可以创建一个涉及人类用户的辅助用户故事,例如“作为状态报告专家,我需要在州拒绝记录时收到电子邮件。”
写作用户故事是敏捷业务分析师的重要技能。关注价值是解决“Userless”用户故事的一种方法。虽然价值始终是重要的,但当用户行为是可预测和可定义的时,它变得尤其重要。
拉里加伦希

Larry在过去的20年里几乎在SDLC中表现了几乎所有的角色,在各个时代都担任开发商,技术作家,商业分析师,数据库设计师和培训师。

他目前正致力于了解有关使用Agile作为业务分析师的更多信息。

他拥有Scrum.org的PSM-I认证,并正在努力从IIBA获得敏捷认证

©ba time.com 2021

MacGregor Logo White Web