敏捷-用户故事定义

Question

我正在为我朋友的业务编写一个小应用程序，我想利用这个机会来复习一下我在年初做的一些敏捷项目管理培训。

我(我认为，我现在的组织！)一直在努力收集用户故事形式的需求，这些需求的形式如下：

作为一个用户类型，我想要一些功能，以便有一些好处

我总是想错过开始和结束，只留下特性-但这只是成为需求收集的旧方式！

但我不想让它适合，这样我就可以说‘我在做敏捷’.例如，如果我知道用户将得到一个项目列表，那么原因是不言而喻的，不是吗？

例如：

作为一名商店经理，我想看一份库存商品清单，以便……？

省略该条款是正常的做法吗？

Answer 1

我们以前也很想念它。我们错过了很多。要正确理解特性，而不仅仅是正确地做事情，而是做正确的事情，关键是要知道为什么要做这个特性，而下一个关键是WHO (角色)，在DDD术语中，涉众。利益相关者可以是不同的，每个关心的人。从程序员和db管理员到所有类型的用户。

所以，首先要了解的是谁是利益相关者，然后你就会知道他为什么关心这个问题，然后是他的利益，然后它已经很明显地说明了应该实现什么。

不要仅仅写“作为一个用户”。具体说明。“作为商店经理”，甚至“作为负责结束一天的班次的领导”，我need....so .

也许你可以实现一些不同的东西，这将给同样的利益相关者更好的利益！

Answer 2

尝试，以实现业务价值的用户，我需要的功能。

其目标是将重点放在功能提供的价值上。它帮助您在垂直切片中思考，这减少了不可见的纯“技术任务”。这不是一个容易的转变，但是当你开始垂直思考的时候，你真的能够减少你的过程中的浪费。

另一种方法是考虑您的客户可以编写的验收测试，以确保该功能能够正常工作。使用像FitNesse这样的工具来实现这些测试的自动化只是一小段时间。

Answer 3

不，它实际上并不明显--有很多理由想要看到一个列表，很多你可能想要的东西--扫描它，获取一个概览，打印出来，复制并粘贴到一个word文档中等等。它到底会给你提供关于合理的实现细节的有价值的提示--列表的格式，准确的内容；甚至暗示一个不同的特性可能是满足这个需要的更好的主意。不要惊讶地发现真正的原因是“这样我就能数出条目的数量”.

当然，这实际上可能不适用于你。事实上，我的实际观点是，人们想出这个模板是有原因的，而且也有很多有经验的人没有真正使用它的原因。当你刚开始练习的时候，你并不能很好地评估所有的优点和缺点，所以我强烈建议你在一段时间内尽量紧跟它。你可能会对它的有用性感到惊讶--或者不是，在这种情况下，你仍然学到了一些东西，并且可以用一个清晰的、简洁的.:)