Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1725927
  • 博文数量: 98
  • 博客积分: 667
  • 博客等级: 上士
  • 技术积分: 1631
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-27 15:59
个人简介

一沙一世界 一树一菩提

文章分类

全部博文(98)

文章存档

2021年(8)

2020年(16)

2019年(8)

2017年(1)

2016年(11)

2015年(17)

2014年(9)

2013年(4)

2012年(19)

2011年(1)

2009年(4)

分类: IT业界

2019-12-18 14:20:04

下面内容是阅读《程序员的职业素养》记录的笔记。
       大家在产品或者模块开发过程中,或者面对某一异常提出解决方案时,有没有遇到预估的完成时间和实际完成时间偏差特别大的情况?

       预估开发周期应该是软件开发人员面对的最简单、也是最可怕的和无奈的活动之一吧。预估影响到的商业价值巨大,关乎声誉,也给我们带来了很多苦恼和挫折。预估是业务人员和开发人员之间最主要的障碍,双方之间的各种不信任,几乎都由预估引发。关于预估,最主要的问题是不同的人对预估有不同的看法。业务方觉得预估就是承诺,开发方认为预估就是猜测。两者相差巨大。承诺是必须做到的,是需要必须兑现的。兑现不了也是欺骗,只不过比公然的欺骗好一点。而开发人员口中的预估是一种猜测。不包括任何承诺的色彩。不需要任何约定,预估错误也无关声誉。我们之所以预估,是因为不知道到底要花多少时间。那为什么大多数预估都和实际偏差那么远呢?这其实并不是因为开发人员没有掌握预估的诀窍,而是根本就没有诀窍,预估偏差总是很大,原因在于我们并不理解预估的实质。预估不是一个定数,预估的结果是一种概率密度分布。

       不管它概率不概率乐,我们直接说这样的预估方法吧,我感觉挺实用。学名:德尔菲法。
办法很简单,一组人集合起来,讨论某项任务,预估完成时间,然后重复“讨论-预估”的过程,直到意见统一。德尔菲法台高大上乐,我们采用低成本方式:亮手指。
       大家围在办公室或者会议室,每次讨论一项任务。针对每项任务,都必须讨论这个任务涉及什么,有哪些开发任务量,什么因素会把它搞复杂,应该如何实现。然后所有参与者把手收起来,根据自己判断,伸出0-5个手指里表示自己认为的完成时间。注意要大家同时伸出,伸出手指之前彼此都不知道对方的手指情况。如果大家伸出的手指基本相同,就开始讨论下一个任务。否则就开始讨论为什么有分歧。如此重复,直到意见统一。预估的计量单位在会议开始时必须确定。可能是完成任务所需要的天数与手指数一一对应,或者完成所需天数与手指数乘3对应,也可以与手指数平方对应。重要的是,大家必须同时亮出手来,最不希望的就是有人根据他人的预估改变自己的主意。
       预估是非常容易出错的,所以才叫预估。如何减小预估与实际的偏差呢?那就是先把大任务分解成许多小任务,然后分别预估小任务再加总,这样的结果比单独大任务要准确很多。这样做之所以能提高准确度,是因为小任务更明确,估错误偏差会很小。而且拆分成多个小任务也更有利于理解任务本身及其它意外因素。










阅读(1117) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~