PMP®考点汇总—敏捷项目管理（二）

3.2 需求管理

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

      在敏捷实践中，对需求的管理有两种常见方法：完全解析和滚动解析。需求管理体现于一个重要活动：ProductBacklog 梳理。

3.2.1 完全解析

       在某些项目中团队可以将用户的所有需求和需求变更都体现在 Product Backlog 中 Epic 和 Story 的增删改上，一次性将所有需求都分解成足够小的 Story。完全解析后，项目的需求变得一目了然：

      1. 需求优先级十分明确，能够画出细致的路线图；

      2. 项目的工作量和工期能够较精确地估算；

      3. 能让团队形成项目一切尽在掌握中的自信。

       对于需求足够简单的小项目而言，完全解析有助于全面、完整地把握项目，控制项目进度，并且也比较容易梳理和保持 Product Backlog 的条理性。然而对于一定复杂度规模的项目，完全解析可能导致 Product Backlog管理混乱。长长的 Backlog 列表难以组织和梳理，难以对需求进行解耦和确定优先级。并且由于需求是涌现的，频繁的需求变更往往会加重 Backlog 的混乱程度，增加无效工作。

3.2.2 滚动解析

       另一种方法是将需求分解和增量交付有机结合起来。一些项目实践表明，在需求被提出、定义好到开始开发之间存在时间间隔，这期间很可能会出现需求变更或其他影响需求的情况。需求定义和开发间的时间间隔越长，按需求定义来开发产品的风险也越大，团队内重要成员、知识以及其他资源可利用率流失的风险也随之提升。这种情况下，建议采用滚动解析的方法来管理需求：

       1. 将所有待开发模块都识别为 Epic。在 Epic 中，利用 Comment 和附件记录这个 Epic 的原始需求、每次与用户的相关交流结果、需求变更等等，以保持需求的可追溯性。

       2. 首先针对 Epic 进行优先级排序，而不是细小的 Story。是的，开发团队要集中力量实现某个模块，然后再集中力量实现下一个。同时在许多个甚至所有的 Epic 上铺开工作无疑会增加 Epic 的开发周期。周期越长，不可控性和不确定性越大，风险和成本也就随之上升。

       3. 只有决定即将在下个或下下个 Sprint 投入开发的 Epic，才进行详细分解成 Story，放入 Backlog，并进行优先级排序。

       4. 最后，在投入开发前，向需求提出方确认用户故事的描述是否准确。

      滚动解析是为了在保证需求的完整性、合理性和一致性的前提下，尽可能缩短需求定义和开发之间的时间间隔，降低管理难度，控制风险和成本。

3.2.3 Product Backlog 梳理

       产品待办事项列表通常会很长，包含了所有已经识别的 Epic、已经解析得到的 Story 甚至可能还包含版本发布计划等内容，也很宽泛。而且由于需求是涌现且变化的，待办事项会出现增删改、优先级也会变化，所以产品待办事项列表梳理是一个贯穿整个 Scrum 项目始终的活动。该活动包含但不限于以下的内容：

       1. 保持产品待办事项列表有序；

       2. 把看起来不再重要的事项移除或者降级；

       3. 增加或提升涌现出来的或变得更重要的事项；

       4. 将事项分解成更小的事项；

       5. 将事项归并为更大的事项；

       6. 对事项进行估算。

       产品待办事项列表梳理的一个最大好处是为即将到来的一个或几个 Sprint 做准备。为此，梳理时会特别关注那些即将被实现的事项。需要考虑不少因素，这包括但不限于以下的内容:

       1. 理想情况下，下一个 Sprint 的备选事项都应该提升优先级；

       2. 团队能够在一个 Sprint 内完成哪些事项；

       3. 团队每个人是否都清楚预期产出是什么；

       4. 是否存在变更。

       在前文多次强调，应当首先识别 Epic，然后再将 Epic 细化解析成 Story；要首先确定 Epic 的优先级，再确定 Epic 属下的 Story 的优先级；最好基于 Epic 滚动地推进开发工作，而不是一开始就把场面铺陈开。按照这种实践，意味着 Product Backlog 会类似以下树状结构：

       排序越靠前，优先级越高，描述和解析越细致。

       那么，对于那些已经完成开发和交付的 Epic，如果出现 Bug 需要修复，或者某个功能需要升级，要怎么处理呢？同样的，加入到 Backlog 中，参与优先级排序即可。

      软件开发往往有可能需要其它的技能和输入。因此，产品待办事项列表梳理最好是所有团队成员都参与的活动，而不仅是 PO。