zoukankan      html  css  js  c++  java
  • 实践敏捷估算(1)——不仅仅是估不准的问题

    摘要:

    说起估算问题,我们第一反应往往是“估不准”!估得准又如何呢?如果估算结果是需要5个月才能完成,但合同要求3个月交货,你怎样办?所以其实我们还有一个“估得多”的问题,而在“估不准”和“估得多”这两个问题之前,还有“不敢估”的问题。

    估算问题很复杂,我们首先要做的是拆解这个问题,这样才能更好地找到合适的解决方法。

    我们从不同角色的视角来看看估算的问题:

    老板如何看估算?

    老板是很了解自己的手下的:如果让项目组自己去估算,那么估算值一定是大于工期限制,而且实际的工作量又会远大于估算值。

    但老板是要赚钱的,项目的合同金额是固定的,交付期是“死”的,所以项目组不要跟我扯项目有多困难,不要说需要更长时间,反正必须在交付期之前将项目做出来,而且项目能验收!这样才能符合我的利益。

    所以老板不太可能让项目组自己估算工期,然后让项目组按照这个工期来安排工作。

    项目经理如何看估算?

    项目经理(后面简称PM)是责任大,权力小的职位,项目的“几座大山”都压在了PM身上。

    这“几座大山”是什么呢?

    1)进度的压力

    2)老板的压力

    3)客户的压力

    4)软件质量的压力

    5)恨铁不成钢的项目组成员

    6)……

    本来估算应该是舒缓这些压力的好办法,如果能根据估算来安排进度和调整项目组的人力安排,估算就是美好的。

    但问题是估算出来需要5个月完成,但工期只有3个月,老板和客户都不会因为这个估算而放松对进度的要求和限制,也不会降低软件的质量要求,老板也不会安排更多的人手到你的项目组(项目期间老板如果不将人员抽走的话,你已经要阿弥陀佛了)。

    所以估算对于PM来说一点价值都木有,横竖都是死,不如节省这些无用的估算时间,让我死得舒服一点吧。

    项目成员如何看估算?

    我是来打工的不是来卖命的,完成本职工作对得起这份工资就行。项目成败跟我没啥特别关系,PM把任务安排下来,我完成任务就可以了。至于加班嘛,这是IT界的“潜规则”,我就加一点吧,但没日没夜的加班老子是受不了的!

    你说“估算”?让我估计自己任务需要多长时间完成?说了这个时间有用吗?我说10天你还不是直接砍成3天,不要做这种“虚伪”的事情了,直接告诉我什么时候要完成就行了。

    客户如何看估算?

    不要老说我们提不出需求,你不做出来我怎样知道我要什么呢?软件开发我不懂,不要每次催促你们交货就跟我提一些我听不懂的理由,我们懂技术的话就没有你们公司的事了!我们判断事情的标准其实很简单,签署合同时我们已经写得很清楚了,就是:给你们这么多钱,这样的工期,到时必须交出像样的东西出来!

    估算?你说什么估算?你们签合同的时候不是应该想好了吗?现在才跟我说超出工期,那合同要来干嘛呢?

    看上去无论是从哪个角度来看,估算”都是“十死无生”的事情,而且估算似乎没有办法兼顾各方面的利益。那么是不是不谈估算,直接绕开估算这个事情,就“万事大吉”呢?

    理想的估算境界

    理想情况是这样的:项目组的估算符合合同的要求,能在工期内交付,能保证质量要求,而且项目的实际情况与估算情况基本吻合,并且项目组不需要太多加班,甚至是不需要加班。这样就能满足和平衡老板、PM、项目组成员以及客户的利益了。

    避开估算其实象鸵鸟遇到事情将头埋在沙中,避得一时避不了一世。我们需要直接面对估算带给我们的挑战,只要能克服以下的三个问题,就可以实现上述的“理想境界 ”。这三个问题是:1)不敢估;2)估不准;3)估得多。

    问题1:不敢估

    不敢估算或者不愿意估算,主要有三个原因:

    1)项目工期是限死,项目人力资源基本也是死的,让估算者觉得估算没有价值;

    2)项目的需求不确定,采用什么技术也不太确定,让估算者觉得无法进行估算;

    2)估算其实相当于是对自己工作的承诺,估算者不想自己对自己设套。

    问题2:估不准

    不敢估算这个问题克服后,估不准的问题就会呈现出来,估算误差超过100%甚至是200%以上都是很常见的事情。不必太过紧张,如果能克服“不敢估”这一关,“估不准”这个问题是可以解决的。

    “估不准”的原因通常有:

    1)对项目的需求和技术估计不准,特别是项目需求不确定的时候;

    2)对项目组自身的估计不准,包括对自身的技术能力、团队协作能力、研发流程能力的估计等。

    问题3:估得多

    估算出来了,而且实际情况也估算情况相差无几,也不一定能满足要求,因为这个估算往往是大于工期的限制的。这第三个问题,才是我们终极需要解决的问题!

    估算方法最多只能帮助我们估得比较准,但并不能帮助我们估算得少,真正能让估算数字下降的决定性因素是什么呢?这个决定性东西其实就是你们的研发能力!

    如何解决这些问题?

    谈起估算问题,我们表面上谈的是“估得准”的问题,而实际上我们希望的是“估得准并且估得少”,要终极达到这个目标,必须按顺序逐步来解决前文提到的三个问题。

    公司的领导们不要太过心急,这三个问题没有几年时间是不能彻底解决的,给你一个时间表参考参考:

    1)彻底解决问题1大概需要3个月时间;

    2)在解决问题1基础上,彻底解决问题2大概还需要6个月-1年时间;

    3)在彻底解决问题1、2的基础上,彻底解决问题3大概还需要2年以上时间。

    这是一个系列文章,将会围绕这三个问题给出一些最佳实践供你参考,你也不用太担心需要这么长时间 才有效果,后续文章会为你分享马上可以实践的做法,改进是持续进行的。

    以下是本系列文章的大致规划:

    1.不仅仅是估不准的问题  <---------这是本篇文章

    2.估算可以很难也可以很容易

    3.估算和预算 

    4.估什么?谁来估?

    5.怎样估算?

    6.项目初期的估算

    7.项目中后期的估算

    8.怎样才能让估算数值更少?

    请关注后续文章,谢谢!

    作者:张传波

    创新工场创业课堂(敏捷课程)讲师

    软件研发管理资深顾问

    CMMI首席专家

    《火球——UML大战需求分析》作者

    软件知识原创基地创办人

  • 相关阅读:
    Kafka 核心 API ==> AdminClient
    Kafka ==> 简介
    设计模式之 ==> 代理设计模式
    设计模式之 ==> 工厂设计模式
    设计模式之 ==> 模板设计模式
    设计模式之 ==> 单例模式
    Linux目录【持续更新中】
    Python 目录【持续更新中】
    kafka-eagle部署
    ES集群部署
  • 原文地址:https://www.cnblogs.com/umlonline/p/3768403.html
Copyright © 2011-2022 走看看