返回目录 上一章·Scrum 中的基本角色和职责

许多项目的成功，依赖于通过需求工作流、需求分析、和需求可追溯性的管理，在需求层面上进行整体的项目规划和控制。
在 Scrum 中，用户需求被解析成 Epic 和 Story，置于 Product Backlog 中进行管理。Epic 和 Story 并没有统一的划分标准，一般可认为 Epic（史诗）是有一系列相互联系的 Story（故事）组成的故事集。实践中，我们可以把系统模块识别为 Epic，再从 Epic 中解析出足够细致的 User Story。或者说，我们用 Epic 来描述需求范围，用 Story 来定义需求明细。

3.1 需求分析

敏捷开发中许多活动都是全员参与而非专人参与，需求分析同样也可以是全员参与的一个活动。需求分析是在需求理解的基础上进行的，全员参与有助于及时发现团队成员对同一个需求理解不一致的问题，可以在很大程度上避免缺陷的引入。另外，也有助于规避人力风险。比如，一个需求的开发者突然需要请假，其他开发者可以马上顶替他，因为其他人也参与了其负责开发的需求的分析。此外，全员参与需求分析也有助于全体成员的能力的提升。然而通常多数的开发人员和测试人员他们的能力和经验不足以胜任需求分析工作。这意味着全员参与的需求分析活动需要一个扮演导师角色的人带领大家去进行有效的需求分析，Product Owner 需要承担起这个责任，Scrum Master 可以为 Product Owner 如何胜任敏捷开发中的需求指导和 管理工作提供指导和协助。

用户需求由3个要素组成：需求描述、需求优先级和故事点（工作量）。

3.1.1 What or How

需要强调：需求分析是为了准确地描述问题，而非寻求如何解决问题。

从问题解决的角度来看，要解决一个问题首先要弄清楚的是问题究竟是什么。软件开发活动就是要把需求转化为代码，这是一个怎么（How）解决问题的过程。而需求分析的目的是，在动手开发前先搞清楚用户到底想要什么（What）。开发人员在需求分析时往往易犯的一个问题是急于考虑“怎么”的问题，而这是设计开发活动所要解决的问题。

3.1.2 需求描述：完整、合理、一致和兼容

敏捷提倡客户价值导向，应当从客户价值角度描述，就是描述客户想要什么，而不是描述技术层面如何实现。典型的需求描述格式为：

作为 XX（角色，Who），我希望……（系统能够实现什么功能，What），以便……（达成某业务目标，Why）。

例如，一个User Story描述如下：

作为内容管理员，我希望我能对用户投递的稿件进行审核和编辑，以避免发布不合适的内容。

一个Epic概要描述如下：

指挥中心提出建设领导交办模块，以处理领导批示的录入、审核、交办、跟踪和反馈。

3W法是从3个维度描述需求的：需求所有者、需求陈诉和需求背景。其中：

1. 需求所有者明确需求由谁提出、或由谁使用；
2. 需求陈述告诉我们系统要做什么，它反映了客户所要的功能；
3. 需求背景告诉我们系统为什么要做某件事，它反映了客户的业务需要。

结合一个需求的这三个方面，有助于分析需求的合理性。对于不合理的需求应该及时拒绝，否则不仅浪费了团队资源，系统上线后还可能给利益相关方带来损失。

了解一个需求的背景对于理解和分析一个需求来说至关重要。因为需求背景不仅有助于理解需求，也有助于对需求进行进一步分析。比如，移动网络中的广告可能要求内容的个性化定制，即让每个用户看到最适合他的广告，这些广告的内容因受众的年龄、性别等个人信息而异。显然，系统需要先查询用户个人信息然后再根据个人信息去查询广告内容。针对这样一个需求，我们可能会提出这样一个问题：如果用户个人信息查询失败，系统是否还需返回广告内容呢？而需求陈述中并没有提及这点。考虑需求背景可以帮助我们自行找到这类需求完整性问题的答案——根据个人信息获取定制的广告其目的是更好地定位潜在消费者，若无法获取用户个人信息，则返回适宜大众阅读的广告也无妨。

此外，描述需求还要考虑需求的一致性和兼容性：

1. 一致性：对需求的描述和理解应当在需求提出方和敏捷团队之间达成一致。如果需求提出方提出需求变更，那么至少要经过 产品负责人（Product Owner，PO） 评估、修改需求描述，并向需求提出方确认。
2. 兼容性：迭代开发中，当前迭代往往涉及对前面迭代中已经实现的需求的变更，而在此次变更之前该需求可能已经经历若干次变更了。这种情况下，特别需要关注这些变更间的兼容性。因为前些迭代中实现的这个需求可能已经上线运行，需求变更应当考虑到它对线上的系统可能带来的兼容性问题。否则，新的迭代发布的版本若与线上的版本不兼容，很可能给客户带来损失。

3.1.3 确定需求的优先级

在敏捷项目中，对需求进行优先级排序是个非常重要的活动，贯穿项目始终，每个迭代中都需要不断的进行需求优先级评估、用户故事梳理等活动。
对很多敏捷团队而言，一提到需求优先级排序，首先想到的就是产品负责人（PO）的责任。而对产品负责人来说，第一反应就是根据具体的商业价值（business value - 也称业务价值）来确定优先级。业务价值如何定义、如何评估和测量？其中包含哪些考虑因素？
价值，往往不仅仅纯粹是经济价值，能创造利润或节省开支固然是非常重要的因素，但对成本、风险甚至学习新知识方面的考虑也至关重要。所以，确定优先级时通常会从5个方面考虑：

1. 经济价值
2. 所需成本
3. 学习和获取知识的重要性和数量
4. 风险
5. 客户需要

在其中，如何考虑风险，以及风险和价值之间的关系来排定优先级是一个难点。独立的只考虑追求价值或回避风险而进行优先级排序，都会带来问题。一般 PO 都会选择采用风险-价值矩阵来评估需求优先级，优先完成相对高价值-高风险的需求，高价值-低风险的需求次之，低价值-低风险的需求再次之，而尽可能推迟甚至避免开发低价值-高风险的需求。
在此基础上，基于对知识学习和风险的考虑和客户的实际需要，产品负责人也可以结合团队的评估来进行调整。针对风险-价值矩阵，还需要持续监督，因为价值和风险随着项目进行是会动态变化的。

3.1.4 估算Story Point

无论是团队研发一款产品或者开发某一个项目，我们都需要回答“我们大概什么时间能够完成？”， 或者到某一个时间点，我们能够做到什么程度， 因此和传统的开发模式一样，我们在工作开始之前需要对我们需要做的事情进行工作量的估算。
对工作量的估算应当以 User Story 为基础，Epic 的整体工作量体现在分解得到的Story的工作量的总和以及集成成本上。
用户故事的工作量以故事点（Story Point）来衡量。对工作量应当估算大小，而不是估算时间周期，使用相对估算，而不是绝对估算。在项目中，可以预设一个基准故事，例如，把实现用户认证页面的故事点定为1，以后每个用户故事都相对于“用户认证页面”这一故事来衡量工作量。

3.2 需求管理

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

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。