今天，读到了次本书的第三部分——经常讨论的话题，用户故事不是什么，用户故事的优势与不良征兆。
第一，用户故事不是软件需求规格的指南，这种需求规格指南强调的是“系统应该……”，而且对于需求规格指南而言，在写下需求之前，每个需求的成本是不可见的。典型的情况是，一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档。随后把文档交付给程序员。这时程序员告诉分析师(消息会被转告给用户)，完成项目要24个月，而不是分析师所希望的6个月。在这种情况下，分析师在编写团队没有时间开发的四分之三部分的文档上浪费了很多时间，而且在开发人员、分析师和客户之间反复讨论需要在有限的时间内先开发哪些功能上会浪费更多的时间。每个故事开始都会有一个估算。客户知道团队的速率，也知道每个故事的故事点数。编写完足够填满所有迭代的故事后，她知道自己的任务已经完成了。
想对于传统的需求规格指南，用户故事还是有很多优势的，第一，促进口头沟通，大家共同讨论得出最完美的解决方案，众人拾柴火焰高嘛；第二，用户故事没有繁杂的领域术语，这些东西会让开发人员无所适从，所以用户故事比用例和场景更加容易理解；第三，用户故事的大小适合做计划，用户故事时可以根据实际情况和需求进行划分的，所以故事大小可以掌控，也可以很方便地用户做发布规划以及进行编程和测试；第四，用户故事适合于迭代开发，在开始编码之前，我并不需要写出所有的用户故事。我可以写出部分故事就进行编码与测试，然后按照需要的节奏重复这个过程。写故事时，我可以按照合适的粒度去写。正是由于我们很容易对故事本身也进行迭代，所以用户故事很适合迭代开发；第五，用户故事鼓励延迟细节，可以迅速让所有人对要开发的系统有一个整体的概念；第六，用户故事支持随机应变的开发并鼓励参与性设计，用户故事引人入胜，能激发用户的积极性，让开发人员和用户间的关系变得亲密主动，这个良性循环啊使所有开发中设计的人和软件使用者都受益良多。
虽然用户故事相对于传统文档而言优势很多，但是我们也应该正确看待它的不足。首先，故事互相依赖，用户故事之间一旦由于设计偏差导致关联度高的话，很可能不利于迭代往往适得其反；二，由于开发人员在迭代中实现了计划外的功能，使得实际功能超出实际需要；三，细节太多，不应该花太多时间去写故事而是讨论故事；四，过早考虑用户界面细节，我们应该尽量避免写关于页面的故事；故事划分频繁而且客户很难为故事安排优先级或者客户不愿意写故事也不愿意为故事安排优先级。
用户故事是辅助工具，我们更需要的是敏捷方法，靠思考讨论把团队不断引导到正确简洁的方向上去。