3.欲望也有轻重缓急
　　在需求收集和整理完成后和项目开始开发之前，我们需要召开需求评审会来确定每个需求的优先级和开发计划。如果你的团队正在使用Scrum敏捷开发，那么你们一定在用用户故事来整理用户需求。用户故事通常使用客户和团队都可以看懂的表达方式来写，每一个用户故事都是产品的一个需求。当然，用户故事还包括需求的商业价值和相关人员。使用用户故事可以方便的与客户沟通，而且不用查看繁琐的需求文档。
　　用户故事一般使用如下格式：为了[商业价值]，作为[角色]，我想要[做某事]。还是使用“饿了么”软件为例，比如上班族想找到送外卖快的餐厅的需求可以表述为：为了让外卖更快的送达，作为上班族，我想要查看每家餐厅的外卖送达预估时间。
　　在用户故事确定以后，我们需要召集开发人员，客户还以一些产品的相关人员来参加需求评审会。在会议上，我们需要对每个需求的商业风险，技术风险，开发耗时和优先级作出评估。
　　首先需要确定的是商业风险，也是确定哪些是核心需求，哪些是亮点需求。核心需求需要尽早完成，缺失了产品不完整。而亮点需求有则会给产品加分，没有也不会影响用户的使用。一般来讲，核心需求的商业风险会比较低，因为这些需求都是产品必须的，被砍掉的可能性很低。而亮点需求的商业风险会高，可能会因为开发时间不足而被砍掉或者被放入下次版本迭代的周期中。
　　下来需要确定技术风险和开发耗时，技术风险代表的是这个需求开发的难易程度。如果这个需求所需要的技术开发团队从来没接触过，需要对这个技术从头开始学习。那么这个需求的技术风险会很高，因为这个新技术不知道开发团队是否能掌握，多久才能掌握。技术风险的评估对开发耗时的评估有很大影响。开发耗时在Scrum开发团队中一般用时间点来计算，一个时间点代表一个理想工作日。在我的团队中，一般使用斐波那契数列来划分时间点的等级。因为我们发现工程师经常在为一个需求的时间点而争论不休。如果为一个需求是2个时间点还是3个时间点而争论，这是有意义的，因为3个时间点比2个多了一半的工作量。但是如果在为一个需求是99个时间点还是100个时间点而争论是没有意义的，因为这一个时间点的差别对我们的影响很小。为了避免这种无意义的争论，我们使用斐波那契数列来划分时间点，这个时候工程师只需要考虑这个需求的耗时更靠近89还是144，而不用为了细小的差别而争论不休。在评估技术风险和开发耗时时，一般都有技术人员和项目经理来确定，其他人员不应该左右技术人员和项目经理的思维。
　　后则是评估需求的优先级，综合分析以上三个要素，来后给需求评估优先级。一般情况下核心需求的优先级往往是高的，不过有时候由于技术风险过大，或者开发耗时过长，有些核心需求的优先级会被降低。在优先级评估完毕后，开发团队会确定第一轮的迭代要完成的需求。如果是使用Scrum敏捷开发有一段时间的话，开发团队是知道自己在一个迭代周期能够完成多少时间点的任务的，也是团队的速率。一些高优先级的需求由于时间点太大而不能放入本次迭代，而使用其他优先级相对较低但时间点小的需求代替的情况也会时常发生。
　　4.让欲望在掌握之中
　　在完成需求评估后，开发团队会进入开发阶段。在Scrum团队中，需要对开发中的需求进行管理。常用的方法是在一块木板或是一面墙上列出正在开发的，开发完成的，正在测试的和完成了的需求。这块木板或强被称为看板。每个人都可以在看板上清晰的看到团队现在的开发状况。我的团队没有使用实体的看板，而是使用JIRA这个软件提供的电子看板。
　　在开发过程中，需求的变更是必然会发生的。正常情况下，如果一轮迭代已经开始了，Scrum团队是不会中途停止的。新的需求必须在下一轮迭代中才能加入，这样可以保证开发的正常秩序。为此，我们在看板前方新加了一项：待开发。我们会将变更的而且有限级高的需求放在这一列，以保证在下一轮迭代中实现这些需求。
　　大部分公司都会要求写需求文档，这样对所有需求归类，并且可以方便以后的查阅。但是这些需求文档有时候书写的并不是很规范，或是很全面。导致查阅的时候很难找到我们需要的内容而且在需求，有时候甚至是写完后根本无人去理会。而且，在需求变更时需要进行维护，耗费人力，文档在多次修改后导致内容很乱，或是前后需求矛盾的情况时有发生。
　　现在一个新的需求管理方法，需求的实例化，可以解决这些问题。需求的实例化是不再编写和维护需求文档，而是直接使用高质量的测试用例作为需求文档。通过测试用例可以很清楚的看到产品的需求内容，而且，在需求变更时，必然会产生新的测试用例，而不必费力去维护。在清晰的表现需求的同时，减少了维护需求文档的人力。