敏捷开发中，Product Backlog 是否足以实现需求管理？

        敏捷方法指导团队将产品需求置于Product Backlog中管理，并按照优先级对每个产品需求进行必要的排列。在计划会(Planning Meeting)之前，由Product Owner从Product Backlog中挑选迭代周期准备开发的意向表（Willing List）进行总体介绍，然后分配到Sprint研发过程中。以Scrum为代表的纯敏捷方法，认为首先不需要对需求做分析，因为需求一直在变。所以提出了Story的概念，认为需求就该是对需求的一种类似讲故事的方式来表达的，这样便于让原始客户比较清晰的对需求进行表达，同样开发和测试也会逐渐以客户的需求思维来思考自己的工作。使得大家都能在需求的层面上，进行大脑思维。

但是敏捷方法的普遍使用中，又发现了纯敏捷方法的局限性

• 无法支持需求驱动下完整的可追溯性。
• 整个团队完全致力于项目的开发是基本前提。一旦开发团队的方向出现变化，会导致项目的崩溃；因为需求总在变化。

       实践调查发现更多大型项目的成功，依赖于通过需求工