标准 用户故事 的格式是这样的，“作为 [角色]，我想要 [目标 / 期望] 以便 [好处]”。但是，对于有些用户故事，当要填充角色字段时，这种简单的模板就会出现问题。
例如，最近在 Scrum 开发组上， Kevin Krac 问到下面这个真实的用户故事：
产品负责人想到了这样一个故事，关于客户完成购买后，更改客户可以联系的商家的电话号码。目前，在发给客户的电子邮件中列出了市场部的电话号码，但产品负责人认为给出销售代表的电话号码更加明智。
制定这个用户故事时，角色字段应该填谁呢？产品负责人吗？市场部门的员工？销售代表？还是其他人？
到底为什么要在用户故事中包括角色字段呢？ Don MacIntyre 给出了一个理由 ：“我发现清楚地识别出受益角色能帮助产品负责人提出清晰的价值定位——这反过来会帮助他们排列故事的优先级 。 ”然而，在这个故事中，在开发团队实现它以后，受益人是谁不是很清楚。
Ron Jeffries 认为坚持标准故事格式没有多大价值：
卡片上无论写谁都不太贴切：我更喜欢像“把市场部的电话号码替换成客户销售代表的电话号码。” […]
思考很重要；要选择最有价值的故事很重要；给团队解释最后的决定很重要；有具体的测试确保它的有效性也同样重要。
卡片上写的是什么没有那些内容那么重要。
但是，Mick Cohn 认为标准的用户故事格式 有一些好处 。他看到的好处包括：
- 以第一人称（“As a … I want …”）编写用户故事能帮助开发人员和其他人识别出他们的工作能为谁带来利益。
- 按相同的方式组织所有的故事能帮助产品负责人排列故事的优先级，因为这样产品负责人就不需要在脑子里单独解析每个故事的文字了。
为了让非标准的故事也能使用标准的格式， Mick Cohn 有几个提示 ：
一个好的用户故事对系统所有的利益相关者都是有关的。故事可以不用“想要”，比如“作为一名购物者，开始结帐时可以给我展示配套产品。”或者，“作为一名用户，我被强制要求每 90 天更改一次我的密码。”因此并非所有故事都需要有“想要”这个词。
在用户故事模板上填上空白好了，无论那个模板如何完美，它都不会帮助我们去完成艰难的工作。就像 Ron Jeffries 所说的那样，用户故事成功的关键是“ 卡片、对话和确认 ”（3C, Card, Conversation, Confirmation）。就是说，卡片上只要写上适量的文本，能识别需求（“用户故事”）就好了；然后让客户与程序员有适当的沟通，以便他们能成功地进行编码，实现需求；并通过验收测试的方法去验证已经完成的工作。
查看英文原文 ： Who Wants This User Story?
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论