AICon日程100%就绪,9折倒计时最后一周 了解详情
写点什么

一文搞懂 Scrum 中的工作量评估和预测

作者:John Coleman

  • 2022-09-10
    北京
  • 本文字数:7702 字

    阅读完需:约 25 分钟

一文搞懂Scrum中的工作量评估和预测

近年来,Scrum 世界发生了巨大的变化。这一点在工时评估(estimating)方面体现得最为明显;自这个框架诞生之日起,Scrum 从业者就一直在进行着这项艰苦的实践。许多人没有看到评估的价值。2020 年,在 Scrum 指南中,“工时评估”一词被 “规模评估”(size)取代。有人些经常忘记评估是什么,说到底,评估只是评估。

 

社区对于工时评估和预测所持有的观点令人担忧。我的目的不是火上浇油,而是补充一些想法,以供进一步讨论。在我看来,Scrum 世界需要这样一篇文章。这是一篇理论性文章,适合有相当 Scrum 知识和实践经验的读者阅读。希望这篇文章对你有所帮助。

 

如果你做的预测总对,那你就是超级天才了。预测很少完美,原因如下:

  • 由于存在依赖关系,所以等待时间是工作耗时的一个重要因素,受许多不可预测的事件影响。

  • 即使工作环境不复杂,人们也会高估一天能够完成的工作量。

  • 通常情况下,人们会设法尽快把复杂的工作干完,不讲条理,而且可能发生意外情况(意外并发症)。甚至更糟糕,后续的工作导致情况恶化,不管是否解决了杂乱无章的问题,工作耗时都会比之前多。有人称之为“破窗综合症”。

  • 复杂的工作涉及许多未知的变量。

  • 缺乏专注,例如,“拿出你 10 秒的时间“或者”务必想尽各种办法“,原因是发布周期太长或者围绕流程瓶颈的过度计划(工作太多)。

  • 改变优先级,而又没有根据调整后的优先级更新工作量。例如,在有问题的预测会议之后,且明显不允许的情况下,又增加了一个新的优先事项。

 

人们通常认为,预测是为了告诉大家,“什么时候可以完成?”然而问题经常会接踵而至:

  • 我如何才能把担忧传递给别人?

  • 取得了哪些进展?

  • 还有什么风险?

  • 对于这项投资,我们什么时候才会有回报?

  • 哪些工作有潜在价值,如 80:20 原则,对此我们可以接受何种取舍?

  • 部分或全面降低有效性、效率和可预测性,如运行一些试验,对此我们可以接受何种取舍?

  • 我们需要通过“非生产性工作”来避免执行偏差,如试验室准备,对此我们可以接受何种进度取舍?

  • 为了掌握所需的技能,我们需要多大的投入,如培训或学徒训练?

 

有必要考虑下“赢得游戏意味着什么?”这个问题的元问题。团队参与的是一个有可能获胜的游戏吗?如果团队能够获胜,胜算有多大?概率预测可以提供帮助,如蒙特卡罗模拟算法。

 

尽管存在风险,但团队有时还是需要预测,因为人们担心,利益相关者会凭空定一个不可能完成的日期。有时候,团队希望有一个超出利益相关者预期的大致日期范围。有趣的是,大多数人都可以接受天气预报随着最新信息定期更新,即使我们知道那还是不准确。

蒙特卡罗模拟

Troy Magennis 对蒙特卡罗模拟做了很好的解释,简而言之,它让人们可以基于数据和假设“模拟(model)”未来。概率预测可以告诉你,你能够完成多少工作,而不是你手头的工作是否符合预测。虽然对于复杂的工作来说,概率预测是一种幻象,但我们可以在掌握最新信息时重新做,让它们随着时间的推移越来越可靠。

  • “Monte Carlo-When”预测使用 500 到 100 万个随机数表示每个时段内介于上下限(真实数据或 90%置信猜测)之间的吞吐量(每个时间段内,如冲刺,有价值事项的交付率),以及随机生成的一定范围内的事项数量,每个预测将返回一个日期范围以及相关的概率。例如,在下图所示的结果中,经过 10k 次模拟,在 11 月 22 日或之前有 85%的可能交付 50 到 75 个事项。



TWiG and ActionableAgile截图

  • “Monte Carlo-How Many”预测使用随机生成的每个时段中一定范围内的吞吐量,来预测给定日期内可以完成多少事项;输出是一个日期范围、截止那个日期可以完成的事项,以及一个百分比概率。如下图所示,85%的事项将在那个日期或者之前交付。


TWiG and ActionableAgile截图

 

