00.用户故事好处
a.用户故事强调口头沟通
b.人人都可以理解用户故事
c.用户故事的大小适合做计划
d.用户故事适合于迭代开发
e.用户故事鼓励延迟细节
f.用户故事支持随机应变的开发
g.用户故事鼓励参与性设计
h.用户故事传播隐性的知识
01.在尝试之前，你或者会天真地以为只需要把一堆软件需求写下来，开发人员就能够精确地开发出你所想要的。然而，我们有时候连简单的午餐菜单都无法准确地描述，写出软件需求的难度可想而知。
02.短时间的即时反馈能促进相互学习与理解。文档所表现出的精准和精确的家乡不会子啊谈话中出现。没有人会对一次交谈签名确认，所以也不会有人后来拿出来指着说：“就是那次三个月前某周二，你说过密码不能有数字的。”
03.使用用户故事的目的并不是让我们事无巨细地记录下想要的特性；相反，用户故事作为提示语句提醒开发人员在将来需要与客户进行沟通与交谈。
04.我认为，写出“完美的”需求永远都是高不可攀、遥不可及的。
05.相对于追求完美的需求，更有价值的是运用频繁的沟通来加强恰当的故事。
06.相信我们能够写下一个系统的所有需求，然后从上往下想出解决方案，者想来就是一个美丽的陷阱。理由：
a.用户及客户通常都不会准确地知道自己的实际需求
b.即便软件开发者知道所有的需求，很多需求细节只能随着他们的开发进展变得清晰
c.就算假设所有的细节可以在前面弄清楚，人们也没有能力理解这么多的细节。
d.就算我们真的能理解所有细节，产品的项目也会经常变更
e.人非圣贤，孰能无过
07.这种方式中，他们对需求的思考不断地创建及讨论使用场景，在不同（opportunistic）层面的抽象的设计之间来回切换。一旦发现需要切换抽象层次，他们立刻就会切换思路。
a.不再需要依赖于用户预先完全了解及沟通他们的确切需求
b.也不再需要依赖于开发人员能够完全事无巨细地掌握需求
c.能够拥抱变化
08.在参与性设计中，系统的用户作为软件行为设计团队的一份子。他们的参与不是因为管理层的指令（“你们应该组成一个包括用户的跨职能团队”），而是因为他们被所使用的需求及设计技巧大大吸引，从而自动成为团队密不可分的一部分。从一开始，用户就在帮助建立用户界面的原型，而并不是登到审核最初的原型后才参与进来。
09.故事及场景易读、易懂，因而能激发用户的积极性，成为软件设计的参与者。同时，随着用户渐渐掌握如何使用对于开发人员直接有用的故事来描绘他们需求是，开发人员与用户间的关系会白嫩的更加密切和主动。这个良性的循环使所有开发中社会及的人或者软件使用者获益良多。
10.缘于对面对面沟通的重视，故事能够促进团队内隐性知识的积累。开发人员与客户之间以及他们内部的沟通越密切，越多的隐性知识能得到传播与加强。
11.故事在一个团队内部能大大促进隐性知识的积累，但是还是不适用特大规模多团队的结构。这时，确实需要把有些交流记录下来，不然难以保证信息在大型团队中充分共享。
12.用户故事适合于迭代开发，我们很容易从一个史诗故事入手，并在后来需要时把它分成多个小故事。