钢结构防火涂料厂家
免费服务热线

Free service

hotline

010-00000000
钢结构防火涂料厂家
热门搜索:
行业资讯
当前位置:首页 > 行业资讯

为何开发人员不能估算时间

发布时间:2020-03-23 14:33:41 阅读: 来源:钢结构防火涂料厂家

感谢伯乐在线的投递Ashley Moran 是一名软件开发人员,最近在其关注的邮件列表中看到了一些有趣的观点,所以他做出了相应回应。(以下是全文)一些有趣的观点出现在我所关注的邮件列表中。下面是其中的一些。原始评论将以蓝色字体显示,下面是我的回应。这不是对相干问题的完全看法,只是我所想到的一些相干的回应。注:我已加以编辑,以改良流程(flow),并加以论述。

在软件开发中,我们不能对任何单独的任务作出时间的估算,是由于工作性质是创造新知识。  软件开发的目标是实现流程(Process)自动化。只要一个流程实现了自动化,便可以针对大多数情况在可预期的时间内反复运行。源代码就好像生产蓝图,而电脑就好像生产工厂,输入(数据)好像原材料,输入(数据)就像制成品。而使用另一种类比,星巴克可以重复迅速地制作咖啡的缘由就在于他们花费很多时间在流程的设计上,使得该流程成为了一个复杂且昂贵的作业。星巴克的个人经营者没必要再去重新研究该流程,只需买下此蓝图便可。我会让各位读者练习推断我对COSTA咖啡制作进程的意见。  事实上,不可预期的开发时间其实不总是坏事,由于它所带来的价值也是如此。一款成功的软件可以制造或节省的价值远超过其本钱。TomDeMarco之所以赞同关注高成本项目,正是基于这个缘由。能注意到这点,需要一种价值增长的理念,而不是广泛而又普遍的本钱控制理念。这是很重要的问题。  目前为止,Don Reinertsen的《Principles of Product Development Flow /产品开发流程原理》,是我所看过的对可变性与为价值而开发的最好解释,该原理在平常流程管理中大量使用PatchSpaceBible。我所说的“目前为止最好的”是指超出我所看过的其他解释一个档次,不包括束缚理论(Theory of Constraints)的著作。  这就是我的最近开发项目的数据。直方图中的R表示5个小时的量:横轴表示的是User Case的持续时间——0-5小时,5-10小时,等等;纵轴表示的是占此时续时间的UserCase数量。我以90分钟为间隔,工作并将其记录在Wave上,这样我们就能清楚地知道任务持续时间。  我们这么做既为了与客户沟通,又为了账单。结果是:我们的开发时间的可预知程度跟放射性衰变一样,但却是始终如一的辐射。可估计的相干数据少得可怜,我谢绝估计个别任务的的时间,由于这会产生误导,但是我们有足够数据进行合计。  经验法则:接受开发人员的估算意见,但是要在两倍的基础上再加一点时间  两倍加一点法则很有趣。经理开始应用此法则时,多长时间他会提早完成一次?我们通常太过重视超支。如果一个团队未能提早完成任务的一半。他就要增加估计时间,这意味着拿开发周期与项目进度做交易。周期常常比可预测性更重要,由于它意味着更早地进入市场。一样看看Reinertsen的作品,数字会以与数量级不同的规律出现。  并且,这是关键链(CriticalChain)项目管理的基础,这会将项目估计时间2等分,把剩余时间(添补单独项目)放在最后,作为“项目缓冲时间”。这就意味着帕金森定律不会致使单独任务无规律地扩大。虽然我不觉得关键链是软件行业的一个适合的方法,但作为开发工作的内容,它可作为反馈与学习提高的工具,可明显改良计划。  通常人们只是估计时间  不但开发人员估计不好。每个人都会遇到临场发挥(即兴应付)的问题,由于那是他们没从未做过的事,所以在完成之前,他们没法准确地作出判断。  作为一个群体,我们应避免这一点。不知道就是不知道,一定要说出来。相比于没法估计,那些能够定期了解任务进度,从而意想到风险(并选择继续投资)的客户,会给予团队更多的信任。这是事实!我是认真的,不用只相信我的话,看看David Anderson的《Kanban》1书吧。  估算是一个很重要的技能,应当在低级开发人员中广泛教学  我提出了一个替换方案:我们需要教给低级开发人员的是完成的意义。如果估计问题已够糟了,在一些不确定的点找出未完成的某些东西(也许是匆忙地兑现许诺…我的意思是估计判断!)不但会打乱时间的估计,还会打乱所进行的工作的日程。这是常有的事,并且会给一个开发团队的地位造成重大损失。  译文出处:伯乐在线 - 职场博客 - 程序员  译文链接:  原文:Ashley Moran  文章推荐:关关  翻译:伯乐在线 敏捷翻译 - 高志翔

上海德沁机械有限公司

上海德沁机械有限公司

上海德沁机械有限公司