不管在哪种情况下,限值错误都会导致预测质量不高。例如,我们使用一个七面的骰子,点数为 1、2、3、4、5、6、7,而吞吐量只有可能是 3、4、5、6 或 7。我们也允许出现 1 或 2,只是那可能已经超出了限制。也就是说,1、2、8 或 9 还是可能出现,只是可能性比较小。Prateek Singh 更详细地介绍了如何使用各种模型来生成随机数。此外,如果吞吐量不稳定,或者每个时段都几乎为零,那么蒙特卡洛模拟的质量就会大大降低。预测的本质是风险管理。它回答了这样一个问题:我们目前的计划包含多少风险?预测质量下降也就意味着风险管理不足。

 

社区并不认可这种方法。一个项目仅执行一次。虽然概率可以帮助我们做决策,但问题是它们并不会简化决策过程。评估经常作为决策的一个指标(我们要不要做这个项目?)。在这方面,概率预测会提供什么答案吗?还是说只会提出更多的问题?这些问题很重要,但使用估计的原因与概率预测并不相同。我见过许多基于错略评估、缺少历史信息的概率预测,最终还比较准确。如果你想了解更多这方面的内容,可以看下我和Troy Magennis的有关对话

 

接下来,我将更详细地介绍工作量评估和预测,希望可以帮助大家了解 Scrum 语境下的小恶魔。

工作量评估技术

在使用 Scrum 时,Scrum 团队是自管理的,开发人员负责评估工作量,因为他们最熟悉开发工作。

 

最流行的工作量评估技术要么是基于数据,要么是有依据的猜测。要知道,在面对复杂情况时,这些技术一般都不准确。

 

我发现,大部分人都不擅于估计。尽管如此,人们还是可以从对话中感知到价值,当我们就工作及其挑战达成共识时,就可以做出一些假设。“理解事项”和“评估事项”是两项单独的活动,不应该混为一谈。我认为,针对单个产品待办事项的评估并不能为预测完成工作需要多少时间提供一个坚实的基础。

 

下面是使用估计进行预测时最流行的工作量评估技术:

  • 相对估计时间参照——将当前事项与完成历史参考事项所用的时间进行比较。分配数字值——例如,使用基于斐波那契数列的故事点,并经常搭配扑克牌方法(计划扑克)使用。T 恤尺码分类法——给待办事项列表上的事项分配尺码(s、s/m、m、m/l、xl、xxl、xxxl、xxxxl)而不是数值,有时候,为了简单起见,我们会去掉一些尺码,只保留 S=1、M=3、L=8、XXL=20(四舍五入)、XXXXL=60、?=100(四舍五入)。墙壁估计(Wall estimation)——通过一起在墙上放置和移动卡片来分配数字值,也称为魔法估计或沉默估计。

  • 流量计(Flow metrics)或事项计数对于一个目标或时段—— (尽可能)识别/清点待办事项列表上需要完成的事项数量或范围。

  • 适型化(Right-sizing)—— 识别出足够小的事项以供团队纳入工作计划——通常使用一种基于流的方法—— 一个事项是小号还是中号并不是那么重要。这项实践是为了弄清楚,根据完工定义,团队能否在一次冲刺中舒畅地完成一个待办事项。

  • #NoEstimates —— 一种解释是:争取让待办列表上的事项“大小合适”且均匀分布。数一下现有已测故事或特性,展示输出进展。以“为什么”为目标,致力于简化“是什么”,即聚焦预期成果。适型化 —— 识别出足够小的事项以供团队纳入工作计划。将事项切分到 24 小时的时间框里,鼓励创建试验,验证为达成目标所做的假设和猜测,了解情况以便交付。使用滚动预测来沟通不确定性。

 

有人会认为,只清点待办列表事项而没有吞吐量数据还是一种估计,我对此表示赞同。基于已完工事项的吞吐量计数是一种预测。

 

在上面的工作量评估方法中,只有墙壁估计直接考虑了相对潜在价值。它使用价值点来评估价值(而不是工作量)。价值不是绝对的,而是相对的。客户价值只有在发布给客户之后才能实现,而其价值可能高于预期,也可能低于预期。

 

上述所有的评估方法都会因以下情况贬值:

  • 没有与开始日期相关的说明,如从开始之日起 9 周。

  • 没有识别出在制品的数量及其进展(或者没有进展)。

  • 障碍的严重性。

  • 没有根据交付风险大小对产品待办列表的事项做降序排列。

  • 没有用最好的方法来处理依赖关系。

  • 将输出与成果混淆;客户/最终用户成果是他们的行为变化。

  • 当无法获取潜在价值的风险很高时未参加发现活动,而假定所有事项都从发现移到交付使情况进一步复杂化。

  • 妄想准确,还追求更准确。

 

