用户角色建模：

每一款产品都有自己的受众，我们需要对自己产品的受众进行分析，看看这些用户使用产品的习惯是怎么样的。这样可以更好的提取用户的需求。

1.  找出产品的受众，这个流程一般被称为用户角色建模

用户角色建模方式：通过头脑风暴的方式列出可能的用户角色集合

思考：以“饿了么”软件为例，一般都是什么样的人会叫外卖呢？劳累一天的上班族，学校的学生，偶尔想改善伙食但不想出门的人，加班的人，不会做饭的人。

2.  用户角色整理

方式：看看角色之间有没有包含或者重合的地方，如果有，则需要考虑是否有角色需要被丢弃。

思考：不会做饭的人并没有典型的特征，在上班族、学生、加班的人中都可能会有不会做饭的人。不会做饭的人完全可以被其他角色所代替，这个用户角色就可以被丢弃了。

3.  每个角色写下一些特征

方式：在小卡片上将不同的角色分类，每个角色下写下一些特征，方便的对用户角色进行分析

4.  重要用户角色建立角色实例

角色实例是一个贴近生活的用户场景，通过角色实例可以建立起一个真实的人物，让我们对角色有更真切的了解。

案例：（假设上班族是我们的目标用户，上班族建立的角色实例）

角色实例

需求源于角色

用户建模是为收集需求做准备，不同的角色肯定会有不同的需求，这个时候，我们需要将自己代入角色，仔细想想如果自己是这个角色，会有什么样的需求。将所有考虑到的需求都记录下来，为以后的需求整理做准备。

区分需求的优先级：

在需求收集和整理完成后和项目开始开发之前，我们需要召开需求评审会来确定每个需求的优先级和开发计划。

用户故事整理用户需求：

用户故事通常使用客户和团队都可以看懂的表达方式来写，每一个用户故事都是产品的一个需求。当然，用户故事还包括需求的商业价值和相关人员。使用用户故事可以方便的与客户沟通，而且不用查看繁琐的需求文档。

用户故事一般使用如下格式：为了[商业价值]，作为[角色]，我想要[做某事]。

用户故事确定后评审流程：

召集开发人员、产品相关的人员来参加需求评审会，在会议上，我们需要对每个需求的商业风险，技术风险，开发耗时和优先级作出评估。

1. 确认商业风险，也就是确定哪些是核心需求，哪些是亮点需求。

核心需求需要尽早完成，缺失了产品就不完整。

亮点需求有则会给产品加分，没有也不会影响用户的使用。

一般来讲，核心需求的商业风险会比较低，因为这些需求都是产品必须的，被砍掉的可能性很低。而亮点需求的商业风险就会高，可能会因为开发时间不足而被砍掉或者被放入下次版本迭代的周期中。

2. 确定技术风险和开发耗时

技术风险代表的是这个需求开发的难易程度。
如果这个需求所需要的技术开发团队从来没接触过，需要对这个技术从头开始学习。那么这个需求的技术风险就会很高

2.1 技术风险的评估

技术风险的评估对开发耗时的评估有很大影响。开发耗时在Scrum开发团队中一般用时间点来计算，一个时间点代表一个理想工作日。

一般使用斐波那契数列来划分时间点的等级。使用斐波那契数列来划分时间点，这个时候工程师只需要考虑这个需求的耗时更靠近89还是144，而不用为了细小的差别而争论不休。

在评估技术风险和开发耗时时，一般都有技术人员和项目经理来确定，其他人员不应该左右技术人员和项目经理的思维。

3.  评估需求的优先级

综合分析以上三个要素，来最后给需求评估优先级。

3.1 核心需求的优先级往往是最高的，不过有时候由于技术风险过大，或者开发耗时过长，有些核心需求的优先级会被降低。

3.2  在优先级评估完毕后，开发团队会确定第一轮的迭代要完成的需求。

4.  需求评估后，开发团队进入开发阶段

通常会有一些需求管理工具，如JIRA等

注意⚠️

在开发过程中，需求的变更是必然会发生的。正常情况下，如果一轮迭代已经开始了，Scrum团队是不会中途停止的。新的需求必须在下一轮迭代中才能加入，这样可以保证开发的正常秩序。

为此，我们在看板最前方新加了一项：待开发。我们会将变更的而且有限级高的需求放在这一列，以保证在下一轮迭代中实现这些需求。

需求的实例化：

需求的实例化可以解决这些问题。需求的实例化是不再编写和维护需求文档，而是直接使用高质量的测试用例作为需求文档。

通过测试用例可以很清楚的看到产品的需求内容，而且，在需求变更时，必然会产生新的测试用例，而不必费力去维护。在清晰的表现需求的同时，减少了维护需求文档的人力。