为什么要改变？

你可能会问到这几个问题：“为什么要改变？为什么要写故事卡，并保持所有这些对话？为什么不继续编写需求文档或者用例呢？”因为用户故事展现了许多优于其他方法的优点。在第13章中提供了更多的细节，一些使用用户故事的原因如下。

用户故事强调的是口头沟通而不是书面沟通。

用户和开发人员都可以理解用户故事。

用户故事的大小适合做计划。

用户故事适用于迭代开发。

用户故事鼓励推迟细节，直到你对自己真正需要的东西有了最好的了解。

因为用户故事的重点在于对话和远离书面，所以重要的决定不会被记录在不太可能被阅读的文档中。相反，关于故事的重要方面会记录在自动化验收测试中频繁运行。此外，我们避免使用含混不清的书面文档，比如：

系统必须存储地址和业务电话号码或者移动电话号码。

这是什么意思？这可能意味着系统必须存储其中一个：

（地址和商务电话）或者移动电话；

地址和（商务电话或者移动电话）；

因为用户故事没有技术术语（请记住，是客户团队编写了这些业务术语），

所以无论是开发人员还是客户团队都可以理解它们。

每个用户故事都代表一个独立的功能块，换言之，就像用户在一个单一环境下可能做的事情。这使得用户故事适合成为一种做计划的工具。你可以评估在不同的发布版本之间调整故事顺序的价值，这远胜于估计去掉一个或者多个“系统应该……”类似陈述所产生的影响。

迭代过程是一个逐步求精的过程。开发团队对系统进行第一次切割实现，知道它在某些（可能是许多）区域是不完整的或者薄弱的。然后，他们不断细化这些领域，直到产品令人满意为止。每一次迭代都通过增加更多细节来改进软件。对于迭代开发来说，故事可以很好地适用，因为它也可以迭代这些故事。对于一个你最终想要的但现在并不重要的特性，你可以先写一个大的故事（一个史诗）。当你准备把这个故事添加到系统中，你可以丢弃史诗，用更小的故事来代替、并且完善它。

允许故事鼓励细节延迟，使故事集能够迭代这一能力得以体现。假如今天你为系统的一部分编写了一个占位符史诗，就没有必要写出这部分的故事，除非马上就要开发实现这部分。推迟确定细节是很重要的，因为它允许我们在不确定新特性是否真的被需要之前就不需要花费时间去考虑。故事劝阻我们不要假装知道并事先写下所有东西，相反，故事鼓励这样一个过程：在客户团队和开发人员之间的讨论中，软件被迭代细化。