Menu
Menu
预测是对未来事件、趋势或结果的预判或估计。它是基于已知信息以及对过去和现在情况的分析而做出的。
在产品开发中，预测通常用于发布计划，以创建一致性并管理所有相关人员对新产品或新功能交付时间的期望。
如果 Scrum 团队希望了解产品待办列表的工作何时可以完成，他们可以根据趋势和历史记录来预测产品待办列表项 (PBI) 的交付情况。但是，重要的是要知道，由于工作的复杂性，他们的预测绝不是承诺或保证。
产品发布是指团队向客户提供新的或升级的体验，以获得反馈并交付价值。
Scrum 团队可以使用发布计划作为指南，通过小规模增量和频繁发布来交付产品，而不是大规模的一次性产品发布。计划和执行频繁的小规模发布的好处是：
请记住，当 Scrum 团队使用持续集成、持续交付和持续部署等实践时，他们可以在任何时间点向客户交付。这使他们可以在 Sprint 期间发布多次，甚至每天发布多次。在这种情况下，发布计划涉及短期计划，团队必须验证他们交付的产品增量是否真正带来价值，同时专注于他们的下一个实验。
在沟通预测时，Scrum 团队应确保将所涉及的不确定性考虑在内。团队中的每个人以及利益相关者都必须明白，随着更多信息的出现、情况的发展以及障碍的识别和消除，他们的预测将会发生变化。这些因素包括技术和开发复杂性、团队内部的变化、不可预见的依赖关系、不确定的客户行为以及不断变化的市场条件。
在 Sprint 计划会期间，Scrum 团队可以使用历史数据（例如吞吐量）来预测他们认为可以在 Sprint 中交付的工作量。此 Sprint 预测与 Sprint 目标和交付增量的可行计划一起构成了 Sprint 待办事项。
Sprint 评审是 Scrum 团队向利益相关者更新和公开其最新预测和产品目标进展的机会。根据他们所了解的情况，Scrum 团队会根据需要更改其产品待办列表，以利用新兴机会。这些更改随后可以被纳入更新后的预测和发布计划中，几乎实现实时调整。
Scrum 团队可以使用多种预测技术作为 Scrum 的补充实践，这些技术各有利弊。然而，它们的真正价值在于 Scrum 团队使用它们来推动团队内部以及与外部的对话。
燃尽图或燃起图可用于展示 Scrum 团队随时间推移在完成给定工作量方面的进展透明度。
两者的区别在于，燃尽图显示的是某个时间点上仍然剩余的工作量，而燃起图则显示的是朝着目标已完成的工作量。 “工作” 可以用产品待办列表项的数量、故事点或其他度量单位来表示。这两种图表都允许 Scrum 团队随时间透明化实际完成的工作进度。根据进度趋势，他们可以预测所有工作的完成时间，或者在某个日期前可以交付多少工作。预测的不确定性可以通过绘制乐观的趋势线和悲观的趋势线来捕捉，这被称为 “不确定性锥”。 结果是一个可能的工作交付时间范围。Scrum团队展望的时间越远，这个锥形就越宽，反映了对未来预测的不确定性越大。
燃尽图和燃起图的优点是制作起来相对简单，而且相当直观易懂。然而，它们无法表明是否真正实现了价值。因此，它们用于以输出而不是成果的形式跟踪进度，Scrum 团队及其利益相关者很容易专注于完成最初预测的工作，而不是监控朝向实现产品目标的进展。此外，在燃尽图的情况下，它们对实际情况提供的透明度有限。例如，考虑一个 Scrum 团队，它在 Sprint 中没有完成任何工作，而另一个 Scrum 团队完成了很多工作，但将相同数量的工作添加到产品待办列表中。在同一个 Sprint 中，这两个团队将拥有相似的燃尽图。
概率预测是一种预测某项任务何时完成的计算。例如，根据以下日历，预测可以采取如下形式：有85%的可能性该项工作将在2018年2月11日之前完成，但只有50%的可能性会在2018年2月3日之前完成。
概率预测可用于预测单个项目、整个产品待办列表的完成情况，或某个日期前产品待办列表可能完成的工作量。它们通常使用蒙特卡洛模拟创建，并基于 Scrum 团队的历史表现。
概率预测有助于传达不确定性，因为概率语言是大多数人都能理解的。然而，这类预测并不容易创建，而且可能会有缺陷，因为模拟的质量取决于输入数据。
预测提供了发布计划所需的信息。与预测技术类似，Scrum 团队可以使用与 Scrum 互补的发布计划技术。每种技术都有其优点和挑战。重要的是，团队应将他们的讨论和计划重点放在他们试图通过每次发布实现的目标上。他们应该从“为什么？” 开始，并考虑循证管理概念中的 “未实现价值” ，即客户当前体验的结果与他们希望体验的结果之间的“满意度差距” 。
这次发布将如何帮助团队满足客户当前的“满意度差距”？
大多数人认为发布计划仅仅是对某些产品待办事项何时可以交付的统计和预测。然而，Scrum 团队可以通过探索以下问题，以专注于有效地向客户交付价值的方式使用发布计划：
我们每次发布都想实现什么目标？我们希望为用户和客户达成什么样的成果？
哪些特性能够满足这些结果，并且我们应该包含哪些（以及不包含哪些）？
我们的预测是什么？我们什么时候应该/可以发布什么？
我们将衡量什么来验证发布的价值？
我们的利益相关者和客户是否有能力并准备好接受我们想要发布的变更？
我们需要考虑哪些依赖关系？
哪些潜在的障碍可能会延迟我们的发布？
谁需要参与进来？
包括利益相关者在内的每个人都意见一致吗？
我们如何沟通/管理期望？
用户故事地图是 Jeff Patton 开发的一种技术，在他的书《用户故事地图：发现整个故事，构建正确的产品》中进行了描述。Scrum团队可以使用故事地图来开发其产品待办事项的多维视图，因为它将用户使用产品的旅程、完成这些活动所需的工作以及这些用户故事如何融入 Sprint 和发布中联系在一起。
路线图是 Scrum 团队用于规划发布的一种技术。为了让路线图对Scrum团队有用，它们应该是不完整的，这样可以允许产品负责人根据团队从每次发布中学到的内容来做出决策。
然后，路线图充当一个灵活的工具，用于讨论愿景、目标、策略和机会，而不是作为固定时间段内工作项的清单。当路线图仅仅被用作项目或计划的不同可视化展示时，可以认为它是一种敏捷反模式或陷阱。
为了使预测有用，Scrum 团队需要持续进行预测工作。随着更多信息变得透明，他们应该更新预测和发布计划。
无论 Scrum 团队在预测和发布规划方面采用什么方法，每个人都应该记住，发布预测不是承诺，也不能取代经验主义的重要性。在复杂的环境中，未来是未知的。
