pmp考试内容 pmp考点精粹 _生活百科

许多项目的成功依赖于通过需求工作流、需求分析和需求可追溯性的管理，在需求层面的整体项目规划和控制。
在Scrum中，用户需求被解析成Epic和Story，它们被放在产品Backlog中进行管理。史诗和故事没有统一的标准。史诗是由一系列相互关联的故事组成的故事集。在实践中，我们可以将系统模块识别为Epic，然后从Epic中详细解析用户故事。换句话说，我们用Epic来描述需求的范围，用Story来定义需求的细节。
3.1 需求分析
在敏捷开发中，许多活动是由所有员工而不是特殊人员参加的，需求分析也可以是所有员工都参加的活动。需求分析是在理解需求的基础上进行的，充分参与有助于及时发现团队成员对同一需求理解不同的问题，可以在很大程度上避免缺陷的引入。此外，它还有助于避免人为风险。例如，如果一个需求开发人员突然需要休假，其他开发人员可以立即代替他，因为其他人也参与了开发需求的分析。此外，充分参与需求分析也有助于提高所有成员的能力。然而，一般来说，大多数开发人员和测试人员都没有资格进行需求分析。这意味着扮演导师角色的人需要在需求分析活动中领导每个人，产品负责人需要承担这一责任。ScrumMaster可以为产品所有者提供指导和帮助，使其能够胜任敏捷开发中的需求指导和管理。用户需求由三个要素组成：需求描述、需求优先级和故事点(工作量) 。
3.1.1 WhatorHow
需要强调的是，需求分析的目的是准确描述问题，而不是找出解决问题的方法。
从解决问题的角度来说，要解决一个问题，首先要搞清楚的是问题是什么。软件开发活动是将需求转化为代码，这是一个如何解决问题的过程。需求分析的目的是在开发之前找出用户想要什么。开发人员在分析需求时经常会遇到的一个问题是，他们急于考虑“如何”，这是设计和开发活动应该解决的问题。

文章插图
3.1.2 需求描述：完整、合理、一致和兼容
敏捷提倡客户价值导向，应该从客户价值的角度来描述，即客户想要什么，而不是在技术层面如何实现。典型的需求描述格式是：
作为XX(角色，谁)，希望……(系统能实现什么功能，什么)，从而……(实现某个业务目标，为什么) 。
例如，用户故事描述如下：
作为一个内容管理员，希望可以对用户提交的稿件进行审核和编辑，避免发布不合适的内容。
史诗简述如下：
指挥中心提出建立领导分配模块，处理领导指令的输入、审核、分配、跟踪和反馈。
/>3W 法是从 3 个维度描述需求的：需求所有者、需求陈诉和需求背景。其中：
1. 需求所有者明确需求由谁提出、或由谁使用；
2. 需求陈述告诉我们系统要做什么，它反映了客户所要的功能；
3. 需求背景告诉我们系统为什么要做某件事，它反映了客户的业务需要。
结合一个需求的这三个方面，有助于分析需求的合理性。对于不合理的需求应该及时拒绝，否则不仅浪费了团队资源，系统上线后还可能给利益相关方带来损失。
了解一个需求的背景对于理解和分析一个需求来说至关重要。因为需求背景不仅有助于理解需求，也有助于对需求进行进一步分析。比如，移动网络中的广告可能要求内容的个性化定制，即让每个用户看到最适合他的广告，这些广告的内容因受众的年龄、性别等个人信息而异。显然，系统需要先查询用户个人信息然后再根据个人信息去查询广告内容。针对这样一个需求，我们可能会提出这样一个问题：如果用户个人信息查询失败，系统是否还需返回广告内容呢？而需求陈述中并没有提及这点。考虑需求背景可以帮助我们自行找到这类需求完整性问题的答案——根据个人信息获取定制的广告其目的是更好地定位潜在消费者，若无法获取用户个人信息，则返回适宜大众阅读的广告也无妨。
此外，描述需求还要考虑需求的一致性和兼容性：
一致性：对需求的描述和理解应当在需求提出方和敏捷团队之间达成一致。如果需求提出方提出需求变更，那么至少要经过产品负责人（Product Owner，PO）评估、修改需求描述，并向需求提出方确认。
兼容性：迭代开发中，当前迭代往往涉及对前面迭代中已经实现的需求的变更，而在此次变更之前该需求可能已经经历若干次变更了。这种情况下，特别需要关注这些变更间的兼容性。因为前些迭代中实现的这个需求可能已经上线运行，需求变更应当考虑到它对线上的系统可能带来的兼容性问题。否则，新的迭代发布的版本若与线上的版本不兼容，很可能给客户带来损失。

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

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

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

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