我正在为我朋友的业务编写一个小应用程序，并想借此机会复习我在年初进行的一些敏捷项目管理培训。
我（我认为，我现在的组织！）一直在努力以用户故事的形式收集需求，其形式如下：
作为 [用户类型] 我想要 [功能] 以便 [一些好处]
我总是很想错过开始和结束，然后离开这个功能——但这只是变成了收集旧方法的需求！
但我不想让它适合，这样我就可以说“我正在做敏捷”......例如，如果我知道要向用户展示一个项目列表，那么原因不言而喻，不是吗？
例如
作为[商店经理]，我想[查看库存商品列表]，以便...？
省略 [so that] 子句是正常的做法吗？
我们曾经也错过了它。通过忽略它，我们错过了很多。要正确理解该功能，而不仅仅是做正确的事情，而是做正确的事情，关键是要知道为什么要使用该功能，而下一个关键是谁（角色）在 DDD 术语中，利益相关者。利益相关者可以是不同的，每个关心的人。从程序员和数据库管理员到所有类型的用户。
所以，首先要了解，谁是利益相关者，然后你知道他关心的 50%，然后是好处，然后几乎很明显要实施什么。
尽量不要只写“作为用户”。指定。“作为商店经理”，甚至“作为负责结束一天的轮班负责人”，我需要......所以......
也许你可以实施一些不同的东西，这会给同一个利益相关者带来更好的利益！！！
尝试，以实现 [商业价值] 作为 [用户] 我需要 [功能]。
目标是专注于功能提供的价值。它可以帮助您在垂直切片中进行思考，从而减少不可见的纯“技术任务”。这不是一个简单的过渡，但是当您开始垂直思考时，您就开始真正能够减少流程中的浪费。
另一种方法是考虑您的客户可以编写的验收测试，以确保该功能能够正常工作。然后使用FitNesse之类的东西来自动化这些测试只是一个短暂的跳跃。
不，这实际上并不明显 - 有很多理由想要查看列表，很多您可能想要使用它的东西 - 扫描它以获取一些信息，获取概述，打印，复制并粘贴到word 文档等。它究竟是什么会给你关于合理实施细节的有价值的提示——列表的格式、确切的内容；甚至暗示不同的功能可能是满足这种需求的更好主意。不要惊讶地发现原因实际上是“这样我就可以计算条目的数量”......
当然，这实际上可能不适用于您。事实上，我的实际观点是人们想出这个模板是有原因的——还有很多有经验的人实际上并没有使用它的原因。而且，当您不熟悉该练习时，您无法评估遵循练习的所有利弊，因此我强烈建议您尝试密切关注它一段时间。您可能会对它的有用性感到惊讶 - 或者不会，在这种情况下，您仍然学到了一些东西，并且可以用简洁明了的方式放弃它...... :)
用户故事是另一种说法，您需要采访您的用户以了解他们想要什么以及他们试图解决什么问题。这就是敏捷开发的核心。如果表格不适合您，请退后一步，尝试一种不同的方法，让您感觉更自然或更适合您作为作家的能力。
简而言之，不要觉得你必须穿直筒夹克。重要的是你要遵循方法论的精神。
在这种特定情况下，您希望获得用户遇到的问题、问题的原因以及他们认为对他们有帮助的列表。
我认为你真的应该尝试定义一个原因，即使它看起来很明显。如果你不能想出一个理由，那么为什么要首先构建这个功能呢？此外，原因可能会指出设计中的其他缺陷，这些缺陷可能会引发其他领域的改进。
我经常按主要相关的用户/角色对我的故事进行分类，因此我不会将用户的身份放在故事标题中。我的故事也比一些敏捷方法建议的要大。通常，我从一个标题开始。我将其用于计划目的。一旦我接近实际处理那个故事，我就会用一些细节充实它——基本的想法、约束、假设、相关的故事——这样我就可以捕捉到更多我知道的关于它的信息。我还将我的故事保存在 wiki 中，而不是记事卡上。我理解这种权衡——即，我可能会在需要细节之前花太多时间在细节上，但我能够轻松地捕捉并与通常不在现场的客户分享。
对我来说，底线是敏捷是一种哲学，而不是规范。有些特定的实现可能（强烈）建议您以某种方式做事，并且在某些项目上可能是不可协商的。例如，如果你不配对程序，就很难说你在做 XP。不过，总的来说，我会说大多数敏捷主义者会说你应该按照它们为你工作的方式做那些对你有用的事情——只要它们符合一般原则，你仍然可以调用自己敏捷。一般原则包括早期发布/经常发布、单元测试、短迭代、承认会发生变化、延迟详细计划直到你准备好实施……
对我来说，底线是：如果这些故事在没有用户和理由的情况下对你有用——只要你了解用户是谁以及他们为什么想要某样东西——就按你的意愿去做。在开始实施之前不需要完整的规范。