这本书放书柜中少说也有3年了，最近终于读完了。在没有读本书之前，虽然课上老师也讲用户故事，但是其实一直是对这个概念比较模糊，当时的理解就是用户故事就是简单的模拟用户使用软件的情形，也仅仅是模拟用户使用软件的场景描述，没有什么其他太多的理解。但是读了这本书后，对用户故事有了更为深刻，甚至可以说是对用户故事的真谛有了一些了解。
用户故事描述了对用户、系统或软件购买者有价值的功能。主要包括三个方面：
1、一份书面的故事描述，用来做计划和作为提示。
2、有关故事的对话，用于具体化故事细节。
3、测试，用于表达和编档故事细节且可用于确定故事何时完成。
这三点又被简称为：卡片、对话和确认。
以前理解的用户故事就是一个情景模拟，对编程没有太大帮助，而且当时的用户故事都写得比较笼统，看了书后才知道只有写的适度详细的用户故事才能更好的帮助编程，在我们写用户故事时，首先写出来的用户故事要能代表对用户有价值的功能。这就需要我们在写用户故事之前，确定好用户的范围以及用户的真实需求。只有这样写出来的用户故事才能代表用户有价值的功能。
用户故事还要写的够细节，因为只有足够细节的用户故事，当然也不用太过细节，理想的情况是所写的故事能够让一两个程序员花半天到两周时间完成代码和测试。只有写出了对细节描述准确而又不是太过细节的用户故事才可以协助程序员更快更好的完成用户故事所涉及的软件功能。
完成时间也是用户故事记录的另一条信息，而完成时间就是项目用户的期望时间，同时我们还有理解项目用户的期望是什么，用户的期望最好以验收测试的 形式记录下来。测试描述可以简短、不完整，可以在任何时候加入或者删除。写这些测试描述的目的就是传递故事的额外信息，以便于开发人员知道故事于什么时候结束。这对于开发人员更好的理解用户需求是很有帮助的。
用户故事就是为了开发人员与软件的使用者沟通的中间传话人，通过用户故事可以更好的理解用户需求，只有对用户的真实需求理解透彻了才能写出好的软件，做出客户满意的产品。
