敏捷的需求管理

Scrum方法和传统项目开发方法对待需求的方式不同，传统项目开发中，需求是在项目一开始就尽早细化成文的，而且是不可轻易变更的。Scrum方法中，需求细节是在开发期间持续不断的讨论出来的，而且是等到团队开始开发功能的时候，及时、刚好地细化这需求就可以。传统项目开发对待需求的方式跟制造业很像，它们是必需的、不可协商的需求规格说明书，产品必须与之相符。这些需求事先拟定并以高度详尽的文档形式呈现给开发组，开发组会按照这些详细的需求来开发产品。

当需求不得不变化时，必须通过正式的变更控制流程来管理。因为变更的成本通常会非常高。而Scrum方法可以自由掌握、灵活相应，Scrum视需求为业务价值的载体，利用这个载体可以达成关键业务目标。例如，如果缺乏时间或者资金，可以放弃低价值的需求。如果开发过程中，外界信息（客户、用户、软件购买者等的反馈）表明某个需求的成效比低于预期，则可以从产品待办列表（可以理解为待处理的需求列表）中去掉。如果有新的高价值的需求涌现出来，可以通过置换的方式替换掉低价值的需求为它留出空间。

因此在Scrum方法中，不会在项目前期事无巨细的确定所有需求并形成格式化的需求文档，除非你百分百确定需求不会变化且你在项目初期就百分百确定你要做的所有功能。否则Scrum方法中不会再前期就投入大量的时间和成本去完成一个极有可能变化的需求文档，而是创建一个“产品待办列表（Product Backlog）”，它里面每一项都是一个产品待办列表项（Product Backlog Item），产品待办列表项即PBI一般是以用户故事来呈现，每个PBI代表一个业务价值。在项目开始的时候，PBI的个头比较大，相关细节可能很少。随着时间的推移，产品负责人即开发团队围绕这些PBI进行一系列讨论，逐渐被细化并未开发人员提供线索。

综上，Scrum的需求收集和管理是通过需求收集（可以采用访谈、标杆对照等工具），进而产生初始的产品待办列表（包括优先级的设置）。初始的产品待办列表列举最初所知的以及理解最透彻的需求，而后会随着产品及其应用环境的改变而演进，需要持续更新以反映出产品需要有什么来保持其适用性和竞争力。