敏捷开发之故事点估算

背景:

M阅读是业内知名的一款阅读APP,从今年8月份起,为了适应快速的市场变化,版本规划从以往的4周一版,演变为2周一小版,4周一大版的方式发布。需求的下发,按月度规划,由版本经理和需求经理统一安排下发。

长期以来一直存在一个问题,版本经理和需求经理与团队对于工作量的裁定是以人天作为单位,采用团队能承接多少人天需求来安排需求。迫于市场,运营,甚至总部的压力,会给团队安排更多人天的需求,而团队为了能准时完成的交付任务,避免延期的风险,往往在人天估算中加入很多Buffer,或者以超出团队承载能力为由,拒绝接收需求。长此以往进入了一种恶性循环,一方面版本经理/需求经理观察到人天估算里有水分,会敦促团队承接超出团队承载量的需求,一方面团队会在下一次人天估算里加入更多水分,以减缓超出承载的需求交付压力。

人天估算的构成:

人天估算的构成中往往包括两个部分,一是客观的实际工作量,二是团队的主观因素,比如个人技能水平,团队联调等待,数据准备,团队公共人力等。这些因素的存在让人天估算不能准确的反映客观的工作量,同时也遮盖了团队开发过程中存在的浪费,浪费本身反而成为团队输出的工时构成之一,这很不合理。

如何以更科学的方式,让团队愿意承接更多的需求?如何避免估算的工作量越来越多,而产出却毫无变化?如何让估算本身成为敏捷团队有意义有价值的活动?

引入故事点估算:

故事点估算实际上是一个综合的对于用户故事的复杂度,工作量,风险或不确定性等,针对不同的用户故事类型设计不同的基准故事点。

Story Point=f(E,R,U,C)

工作量(Effort):开发一款个人信息的web页面 VS 多款web页面

复杂度(Complexity):页面包含不同的组件,比如包含日期,信用卡号,省份等复杂度不同

风险(Risk):改动底层敏感模块,破坏现有功能。

不确定性(Uncertain):需求开发初期不清晰的情况。

相对大小

故事点估算是相对概念,所以它允许即使具备不同能力的人,也可以达成一致的故事点估算。

假设孩子和成年人从家里出发到学校(1x距离),可能孩子走20分钟才能到达,大人只需要10分钟,但如果他们在这个距离上达成一致意见,即这就是1个故事点,同理在从家到医院的路程上(3x距离)大人和孩子都可以给出3个故事点的估算。

相对大小是团队估算的基础,有了相对估算,团队估算才可以有效实施。


团队估算:

故事点估算采用团队估算的方式进行,个人觉得这是故事点估算最大的意义。

以往一个需求只有一个专家分析,大部分团队成员只负责写代码,需求分析的质量全取决于专家。首先专家的资源有限,经常会成为团队的瓶颈,其次专家是人不是神,也会存在分析遗漏。其次团队其他成员每个迭代每个迭代接触的需求有限,往往各人自扫门前雪,开发哪个需求关注哪个需求,各自独立作战,团队能力成长缓慢。

团队估算的引入,一来会给与更多团队成员分析需求的机会,激发了团队分析思考的热情,促进了团队分析能力的快速培养。二来,在估算的过程中,团队一起碰撞讨论需求,使得对需求的理解更加清晰,更贴近用户的需求,开发风险暴露的越充分。



估算如何在团队间对齐:

故事点估算并不是基于公式的定量估算,因此没有准确的标尺,明确的告诉所有的团队多少工作量是一个故事点。一般来说,故事点一般用作团队内部,团队与团队之间的故事点基准可能完全不同。

但在项目组内,一个特性组的组长往往带领多个团队,在一个特性组内部的多个团队,有统一故事点的需求。因为需求的下发到一个特性组场后,经常在不同团队之间调配,如果一个团队估算完需求故事点,调配到另一个团队的时候需要重新估算,很浪费时间。因此在应用上,一个特性组内部的多个团队之间,形成统一的故事点标准。

首先,为了方便起见,估算我们采用的是在一个“理想人天”里可以完成的工作量作为一个基准故事点。以此为基准,团队和团队之间差别不会特别大了。

其次,由组长作为各团队对齐的一个标杆,组长会参与到各组的故事点评估,如果有发现各组标准不一致,组长可以当场提出来进行故事点调整。



需求太小,必须做团队估算吗?

在我们的团队中,存在这样一种情况,往往一个迭代,团队要接纳4,5个或者更多的需求,而这些需求大小不一。有些需求较大,需要好几个开发测试配合才可以在一个迭代内部完成。大部分都是小的需求,这样的需求只需要一个人很短的时间内就可以完成。而针对这些小的需求,往往只需要一个团队成员进行分析即可。如果让所有的团队成员都去了解,分析,并进行估算,团队会认为没有必要,属于浪费时间。

针对这种需求,其实很简单,因为需求本身不复杂,只需要分析人员给大家稍微做下介绍,就可以由团队一起帮其做评估,而且不会花费太多时间。因此建议即使是小的需求,也务必采用团队估算的方式。

估算的时间点:

故事点估算可以发生开发过程中的任何时间,但不是说没有准入条件,要做到一个比较准确的故事点估算,需要团队预备以下条件:

需求基本已经定稿,团队对于需求本身,以及实现的方案的理解,至少达到了80%的程度。

有些团队对于开发模块比较熟悉,这样的团队能力水平较高,在需求讲解完成的后,立即可以对需求进行估算。但有些团队模块熟悉程度不高,或者团队成员能力较差,并不能在需求讲解后马上进行故事点估算,还取决于对需求的分析程度。对于这样的团队,我们一般在需求分析初稿完成之后进行。也就意味着通过对需求的了解,代码的分析之后,实现方案基本已经敲定,因此此时的估算才稍微准确一些。

团队估算是否需要全员参与?

对于估算是否全员参与,个人认为还是看情况,因为这涉及到一个收益和成本的问题。

有些团队把估算的过程,和需求讲解的过程结合在一起,这种情况下建议由团队全员参与,先决条件是团队能力较强。相反有些团队为了避免新手开发在估算中无法给出较准确的值,把估算的过程安排在一部分具备分析能力的团队成员间进行,这些人相当于团队的专家小组进行高效估算。在各个团队,情况都不一样,选择的方案也不一样。当然在版本压力不大,大家学有余力的情况下,全员参与是有必要的。