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

       许多项目的成功，依赖于通过需求工作流、需求分析、和需求可追溯性的管理，在需求层面上进行整体的项目规划和控制。

       在 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. 需求背景告诉我们系统为什么要做某件事，它反映了客户的业务需要。

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

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

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

       一致性：对需求的描述和理解应当在需求提出方和敏捷团队之间达成一致。如果需求提出方提出需求变更，那么至少要经过 产品负责人（Product Owner，PO） 评估、修改需求描述，并向需求提出方确认。

        兼容性：迭代开发中，当前迭代往往涉及对前面迭代中已经实现的需求的变更，而在此次变更之前该需求可能已经经历若干次变更了。这种情况下，特别需要关注这些变更间的兼容性。因为前些迭代中实现的这个需求可能已经上线运行，需求变更应当考虑到它对线上的系统可能带来的兼容性问题。否则，新的迭代发布的版本若与线上的版本不兼容，很可能给客户带来损失。

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，以后每个用户故事都相对于“用户认证页面”这一故事来衡量工作量。