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

在那里写用户故事's No User

撰写者
在过渡到敏捷业务分析时,我们大多数人首先要学习的内容之一就是如何编写用户案例。
如果您已开始敏捷之旅,则可能对以下格式很熟悉:<role>, I want to <action> so that I can <实现一些业务目标>”
但是,如果您没有用户,而是与系统打交道,会发生什么?当我开始在Agile中工作时,我没有用户要为其编写用户案例,而是拥有API和文件传输功能。在我的情况下,用户是将消耗其他进程的输出并创建其他进程使用的输出的系统。 
我不得不想出另一种思考用户故事的方式。用户没有直接参与到流程中,也没有参与到流程的早期,因此用户对此没有太多投入或影响。我发现很难确定要包含在通常格式中的角色或用户个人资料。本文是关于我如何学会以不同的方式来解决该问题的。
当没有用户时,故事的目的或价值就必须成为焦点。在输入相同的情况下,系统应始终执行相同的操作,因此人类用户不会看到这种变化。变得更重要的是故事完全存在的原因:系统以某种方式表现的原因。诚然,无论是否存在人类用户,故事的价值都很重要,但是在这种情况下,故事的价值就变得更加重要。
在我的世界中,大多数要求来自州法律或法规的变更,因此讲故事的原因通常是遵守法规或向州提供所需的信息。在其他情况下,负责处理来自州的报告和查询的部门需要以某种方式处理信息,但仍无法与进行处理的系统直接交互。

广告

为了解决此问题,当用户不是故事的主题时,我使用几种不同的格式来编写我的用户故事:“为了/为了<实现这个商业目标>, the system <执行此功能>。”我试图将具有目标的业务部门或实体包括在第一条款中,因为这可以使故事的价值更加清晰。
因此,举例来说,我可以这样写:“为了使状态正确处理车辆记录并提供有效的传输,系统会在每条记录中发送一个有效的驾驶执照编号。”在这种情况下,故事的价值在于国家能够正确处理车辆记录。如果需要,我可以详细介绍一下,但是由于团队中的所有人都知道为什么这样做很有价值,因此不需要这样做。 
我可以而且经常提供有关故事目标或接受标准中未实现目标的详细信息。这个故事可能是较大的史诗的一部分,该史诗描述了有效记录对该状态的含义,列出了在发送记录之前需要验证的所有字段。我可能会包含有关在该级别发送无效记录的后果的详细信息,因为它适用于记录中的所有数据。这个故事是该史诗的一部分,但只关注一个数据元素。我喜欢像史诗般地做这些事情,因为在这种情况下,合并故事或将故事分开组织工作更加容易。
如果愿意的话,写这些的另一种方式是说“因为<requirement>, the system <does this 行动>. Again, I try to include who made the 需求 necessary in the initial clause to make things very clear as to why the story is valuable.
在与其他一些BA类型讨论了这一点之后,有人说,为什么不让系统成为用户,以便您可以使用通常的格式?例如“作为一个<name of system>, I need to <do this 行动>, so I can <实现这个目标>。这是一种完全可以接受的处理方式。我确实认为这使重点从故事的价值上移开了,这就是为什么我更喜欢前两种格式,我自己。
编写完用户故事后,我们大多数人都知道下一步就是编写验收标准并提供开发人员实施故事可能需要的其他信息。在这种情况下,我需要提供规则,以为相关州识别有效的驾驶执照号码。我还需要提供一套验收标准,以使开发人员可以知道故事何时完成。 
在大多数情况下,这是用例或描述传入数据的业务规则列表的形式,以及如何处理错误消息,日志记录或对数据的其他响应。这实际上可能会创建涉及人类用户的辅助用户故事,例如“作为州报告专家,当记录被州拒绝时,我需要接收电子邮件。”
编写用户故事是敏捷业务分析师的一项基本技能。关注价值是解决“无用户”用户故事的一种方法。尽管价值始终很重要,但是当用户行为是可预测和可定义的时,价值就变得尤为重要。
拉里·布兰肯希(Larry Blankenship)

在过去的20年中,Larry几乎在SDLC中担任过所有角色,曾在不同时间担任过开发人员,技术撰稿人,业务分析师,数据库设计师和培训师。

他目前正在努力学习有关使用敏捷作为业务分析师的更多信息。

他获得了scrum.org的PSM-I认证,并且正在获得IIBA的敏捷认证。

拉里·布兰肯希(Larry Blankenship)的最新作品

©BA Times.com 2020

麦格雷戈徽标白色网站