实践敏捷估算(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.估算能够非常难也能够非常easy

3.估算和预算

4.估什么?谁来估?

5.怎样估算?

6.项目初期的估算

7.项目中后期的估算

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

请关注兴许文章,谢谢!

作者:张传波

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

软件研发管理资深顾问

CMMI首席专家

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

www.umlonline.org创办人

时间: 2024-08-02 19:07:27

实践敏捷估算(1)——不不过估不准的问题的相关文章

实践敏捷估算(1)——不仅仅是估不准的问题

摘要: 说起估算问题,我们第一反应往往是"估不准"!估得准又如何呢?如果估算结果是需要5个月才能完成,但合同要求3个月交货,你怎样办?所以其实我们还有一个"估得多"的问题,而在"估不准"和"估得多"这两个问题之前,还有"不敢估"的问题. 估算问题很复杂,我们首先要做的是拆解这个问题,这样才能更好地找到合适的解决方法. 我们从不同角色的视角来看看估算的问题: 老板如何看估算? 老板是很了解自己的手下的:如果让

阿里内贸团队敏捷实践-敏捷回顾

回顾(review)是敏捷开发中的一个必不可少的实践,也是把整个敏捷开发过程连接成一个闭环的关键节点,本文将阐述我们是如何做敏捷回顾的. 敏捷回顾最高指导原则 ?无论我们发现了什么,考虑到当时的已知情况.个人的技术水平和能力.可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴. 敏捷回顾的目标 ?发现问题,持续改进. 敏捷回顾常碰到的问题?唉,又要开总结会了…?每次时间都那么长?问题讨论来讨论去就那几个,没啥新意?都不记得这段时间做过啥了?新迭代KO,总结放在一天时间太紧

敏捷估算扑克

原文地址:http://www.uml.org.cn/SoftWareProcess/201108264.asp 敏捷扑克是什么? 其实应该叫“估算扑克”更准确一些,本质上是扑克牌,基于Delphi估算原理,可以快速估算出需要的数字. 关于扑克牌上的数字 估算扑克牌上的数字,有的牌是自然数排列,有些是斐波纳契数,有些则是不连续自然数.具体选用哪种扑克,要根据被估算的内容的跨度大小而定,如果估算值跨度在10倍以内,那么采用顺序自然数比较好,如果数值跨度较大,达到10倍以上,那么采用斐波纳契数比较好

敏捷估算与规划—规划失败的原因

基于活动的规划分散了我们对功能的注意力,而功能才是衡量客户价值的单元.采用基于活动的计划所得到的进度表时,许多问题都可能导致延迟交付.项目的参与者本来是满怀好意的把多任务处理当做一个可以解决延误的办法,但由于多任务处理背后隐藏的代价,实际上会导致更长的延误.当进度表上剩余时间不够时,不可避免地要放弃一些功能.由于是按照开发人员认为的最有效的顺序来对功能进行开发,因此被放弃的功能对用户来说不一定是价值最低的. 忽视关于用户最终需求的不确定性,会导致虽然按时完成了项目,却没有包含在制定计划以后发现的

[转载]基于TFS实践敏捷-实现用户场景

您是新用户的 Visual Studio 应用程序生命周期管理 (ALM) 和 Team Foundation Server (TFS) 吗? 您想知道如何您和您的团队可以获得最大受益的这些工具来生成您的应用程序的最新版本? 然后花几分钟就可以走逐步完成该两个章节教程,并按照 Peter 和朱丽亚在 Fabrikam 纤程的两个开发人员的生活的一天 — — 虚构的公司,提供有线电视和相关的服务. 您将看到如何使用 Visual Studio 和 TFS 签出并更新代码. 暂停工作时被打断. 请求

6.1-6.30推荐文章汇总

6.1-6.30推荐文章汇总 [移动开发] Cocos2d-x Auto-batching 浅浅的"深入分析" 笨木头 OpenCV4Android释疑: 透析Android以JNI调OpenCV的三种方式(让OpenCVManager永不困扰)yanzi1225627 Unity3D游戏开发之回合制游戏原型的实现qinyuanpei iOS安全攻防(二十三):Objective-C代码混淆念茜 Android ActionBar完全解析,使用官方推荐的最佳导航栏(上)guolin i

以为4天能搞定的项目,结果搞了近一个月……

有朋友提到这个问题: 我最近做一些小项目,兼职的,几个人讨论着4天能完成的项目,结果整个周期花了将近一个月. 预计是4天,结果几个人时间不合拍,花了一个月. 还有时间也不统一,沟通不方便 , 光沟通都花了不少时间.一般是客户把需求传达给我,我再传达给开发人员,这样从中就浪费了很多时间.并且客户需求不是很明确,我的理解和其他伙伴的理解也不一样.因为合作的少,没有那么多默契,技术上面也有时候对接不上. 俺的见解: 开发去估算时,往往假定需求就是这样的了不怎么会变,然后估算开发工作量时,往往认为一次可

敏捷的最佳实践-2

第二部分:方法与实践 敏捷测试的实质 测试不仅仅是测试软件本身,还包括软件测试的过程和模式.产品发布后才发现很多问题,很可能是软件开发过程出了问题.因此测试除了需要确保软件的质量,即软件做了正确的事情,以及软件做了应该做的事情以外,敏捷的测试团队还要保证整个软件开发过程是正确的. 敏 捷测试即是不断修正质量指标,正确建立测试策略,确认客户的有效需求得以圆满实现和确保整个生产的过程安全的.及时的发布最终产品.敏捷测试人员因而需要 在活动中关注产品需求,产品设计,解读源代码:在独立完成各项测试计划.

《敏捷测试的最佳实践》学习笔记

第一部分:敏捷的实质 敏捷开发有益于个人发展 就测试而言,测试人员就是好比一辆跑车里的唯一的驾驶员,项目就好比这辆跑车,测试人员需要及时修正行驶方向的偏差,确保这辆车在正确的道路上稳步前行.如果,测试人员没有具备足够的责任心和领导力,只是人云亦云,恐怕这种测试要与不要没什么分别,敏捷项目的质量也更让人担忧,而敏捷也就失去了原有的意义.因此,作为唯一的测试人员,他(她)将拥有对测试的所有权,计划.设计并且执行所有的测试工作.而也因为拥有了更多的主人翁精神,积极的工作热情,测试人员勇敢的面对工作中的