以下趋势并不是很理想:

  • 按技能评估——通常是因为关注资源效率胜过流程效率

  • 大小通胀——通常由迫于压力“提速”所致。在非典型情况下,团队在评估工作量大小时会就高选还是就低选?不用猜,很可能是就高选。在极端情况下,我称之为(评估)Bingo。

  • 不重视质量,例如,完工定义缺乏一致性——通常由迫于压力“提速”所致。别搞错了,完工定义的质量承诺很重要。

  • 不重视客户,例如,交付输出却不衡量效果——通常是由“楼内思维”过盛或远离客户所致。

  • 团队之间大小标准化,通常是因为把人当成了可替换的机器零件。根据我的经验,在很多情况下,即使产品待办列表、比较参考项和范围都相同,团队也从来无法得出相同的大小评估。

  • 清点已完成的伪产品待办事项(不提供价值的事项)作为吞吐量——通常是由使用了忽视价值的工作分解结构所致。

  • 不专注,未完工。在 Scrum 中,专注很重要,这主要体现在产品待办列表中的产品目标、冲刺待办列表中的冲刺目标以及 Scrum 价值。专注于已经开始的工作,即使那意味着分割或取消工作,如何?

  • 妄想预测无法与以前比较的工作。

  • 未能通过发现找出我们可能不应该构建的事项,有人说是 70%。我们可以通过低成本的试验获得更好的想法。例如,据我所知,当 Bose 发现降噪耳机时,他们其实是在寻找提高声音保真度的方法。缺少发现通常是因为领导者致力于代表团队工作;他们的观点是,“寻找更好的方法没有意义,我们有最后期限。”

 

这篇文章不是为了帮助人们保持这种趋势,而是要介绍更好的方法。需要注意的是,本文介绍的内容并不能帮助你更好地使用故事点进行评估。

 

本文将重点介绍的三个工作量评估选项是估计、适型化和 #NoEstimates。没有哪一种方法是完美的。我还考虑了其他一些选项,但无论采用哪种方法,准确度都很低。

  • 关于估计:估计有不同的方式。如果进行估计,最好的结果就是估计对了。而事情要用多长时间和处理时间几乎是没有关系的(参见Troy Magennis探讨这一主题的文章)。估计容易出现“平均值缺陷”(萨维奇)。采用五五开的方法设定期望值好吗?独立盲估的平均值可以足够接近真相(参见Dave Snowden的Xagility播客)。但估计很少是盲目的。如果你根本不进行估计,就可以节省时间;希望你能更快地发现/交付成果。

    关于适型化:如果你能更多地关心团队能否在冲刺中完成一项工作,而不是想尽办法压缩这项工作,那能节省多少时间?要考虑到 PBI 数量少可以减轻产品所有者的认知负荷。清点一下每个冲刺要完工交付的 PBI 数量(有价值、大小合适),这对于冲刺规划和目标预测很有价值。如果吞吐量断断续续或者无规律,那么我们面临的问题就会比预测严重;我们会面临“管道问题”。使用平均吞吐量也会导致“平均值缺陷”。蒙特卡洛概率预测法更可取。

  • 关于 #NoEstimates,一种解释是:清点一下每个冲刺要完工交付的 PBI 数量(有价值、大小合适),这对于冲刺规划和目标预测很有价值。如果吞吐量断断续续或者无规律,那么我们面临的问题就会比预测严重;我们会面临“管道问题”。基于有变化限制的吞吐量进行”滚动预测(Rolling Wave Forecast)“更可取。

 

不管是使用估计、适型化还是 #NoEstimates,有时候产品待办事项(PBI)很难拆分,所以它们仍然有价值(而不仅仅是子任务)。介绍如何拆分产品待办事项的指南有很多实例映射就是一种很强大的方法;Scrum 团队可以仅为这个冲刺选择一个实例,并获取反馈。当我们可以收获价值的证据不足时,即使潜在价值很高,明智的做法也是借助试验通过推测(hypotheses)来验证假设(assumptions);#NoEstimates 和 Scrum with UX 支持这种方法。拆分可以引发发现或是发现-交付(discover-to-deliver)。例如,拆分可能引发客户访谈和 UX 研究。

部分评估方法的潜在优点

历史时间参考

分配数字值,如故事点

要完成的T恤尺码

墙壁估计

要完成的产品待办事项数量/范围(目标)

