用户故事 - 卡片、对话和确认 [关闭]答案

【问题标题】：User stories - Card, conversation and confirmation [closed]用户故事 - 卡片、对话和确认 [关闭]
【发布时间】：2013-10-28 08:48:01
【问题描述】：

我对用户故事的卡片、对话、确认公式一无所知。我不明白对话和确认部分是否必须写下来，或者它们仍然作为对话，特别是对话部分。需要明确的是：在用户故事中写下所有这些内容是否正确？（见下面的例子）还是我只需要写下 CARD 部分？

例子：

卡作为咖啡机的用户，我希望能够购买饮料。

对话 - 如果用户没有在 CoffeeMaker 中存入足够的钱，他们将无法购买饮料 - 如果没有足够的库存来制作饮料，用户的钱将被退回

确认 1位用户介绍购买饮料所需的金额 2 用户选择饮料 3 位用户获得饮料

【问题讨论】：

【解决方案1】：

你可以做任何你想做的事;)，从写下所有内容到记住所有内容并且什么都不写。我个人把所有的东西都写下来，这样下一个接听这个故事的开发人员可以和我一样理解并从那里接过来。

【讨论】：

【解决方案2】：

3C 是一种说法，用于提醒人们在使用用户故事时什么是重要的。

写下要求的简单卡片 - 与繁重的文档相反。

进行对话 - 合作定义需求并理解价值。

确认 - 就验收标准达成一致，以便您知道何时完成。

还有一句话很好地总结了用户故事背后的想法。 “卡片是对话的占位符”。这凸显了对话是重要的部分，而不是卡片神器。一旦开发了功能并使用任何合适的可接受标准编写了自动化测试，就可以丢弃该卡。

用户故事的格式通常如下：

As a (role) - This can be an end user or a business proxy

I want - A description of what need to be done

So that - the definition of the value

尝试你的场景

As a vending machine customer

I want my change returned 

So that I do not loose my money

确认部分可能只是背面的要点

或者您可以使用上下文规范样式，一种 BDD（业务驱动开发）技术

Given a customer does not put in enough money
When they select a beverage
Then their change should be returned

如果您想了解更多信息，我建议您研究 INVEST 原则并阅读 Mike Cohn 的 User Stories Applied。

【讨论】：

所以按照你的回答，我应该做的是用“作为（角色）我想要（描述）所以（定义）”格式写下卡片部分。关于我上面例子的另一个问题：你做了一个关注退款的用户故事的例子。你不认为这部分可能是一张卡片背面的废话，而不是一个全新的用户故事吗？（这只是一个例子，还是你想告诉我，如果我写一个与饮料购买整个过程相关的用户故事，我做事的方式不对？）
如何分解用户故事完全取决于您和您的团队。使用 INVEST 原则作为指导。确保您作为一个团队并在产品负责人在场的情况下分解和整理积压工作。这就是所有魔法发生的地方（对话）。你会发现人们对于如何分解一组需求有各种各样的想法。
为了扩展 Will 关于卡片是“讨论的占位符”的评论，我将卡片视为一个起点。你拿着卡片/故事，你有你的讨论，然后输出是一组最终定义需求的验收标准。如果你能在卡片背面符合这些标准，那就太好了。如果没有，您可以将故事拆分为多个较小的故事，或者将标准存储在其他位置。