在远古时代，文字没有出现之前。知识的传承靠口口相传，不管隔了多少代，其准确性很高。文字出现后，我们大脑中的这种技能反而逐步衰退。于是各种软件、各种方法充斥着我们，左右着我们。各位是否也有相同的想法？试想一下，上节课我们讲了什么？每次应允别人的承诺，我们转过头就忘记？比如忘记约会，忘记洗车、忘记写日报？
“要想知道栗子的味道，你得咬一口”这个真理朴实，正确。当用户提出一款软件时，我们不要只想着从技术的角度，认为用户不专业，他的需求是错误的。如果他专业，就没我们啥事了。用户大脑中的需求是离散的，不可控的，这时，就需要我们放下成见，彼此真诚相对，让用户参与进来，通过各种方法，一条条梳理，直至双方的理解是一直的。
其作用：1.我们弄懂了用户为何会这样想。2.用户通过亲身参与，头脑中的需求逐渐变成技术可理解的。“求同去异”是一个很难的过程，需要双方彼此做出改变，很难.....，往往难得事情才是最重要的，要不怎么会有“战胜困难”的伟大，痛苦成就了欢乐。
软件的最大价值只有在用户认可，使用才算真的有价值。“再牛逼的算法，再严谨的逻辑”不符合用户实际需求，都是白费力气。“当顾客很饥饿时，他只需要的立马填报肚子的食物，而不是需要几天或者几个月才能做好的满汉全席”。
扯远了，回归正题。因用户对软件领域不专业，脑中对需求没有一个正确的定论。就需要我们专业人士，运用特殊的方法，梳理用户真正的意图。“用户故事”无疑是最好的方法之一，其包含三个要素“角色、活动、商业价值”，用户故事的表达方式：”作为一个<角色>，我想要<活动>，以便于<商业价值>，
“例：作为一个很饥饿的顾客，我想要一份食物，来填饱我的肚子“。这就是一份明确的用户故事。
那么要实现这种记录方法，有三个原则：卡片：故事一般写在小的记事本上。故事尽可能对当前的需求简单的描述，其作用是为了以后的交谈；交谈：故事背后源于我们和客户/产品负责人的沟通交流；确认：可以确认验证的正确结果、通过验收测试确认的用户故事被正确完成，才算整的完成。
敏捷开发故事细化为开发提供了可执行标准，其特点是快速迭代，故一个用户故事的大小和复杂度应该在一个迭代周期内完成。如果是史诗那样的故事，可能会导致它需要“几代人”（几波人，即有可能只做了一半，团队砍了，新人接手），其弊端不是本次重点。每个人物最好不要超过8小时，如果超过8小时，说明任务的划分是有问题，如何做到事事清日日清？
用户故事的6个特性：
- 独立性
- 可协商性
- 有价值的
- 可以估算的
- 短小的
- 可测试的
正是每个故事的独立性，才保证其短小，可以估算，也可协商（更改某个故事对系统的影响很小），最终交付给用户才是可以测试的，只有软件通过用户的测试，软件的价值才会被最大化。要避免”孤芳自赏“，做技术的，多少有点读书人的清高，说通俗点就是有”臭老九“的毛病，我的产品是最好的，你客户不认可，是你的问题。要学会转变（不是服软），运用有用的方法，来实现可协商，可以估算、等六个特性，做到刚柔并济....
确定用户故事的优先级，有几种方法：
- 相对优先级=价值/工作量
- 莫斯科规则：必须有的、应该有的、可以有的、这次不会有的；按照价值进行分类，优先处理必须要的和应该有的。如果离约定交付的日期还有一定的空余时间，可以考虑可以有的，反之跳过。这次不会有的，不多少，看字面各位应该会理解。
- 卡诺模型：1.基础型需求；2.期望型需求；兴奋型需求。搞过KPI的都会知道，关于目标会有门槛值、期望值、挑战值，往往我会按挑战值的来做，最终有可能实现期望值，别问我怎么知道的.....
- 风险--价值指标：确定优先级的同时，要考虑风险和价值，至于是先处理哪一个？灭火时，消防员会优先处理哪一个？娃娃一个不哭、一个哭闹时，我们会优先关注哪一个？
确定好用户故事的优先级后，我们将这些故事组成产品待办列表（product backlog），根据backlog和团队速率（至于如何估算，以后会讲）来估算故事规模，并确定最终的发布计划。