敏捷规划和估计
计划和估算在软件项目中是必不可少的，以实现可预测性、降低所涉及的风险并为所有利益相关者设定基本期望。计划将重点放在准备和预测上，而估算是预测与项目相关的变量（即工作量、范围、进度等）的过程。
计划：无论团队遵循何种项目管理方法，无论是瀑布式还是敏捷，都需要进行计划。规划为项目团队提供了如何以系统方式实现目标的视角，并帮助项目利益相关者密切关注项目进度和完成的投资。
正如 Mike Cohn 所定义的那样，“敏捷规划平衡了规划中的努力和投资，以及我们将在整个项目过程中修改计划的知识。敏捷计划是我们不仅愿意而且渴望改变的计划”。这个概念的存在主要是为了避免规划的弱点。
这些弱点包括：
- 专注于活动而不是交付的功能
- 忽略优先级
- 忽略不确定性的存在
- 根据估计作出承诺
计划中的这些弱点使团队无法应对项目的动态环境。为了解决这个问题，计划也必须提前成为敏捷。
估计：进度、范围、成本和努力是通常控制软件项目的四个主要变量。任何这些变量的任何变化都会对项目产生影响。估计是根据客户指定的信息预测这些变量以开发或维护软件的过程。
在估计过程中面临三个主要挑战，即不确定性、自我认识和用于估计的方法的一致性。使用标准化和科学的估算方法来估算规模、工作量和进度，有助于保持计划估算与实际值之间的最小差异，从而实现最大的估算准确性。这提供了更好的客户体验。一个项目的所有估算需求不能由单一方法确定。对不同阶段采用不同的估计方法很重要。
敏捷项目中的规划和估计将大量精力放在准备和预测上。这两项活动都是在牢记业务环境的情况下完成的，并且致力于为客户提供可衡量的价值。因此，建议从项目一开始就在敏捷中进行必要的规划和估算，以确保更好的风险覆盖和更高的可预测性。
敏捷项目中的规划和估计通常在三个不同的阶段完成，它们是：
- 项目启动级别
- 发布级别
- Sprint 级别（即，每个版本中的迭代）
现在让我们详细了解每个阶段。
项目级别：
规划：
项目级别的规划活动需要 360 度的项目视图，包括了解全局、总体愿景、路线图、价值交付、规划更好的风险覆盖范围、创建产品待办事项、定义发布等。这是最高级别计划的重点是项目即将发生的活动及其最终目标。产品负责人（或客户/业务经理）是参与此活动的主要利益相关者。
在此阶段，产品负责人 (PO) 向项目/交付团队解释他们需要遵循的策略，以按时交付潜在的可交付产品。团队在这里的角色是清楚地理解战略计划并充分满足产品负责人的需求。
一旦知道了项目目标，就需要定义如何实现该目标。这一切都是为了将需求分解为各个部分，以便可以构建、验证和发布最终的可交付成果。这有助于根据功能要求计划和估计各种版本。此时，产品负责人的角色变得至关重要。该计划导致生成产品待办列表，然后将其用于进一步的计划，即发布计划。忽略项目计划活动将导致开发出无用或不符合利益相关者预期的最终产品。
在实践中，项目级别的规划涉及许多提供整体控制的组件，以便在每次交付中实现可预测性，降低风险并与所有利益相关者设定基本期望。这些组件与基础架构规划、质量管理规划、环境设置规划、工具和重用规划、构建自动化和持续集成规划等有关。但是，在较高的层次上，规划的重要方面包括创建产品待办列表、拥有需求研讨会，通过定义发布创建发布计划，并通过应用程序生命周期管理工具规划敏捷实践，这些都需要在项目中采用。
- 产品待办事项：产品待办事项是完成产品/功能的预期交付所必需的简化要求的优先列表。这是规划的关键输入。产品负责人通常会在咨询业务战略家和最终用户的情况下准备积压工作。优先级通常基于业务价值、发布日期、相互依赖性，并在一个常见的地方进行维护，例如集中式 MS Excel 文件、ALM 工具等。
- 研讨会：举办研讨会的主要目的是收集、理解和优先考虑需求，并主要在项目启动阶段为发布定义一个高级计划。研讨会是一群人合作提出各种想法的活动，以便在公正的主持人的帮助下实现既定目标。这与头脑风暴不同。在研讨会上，应该清楚地知道需要什么以及应该得到什么结果。
- 应用程序生命周期管理：应用程序生命周期管理 (ALM) 通过提供更可预测地交付软件和推动业务价值的机制来帮助管理敏捷项目。敏捷 ALM 工具用于规划和估计用户故事并在团队内共享它们。它可用于构建产品待办事项、冲刺待办事项、建立团队承诺和速度、通过燃尽图可视化团队活动和项目进度，以及报告团队进度。只需通过在积压中向上/向下拖动用户故事，团队就可以按顺序排列它们的优先级。此外，团队可以使用良好的 ALM 工具有效地捕获、自行分配和管理他们的任务。
估计：
在项目启动阶段，功能需求处于高水平，或者需求的细节没有很好地制定和记录。在 Product Backlog 中，许多需求仍处于 Epic 或 Feature 级别。此时，需要进行估算，因为这将有助于确定发布的优先级和规划。在这个阶段可以使用不同的估计技术。他们之中有一些是
- QFPA（快速函数点分析）
- 用例点
- 基于复杂性的估计
- COCOMO（建设性成本模型）
- 宇宙FP
在项目启动阶段，估计应该作为一个小组活动进行，应该比较结果并解决分歧。所有的项目假设和风险都应该清楚地强调出来。通常，执行此活动的团队将包括：
- 产品拥有者
- 客户和业务利益相关者
- 专案经理
- 开发人员和设计师
- 测试人员
下图说明了项目级别的一般估算方法：
项目级别估算将提供有关
- 部署前可能需要的发布/冲刺的大致数量
- 项目的大约结束日期
- 大概的人员配置计划
- 大致的努力计划等
在每个发布/Sprint 的规划阶段，项目级别的估算会定期得到完善。
发布级别：
规划：
如果没有发布计划，项目团队会从一个 Sprint 跳到下一个 Sprint，不确定在哪里停止（即逻辑上）。可交付的产品已交付并准备好在每个版本结束时进行部署。因此，项目团队理解并遵守发布计划至关重要。
发布计划就是计划和安排团队将把用户故事（即功能性/非功能性需求）转化为工作软件并为该版本交付的用户故事。团队以有时间限制的方式决定每个版本的 Sprint 数量（持续时间 1 到 4 周），其中一组用户故事在进行发布计划时被转换为工作软件。
发布计划还可以提及一些关键假设，例如 Sprint 将持续多长时间、团队规模、团队中的工作人员、第一个 Sprint 的开始、最后一个 Sprint 的结束等。对于年金（长期，即超过一年）项目，建议根据业务情况计划三到六个月之间的任何时间，对于非年金项目，建议一到三个月。
为发布做计划很重要，因为它为所有利益相关者提供了清晰的画面，在项目执行的适当过程中预计将投入生产的内容。发布计划是一个重要元素，因为它发生在每个新版本开始之前。这有助于团队以增量的方式向客户交付预期的项目输出，从而帮助他们获得早期反馈，从而使未来的计划更加符合客户的需求。
所有利益相关者识别并同意每个 Sprint 和发布的持续时间、目标和内容。但是，由于随着项目的推进，需求可能会被添加或删除，因此在每个发布和 Sprint 的开始，都会重新审视相同的计划并修改范围。项目团队可以根据当时的动态决定在项目过程中增加额外的 Sprint 或 Release。
以下是发布计划中涉及的各种活动：
- 确定发布目标：产品负责人通常会在发布计划会议上讨论期望的目标。大多数目标将是时间\日期驱动的输出或功能驱动的输出。当目标是时间\日期驱动的输出时，产品负责人将期望发布在所述日期之前完成。产品负责人通常会设定在发布结束时完成“x”功能的目标。
- 估计用户故事（大小）：产品所有者总是有一个他们希望在项目即将发布的每个版本中成为目标的项目的愿望清单。根据与用户故事相关的业务价值来识别和估计用户故事的规模（复杂性）非常重要。这些估计提供了发布计划需要考虑的关键输入，以定义发布的时间表以及 Sprint 的持续时间。
- 优先考虑用户故事：项目总是面临需要交付的工作太多或交付时间太短的情况。因此，始终建议产品负责人优先考虑可用的用户故事，以便团队可以根据业务需要相应地处理它。
- 选择故事并定义发布日期：通过此步骤，敏捷团队将获得有关用户故事估计（规模/复杂性）、优先用户故事（基于业务需要）以及每个 Sprint 所需持续时间的信息。这些输入将有助于发布计划，以满足产品所有者（或客户）为发布定义的目标。项目团队的所有成员，以及产品负责人和任何其他利益相关者（即最终用户等）都参与了此活动，并且发布结束日期是在达成共识的情况下协作定义的。
估计：
发布级别估计是在发布计划时完成的。优先需求取自用户故事形式的产品待办列表。用户故事是根据发布计划期间的故事点来估计的，其重点是估计要为该特定版本交付的软件的大小。考虑的其他输入是项目级别的大小、工作量、周期时间和可用技能。基于此估计，为整个项目计划了多个版本和每个版本中的故事点总数。
发布计划期间的估算由整个团队使用以下技术之一完成：
- Wideband Delphi（或共识方法）在使用 Wideband Delphi 方法执行用户故事点估计时遵循以下步骤：
- 协调员与团队和产品负责人讨论用户故事。
- 每个团队成员估计完成每个功能所需的人日数。
- 协调员与团队比较和分析个人估计。
- 重复该过程，直到该组的估计没有显着差异。
- 这个练习通常可以分三轮完成。
- 类比估计（或外推）在使用类比估计方法执行用户故事点估计时遵循以下步骤：
- 用户故事的估计是基于它与一个或多个参考的关系。
- 相似大小的用户故事被收集在一起并作为一个组进行估计。
- 例如，用户故事“添加收款人的能力”估计需要 40 小时才能完成。如果用户故事“编辑收款人”的复杂程度是“添加收款人”的一半，那么这个故事所需的工作量将是 20 小时。
以下是对示例的另一种描述：
- 规划扑克技术使用基于斐波那契数列（即 0、1、2、3、5、8、13、20、40、100 和 ∞）的估算卡，同时估算用户故事的故事点。规划扑克包括所有团队成员，即开发人员、测试人员、分析师等。这是一种基于团队范围内的共识的相对规模技术。以下是使用此方法执行估计时遵循的步骤：
- 每个成员/估算者都有一副卡片，每张卡片上都有合法的估算值。
- 主持人（通常不玩）阅读一个故事，然后对其进行简要讨论。
- 产品负责人会回答提出的任何问题。
- 每个估计者选择一张代表他们估计的卡片并将其面朝下（隐藏）。
- 卡片同时翻开，让每个人都能看到。
- 如果估计值不同，则最高和最低估计量可用于证明差异的合理性。
- 重新估计直到就故事点达成一致。
冲刺级别：
规划：
发布计划提供了团队打算构建什么以及团队打算在发布结束时部署什么的高级视图。它没有提供团队计划如何在 Sprints 中推动工作的详细视图。一旦知道版本及其 Sprint，团队就开始为每个 Sprint 进行规划。这发生在每个 Sprint 的开始，即 Sprint 的第一天，并允许团队更明确地了解他们将在 Sprint 结束时交付什么。团队会考虑 Scrum Master 的建议以及产品负责人的优先级列表。然后，团队决定他们可以从这个 Sprint 的优先积压中获取什么，然后分解每个用户故事的任务并将其分配给自己。
在 Sprint 计划会议中，团队将更多地关注他们需要做什么，以完成为该 Sprint 选择的用户故事。本次会议由产品负责人、Scrum Master、所有团队成员如分析师、程序员、测试人员、数据库工程师、用户交互设计师等参加。 Sprint 计划的输出可以记录在简单的电子表格或 ALM 工具（应用程序生命周期管理）中，团队将在其中按顺序列出该 Sprint 的所有用户故事及其任务（即 Sprint Backlog）。
Sprint 的团队容量规划和用户故事承诺对于 Scrum 团队来说始终是巨大的挑战。在致力于 Sprint 目标之前，了解当前团队的能力很重要。根据 Scrum 团队的能力，承诺将在该 Sprint 结束时完成一定数量的用户故事（或用户故事点）。基于这些输入和产品负责人、Scrum 团队和 Scrum Master 之间的同意协议，可以准确地估计任务。这样，团队的能力就可以用于有效的计划和估算。
Sprint 计划在每个 Sprint 开始时进行。这有助于团队将注意力集中在 Sprint 目标上。在 Sprint 计划中，团队决定将在即将到来的 Sprint 中构建什么以及如何构建它。在将用户故事分解为任务并进行任务级估计之后，团队致力于 Sprint 目标。 Sprint 计划由产品负责人、Scrum Master 和团队完成。在本次会议期间，将考虑团队速度、先前的速度趋势（如果可用）和可用的团队容量，以进行有效的规划。
Sprint 计划会议分为两个部分，每个部分分配一半的 Sprint 计划会议时间。
第 1 部分：在第一部分
- 团队与产品负责人一起确定将作为 Sprint 的一部分交付的内容。
- 产品负责人向团队解释用户故事。
- 详细说明交互
- 审查基础设施和接口
- 解释验收标准
第 2 部分：在第二部分
- 团队成员决定他们将如何在 Sprint 期间将此功能构建到产品增量中。
- 团队选择用户故事
- 用户故事被分解为任务
- 每项任务都以小时为单位进行估算
- 团队同意将在 Sprint 期间完成的用户故事。
Sprint 计划会议所需的时间将与 Sprint 的持续时间类似。
估计：
在 Sprint 计划期间，产品 backlog 中的优先故事被分解为可以估计的任务。在 Sprint 计划中，使用自下而上的估算，任务以天/小时为单位估算，从而产生用户故事的实际工作量。
可以定义与设计、编码、测试场景、单元测试、测试用例执行等相关的任务。根据“完成的定义”，任务列表可能包括自动化、回归测试、更新样式指南、完成代码审查等。团队必须明白 Sprint 成功意味着所有参数都设置为完成定义的一部分。
在敏捷项目中，“完成的定义”决定了用户故事要考虑的条件，其相关任务已完成，并准备好供用户接受。 “完成的定义”提供了项目团队成员和产品负责人之间的共同理解。当团队中的某个人说某项任务完成时，团队中的每个人都会对它的含义有一个共同的理解。通过“完成的定义”，团队坚持质量标准。
每个团队成员负责他们自己的任务，他们必须单独估计。每天，任务所有者必须报告任务的剩余（待办事项）小时数，用于绘制燃尽图。
多次询问测试人员是否也应该估计开发工作量，反之亦然。所有与用户故事相关的活动都应该作为一个组一起估计。 （即测试人员和开发人员）。估计是基于发布计划期间的相对大小进行的，并被自动考虑在内。每项工作都应由其所有者在 Sprint 计划期间进行估算。
作为 Sprint 计划的一部分，Scrum Master、产品负责人和项目团队成员从优先产品 Backlog 开始，以定义 Sprint 的范围并创建 Sprint Backlog。 Sprint Backlog 包含将在当前 Sprint 期间完成的用户故事。团队一起从 Sprint Backlog 中获取用户故事，并将它们分解为可以估计的单个任务。
估计完成任务的理想时间。理想时间的估计将任务的规模（以故事点衡量）转化为对工作量的全面估计。通常，这种努力是以天或小时为单位来衡量的。任务估计适用于 Sprint Backlog，仅在 Sprint 期间出现。
例如，当团队进行 Sprint 计划时，他们将选择一个大小可能为 5 个故事点的用户故事。然后将此用户故事进一步分解为不同的工作任务，例如设计、详述、实施和测试。目标是弄清楚开发团队在 Sprint 期间可以提交多少用户故事。开发团队必须对承诺感到满意，产品负责人必须相信团队会兑现承诺。
理想时间估算基于自下而上的方法，其中业务需求由团队成员分解为低级活动，每个活动都单独估算。要求团队成员注册任务并估计他们在几小时或几天内完成它们需要多长时间。
当团队使用理想时间进行估计时，他们指的是程序员完成一项功能或任务所需的时间，与其他功能或任务相比。团队通过显示剩余的工作量（即燃尽图）来实现预期目标。
个别团队成员选择一项活动并提交估计任务的理想时间估计。如果团队成员对这些估计存在分歧，那么他们会讨论并达成共识。