没有一个魔术模板可以应用于所有的用户故事。用户故事可以用多种方式来编写，但是编写用户故事的最流行方法是使用此模板：
作为……，我想要……，以便……
该模板起源于2000年代初期在英国Connextra公司的敏捷教练Rachel Davies。此后，它已成为表达用户故事的公认标准。
在本文中，让我们看一下此标准模板的三个元素，该模板经受时间考验的原因以及该模板的优缺点。
标准模板的三个要素
- As a (role), I want (function), so that (business value).
- 作为(角色)，我想要(功能)，以便(业务价值)。
后来我转而将三个要素称为角色(role)，目标(goal)和理由(reason)。最终，我决定只是更简单地称他们为谁(who)，什么(what)以及为什么(why)。标准用户故事模板的三个元素涉及：
- 谁想要这个功能（Who wants the functionality）
- 他们想要什么（What it is they want）
- 他们为什么想要它（Why they want it）
让我们看一下用户故事模板的每个部分。
谁（WHO）：用户故事模板的第一个元素
通常可以对典型产品或系统的用户进行分类。例如，我现在将其输入到Google文档中。我可以算是Docs的临时用户。我没有使用它的大多数功能。我从未单击过其“加载项（Add-Ons）”菜单，甚至看不到那里的内容。我没有做很多花哨的格式化，因为我写的大部分内容都移到了我的网站上并在那里进行了格式化。因此，我可以被称作“临时用户”。
其他使用这些功能的人可以称为“高级用户”。
我通常将博客草稿发送给编辑。因此，在识别各种不同类型的Google文档用户时，编辑可能是另一个角色。
这些用户角色形成标准的用户故事模板的第一部分。因此，开发文字处理程序的人可能会有一个用户故事：“作为高级用户，我想要一个拼写检查器……”
什么（WHAT）：用户故事模板的第二个元素
标准模板的第二部分规定了希望或需要什么。通常将其表示为“我想要...”。实际上，多年来，我的会议演示和其他有关用户故事的培训都有一张幻灯片显示“我想要...”。
我最终意识到那是不正确的。有时，所描述的功能根本不是用户角色想要的。例如：
没有（正常）用户想要输入包含很多字符、三个特殊符号、没有重复字符以及至少两个大写字母的高安全等级密码。顶多我们能理解为什么需要这么做，但是就我个人而言，我更希望该系统神奇地知道它是我，只允许我进入。
因此，这些天我在课程或演示中显示模板时不再包含想要。因为并非总是我想要的，有时我是被要求，被迫，被需要的。
为什么（WHY）：用户故事模板的第三个元素
标准模板的最后一部分“为什么”是用户用来描述其需要这个功能的原因的。这是在模板so-that部分提供的。例如，早期的拼写检查故事的完整表达版本可能是“作为一个超级用户，我希望有一个拼写检查器，这样我就不用担心拼写错误。”
一个故事的so-that子句是非常重要的，因为当理解了为什么一个用户想要某个功能（what子句中描述的内容）时，有助于团队决定该功能的最佳实现方式。
举例来说，继续看看我们的拼写检查器故事。假设将其提供给团队时不带有so-that子句，就这么简单：作为高级用户，我想要一个拼写检查器。这很可能导致团队开发出这样的拼写检查器：在文档编写完成后，拼写检查器作为事后工具才开始在文档上运行检查。
但是，我们的高级用户在完成文档编写后并不想采取额外的步骤。相反，高级用户想要的是现在看起来更标准的东西：实时纠正错误。用户真正想要的是由so-that子句提供的：用户不用担心拼写错误。
So-That子句是可选的吗？
当我在课程现场展示用户故事时，我经常被要求证明我看似矛盾的观点，即so-that子句是一个故事中最重要的部分，但它不应该是强制性的。
我不认为它是强制性的，因为有时它不增加任何价值。考虑有关登录的故事：作为成员，我需要登录。您可以在该故事中添加什么so-that子句，以增加价值或阐明该故事的意图？这些措施真的有帮助吗，还是只是添加了多余的文本以符合模板：
- 。
- 。
- 作为成员，我需要登录后系统才能知道是我。
- 作为成员，我必须登录，以防止黑客入侵。
尽管我不认为so-that子句是强制性的，但我几乎一直都在写它。我回顾了我最近写的待办列表，其中64个故事中的62个（占97％）具有so-that子句。少数情况使我不认为它是强制性的。
三段式用户故事模板的优点
那么，这个模板有什么优点能让它经受住时间的考验呢？毕竟，这种做法是在2000年代初期引入的，并在很多年后逐渐被人们接受，因此其肯定有可取之处。我认为模板有四个主要优点。
它涵盖了5W中的三个
我以新闻专业毕业。I think I romanticized movies filled with cigar-chomping newspaper reporters—films like Ace in the Hole, Citizen Kane, It Happened One Night, and All the President’s Men。（不怎么看电影，所以这段英文不知道在说什么）训练有素的记者，任何报纸文章都需要回答5个以W开头的问题：
- 谁？（Who）
- 什么？（What）
- 什么时候？（When）
- 哪里？（Where）
- 为什么？（Why）
用户故事讲述了五个W中的三个：WHO、WHAT、WHY。在讨论产品或系统要求时，将“WHEN、WHERE”排除在外似乎是合理的，因为答案通常是“立即”和“包含在产品中”。
元素以正确的顺序显示
我认为这些元素——WHO、WHAT、WHY——以正确的顺序呈现。考虑任何故事，而不是用户故事，比如你想告诉朋友的电影、小说、轶事或笑话，这个故事中最重要的事情几乎总是谁在做。我们称这个人为主角。
当我们看电影时，我们需要先关心主角，然后再关心情节。I don’t care one way or the other the Death Star being blown up until I see a little of myself in Luke, Han or Leia and can relate to them.（不怎么看电影，所以这段英文不知道在说什么）
只有在知道WHO之后，我才在乎WHAT和WHY。标准的用户故事模板按这些顺序排列。
以第一人称视角讲故事
我们喜欢关于自己的故事。（好吧，除非我们是十几岁的孩子，而且我们的父母正在讲关于我们婴儿时所做的调皮捣蛋的故事。）仅次于我的故事的是关于你的故事。最无聊的是一个关于我从未见过的小镇上的家伙的故事。
关于我、你、我们、她和他的故事是有趣的。
甲壳虫乐队知道这一点。他们故意将尽可能多的人称代词塞入歌曲标题中。如果他们不能在歌曲标题中使用人称代词，那么他们会在歌曲的歌词中尽可能多地添加。
甲壳虫乐队的第一张英国专辑在14个歌曲标题中有8个出现了代词（57％）。在这八首歌曲的19分30秒中，甲壳虫乐队使用了325个人称代词，每3.6秒使用一个代词。
效果很好，他们的第二张专辑中有64％的人称代词。披头士在他们的第三张专辑中达到了79％。
甲壳虫乐队成员保罗·麦卡特尼在接受公告牌杂志（Billboard magazine）采访时表示，这是经过深思熟虑的：“我们所有的早期歌曲包含‘我’或‘你’。我们对粉丝们是完全直接和无耻的：Love Me Do, Please Please Me, I Want to Hold Your Hand。”
标准用户故事模板以我开头，我是最个性的人称代词。我没有这个主张的依据-我不是脑科学家-但我发誓当我们有一个以我开头的用户故事，与同一个故事作为传统的“系统应……”声明相比，我们与该故事的联系更加紧密。
保罗·麦卡特尼（Paul McCartney）和约翰·列侬（John Lennon）知道这一点，并用它来促进他们的职业生涯。使用三段论的用户故事模板时，敏捷团队会做同样的事情。
我们的利益相关者可以立即轻松填写
在用户故事出现之前，我喜欢用例。或者，我试图喜欢用例。我真的很爱他们。但我永远无法让与我共事的利益干系人像我一样喜爱用例。
用例离利益相关者如何看待他们的工作太遥远了。利益相关者不会考虑次要角色或前提条件或后置条件。因此，用例在实践中从未像我认为的那样运作良好。
使用用户故事的时候我从来没有遇到过那样的问题。我可以和利益干系人一起举办一个故事编写工作坊，只要把用户故事模版“作为一个____，我____，以便于____”写在一个白板上，并且告诉他们我们已经很多次聚在一起通过填写模版来准备用户故事了。
利益干系人能够明白。因为对他们来说，这是一种自然的表达方式。
三段式用户故事模板的缺点
标准用户故事模板有两个缺点，值得一提。
很多故事以“作为用户……”开头
团队成员经常习惯于以“作为用户……”开始每个用户故事，这是懒惰思想的结果，故事作者需要在写出许多“作为用户……”故事之前更好地了解产品的用户。
但是有时它可能表明系统不太适合用户故事。发生这种情况是因为太多的人将敏捷与编写用户故事联系在一起。他们认为，要保持敏捷，即使没有用户，您也必须编写用户故事。
我研究了财务合规跟踪系统。该系统所做的绝大多数工作将永远不会被看到或报告。但是，如果发现合规性问题，将生成报告并通知个人。该系统从用户故事中受益，因为它提供了产品整体功能的一小部分。但是用户故事不适用于系统的其余部分。
模板过于频繁地被狂热跟随
无论如何，常识必须成为敏捷团队的指导原则。当在标准用户故事模板中表达某些内容没有意义时，请勿使用该模板。用另一种方式编写它，包括很可能是自由格式的文本。
今天早些时候，我写了一个产品待办事项，题为“改变上周五电话会议讨论方式的最后一天发送网络研讨会重播提醒的方式。”
作为产品待办事项，这很糟糕。这不是用户故事。这不是BDD甚至不是工作故事（job story）。这太糟糕了。而且，如果该问题无法尽快解决，那么甚至没有人会记得在某个被遗忘的电话中所谈论的错误。
但是，我知道团队会尽快修复它，所以我写的东西足够好。我不需要一位Scrum Master坚持三段论模板来编写这个产品待办事项，而不管该模板对大多数产品待办事项的效果如何。
你怎么看
作为该博客的读者，我想知道您对三段式用户故事模板的看法，以便我可以了解您如何使用（或不使用）它。（请问我在那儿做了什么？）请在下面的评论部分中分享您的经验。