敏捷估算 实践

一文搞懂敏捷估算及实践案例分享【壕叔盘敏捷】 在业务研发中估算一直是相对比较难以把握的事情,本文结合个人和团队的经验来谈谈对估算的认知和实践。先介绍一下个人的背景,以方便大家更好理解我们的出发点。个人是研发出身,做过多年交付型项目经理,近些年在移动互联网行业的多家公司担任过产研团队PMO职位,其中不乏独角兽级创业公司。我们的。... 阅读详情


说起估算问题,我们第一反应往往是“估不准”!估得准又如何呢?如果估算结果是需要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年以上时间。



敏捷开发中的故事点估算:从理论到实践 本文深入解析了敏捷开发中故事点估算的核心理论与实践方法。故事点作为衡量工作量的“通用货币”,其本质是相对估算,而非精确工时。文章详细介绍了斐波那契数列的理论依据、规划扑克等高效估算会议实践,并阐述了如何利用团队速度进行可靠的项目预测与软件项目管理。 阅读详情

相关推荐

13、敏捷项目的估算与规划:从理论到实践

本文探讨了敏捷项目管理在估算与规划方面的核心理念与实践,深入分析了瀑布模型与敏捷方法的差异,以及敏捷在应对项目不确定性方面的优势。从Scrum与Kanban方法的特点,到团队角色、多层次规划结构(长期、中期与短期规划),再到敏捷规划的挑战与未来趋势,文章为项目管理者提供了从理论到实践的全面指导。通过敏捷的增量式、迭代式方法,团队能够更有效地应对变化,提升项目交付的可预测性与成功率。

xray4的博客 85

敏捷开发中RAG技术优化故事点估算实践

在敏捷开发实践中,故事点估算是确保迭代计划有效性的关键技术环节。传统估算方法如计划扑克存在效率低下和认知偏差等问题。检索增强生成(RAG)技术通过结合历史数据检索与LLM推理能力,为估算自动化提供了新思路。该技术首先对任务描述进行语义编码,再通过相似度检索历史参考任务,最终由大语言模型生成估算建议。实际应用表明,这种AI辅助方案能显著缩短估算时间,同时保持合理准确度。特别是在技术术语理解方面,经过领域适配的SBERT模型展现出优势。该方案适用于Jira等项目管理工具集成的开发环境,为敏捷团队提供了一种平衡效

weixin_30099989的博客 338

吉林大学2016级唐班c语言期末考试B卷

