用户故事 - 卡片,对话和确认

时间:2013-10-19 15:35:58

标签: extreme-programming user-stories

我不了解用户故事的卡片,对话,确认公式。 我不明白是否必须写下会话和确认部分,或者它们仍然是对话,特别是CONVERSATION部分。 要明确:如果在用户故事中写下所有这些内容,这是正确的吗? (见下面的例子) 或者我是否只需要记下CARD部分?

示例:

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

交谈 - 如果用户没有足够的钱存入CoffeeMaker,用户将无法购买饮料 - 如果没有足够的库存来制作饮料,将退还用户的钱

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

2 个答案:

答案 0 :(得分:2)

3 C是一种用来提醒用户故事时重要内容的说法。

一张简单的卡片,记下要求 - 而不是重量级文件。

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

确认 - 同意验收标准,以便您知道何时完成。

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

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

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

答案 1 :(得分:0)

你可以做任何你想要的事情;),从写下一切到记忆一切,什么都不写。就个人而言,我把所有内容写下来,所以下一个能够理解这个故事的开发人员可以像我一样理解并从中获取。