Scrum团队通常喜欢使用用户故事来表示待办事列表项目。但是很不幸，一个用户故事中最重要的一环通常会被渐渐忘掉，那就是用户故事应该保持简短，慢慢地用户故事失去了它的本质和效力。
用户故事现在通常以“作为一个…我希望能…”的形式来描述。用户故事的编写者，应该马上利用约束列表或者自动化验收测试的形式来记录下该用户故事的验收标准。很多人觉得如果团队以外的成员（例如，高级经理或者股东）不能在没有别的文档的帮助下明白用户故事的目的，那么这个用户故事的编写就是失败的。
一个理想的用户故事的描述应该是一个简要的描述——Robert Martin把它叫做“助记令牌”。
众所周知的过去
Ward Cunningham在1995年第一次用他的模式语言提到了用户故事。这种模式被命名为“暗喻需求”。
承诺通常指的是开发团队需要在一定程度上或者一定时间内满足客户的需要。在这里需要做的就是定义一个足够详细描述，使开发人员不需要花费额外的功夫来分析需求，也不会对解决方法带来太多的影响。所以，选择然后为功能命名，关键是要选择对用户有意义并且和产品提案相同的名字。这样客户就可以根据名字了解相关的需求，而不再需要像传统的方式一样去查找需求文档。
在这个他举了一些例子，如“高质量打印”和“结算日处理”。在相关的“工作队列”模式中，在这些项目很明显地只是起到暗示的作用。这些项目真的只是名字而已，而且需要交付的东西可能没有定义得足够好，我们能够看到的只是一个愿景或者希望，而不是一些实际的可以量度的东西。
除了Jim Coplien and Neil Harrison在他们的《敏捷软件开发组织模式》以外，现在很少人会用“暗喻需求”这种说法了。在行业中更为广泛使用的术语是“用户故事”。而在这个称谓变成主流以前，它只是一个在极限编程的文献里面提到的一个概念而已，那时候大家管它叫“故事”。
告诉我一个故事
“故事”这个术语最早出现在Kent Beck’s的《极限编程解析》里面，这本书在1999年出版。在词汇表中给出的定义是：“客户希望系统能够做的事情”。在“计划的策略”一章里面解释了一个故事是写在索引卡上面的，卡上应该包括一个名字和一段关于该故事的目的的简短描述。
在《极限编程解析》一书中提到的用户故事的文档长度已经超越了在“暗喻需求”模式中提到的只有名字的长度。然而，在第二年出版的《极限编程计划》中，Beck又把用户故事的长度缩短到了最小。于此同时，他可开始使用了现在最流行的“用户故事”的说法。
你会用它吗？
在《极限编程计划》中，Beck和Martin Fowler从新解释了用户故事的定义，在书中提到，只有在你真正需要组织这些用户故事的时候才有必要补充详细的信息，而不是在这些故事被创建的时候。
用户故事越短越好。用户故事体现的是一个概念而不是一套规范。“用户故事之不过是一个客户和开发人员需要一个讨论一个功能的一项协议”。如果客户能够在开发人员编程的时候更他们一起工作的话，记录细节就完全不必要了，当然这是不可能的。也就是说，你并不是完全不需要所有细节，你只是不需要马上得到所有细节而已。当你整理这些用户故事的时候，你才需要更多的细节。需要注意的是，无论你需要做什么来获得细节，一定要在真正需要细节的时候再来关注细节。
Mike Cohn在《用户故事应用》一书中强调：“让开发团队和客户去讨论这些细节会比把这些细节写在用户故事里面更好。也就是说，在细节变得重要的时候再进行相关讨论。”
当团队延迟处理细节的时候，他们实际上能够减少潜在的时间浪费，从而减少开发软件的成本。试想一下，如果一个用户故事的优先级降低到可能永远不会被用到，那么创建和维护这个故事所付出的努力就等于被浪费了。正如David Anderson在他的《敏捷项目管理》中提到的：“为了能够最大化产能，应该要最小化变化所带来的浪费。”
你有更重要的事情要做吗？
少量文档的另外一个好处就是可以节省下书写的时间。无论是编写一段描述，还是一个验收条件列表都是需要时间的。Product Owner有很多各种各样的事情要做——市场调研、客户关系、竞争力分析、产品特性革新、发布计划、验收测试、管理层会议等等。难道编写文档是最有价值的事吗？
除此以外，过多的文档可能会导致变成负担，因为编写的人可能会觉得由于需求变更而导致需要重新编写或者对已经写好的用户故事调整优先级是一种浪费。
这种用户故事的实践非常灵活，因为我们只需要花费很少的时间来创建一个用户故事。然后我们就可以根据新的信息和环境改变的需要来调整优先级而不需要担心浪费了之前的努力。到最后，就能够提高工作效率从而降低开发成本。
强调回忆
如果用户故事只包含一个名字的话，那么开发人员从哪里得到用户故事的细节呢？这种简短的用户故事起到的作用就是Amr Elssamadisy所说的“能够勾起回忆的文档”。“这些文档能够勾起记忆、谈话和编写这些文档的人的处境。”使用“回忆文档”模式的团队会花更多的时间进行面对面的讨论，而不需要太多的建立和维护文档的时间。这些团队所需要的文档通常只是刚好足够详细得让他们讨论的时候能够理解。因此，如果要把文档包含的全部内容传授给某个新人的话，之前进行过的讨论和谈话的上下文都需要重复一遍。这样做的好处是，知识能够在有上下文的情景中更好地传递，从而能够更好地理解程序，降低维护成本。
这种没有细节的简洁的用户故事起着一个“强制”加强沟通的作用。“为了鼓励沟通交流，只需要记录下能够足以提醒你和其他人主题的信息。对于之前没有参加讨论的人来说，记录下来的信息不足以让他们了解足够的细节，因此他们不得不寻找合适的人的帮助。”
为什么我现在不去想它呢？
由于PO不会承诺在用户故事中写入详细的信息，团队就可以自由地发挥。创新从本质上讲是十分值得鼓励的。由于没有非常详细的规范，那么在文档中没有提及到的地方就形成了真空地带。团队就需要发挥自己的创意来填补这块的空白。
这种简洁的用户故事，使用的是一种“Just-in-time 承诺”的方式。Mary Poppendieck在他的《实现精益软件开发》中解释了这种做法的价值：“当我们在主导产品开发流程的时候，我们应该意识到产品开发是一个学习的过程，我们越晚做觉得，我们学到的东西也就越多。”
一个原则立场
根据需求变更进行实时调整的能力需要一个能够在团队修改特性的时候支持持续重构的框架。有一些敏捷团队常用的工程实践来保证软件拥有足够的稳定性和可塑性来应付持续的变更，例如测试驱动开发、重构、自动化验收测试和持续集成。群体模式如结对、团队聚集和整体代码所有等等，有利于建设能够在团队中共享知识、强调团体协作、创新的良好环境。
在这些模式当中，简洁的用户故事符合很多敏捷宣言中的很多条目：
简化
自组织
信任和启用
日常合作
进行面对面对话
欢迎需求变更
测试，测试， 1…2…3…
那么，如果一个用户故事没有在其被使用之前包含细节信息，而且能够引起回忆的文档足以在团队成员中产生共鸣，我们还需要记录下用户故事详细的信息吗？答案是肯定的。因为一旦我们开始处理一个用户故事，我们需要用自动化验收测试的形式来记录细节信息。
自动化验收测试模式是防止为了进行讨论而重复上下文的时间浪费的安全网。在合适的时候，团队会将细节信息以客观可验证而且可执行的自动化测试的形式记录。这些测试被用作回归测试的保障，让团队成员对用户故事的记忆保持在一个“永远”准确的形式下（如果测试可以稳定执行的话）。
总而言之
一个理想的用户故事是简短的：
一个名字
一个引起回忆的文档
精心制作的
如同自动化验收测试版详细的
作者:Paul Dupuy
原文地址：http://www.scrumalliance.org/articles/359-the-short-short-story