适型化

#NoEstimates

除了“完工定义”和“产品待办清单细化”之外,不需要太多Scrum培训。

开发人员非常重视有关相对大小的讨论,他们认为那有助于更好地理解工作。

开发人员非常重视关于相对大小的讨论,他们认为那有助于更好地理解工作。

开发人员非常重视关于相对大小的讨论,他们认为那有助于更好地理解工作。

以持续预测为基础,根据交付经验值,不断就预算和/或事项数量展开协商。

简单。开发人员评估产品待办事项是否正好与一个冲刺相匹配,如果不是,则进行适当拆分。

关键是,估计是用来为决策提供信息的。如果基本信息(估计)错得离谱,就会在决策过程中导致灾难性的失败,那时,就必须替换这项技术

通常包含等待时间。

开发人员会觉得更好地发现了相对复杂度/风险。

开发人员会觉得更好地发现了相对复杂度/风险。

开发人员会觉得更好地发现了相对复杂度/风险。

开发人员可以用范围来“粗略估计”。

减少“分析瘫痪”。对于规模,LeSS的一般原则是,在接下来的2到3个冲刺中,每个团队每个冲刺完成4个待办事项。

关注发现/交付,必要时拆分事项。

来自LeSS社区的Bas Vodde指出,这种方法比“要完成的故事点”危害性小(参见这篇文章的第40条

人们说对话很重要(不过,触发这样的对话或许有更好的方式)。

如果有T恤尺码数值表,那么T恤尺码分类法就可以转换成故事点法。

可以使用T恤尺码/数字值。

这对确定待办列表块的大小很有用,如产品目标、冲刺目标。

可用于对从产品待办列表中选择的事项做概率预测。

小批量仍然是目标,减少承担“大象”事项的可能。

适用于“蛋糕片”团队(可以不依赖其他团队独立交付价值,蛋糕的每一层在团队中都有代表)。

一种限制冲刺在制品数量的方法,但可能有更好的方法。

人们说对话很重要(不过,触发这样的对话或许有更好的方式)。

当搭配使用T恤尺码分类法和T恤尺码数值表时,速度非常快(不到1小时就可以评估出大部分待办事项的大小)。

可跨团队使用。

产品待办事项因为拆分少而更有价值。

假定/接受不确定性和信息不完整性,使用数据进行预测。

用客户的语言(时间)说话,还是?(时间价值?)

如果使用计划扑克会非常耗时。要了解更多细节,可以查看这篇文章

开发人员只需看下相对大小,而不需要了解多少细节。

可以看下Mitch Lacey & Associates公司所有者Mitch Lacey写的这篇文章,其中考虑了潜在的价值和工作量。

可以用于概率预测。

当与概率预测搭配使用时,用客户的语言说明可能什么时候完成(还是?),同时要说明:“下个周/冲刺/月会有更好的预测。"

根据价值交付经验,以持续预测为基础,不断进行预算和/或事项数量谈判。

 

 

 

 

当与概率预测搭配使用时,用客户的语言说明可能什么时候完成(还是?),同时要说明:“下个周/冲刺/月会有更好的预测。"

假定/接受不确定性和信息不完整性,使用数据进行预测。

归类——将目前的投资规模与以前类似的投资进行比较,有助于获得大家的一致认可;有三到五个特征相似即可,如业务领域、技术、事项类型、团队、流程、客户类型,注意不要过拟合(确定性思维而非概率思维)。

 

 

 

 

假定/接受不确定性和信息不完整,使用数据进行预测。

根据价值交付经验,以持续预测为基础,不断进行预算和/或事项数量谈判。

吞吐量基于现有的已测故事——没有歧义。

 

 

 

 

 

 

相互独立的故事将投资纵向切分(你得到的是“一块蛋糕”,而不是“一层蛋糕”)。

 

 

 

 

 

 

尝试在现有已测故事中混合不同大小的事项,以此作为进度指标(至少是输出)会更可信。

 

 

 

 

 

 

将关注点转移到价值上;发挥创造性,简化价值交付的内容,然后按照Scrum的预期定期交付。

 

 

 

 

 

 

鼓励将产品待办列表中的事项切分成验证假设/推测的试验

部分评估方法的潜在缺点

历史时间参考 

分配数字值,如故事点

要完成的T恤尺码

墙壁估计

要完成的产品待办事项数量/范围(目标)

适型化

#NoEstimates

需要以前的大小(可能是类型)相近的参考项。但由于意外并发症、环境变化等原因,参考项可能没用。

即使是声称创造了故事点的Ron Jeffries也对故事点感到失望。

 

 

只适用于这个Scrum团队,甚至不适用于同一产品的其他Scrum团队(但也可能适用?)。

为在同一产品的多个团队之间标准化事项大小提供了可能——比较团队几乎从来都不是什么好主意。

倾向于使用“史诗”作为产品待办事项的容器,而不是PBI本身。

产品待办列表上的事项数量对于预测目标用处不大,因为许多事项是“大象尺码”的。

会成为某些利益相关者的心理障碍——与不确定性相比,人们宁可犯错。

容易被具有”利用率(utilization“)思维的人滥用。参见这个视频

只适用于这个Scrum团队,甚至不适用于同一产品的其他Scrum团队。

团队之间容易出现大小通胀或标准化。有些人喜欢限制事项大小,不知不觉中隐藏了工作量。

 

 

往往是一次性的:应该经常重新审视。

违反直觉:即使吞吐量的有用性已经得到了证明,人们还是强烈偏向于相对大小。

误以为所有PBI都一样大——我们不是在制造小部件,这不是制造业——我们在做的是复杂的知识工作,我们期望事项的大小不一样。

大多数团队是“蛋糕层”团队,因此不会生成“现有已测故事”指标,除非他们使用像Nexus这样的应对策略(尽管Nexus不跨团队共享产品待办事项)。但公平地说,这并不是#NoEstimates的缺点。在#NoEstimates INVEST中,故事往往会被切分。

不能用于概率预测,因为它不是以输出为基础。

团队之间容易出现大小通胀或标准化。有些人喜欢限制事项大小,不知不觉中隐藏了工作量。

容易被具有”利用率”思维的人滥用。参见这个视频

 

误以为所有PIB都需要一样大——对于知识性工作,我们期望它们彼此不同。

对于PBI拆分率是否有用,精益/敏捷社区并未形成一致的看法。参见这个视频

 

 

容易被具有”利用率“思维的人滥用。参见这个视频

转换为故事点后可以用于概率预测,但应该这样做吗?在任何情况下,如果产品待办列表的大小没有完全确定,你会对待办列表的大小施加什么限制(最小/最大)?

 

人们会对此表示反对,因为在他们看来,PBI的类型就像是把苹果和橘子混在了一起。

如果团队大部分时间都没有交付任何PBI,那么概率预测将变得不那么有用。

 

 

可以用于概率预测,但应该这样做吗?在任何情况下,如果产品待办事项列表的大小没有完全确定,你会对待办事项列表的大小施加什么限制(最小/最大)?参见这个视频

 

 

如果团队大部分时间都没有交付任何PBI,那么概率预测将变得不那么有用。

 

 

 

斐波那契数列是趋势,但可能不够指数化。

 

 

经常误以为我们应该使用滚动/移动平均数进行长期预测——正向或反向?

 

 

评估方法的其他注意事项

 

历史时间参考 

分配数字值,如故事点

要完成的T恤尺码

墙壁估计

要完成的产品待办事项数量/范围(目标)

适型化

#NoEstimates

通常结合

T恤尺码分类法

T恤尺码分类法

 

三点法

 

故事点

分配数字值

 

T恤尺码分类法

蒙特卡洛概率预测

#NoEstimates

 

要完成的PBI数量(或数量范围)

 

WIP监控

 

周期时间和事项年龄

要完成的PBI数量(或数量范围)

 

WIP监控

 

周期时间和事项年龄

 

参考类分级

 

故事映射

 

影响映射

使用复杂度

中低

中低

减分项

限制大小。

转换为供人使用的时间,依据技能进行故事点估计,限制大小,方法耗时,如计划扑克。

转换为供人使用的时间,按技能进行T恤尺码分类,限制大小,方法耗时,如计划扑克。

限制大小。

缺少对PBI年龄的关注,对精度的复杂性存在错觉。另外,即使在Scrum语境下,关注吞吐量而忽视受阻/被遗忘的PBI也是一种愚蠢的做法。

把事项强行塞入冲刺,完工定义在错误的人手中得不到重视,处理依赖关系的方法不是最好的。

对于产品待办事项大小是否适合在冲刺中增量完成,缺少指导规则。

 

如果使用时间间隔/跨度来传达对一系列事项的预测,那么利益相关者可能只会做出最乐观的时间间隔/跨度选择。

 

“故事”可能拆分到故事本身没有价值的程度。在Scrum和看板中,事项应该都是有价值的。危险在于团队交付的是活动,而不是促成成果的输出。

(如果做得不好)可能发生的最糟糕的事情

妄想通过过去决定未来。

依据技能进行故事点估计,偶然性大幅增加,活动度量与未完成工作的输出度量相反。

依据技能进行T恤尺码分类,偶然性大幅增加,活动度量与未完成工作的输出度量相反。

开发人员在小组中进行墙壁估计,没有交叉检查。

妄想事项必须大小相同,以就绪定义补充性实践为闸门。

妄想事项必须大小相同,根本不考虑大小,把“大象”事项纳入冲刺,以就绪定义为闸门。

根本不考虑大小,把“大象”事项纳入冲刺

预测

在预测工作量时,最受欢迎的方法往往是基于:

  • 产品待办事项(PBI)完工数量/范围的过往表现,基于平均值或范围——过往的表现不能预测未来,但短时间内(如一个冲刺)还可以。

 


TWiG and ActionableAgile的截图 —— 团队在交付,但许多天没有交付完工内容。

 

  • 数字值或 PBI 完工数大小/范围的过往表现过往的表现不能预测未来,但短时间内(如一个冲刺)还可以。对数字值做算术运算要谨慎,因为复杂性会随着产品待办事项的大小呈指数级上升,把“大象”事项纳入冲刺是有问题的。注意正在进行中的 PBI 的数量。有时根据燃耗/燃尽图,使用剩余工作随时间推移的“精确”/相对大小。

 

燃耗/燃尽图是基于平均数的,经常被误解

 

  • 概率预测(使用百分比概率)用于预测一定数量(或范围)的事项在不同日期完成的不同概率;可用于短期、中期和长期预测。考虑使用参数比例或随机抽样,根据以前的工作进行建模。例如,你可能会想:这项投资感觉和以前的两项投资类似,但我们需要增加 15 个事项。还要考虑将所有东西整合在一起的事项的数量或范围,因为工作最终整合时并不一定那么容易——但无论如何,风险不是通过迭代、增量和持续交付得到了很好的管理吗?

 


TWiG and ActionableAgile截图

  • 概率预测用于预测在特定的时间内可以完成多少 PBI——包括一个百分比概率、一个日期以及截至该日期可以完成的事项数量(或范围);可用于短期、中期和长期预测,但它更适用于输出导向而不是目标导向。


TWiG and ActionableAgile截图

 

  • 滚动预测证明了同时预测可能性和不确定性是门艺术。




  • 可以这样说,“我们采用一种经验性的方法,一次处理一个冲刺;冲刺目标并没有什么保证;真正的答案是,我们不知道,但让我们开始并快速学习吧。“你可能都不会用到“现在?”、“下一步??”、“其后???”这样的字眼。

 

在预测过程中,最令人不快的部分是,它通常不考虑我们同时进行的 PBI 有多少个。唉,我也经常看到一些团队,承担了超出他们通常能力的事项。

 

如前所述,团队可以使用不同的方法来评估工作量,实现冲刺/产品目标。几乎可以肯定,预测是错的,所以它们传达的是不确定性,这是为了提醒利益相关者,他们正在使用经验性的方法,一次一个冲刺的前进,而且要经常更新预测。(希望)产品待办事项成为一件有生命力的神器。

 

可能有人会说,最好的做法是根本不预测。他们会说:“我们只需发现并交付功能——与客户和最终用户一起评审成果。能学什么学什么。根据我们的发现采取行动。不做什么预期管理。”

结论

  1. 避免使用故事点方法。如果必须要使用故事点,那也只能当做一种临时性的方法。流行的做法是,将故事点方法作为团队工作量评估技术的一种补充,但它不能作为 Scrum 的一部分。我不喜欢这种方法。据我观察,当人们使用故事点时,经常会有破坏性的行为。我看到,人们使用故事点通胀、故事点 Bingo、故事点标准化和故事点速度作为衡量绩效的指标。举例来说,高层领导希望提升速度,所以他带领团队成员拆分未完成的事项,为的是达到某种故事点速度水平。团队无法完全控制他们可以交付多少工作。因此,如果一个团队面临着提升速度的压力,那么一个中等事项被定义为大型或超大型事项的几率就会增加。

  2. 避免使用平均吞吐量方法。吞吐量方法比故事点方法好一点,虽然它也不完美,但在与概率预测和吞吐量有价值事项计数一起使用时,它是一个更准确的预测基础。不过,如果事项无价值或大小不合适,那么吞吐量的可信度就会降低。吞吐量方法不是 Scrum 的一部分,在看板指南中也是可有可无,对于非软件行业,应考虑为不同类型的产品待办事项单独计算吞吐量,如包装 vs. 运输。用平均值来预测时间/点数/吞吐量可不是什么干事业的好方法。“老板,我们准时交货的概率是 50%;这样可以吗?”

  3. 考虑使用历史参考项。历史参考项包括“等待时间”,使用该方法的前提是记住了它消耗的时间,不过意外并发症不在考虑之列。意外并发症是指我们的遗留工作比较杂乱,间接影响了估计质量;这也是参考项用于时间估计效果不是很好的原因。

  4. 尝试将有价值事项吞吐量作为概率预测的基础。对于非软件行业,应考虑为不同类型的产品待办事项单独计算吞吐量,如包装 vs. 运输。对于复杂的工作,这仍然是“雾里看花”,所以你最好加一条声明:你将随着了解的深入,在下周和下下周提供更好的预测。在进行概率预测时要警惕虚假吞吐量(无价值事项吞吐量)和散发吞吐量,特别是当所选的大多数时间段吞吐量为零时——基于不稳定的吞吐量进行概率预测会大大降低预测的质量。

  5. 尝试 #NoEstimates——滚动预测很好地传达了不确定性。为了避免破坏 Scrum 或看板(如使用 Scrum 团队看板指南),务必要确保所有(产品待办)事项都有价值。

  6. 当有人问你,团队何时能完成某件事时,试着回答说你不知道。但你得向他解释,你使用的是基于证据的经验主义方法,并且一次一个冲刺/周/月。许多事项需要发现/Spike(探针);你不知道会得到什么反馈,你不知道会学到什么,你也不知道要如何回应。但请注意,在许多文化中,人们都习惯于把真空填满,如果没人提供预测,其他人就会急切地等待,而且可能会一直等下去。

  7. 宜以敏捷为榜样。了解问题空间。发现并交付功能——与客户和最终用户一起评审成果。能学什么学什么。根据我们的发现采取行动——设定对不确定性的预期,而不是日期,让相关人员知道,这在某种程度上是在赌博。不要总想着了解我们不知道的东西。正如一位著名的敏捷专家对我说的那样,预测让我们觉得自己在做一些有用的事;这种感觉或未满足的需求都是我们要解决的。

 

我们经常会在估计和预测时迷失方向,忽略了价值。我们要和受影响的人一起衡量工作是否发挥了作用并适时做出调整。

附录

流量计

流量计不只是与吞吐量有关。根据 Scrum 团队看板指南,你还可以关注在制品、周期时间和事项年龄;在这种背景下,只看吞吐量是短视的。即使在 Scrum 背景下,只关注吞吐量而忽略受阻或被遗忘的产品待办事项也是很愚蠢的。

 

Scrum 团队看板指南为 Scrum 引入了 4 个指标,包括:

  • 在制品(WIP):已经开始但尚未结束的工作事项。团队可以使用 WIP 指标来展示进展,减少在制品,改进工作流程。请注意区分 WIP 指标和 Scrum 团队用于限制 WIP 的策略。

  • 周期时间:根据 Scrum 团队看板指南,周期时间是一个事项从开始到结束所消耗的日历时间(四舍五入)。

  • 事项年龄:一个事项从开始到现在所消耗的日历时间;它只适用于正在进行中的事项。

  • 吞吐量:单位时间内完成的产品待办事项数量。

 

参见:Scrum with Kanban如何帮助人们解决复杂问题?

一些影响/挑战预测的技术

工作量评估指南——其他方法

其他评估方法的优点

时间估计——以小时、人天、理想日(perfect days)为单位估计工作量

成本估计

三点法

不需要Scrum培训。

不需要Scrum培训。

开发人员非常注重讨论相对大小,他们认为那可以加深对工作的理解。

用客户的语言(时间)说话,还是?

用客户的语言(金钱成本)说话,还是?(时间价值?)

发现相对复杂度/风险会让开发人员感觉更良好。

 

常以冲刺(适用于产品目标)或转换为成本的时间进行估计。

乐观主义、悲观主义、现实主义——每个人都能发表意见。

 

 

设定一个范围,而不是一个数值,非常适合于沟通不确定性,让利益干系人习惯于不确定性。

其他评估方法的潜在缺点

时间估计——以小时、人天、理想日(perfect days)为单位估计工作量

成本估计

三点法

容易被具有”利用率“思维的人滥用。参见这个视频

对于即将进入冲刺阶段的单个产品待办事项的工作量评估,用处不大。更适用于评估整个产品目标大致的工作量数量级。

可以用于加快计划扑克,但会损失一些对话价值,少一些了解更多意见的机会。

不能用于概率预测,因为它不是以输出为基础。

 

转换为故事点后可以用于概率预测,但应该这样做吗

你最后一次度过完美的一天(理想日)是什么时候?

 

 

其他评估方法的其他注意事项

 

时间估计——以小时、人天、理想日(perfect days)为单位估计工作量

成本估计

三点法

通常结合

T恤尺码

T恤尺码、时间估计、历史时间参考

分配数值、T恤尺码

使用复杂度

中低

减分项

限制大小

限制大小、使用功能点、使用甘特图

限制大小

(如果做得不好)可能发生的最糟糕的事情

误以为所有人负重奔跑,整日整月地工作就可以将效率最大化

误以为过去发生的事情可以决定未来

更容易耍花招


作者简介:

John Coleman X-agilityOrderly Disruption的敏捷大厨。同时,他还是一名博文作者和播客创作者(Xagility™Agility Island)。John 是Thinkers360的十大敏捷思维领袖之一。他最擅长管理层敏捷性、真正可持续的组织敏捷性、降规模(descaling)和度量。John 经常使用 Scrum、看板或精益 UX。他曾设计方法,供那些需要保护措施或纯粹基于价值观或原则运作的团队使用。John 是看板指南的合著者,同时也是 Kanplexity™的作者。他是 Scrum.org 的专业 Scrum 培训师、Prokanban.org 的专业看板培训师,同时也是一名 LeSS 友好的 Scrum 培训师。

 

原文链接:

https://www.infoq.com/articles/sizing-forecasting-scrum/

2022-09-10 08:008660

评论 3 条评论

发布
用户头像
干就完了!
2022-09-19 11:28 · 北京
回复
用户头像
字都认识,就是不知道讲了个啥....

 

2022-09-11 20:25 · 四川
回复
毕竟有机器翻译的感觉
2022-09-16 14:34 · 浙江
回复
没有更多了
发现更多内容

架构师训练营第 06 周—— 练习

李伟

极客大学架构师训练营

JVM详解之:java class文件的密码本

程序那些事

Java JVM class GC 密码

架构师训练营作业(6周)

Hanson

架构感悟 6- 平衡之美

旭东(Frank)

CAP的原理

满山李子

朱嘉明:区块链对深入改革的意义何在?

CECBC

区块链技术 政策扶持 块链与经济 区块链功能 产业数字化

Redis进阶篇二——持久化

多选参数

redis redis6.0.0 redis集群 redis持久化

负载均衡

满山李子

【week06】总结

chengjing

从面试到入职到离职,我在B站工作的30天时光!!!

诸葛小猿

面试 B站 哔哩哔哩 收钱吧

架构师训练营第六周学习总结

fenix

极客大学架构师训练营

为了保存VuePress构建的网站为PDF,我竟然。。。

Leetao

Python python 爬虫 PDF vuepress pdfkit

上亿数据怎么玩深度分页?兼容MySQL + ES + MongoDB

Kerwin

Java MySQL ES 深度分页

【week06】作业

chengjing

Java这么优秀,我当然要深入啦

程序员小跃

Java Lambda

rdd序列化

InfoQ_6cf02607664f

计算机网络基础(三)---网络层-IP协议的转发流程

书旅

php laravel 网络协议 计算机基础 网络层

400GE燎原前夜,智能IP网络的核心路由器巅峰际会

脑极体

redis系列之——数据类型bitmaps:今天你签到了吗?

诸葛小猿

redis bitmaps bloomfilter

架构师训练营第六章总结

叮叮董董

职业发展的迷茫与困境:你真的了解职级体系吗?

伴鱼技术团队

程序员 技术管理 人才培养 职业成长 技术人生

极客时间架构师训练营 - week6 - 作业 2

jjn0703

极客大学架构师训练营

黑鹰坠落

escray

[架构师训练营]Week03 - 作业

谭方敏

天猫小店、京东小店的问题分析

石云升

价值网络 新零售 天猫小店

架构师训练营第 06 周——总结

李伟

极客大学架构师训练营

架构师训练营第六章作业

叮叮董董

By Experience的三个层次 -- 领域驱动设计的经验之谈

冯文辉

架构 领域驱动设计 DDD 架构设计

并发业务中,线程安全与否很重要,来看看你懂多少?

Java小咖秀

Java 多线程与高并发

架构师训练营(6周)

Hanson

C、C++、Java到Python,编程入门学习什么语言好?

华为云开发者联盟

c c++ Python 编程语言 Java 分布式

一文搞懂Scrum中的工作量评估和预测_研发效能_InfoQ精选文章