1999年，KentBeck出版了一本革命性的《解折极限编程一一拥抱变化》。一夜之间，我的这份愧疚烟消云散。终于有人旗帜鲜明地提出开发人员和客户之间用交谈取代“写文档-商谈-再写文档”。Kent阐明了许多事情，带给我许多有用的方法。但最重要的是，他证明我在实践中领悟到的是正确的。大量预先的需求收集和文档会以很多方式导致项目失败。最常见的是需求文档变成软件开发的目的。应当只在对交付软件有用时才写需求文档。
大量预先的需求收集和文档导致项目失败的另一个方式是记录语言的不准确性。
什么是用户故事？
用户故事描述了对用户、系统或软件购买者有价值的功能，用户故事由以下三方面组成
一份书面的故事描述，用来做计划和作为提示
有关故事的对话，用于具体化故事细节
测试，用于表达和编档故事细节且可用丁确定故事何时完成
由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries 2001年对这三个方面起了一个非常好的以相同英文导母开头的名字：卡片（Card，对话(Conversation)和确认(Confirmation)
卡片可能是用户故事最明显的表现，但它并不是最重要的，Rachel Davies(2001)说过“卡片代表客户需求而不是记录需求”
这是对用户故事的最佳诠释：卡片包含故事的文字描述，然而需求细节要在“对话”中获得，并在“确认”部分得以记录
为什么要变？
现在你可能会问，为什么要变？为什么编写故事卡并进行所有这些对话？为何不继续编写需求文档或者用例？相较于其他方法，用户故事可谓优势多多，但部分理由如下：
• 用户故事强调对话交流而不是书面沟通
• 用户故事以同时被你和开发人员理解
• 用户故事的大小适合于做计划
• 用户事适用于迭代开发
• 用户故事鼓励推迟考虑细节，直到你非常清楚地了解自己的真正需求
由于用户故事的重点从文档转移到对话，所以重要决策不会写在文档里，因为很可能没有人阅读那些文档。取们代之的是在自动化测试中捕获用户故事的重要方面。
理想情况下，故事之间是独立的，有时很难做到这一点，但我们要尽量实现这一目标，故事之间的交付顺序应该是无关的，可以任意拿一个故事来实现。
故事细节由用户和开发人员讨论得出。
故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事
故事可以注释一些细节，但是过多的细节会使故事难以理解，也可能给人一种开发人员和客户无需交谈的错觉
给故事加上注释的最好方法是给它编写测试用例
如果故事太大：复合故事和复杂故事可以分成几个小的故事。
如果故事太小：几个小故事可以合并成一个较大的故事·
故事应该是可以测试的。
不要忘记意图
不要忘记，故事卡的主要H的是用*提开发人员和客户团队对功能进行讨论的·既然仪仅是一个提．獻要保恃它的简洁性·加入需要的节，以便联想到继续对话的切入点，但不要在牧事卡上加入太多细并以此取代对话·
细节太多
在实现散事之前花太多的功庆去收集整理故事细节·也有可能是花太多的时间去写故事而不去讨论故事。讨论·把故事写到小卡片上的一个好处是在小卡片上只能記录下很有限的东西。很难把很多具体细节记录到小卡片上·如果在故事中包括太多的细节·这说明团队过于重视文档，而忽视了口头交流．TomP叩pdi“23）评论说“如果总是需要写小卡片·那下一次用一个更小一点儿的卡片“”这是个好主意，因为这能够迫使故事作者有意识地减少记录过多的故事细节。