敏捷需求管理是对传统需求管理的颠覆。两者的差异如下。

1.需求所承担的作用不同

在传统的需求管理方式里，需求的作用是为了详尽地描述团队需要完成的产品特性，它经常成为产品和研发之间的契约。产品负责人将需求传递给研发人员，研发人员依据文档的描述进行开发和测试。团队最终交付的是文档中描述的产品特性，但是该描述是客户真正的需求吗？这只有等团队交付给客户之后才能知道答案。

在敏捷开发模式里，“需求”（Requirements）的作用是为了引导团队对客户“诉求”（Needs）进行理解。事实证明，只有产品经理一个人写的需求，并不能使团队真正理解客户的诉求。团队只有通过一起来讨论并分析需求，才能达到真正理解客户诉求的目的。

2.时限不同

在瀑布开发模式里，需求的生命周期非常漫长，有专门的需求分析阶段，它是产品开发的早期阶段，以后的阶段都是为了交付需求。在需求分析阶段结束后，评审委员会需要对需求冻结的里程碑进行评审，对团队新提出的需求或者对原有需求的变更也要通过评审委员会的评审，走正式的变更流程。

在敏捷的开发模式里，需求的生命周期很短暂，没有专门的需求分析阶段，团队可以随时对记录需求的特性列表进行增加、删除和修改。产品负责人和团队对需求的分析贯穿于整个产品生命周期，他们在每个迭代周期都有讨论和梳理需求的时间。团队不需要针对需求变更走评审流程，团队可以随时在Backlog里修改需求（只要需求还没有被纳入团队不需要针对当前的迭代计划，或者没有被拉入看板的就绪队列之中，团队就可以修改）。

3.需求的规模不同

在瀑布模式里，没有明确的需求拆分的概念，因为不管各个需求的规模是大还是小，团队都是到“最后一公里”的时候一起交付。而在敏捷开发模式里，需求必须被拆分到最小粒度，以保证产品特性的持续发布。

4.参与人不同

在瀑布模式里，一般有专门的产品经理或者业务分析员依据其对客户诉求的理解进行需求分析，形成需求分析文档后传递给研发团队，而研发团队基本不参与需求分析。

在敏捷开发模式里，产品负责人是需求分析的主要责任人，他需要与研发团队一起讨论需求。这样做的必要性在于以下几点。

• 无论需求写得多么具体，实际的需求信息无法通过文字完整地传递出来。
• 产品的需求与其解决方案之间的界限并不是完全清晰的。
• 无论产品负责人的个人能力有多强，单靠其自己的力量无法对需求的场景全面分析。研发团队从解决方案的视角来思考和澄清需求，往往会让产品负责人发现很多其之前没有考虑到的场景。
  

5.优先级制定方式不同

在瀑布模式里，需求库里所有的需求通常都必须做。然而，在敏捷开发模式里，团队需要将需求拆分到最小价值单元，最小价值单元须有明确的优先级，只有少量的需求才是版本里不可或缺的。

很多团队做敏捷有很长时间了，但是他们的需求管理方式仍然流露出传统需求管理方式的痕迹。客户对产品的需求是团队工作的中心，也是凝聚团队与产品负责人、客户或用户的核心纽带。如果团队处理需求的思想和工作方式没有转变过来，那么在敏捷的转型的过程中会产生很多问题。

很多敏捷团队仍旧在用瀑布方式管理需求，常见的现象如下。

• 所有需求都必须在某个时间点完成。
• 产品负责人将需求扔给团队后就“消失”了，团队很难找到他/她澄清需求。
• 需求完全没有被拆分，或者拆分不到最小价值单元时就进入开发阶段。
  

当然，还有一些情况是从传统工作方式走向了敏捷的极端，产生了更大的浪费。

• 需求没有被纳入Backlog，团队通过口头传递就进入了开发阶段。
• 需求表达不清晰，产品负责人将需求分析工作推给了研发团队，研发团队在开发的时候现做需求分析。
  

