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

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

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

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

       实践调查发现更多大型项目的成功，依赖于通过需求工作流、需求分析、和需求可追溯性的管理，在需求层面上进行整体的项目规划和控制。敏捷过程中，仅用Product Backlog，不足以满足需求的管理。通常，一个项目的研发过程，通过3个空间来进行表达：需求空间、研发空间和QA测试空间。3个空间相互间应当是完全整合的，使得整个团队的不同职能工作能够相互协作。今天我们首先探讨需求空间！

需求空间用来做什么？

       SpecDD模型中，用户需求，在需求空间中被录入登记。敏捷提倡客户价值导向，应当从客户价值角度描述，就是描述客户如何使用，而不是描述技术层面如何实现。我们喜欢Story的用户需求表达方式，但这不代表用户需求的管理就是杂乱、随意和无序的。产品负责人需要借助需求工作流、需求分析、和需求可追溯性的管理，进行产品需求的提炼、条目化、优先级排序等。通过需求空间，对用户需求形成细化和量化的SPEC。

       需求和SPEC之间常常存在多对多的关系，即一个需求可能拆分出多个SPEC，一个SPEC可能来源于多个原始的用户需求。而实际的开发任务和测试任务，又常常需要基于具体的SPEC来分解和分配。这样的话，借助于需求空间的系统化管理，项目负责人能更好的对需求相关联的产品功能、用户需求、开发任务、测试用例、产品缺陷等进行全程跟踪，实现需求可追溯性管理。

有了需求空间后，Product Backlog 是否被取代？在实践中应当如何使用？

       可以明确的回答，有了需求空间后，我们仍然需要Product Backlog，并且Product Backlog仍将继续扮演重要的角色。首先我们明确Product Backlog 存放的是给开发团队用的需求，更多服务于开发团队。如何来理解这点？你可能会说，这不是废话么，给开发团队的需求当然应该放在Product Backlog里了。但实际项目进展中，常常会遇到以下2个实际问题。

问题一：“需求还在设计中；或整理完毕，但还未决定让开发团队去实现；这些需求是否需要存放在Product Backlog来管理”？

回答：可以啊，就放Product Backlog来管理，通过特定字段或者标题标识加以区分就好。

评论：这样的处理办法，您依然可以使用Excel来管理产品Backlog。但随着用户需求的增加，或者当项目很庞大的时候，您势必会需要一台47寸显示器和一双鹰般锐利的眼睛来管理Product Backlog 列表:-)

       SpecDD认为，只有当需求决定要开发的时候，才需要有分配；有了分配后，才需要放到Backlog中。否则当一个需求还在设计阶段，或者还没有决定是否需要开始实施的时候，甚至都可以对开发部门和测试部门进行隐藏。有了这样的改进，能更好的控制、管理Product Backlog列表。需求一旦分配到开发团队后，也就从Backlog中移除了。新的，设计完毕的，可供分派到开发团队的待处理需求，又从需求空间进入到 Product Backlog中。这样的改进，更能让Product Backlog实现了Scrum最早的思想；帮助项目经理从茫茫海洋中快速定位急待开发的任务。

问题二：一个需求包含的开发工作较大，Sprint 1 开始的时候，需求从Product Backlog分配出去。但是在Sprint 2中，同一个需求需要继续迭代开发，但该需求已经不存在于Product Backlog中了，该怎么办？

产品负责人：从Sprint 1将之前的需求move到Sprint 2中？

项目经理：那Sprint 1的历史工作记录不就失真和破坏了么？

产品负责人：或者在ProductBacklog建立一个相同的需求，再分配到Sprint 2中？

项目经理：那不就出现了重复的需求条目了么？

       显然这2种想法都不是好办法。针对这个问题，SpecDD做了现实解答。SpecDD认为，Product backlog和需求空间是相互整合的。只不过需求（Epic/Spec）并不直接从需求空间被分配到 Product Backlog或Sprint中。当产品负责人决定要实现的时候，需求以Story的形式分配到Product Backlog中。Story是需求的一次实现分配。

       SpecDD模型认为Product Backlog中不要直接存放用户需求，否则会使得Backlog中的任务队列越来越多，反倒影响了对于任务优先级的排列。 Backlog中的内容应该尽可能的少，因此避免直接把需求放到Backlog中。而是采用把Story和Task放到Backlog中更好。Story一旦被分配，也就从Product Backlog中移除了。一个需求，如果工作量较大，需要通过多次迭代开发，或多个团队共同协作来完成的话，那么就可以根据开发情况，生成多个Story来进行分配。您也可以把Story理解为一个指向需求的指针；通过Story，开发团队能直接查看到具体Epic/SPEC的描述信息，获得上下游需求。分配到开发团队的Story，可包含一组已分类的开发任务。所有这些关联派生的Story以及拆分的任务，在需求空间上，又全都能够在Epic/SPEC条目上进行全程跟踪和追溯管理；从而让项目负责人和管理组从需求层面上，牢牢掌控、规划项目的进度和质量。

       通过上面一系列的讨论，我们就会发现单纯的Product Backlog 不足以实现需求管理。通过引入需求空间，重新定位Product Backlog的作用，以及Story概念的定义等系统化地需求管理，将有助于团队决定产品功能取舍的“智慧”有效地发挥作用，且能直接从软件产品结果中进行追踪，也提高了可执行产品的交付正确性。高效、灵活地保证了可执行产品的交付，也就能让用户更早提出修改意见，从而使得项目整体保持良好的进展健康度。管理层也无需担忧由于团队人员变动和流失，而让企业找不回当初创造产品功能时所经历过的团队讨论与决定过程。