为何成熟团队都已放弃点数估算?

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

我之前提过「建议使用需求个数而非估算点数来衡量需求规模」,观点引发大量讨论。本篇将围绕一个访谈案例展开,并对估算和估计进行概念厘清,阐述我们不建议采用点数估算的理由。

他们为何放弃了点数估算?

曾经,我们对一家研发组织进行了访谈。最初,他们使用故事点数进行估算:

我们两周一个迭代。每次开计划会,扑克牌估算要花很长时间。为期半天的计划会,至少有两个小时花在估算上。完成估算后,再用故事点总数决定进入迭代的需求是否符合工作量预期。

但是,经过一段时间的统计,他们发现:

不管计划会形成了怎样的估算结果,最终进入迭代的故事个数都是差不多的

基于这种情况,他们从估算点数改为个数:

于是,我们决定不再把时间浪费在打牌上!需求人员在梳理需求时数好故事个数,计划会上直接进行需求澄清,计划会时间立刻从半天缩短到了1.5小时

组织观察对估算行为有反作用

放弃点数估算,不止在于上面案例中提到的原因。

类似量子力学的观察者效应,组织对估算的观察会影响到估算者的行为。这是定义估算体系时必须充分考虑的因素,也是我们反对用点数来进行估算的主要原因。

一家大型国有行的软件研发中心,曾对软件需求进行功能点估算,并以此为基础对开发团队进行产能评估。很快地,研发团队为了显示自己干活多,把需求文档写得越来越复杂。于是,大量时间被花费在写文档上,直接影响了交付速度和项目进度。

最后,功能点估算法在全行被废弃。

另一家股份行的研发中心,鉴于上述问题造成的弊病,让测试团队介入功能点计算。结果,测试团队不时跑去开发团队询问信息,增加了更多的干扰和浪费。

点数估算很容易引起开发团队的规模冲动。我在咨询辅导中时常发现,同一个团队,在引入故事点估算的几个月后,团队完成的需求个数基本没变,但交付的故事点数可能翻了一倍甚至几倍之多。

另外,点数估算会加剧业务和研发之间的不透明。对业务人员来说,点数计算难以理解且不可控,与故事点相比,功能点这类问题更加严重。还是前面提到的国有大行,业务每年按一个折扣和研发计算功能点产能,这也彰显了业务和研发之间由功能点计算引发的不信任。

个数到底比点数好在哪里?

业务提出一个大需求,被研发拆成了若干个小需求,分步上线交付,加起来还是最初的那个大需求。这是需求个数比点数好的地方,直观可见且容易被业务同学理解,有利于业务与研发之间互信的建立

估计需求个数,可能让开发产生拆细需求以增加个数的冲动。但是,这种「副作用」对组织甚至是有益的。需求拆分到细小的颗粒度,会让团队更快速地完成交付,减少进度和质量风险,从而尽早实现业务价值。

需求颗粒度拆分还受到需求可测试、潜在可发布的制约。虽然开发想把需求尽可能拆细,因为增加了测试和产品的管理成本,会受到来自测试和业务同学的阻力。于是,开发、测试、产品三方之间形成制衡,有效避免了需求无节制细分的可能性。

因此,我们建议将需求拆分成粒度相对均匀的条目,再使用经过平准化的需求个数作为规模基数进行估计。

厘清概念:估计与估算

第三节中出现了「估计」和「估算」两个概念,通常均被译为「Estimate」。其实,两个词的含义并不相同,需要特别注意并加以区分

估计是对未来的预测。对个人而言,估计可能是预测某个任务完成的时间:

对团队而言,估计可能是预测某个项目上线的时间,也可能是预测某个版本将要完成多少需求:

估算是被组织刻意观察的估计。如果组织对估计结果与实际结果进行统计分析,那么,估计行为就变成了估算行为。

我绘制了一张估计与估算关系的简要示意图,便于读者理解:

估计是人类应对不确定环境的必要手段。Martin Folwer 在一篇文章中提到,估计的价值在于为管理者做出相关决策提供支持,如帮助分配资源、协调进度、提升沟通效率等。本文题目「放弃点数估算」强调的是估算行为,而非估计行为。

需求规模自然地趋于一致

对个数估算常见的质疑之一是:需求规模有大有小,很多组织不知道该如何拆,或者拆不好,估算也就无从谈起了。

回到本文第一节的访谈,该组织认为能进行这种改变有个基本前提:

即使不刻意进行需求拆分,我们的需求颗粒度也是比较一致的。

这也是我们长期观察所印证的一个发现:

每个组织都有一种「平整化」的力量,能让需求规模(颗粒度)自然地趋于一致。

上面访谈的组织不是孤例。十年来我们接触的很多组织都有类似的「平整化」力量,这是组织内部长期习惯的表现之一。组织经过一段时间的磨合,某些合适的做法被沉淀下来,这些做法会对组织成员(包括新成员)持续产生影响。即使不施以人为控制和提醒,组织成员的习惯、偏好也会彼此传染。久而久之,需求提出、需求澄清、任务分解、开发测试……不同角色会在「平整化」力量的影响下,逐渐达成这种「不可见」的一致。

再来看个现实数据的例子。下图为一家研发规模约900人金融企业,在刚过去的9月和10月,研发每周完成的需求个数相对均匀(国庆假期除外),基本一周上线30个需求。没有被刻意要求和调整过,数据分布清晰显示了组织内「平整化」的力量。

另外,有江河流域生活经历的读者可能知道,一定区域内的鹅卵石不会在大小上出现明显差异,因为持续的水流冲刷会导致鹅卵石之间互相摩擦,造成该现象的产生——这也是一种「平整化」的力量。

最后,总结本文的几个核心观点:

  • 估算是被观察的估计,会对组织起反作用;
  • 点数估算让研发产生规模冲动,容易造成浪费,损害业务和研发之间的信任关系;
  • 个数估计推动需求拆分,对组织利大于弊;
  • 每个组织都有一种「平整化」的力量,让需求规模自然地趋于一致。

 

作者:吴穹;20年经验软件工程专家,Agilean 创始人

本文由 @吴穹 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!