了解用户故事

因为是借来的，要还回去，破天荒终于写了一次与工作和专业相关一点的读书笔记。厄。《用户故事与敏捷方法》是本出版于2004年的老书，不过依然颇有启发性。

书中说用户故事（User Stories）可以做到：

不再需要依赖于用户预先完全了解及沟通他们的确切需求；
也不再需要依赖于开发人员能够完全事无巨细地掌握需求；
能够拥抱变化。

因为经历过失败，所以我很清楚如果真的有什么良方做到这三点该是多么激动人心。

此书特别注重实践，乃是传授实际经验的类型，详细介绍了用户故事的执行方法，举了很多例子，段落短小结构清晰，如果忽略掉各种错别字和中译本乏味的语言，此书应该说很好读。鼓舞着人们立即改良团队的工作方式。效率最高的方法不是任何一个最新潮的方法，而是最能切实解决问题的方法。好的方法从工作中得来——如果我们每次都围绕着核心问题不断改良，而不是盲目遵从“大公司”、“最流行”的已成定势的方法。吸取他人的经验，然后灵活改变它。

最核心的问题有几个。

1. 双向沟通

以客户价值为核心，“故事应该以对客户有价值的方式写下来”，“应该坚持客户组织利益最大化的原则”。

说都是这么说，但并不都这么做。传统的需求文档因为有契约精神，开发人员容易为完成需求而完成需求，而需求讨论只停留在前期导致不能把握住客户的想法变化。且一旦早期需求未讨论清楚容易导致后面全盘失算。殊不知一个满足了需求文档的产品不一定是客户真正想要的产品。不及时与客户沟通还会导致客户不放心、不安心。死板的开发方式还绑定着死板的收费模式，越到后期越不灵活，双方怨声载道。

此书称，尽可能让客户和真实用户参与讨论，“鼓励推迟考虑细节，直到非常清楚地了解真正的需求”，“重视口头交流”，将有效避免各种悲剧。

日常的工作中充斥着因为沟通不畅而造成的误解。所有接触过客户的人都知道，客户往往不是专业的软件开发人才，他们顶多告诉你哪个同行的网站他们很喜欢，并不能把真正想要的产品表述出来。而我们的软件开发人才也不了解其他行业的具体情况。不了解需求，势必做无用功。所以，“只询问用户‘你们需要什么’是不够的，大部分用户不太善于理解，更难以表达他们的真实需求。”

“讨论才是关键，与其写下细节不如与客户讨论它”。“总是提背景无关的需求”，真正的沟通是给客户一个开放的沟通环节，不强加固有判断。讨论真正需求，而不是具体界面和具体功能。知道产品派什么用，然后再确定其特性。当需求真正明确，“用户界面会在同客户的交谈过程中产生”。

“在迭代的开始，客户就要过一遍所有故事，写一些他能想到的故事”。明确用户角色：我是谁，我要做什么，为什么。在迭代过程中，“尽量在完成一个故事后再去做下一个故事”，只在遗忘任务的时候添加任务。在每轮迭代中都不断讨论，深入理解，灵活调整。在每轮结束后再考虑追加新需求还是调整未完成的故事。在添加新故事B时，不是将B与老故事A相比较，而是未完成的故事B与已完成的故事A相比较。不断双向沟通、调整、变化。排定优先级，逐一击破。

2. 规避语言歧义

用户故事相对于连写的人都不愿看的公文式需求报告有着得天独厚的优势。一个好的用户故事以主动语态写就，简短清晰，可以灵活分割或者合并。复杂的从句不是人人都可以掌握。语言本身的歧义性在实际沟通中可能是个恐怖的陷阱。应当用严谨同时可阅读的语言描述出当下哪些地方清晰，哪些地方模糊。不能擅自夸大清晰度，也不能不去试着表述。我们规避各种无法理解的专业术语，建立起可理解的沟通桥梁，提供出从开发人员到客户都可以理解、乐于阅读、能够阅读的文本，从而“用户故事不是分析活动的产物，相反是进行分析的支持工具”。

有时候有些功能无法用简短的语言概括，那就是过于复杂或者未能达成共识。

3. 高标准的团队

团队成员之间需要有所承诺，适用于小团队，所有人不能推卸责任。用户故事看上去好像不够规范，恰恰非常强调沟通能力和逻辑思维能力。

围绕用户故事，测试是几乎同步进行的，“测试是与客户讨论新功能非常有效的方法”。既然永远无法保证产品是最完美的，但可以保证已交付的成品是OK的，可用的。在不断的使用中，能获取新的意见。

记住用户故事：卡片 Card / 对话 Conversation / 确认 Confirmation

不要流于形式。卡片不是核心，核心在于加强沟通，消除隔阂，打破沟通不畅造成的壁垒，减少重复劳动，产生价值。这只是抛弃陋习的方法之一。

用户故事与敏捷方法
User Stories Applied: For Agile Software Development, 2004
Mike Cohn
清华，2010年4月版
User Stories Resource