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