最后则是评估需求的优先级，综合分析以上三个要素，来最后给需求评估优先级。一般情况下核心需求的优先级往往是最高的，不过有时候由于技术风险过大，或者开发耗时过长，有些核心需求的优先级会被降低。在优先级评估完毕后，开发团队会确定第一轮的迭代要完成的需求。如果是使用 Scrum 敏捷开发有一段时间的话，开发团队是知道自己在一个迭代周期能够完成多少时间点的任务的，也就是团队的速率。一些高优先级的需求由于时间点太大而不能放入本次迭代，而使用其他优先级相对较低但时间点小的需求代替的情况也会时常发生。
4.让欲望在掌握之中
在完成需求评估后，开发团队就会进入开发阶段。在 Scrum 团队中，需要对开发中的需求进行管理。常用的方法是在一块木板或是一面墙上列出正在开发的，开发完成的，正在测试的和完成了的需求。这块木板或强被称为看板。每个人都可以在看板上清晰的看到团队现在的开发状况。我的团队没有使用实体的看板，而是使用 JIRA 这个软件提供的电子看板。
在开发过程中，需求的变更是必然会发生的。正常情况下，如果一轮迭代已经开始了，Scrum 团队是不会中途停止的。新的需求必须在下一轮迭代中才能加入，这样可以保证开发的正常秩序。为此，我们在看板最前方新加了一项：待开发。我们会将变更的而且有限级高的需求放在这一列，以保证在下一轮迭代中实现这些需求。
大部分公司都会要求写需求文档，这样对所有需求归类，并且可以方便以后的查阅。但是这些需求文档有时候书写的并不是很规范，或是很全面。导致查阅的时候很难找到我们需要的内容而且在需求，有时候甚至是写完后根本无人去理会。而且，在需求变更时需要进行维护，耗费人力，文档在多次修改后导致内容很乱，或是前后需求矛盾的情况时有发生。
现在一个新的需求管理方法，需求的实例化，可以解决这些问题。需求的实例化是不再编写和维护需求文档，而是直接使用高质量的测试用例作为需求文档。通过测试用例可以很清楚的看到产品的需求内容，而且，在需求变更时，必然会产生新的测试用例，而不必费力去维护。在清晰的表现需求的同时，减少了维护需求文档的人力。
VIA：人人都是产品经理
更多详细信息，请您微信关注“计算网”公众号：