` #include<stdio.h> #include<stdlib.h> //双指针法,每次从a,b中选一个最大的数,从后向前一次放在数组a中 int merge(int *a,int m,int *b,int n){ int i=m-1,j=n-1,k=m+n-1; while(i>=0&&j>=0){ if(a[i]>b[j])a[...

weixin_42339173的博客 1195

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

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

weixin_34122810的博客 249

Ubuntu下OpenOCD+GDB的安装、编译及使用

目标开发板(芯片):stm32mp157aaa 仿真器:ST-Link 操作系统:Ubuntu 18.04 调试软件:OpenOCD OpenOCD的安装 首先下载OpenOCD有多种方式,可以GitHub上下载,目录下打开终端,输入 git clone git://git.code.sf.net/p/openocd/code openocd 下载完整的OpenOCD的文件夹。进入到OpenOCD的目录下,开始安装。 接着,OpenOCD适用于微处理器的debug和烧写,需要下载相关库 sud

蓝冰露的博客 9524

实战避坑:在STM32上移植AUTOSAR BSW时,MCAL、ECU抽象层和服务层配置有哪些常见‘雷区’?

本文深入解析在STM32上移植AUTOSAR BSW时MCAL、ECU抽象层和服务层配置的常见陷阱,包括时钟树配置差异、GPIO电气特性问题、定时器资源冲突等实战经验。特别针对AUTOSAR架构在资源受限MCU上的特殊挑战,提供具体解决方案和优化策略,帮助开发者规避移植过程中的典型错误。

weixin_30258901的博客 561

软件开发计划_敏捷软件开发实践:估算与计划读书笔记109第7章 重估

《敏捷软件开发实践:估算与计划》第 7 章 重估,重点和要点的思维导图及文字内容。第 7 章 重估There's no sense in being Precise when you don't even know what you're talking about.故事点或理想人天是对要实现的功能的总体规模和复杂度的估算。故事点并不是对实现一个功能所需时间的估算。实现一个功能所需的时间...

weixin_39870664的博客 152

UNSW-NB15数据集:网络流量分析与恶意攻击检测实战指南

本文提供了UNSW-NB15数据集在网络流量分析与恶意攻击检测领域的实战指南。详细介绍了该数据集的构成、核心特征解析、特征工程处理、机器学习模型训练与评估方法,并探讨了模型部署及持续优化的挑战与思路,帮助读者构建高效的网络攻击检测系统。

weixin_29193359的博客 258

敏捷软件开发实践——估算与计划02

目录 一、使用故事点估算大小 1、故事点是相对的 2、速度 3、小结 二、使用理想人天进行估算 1、理想时间和软件开发 2、以理想人天作为对大小的度量 3、给出一个而不是多个估算值 4、小结 三、估算方法 1、共同估算 2、估算的尺度 3、得到估算值的方法 3.1、专家意见 3.2、类比 3.3、分解 4、计划扑克 5、为什么计划扑克会有效 6、小结 四、重...

HTZW的博客 1202

LVGL 源码分析大全

LVGL 是一款流行的免费和开源嵌入式图形库,为纯C的轻量级GUI框架,支持framebuffer直接渲染图层,因此LVGL能更容易为 MCU、MPU等显示设备开发漂亮的UI。可视化的 UI 编辑器官方上有推荐使用工具。当然,也可以选择 NXP(恩智浦半导体) 提供的工具。........................

Bigan(安)的博客 1万+

第三章-python基础语法

有C语言基础应该这样学 Python。

qq_46187594的博客 1175

Scrum敏捷估算

敏捷估算时,我们不会估算绝对时间和周期,我们估算大小,和相对值,也就是倍数。敏捷估算时,我们使用故事点作为计量单位,它是一个倍数,我们会先找一个我们认为最小的一个功能的大小作为参考基准,定义为1个故事点,把其它的故事和它做比较,如果是2倍大小,就是2个故事点,如果是5倍大小,就是5个故事点。Scrum采用迭代增量的方式,是因为需求是涌现的,我们对产品和需求的理解是渐进式的,Sprint长度越长,我们需要预测的越多,复杂度会提升、风险也会增加,所以Sprint的长度最多不超过4周。

我是菜鸟 853

预编码算法(个人总结)

预编码算法是无线通信系统中的关键技术,通过在发送端对信号进行处理,可以有效减少干扰,提高系统性能。预编码算法在5G、Wi-Fi、卫星通信等领域具有广泛的应用前景,同时,随着深度学习、大规模MIMO和物理层安全等技术的发展,预编码算法的研究将进一步推动无线通信技术的发展。CSI的准确性直接影响到预编码的效果。预编码是一种在发送端对信号进行线性变换的技术,以优化信号的空间分布,使得接收端能够更好地接收和解码信号。预编码算法,特别是基于矩阵分解的预编码算法,计算复杂度较高,限制了其在实际系统中的应用。

年糕的博客 5288

软件估算中的敏捷估算方法实践指南

本文将介绍敏捷估算的核心实践,帮助团队提升估算的准确性和灵活性。团队的速度是指每个冲刺完成的故事点总数,它是预测未来工作的重要依据。例如,如果团队的平均速度为30故事点/冲刺,那么一个包含90故事点的项目大约需要3个冲刺完成。故事点是敏捷估算中常用的单位,用于衡量用户故事的相对复杂度。计划扑克是一种高效的估算工具,团队成员通过出牌表达自己的估算意见,经过多轮讨论达成共识。团队应在每个冲刺回顾会上分析估算偏差的原因,并调整未来的估算策略。无论是故事点的应用,还是速度预测的实践,都能显著提升估算的可靠性。

wrlpeq_055的博客 227

机器人动力学仿真软件:Webots_(14).机器人声音仿真

Webots 中的声音仿真主要通过Sound和两种节点来实现。Sound节点用于播放预定义的音频文件,而节点则允许在仿真过程中动态生成和播放声音。这些节点可以用于模拟机器人的语音输出、报警声、环境噪音等。以下是一个示例,展示如何在控制器代码中播放预定义的声音。// 控制器代码(.c) # include <webots/robot.h> # include <webots/sound.h> # define TIME_STEP 64 const char * sound_name = "sound";

kkchenjj的博客 1311

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

难以实践敏捷:估算

谈到敏捷,人们往往都非常高调地打探TDD与持续集成。同时很多实践,非常低调。比如,估算。学习TDD,你有很多具体例子可以学习。但是学习估算,却无从下手。在“搞砸”了几个项目之后,貌似我摸着了一些门道了。 估算的目的 在我看来,估算有两个截然不同的目的。第一个是报价,第二个是规划。为了报价,我们追求的是所有故事卡的总体的绝对大小。为了指导发布规划和在迭代开发中做调整,我们追求的是故事卡之间的相对...

weixin_34234721的博客 194

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

敏捷开发中的工时估算:从理论到实践

本文深入探讨了敏捷开发中工时估算的核心挑战与实践方法。文章指出,敏捷估算的本质是建立团队共识、评估相对复杂度的协作工具,而非精确承诺。重点介绍了故事点、计划扑克、T恤尺码等核心方法,并分享了将估算融入迭代规划、建立团队速率及持续复盘的实战流程,旨在帮助团队将估算从“痛苦猜谜”转变为驱动项目成功的有效指南。

lake5的博客 455

VC中sqlite的使用

在VC中对sqlite的使用,实现数据库大批数据的快速插入,读取数据库中的数据在ListCtrl中显示

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

敏捷软件开发实践——估算与计划(01)

一、计划的目的 1、为什么要进行估算和计划 减少风险——计划通过提供对项目风险的认识而提高了项目成功的可能性 降低不确定性 提供更好的决策支持 建立信任——频繁地、可靠地支付承诺的功能可以在产品开发人员和产品的客户之间建立信任;可靠的估算使得可靠地交付成为可能;客户需要估算来做出关键的优先级和折中决策 传递信息——计划可以传递针对项目的期待,并且描述完成项目的可能路径之一 2、优秀的计...

HTZW的博客 1056

敏捷开发“松结对编程”实践--共同估算篇

估算是经久不衰的管理话题,大致分为两种流派。   第一种是领导指派,领导说这是10天的活,就必须当是10天的活来干,如果干不完,可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算,但是交给领导审批;领导审批其实就是砍一半的过程,还好大家之前就已经加了一倍,所以不怕。   第二种是自我管理派(偏敏捷),就是由具体开发的人员自己说开发工作量,领导和他人不干预。尽管...

优快云1332531529的博客 137

RAG技术优化敏捷开发故事点估算的实践指南

检索增强生成(RAG)技术结合信息检索与生成模型的优势,为软件开发中的故事点估算提供了创新解决方案。其核心原理是通过嵌入模型将任务描述向量化,检索相似历史案例,并生成估算值。这种技术不仅能提高估算效率,还能增强结果的可解释性。在敏捷开发场景中,RAG特别适用于解决传统估算方法依赖个人经验、存在锚定效应等问题。通过调整top_k检索范围和temperature生成多样性等关键参数,可以针对不同规模项目优化性能。实验数据显示,RAG在中型项目中表现最佳,平均绝对误差(MAE)比小型项目降低15%以上。BAAI和

weixin_33582311的博客 267

软件开发计划_敏捷软件开发实践:估算与计划读书笔记124第22章 敏捷计划有效的原因...

《敏捷软件开发实践:估算与计划》第22章 敏捷计划有效的原因,重点和要点的思维导图及文字内容。第22章 敏捷计划有效的原因If you want a guarantee buy a toaster.计划是尝试为产品开发综合问题——特性、资源和进度——寻找出最佳解决方案。其中任何一点发生变化都会牵一发而动全身。在做计划时,我们是在对所有潜在的解决方案范围进行探索,找出如何组合这 3 个参数...

weixin_39948210的博客 261

软件开发计划_敏捷软件开发实践:估算与计划读书笔记103第 1 章 计划的目的...

《敏捷软件开发实践:估算与计划》第 1 章 计划的目的,重点和要点的思维导图及文字内容。第 1 章 计划的目的1.0 前言Planning is everything. Plans are nothings.无论一个软件开发项目的规模与结果如何,估算(Estimating)和计划(Planning)对于项目的成功都是至关重要的。计划可以指导我们的投资决策;计划可以帮助我们了解在项目特定的...

weixin_39766014的博客 256

敏捷开发“松结对编程”实践之三:共同估算篇(大型研发团队,学习型团队,139团队,师徒制度,敏捷设计,估算扑克,扑克牌估算)...

本文是“松结对编程”系列的第三篇。(之一,之二,之三,之四,之五,之六,之七,之八)估算是经久不衰的管理话题,大致分为两种流派。第一种是领导指派,领导说这是10天的活,就必须当是10天的活来干,如果干不完,可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算,但是交给领导审批;领导审批其实就是砍一半的过程,还好大家之前就已经加了一倍,所以不怕。第二种是自我管理派(偏...

diaogan4202的博客 141
上一篇: XHR XMLHttpRequest
下一篇: IT职场求生准则
bamboolsu
博客等级 码龄22年 200粉丝 394原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值