我最近描述 用户故事 和一个的组成 用户故事卡 –卡，对话和确认。
I’我不太确定您是否会认为此用户案例示例是好是坏或无动于衷–我想这取决于你’re used to –但这仍然是一个例子！
这是卡的正面。
的 卡片部分描述了用户故事。对话部分提供有关该功能的更多信息。
请注意，该功能（用于用户登录网站）很小，因此可以在小卡片上很好地描述故事。
显然’不如传统规范那么详细，但对视觉表示进行了注释 一次仅提供一个小功能，这对于团队成员来说是相当自我解释的。
我当然会争辩’比冗长的规范更容易消化，特别是对于业务同事而言。
这是背面 卡的:
卡的背面概述了此功能的测试用例– how it’待确认。
这些是正确的方案，还是涵盖所有可能的方案，’确实是这个例子的重点。
关键是该功能的测试用例写在卡的背面，以支持有关该功能的信息，并且在开发该功能之前。
一般而言， 需求场景 和一个测试用例，所以不是’不必在卡的正面捕获过多的细节并将其弄乱。完整的卡 表示功能要求；是在“对话”部分还是在“确认”部分中捕获的。
甚至用户故事的描述 卡片部分中的一些重要信息。在这种情况下，存在先决条件（必须注册用户）和后置条件（用户可以访问仅订户内容）。所有卡 必须阅读完整的故事。
重要的是，用户故事以商务语言和微型，更易于消化的信息打包格式表示。
凯莉