敏捷需求管理是对传统需求管理的颠覆。两者的差异如下。

1.需求所承担的作用不同

在传统的需求管理方式里，需求的作用是为了详尽地描述团队需要完成的产品特性，它经常成为产品和研发之间的契约。产品负责人将需求传递给研发人员，研发人员依据文档的描述进行开发和测试。团队最终交付的是文档中描述的产品特性，但是该描述是客户真正的需求吗？这只有等团队交付给客户之后才能知道答案。

在敏捷开发模式里，“需求”（Requirements）的作用是为了引导团队对客户“诉求”（Needs）进行理解。事实证明，只有产品经理一个人写的需求，并不能使团队真正理解客户的诉求。团队只有通过一起来讨论并分析需求，才能达到真正理解客户诉求的目的。

2.时限不同

在瀑布开发模式里，需求的生命周期非常漫长，有专门的需求分析阶段，它是产品开发的早期阶段，以后的阶段都是为了交付需求。在需求分析阶段结束后，评审委员会需要对需求冻结的里程碑进行评审，对团队新提出的需求或者对原有需求的变更也要通过评审委员会的评审，走正式的变更流程。

在敏捷的开发模式里，需求的生命周期很短暂，没有专门的需求分析阶段，团队可以随时对记录需求的特性列表进行增加、删除和修改。产品负责人和团队对需求的分析贯穿于整个产品生命周期，他们在每个迭代周期都有讨论和梳理需求的时间。团队不需要针对需求变更走评审流程，团队可以随时在Backlog里修改需求（只要需求还没有被纳入团队不需要针对当前的迭代计划，或者没有被拉入看板的就绪队列之中，团队就可以修改）。

3.需求的规模不同

在瀑布模式里，没有明确的需求拆分的概念，因为不管各个需求的规模是大还是小，团队都是到“最后一公里”的时候一起交付。而在敏捷开发模式里，需求必须被拆分到最小粒度，以保证产品特性的持续发布。

4.参与人不同

在瀑布模式里，一般有专门的产品经理或者业务分析员依据其对客户诉求的理解进行需求分析，形成需求分析文档后传递给研发团队，而研发团队基本不参与需求分析。

在敏捷开发模式里，产品负责人是需求分析的主要责任人，他需要与研发团队一起讨论需求。这样做的必要性在于以下几点。

• 无论需求写得多么具体，实际的需求信息无法通过文字完整地传递出来。
• 产品的需求与其解决方案之间的界限并不是完全清晰的。
• 无论产品负责人的个人能力有多强，单靠其自己的力量无法对需求的场景全面分析。研发团队从解决方案的视角来思考和澄清需求，往往会让产品负责人发现很多其之前没有考虑到的场景。
  

5.优先级制定方式不同

在瀑布模式里，需求库里所有的需求通常都必须做。然而，在敏捷开发模式里，团队需要将需求拆分到最小价值单元，最小价值单元须有明确的优先级，只有少量的需求才是版本里不可或缺的。

很多团队做敏捷有很长时间了，但是他们的需求管理方式仍然流露出传统需求管理方式的痕迹。客户对产品的需求是团队工作的中心，也是凝聚团队与产品负责人、客户或用户的核心纽带。如果团队处理需求的思想和工作方式没有转变过来，那么在敏捷的转型的过程中会产生很多问题。

很多敏捷团队仍旧在用瀑布方式管理需求，常见的现象如下。

• 所有需求都必须在某个时间点完成。
• 产品负责人将需求扔给团队后就“消失”了，团队很难找到他/她澄清需求。
• 需求完全没有被拆分，或者拆分不到最小价值单元时就进入开发阶段。
  

当然，还有一些情况是从传统工作方式走向了敏捷的极端，产生了更大的浪费。

• 需求没有被纳入Backlog，团队通过口头传递就进入了开发阶段。
• 需求表达不清晰，产品负责人将需求分析工作推给了研发团队，研发团队在开发的时候现做需求分析。