当前位置: 主页 > 神算子高手论坛 > 内容

热门内容

如何当个神算子?项目任务估算那些事儿

时间:2017-09-20 20:41  来源:未知  作者:admin

  对于估算,团队常常会有这样的困惑:花了大把时间来估算,最后却发现与实际还是有不小的偏差,到底有没有必要做估算,怎样来做估算?

  俗话说,行百里者半九十,意思是说一百里的走了前面九十其实只完成了一半,剩下的十里仍需要花很大的功夫。那么现实的生活和工作中,我们是不是也经常遇到这样的情况呢?回想一下,会不会有这样一种经历:打扫卫生,让房子从凌乱到整洁只需要20%的努力,要让房子从整洁到一尘不染却要花费80%的努力。那么我们就要审视一下,在精力有限的情况下,从整洁到一尘不染的过程有没有必要,房子从凌乱变到了整洁是不是就已经足够。我想没有洁癖的一般人,就如我,都会觉得后面那个过程的性价比实在 太低,完全没有必要。

  回过头来看看我们在项目中的估算是不是也可以类比,从无估算到有估算其实花的是比较有限的精力,但是从有估算到追求“准确”估算却是个漫长的过程,并且有数据显示我们花一些时间得到的估算数据跟花费大量时间而得到的结果不会差很多。《敏捷估计与规划》这本书中提到,估计的准确度和投入的工作量之间存在以下关系:

  因此,我推荐在进行估算的时候不必精确,更何况我们也无法做到精准,估算只是估算,只要做到尽量合理,尽量贴近真实值即可。

  有的团队往往会在估算开始时纠结于如何选择估算单位,因为合理的选择是影响估算成功的关键因素。那么究竟该如何选择呢?

  理想人日的劣势在于:小组对技术和项目的熟悉程度,个人的经验和能力不同,都会导致基于理想人日的估算值有一定差异。例如,你问一个擅长C语言的某个需用java开发的功能的理想人日,他也许会告诉你是5天。但是你问一个擅长java的同样的问题,他的回答也许就是1天。这样的差异会导致我们对任务规模认识的偏差,很难衡量项目的实际“大小”。而它的优势则在于:对于团队外部的人来想人日更容易被理解,无需解释。对于团队而言,它使估算更容易开始。

  理想人时是对应理想人日而存在的,只不过它的粒度更小。当熟悉需求的情况下,用理想人时的估算会更准确些。想象一下,让你估算接下来1个小时能完成多少工作任务和接下来一天能完成多少任务,哪个的会更接近真实情况些?我想应该是前者吧。因为一天内能做多少工作,我们需要去除很多“杂事”(如喝水,上厕所,跟同事唠嗑,戳网页···)来估算纯干活的时间,这一点往往较难一些,总会存在一些偏差。但是如果要估算接下来1个小时能做什么,应该就比较容易了。理想人时的估算优势就在于:在充分理解需求的情况下,能帮助团队做到更靠近真实值的估算。而缺点是:对于一些大的需求无法做到如此细粒度。

  故事点是来自于敏捷的概念,是对任务规模的估计,它是一种相对概念。例如:需求X为4个故事点,需求Y为8个故事点,则表示Y的规模是X的两倍,但并不表示开发Y比开发X要多一倍的时间,因为这还取决于是由什么样技术熟练度的人员开发。故事点的优势在于:一方面,基于故事点的估算更纯粹,不会因为开发人员的变更,时间的推移而改变。换句话说,项目半途有离职,加入新的,此时我们不需要对每个任务都重新估计,只需要重新评估一下是否有需要调整插入到当前迭代的故事点数。另一方面,由于人们往往更擅长于相对估算,所以故事点会让估算更迅速。想象一下,让你估算一杯水是另一杯水的几倍,是不是会比让你估算两杯水各是多少毫升来的更容易呢?劣势在于:一方面,而且由于编程语言不同或者业务分块,大家很难找到一个共同熟悉的需求作为基准,那么用故事点的作为估算单位的方式就很难开展了。另一方面,故事点相对于其他估算单位更难被理解,这也使估算难以开始。

  由每个开发人员估算自己的任务时间,然后将所有的任务汇总,并考虑过任务间的依赖关系后,就排出了计划。该方式适用于具有以下特点的团队:间业务性强,相互之间的业务熟悉度不高且熟悉成本较大,较难进行共同估算;各的经验相对丰富,对自己的任务能进行较好的评估。

  由一个或多个专家根据相应开发的情况给出任务的估算值,但前提是你能找到这样一个熟悉整个项目所有业务和整个项目团队的专家或专家组,在笔者所在的团队一般会有开发leader来充当这样的角色。

  是以扑克牌的形式进行团队估算。估算开始前,每个估计者会分到一叠扑克牌,每张上有一个数值,如0,1,2,3,5,8···然后由负责人对某个需要进行估算的需求或者任务进行,完之后,所有人可以向该负责人提问关于该条需求或任务的问题,直至足够了解以做出估算。所有各自挑选一张扑克牌代表自己对该条目的估算。例如A给出8,而B只给了2,这样就需要A和B各自给出理由说明自己估算的理由,这样一轮下来,大家对该条目又加深了了解,然后进行第二轮估算,如果相差还是很大,则继续下一轮。大多数情况下至多经过两轮,大家的估算值已经非常接近了,就可以取平均值作为对该条目最终的估算。

  估算单位和估算方法:由于很容易找到大家熟悉的一个用户故事作为基准,目前团队正应用基于故事点的扑克估算。团队在经过几次迭代之后,基本上确定团队的开发速率(每个迭代能完成的故事点数)。在接下来的迭代中,团队通过扑克估算确定每个用户故事的故事点,再根据用户故事的优先级一个个插入迭代开发计划中,直到不能再承诺完成为止。

  估算单位和估算方法:一方面,由于之间的业务熟悉度不高且开发语言不统一,团队无法轻易找到一个合适的基准用户故事,所以团队的估算都是基于理想人天开展的。另一方面,由于开发人员数量较多且一部分经验比较欠缺,无法很好的进行团队估算,所以团队目前采用专家判断(开发leader给出估算)为主的方式进行计划。

  估算单位和估算方法:由于间业务熟悉度不高且开发语言不统一,团队无法找到合适的基准故事点,所以团队选择采用理想人日作为估算单位。另一方面,也由于模块较多,开发leader不能熟知各业务逻辑,所以团队采用了自底向上的估算方式。由各自估算各自的任务,进而给出开发计划。

  估算单位和估算时间:由于迭代时间较短,团队又在自己的领域比较精通,故能做到基于理想人时的自底向上的估算,估算的偏差一般较小。

  通过以上几个例子,笔者想说明的是:各种估算单位和估算时间本身并没有好坏之分,只有合适不合适只说。每个团队都需要根据和项目的现状来进行选择。如果生搬硬套只会弄巧成拙,得不偿失。

  我们要知道,估算仅仅是一个预测,当对外承诺项目完成时间的时候,最好提供一个日期范围,让听者知道你的估算只是估算;

  团队需要估算并且收集反馈,没有反馈的估算最终将被证明是毫无价值的。每一次估算对应的开发结束后,大家需要回过头看看我们当初做的估算是否合理;

  估算也许需要反复进行,当项目进行到一半时,发现估算过于乐观了,那么就需要对剩下的工作进行重新的估算。

  作者:何燕华,网易资深项目经理,PMP,CSM。先后在网易私有云、网易用户中心、网易GACHA、网易LOFTER等项目担任项目管理工作,积累了丰富的项目管理实践经验,并始终致力于项目的成功交付和团队的健康发展。《网易一千零一夜》主要作者之一。

相关推荐