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