敏捷开发绩效管理之五:敏捷开发生产率(上)(故事点估算)

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

这是敏捷开发绩效管理的第五篇。(之一,之二,之三,之四,之五,之六,之七)

 

度量敏捷开发的生产率一直是个难题,确切说度量任何开发方法的生产率都是一个难题,但它实际上有答案,这个答案是本文的主要内容。

 

度量敏捷生产率的目的


真正难以回答的是度量生产率的目的是什么?

很多人都认为是考核绩效,发奖金。根据上一篇文章的内容我们可以知道,这完全是行不通的:客户并不购买我们的生产率,生产率高也并不能证明产品或项目盈利,应该为团队设立外部目标,否则很可能得到一个生产率很高,但是实际上很烂产品——质量上或易用性上很差,抑或其他想象不到但一定遇到的原因。这是我们说为什么用外部目标而非内部目标考核团队的原因。

或许又有人说:“开发得快不快是团队的事情,产品好不好则是产品负责人的事情。”这样也不对,相当于我们在自组织之后,当我们享有勇气,尊重,沟通……这些敏捷的特质之后,我们居然得到了一个只关心自己的开发速度,而置客户价值和企业利益于不顾的团队。“受激励的个体”只被自己小团队的绩效所激励,并不爱也不关心自己的产品,这绝对不是敏捷开发的初衷。

度量生产率的目的不是绩效考核,而是是希望提升生产率绩效。将度量结果进行横向和纵向比较,可以分析造成生产率差异的原因,并进而提升生产率绩效。

 

微观度量方法-故事点


故事点估算方法

“每月完成的人天数”这个方法不说了,用尺子量尺子,肯定不行的。不过通过统计每月的实际投入天数,可以优化人员利用率,并间接提升生产率。 

“每月完成的故事点”这个是比较好的方法。

所谓故事点法,就是提前选择一些大家都熟知的、以往做过的、典型的故事,比如:

1. 对单个表进行增删改查

2. 对父子表的增删改查

3. 为一个已经存在的数据表增加一个复杂报表

4. 修改一个中等难度的BUG

……

(实际上这些故事应该是具体的,而不是像上面例子中一样看起来更像是“分类”)

然后人拿出当年的历史记录,将当时所投入的人天数称为“故事点数”(也有别的做法但这个最简单)。比如“对单个表进行增删改查”当年用了4天,那么标准故事点就是4。

当下次估算时,人们又发现有一个故事也是“对单个表的增删改查”,于是就先选定基数为4,再讨论这次与上次比,到底复杂多少。如果一致认为可能复杂20%,那么故事点就是5。

如果大家的生产率不变,那么这个故事应该5天完成,但是如果结果却是4天就完成了,则表明大家的生产率提高了。当然不是一个一个故事度量,而是把整个迭代内的故事点加起来度量。

通过纵向比较故事点,可以知道大家是否比以前的生产率提高了。

横向比较故事点比较有难度,因为每个团队乃至项目都会选定自己特有的标准故事,而且极难说明这个团队和那个团队的标准故事的转换关系。

故事点的局限性

在推广故事点这件事情上笔者有所保留,建议尝试但需注意风险,必要时知难而退。在笔者遇到的这么多做敏捷的企业和人里边,还没有见到有人提到他们的故事点应用是成功的。

原因在于找到大家都熟知的、以往做过的、典型的故事很难,而让所有人记住它们当年的详细情况以便日后对比修订就更难。

04年笔者去做咨询的一家企业有他们的故事点模板(他们并不做敏捷开发,但却使用完全类似的方法),一共有17种标准故事,已经记录了25个项目的故事点数据和实际工作量数据,每个项目从4个故事到上百的故事不等,他们希望笔者能帮他们计算一下“17个标准故事分别对应多少人天”。终于遇到了又有标准故事又有历史数据的情况,这比所有一穷二白想使用故事点的企业可乐观多了。

这是一个所谓“线性规划”的问题,涉及“最小二乘法”“超越方程”这些玄乎的名词,但却在Excel表里有这个功能,不过是10分钟的事情并不费力,真正费力的是解释其结果:求解的答案是——某些标准故事是负数,也就是说如果把这几种故事当作负数对待,那么以往发生的25个项目的预测结果与实际结果最符合。

再换一种直白的解释:用这17种故事预测工作量不准。

或许有人会说他们的17种故事选得不好,或他们的水平很差。怎么说呢,他们是一家1000多人的电信企业,专职做过程管理的人就有5人,还认真地记录了这么多数据,恐怕当年选定故事的过程也是经过思考的。倘若他们都难以建立其故事点,一般的10人团队想自己做一套恐怕更难。

回过头来观察他们公司的失败原因,是在为新的故事找到对应的标准故事后,没有根据其差异进行调整,而是机械地选择了标准故事的故事点,导致误差很大。在采用故事点的时候应该注意。但他们考虑到某些故事的回归结果居然是负数,即使“进行调整”结果也会是血淋淋的,甚至可以说基本扔到了标准故事从头估算,最终放弃了故事点,采用了另外一种方法,就是下篇文章提到的“功能点估算”。


笔者之前的一篇文章有故事点估算方法的更详尽的介绍,但角度不同:敏捷估算:故事点与直接估算天数的差异

故事点为我们提供了一种比较客观度量敏捷生产率的方法,但其局限性限制了其应用。下一篇文章将介绍另外一种广泛应使用的方法:功能点估算法。 

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册》





本人正在参加优快云博客之星评选,如果读完并喜欢这篇文章,欢迎投票:http://vote.blog.youkuaiyun.com/item/blogstar/cheny_com



敏捷开发绩效管理之七 敏捷开发生产率(下)(简化功能点分析,NESMA,两级简化) 阅读详情

相关推荐

Setup&Hold互卡问题和Useful Skew的影响

setup和hold互卡问题分析

godping的博客 5093

软件开发计划_敏捷软件开发实践:估算与计划读书笔记125第23章 案例分析:Bomb Shelter Studio...

《敏捷软件开发实践:估算与计划》第23章 案例分析:Bomb Shelter Studio,重点和要点的思维导图及文字内容。第23章 案例分析:Bomb Shelter Studio本章将通过一个虚构的公司 Bomb Shelter Studio 和它所承担的第一个敏捷开发项目来概括说明本书的许多关键知识点。Bomb Shelter Studio 是一家 3 年前才创业的小型、私有游戏开...

weixin_39713841的博客 317

树莓派3-改装wifi外置天线

声明:本文只是技术性探讨,改装引起的产品损坏等后果,由用户自负! 改装主要有两种方法 方法一:直接替换原来的天线 1、移除原有的小陶瓷天线,就在Made in PRC(或UK)那边的那个 清理一下阻焊剂方便天线接地(图中PRC左侧) 2、焊接天线 天线的屏蔽层焊接到清理完阻焊剂的地方,中间的信号线焊接到PRC右侧焊盘。 3、最终的样子

huayucong的博客 2万+

度量术语之二:应用类和开发类生产率(实际度量案例)

一个令人震惊的事实是连生产率这样的常见度量数据都没有一个简单的定义。连我们日常经经常使用到的公式:生产率=工作产品/工作量(工作产品能够是代码行,功能点,也能够是不论什么能够计数的东西。比方文档页数)都是错误的。假设你正常尝试使用生产率做度量,那么至少应该先分为以下两种度量数据。注意以下的样例为了便于理解使用的是代码行,但实际上这两个概念是IFPUG(国际功能点用户组)对功能点计数时做的分类。...

weixin_34240657的博客 163

Win上通过Jconsole查看Java程序资源占用情况(教程总结,一篇就够了)

JConsole 是一个内置 Java 性能分析器,Java 5开始 引入了 JConsole。可以从命令行或在 GUI shell 中运行。您可以轻松地使用 JConsole来监控 Java 应用程序性能和跟踪 Java 中的代码。Jconsole工具查看程序的资源占用请求。安装jdk时bin目录有jconsole.exe工具,或者通过 Win + R,输入jconsole.exe启动jconsole( 可以从命令行直接输入jconsole。

明生的博客 6240

【小贪】万字长文介绍因果推断和增益模型

本文首先从一个实例出发阐述了因果性不等于相关性,进而引出因果推断和增益模型。然后简单介绍了因果推断的基础内容,并介绍了主要的三类增益模型:元学习、增益直接建模、表示学习,每一类模型都简要介绍了其经典模型。之后介绍了增益模型的评价指标,包括uplift bins、uplift curve和qini曲线。增益模型实际上是一大类模型框架,本质上可以用传统响应模型或其他机器学习模型嵌入增益模型的框架,但是预测结果并不是一个概率,模型评价方式也有变化。训练样本收集增益模型建模强依赖于ab实验,数据要求很高。

打瞌睡_的博客 2506

敏捷开发用户故事系列之九 用户故事早期估算

敏捷开发用户故事系列之九 用户故事早期估算

hdfyhf的博客 351

从LLM到Agent:智能体核心范式与认知架构全景解读

摘要: Agent技术正成为AI领域的新焦点,其核心在于通过外部认知基础设施(如记忆、工具、协议等)将大语言模型(LLM)从“生成文本”升级为“执行任务”的智能体。2026年的研究显示,Agent能力提升的关键已从模型本身转向外部化架构,如Harness工程(执行框架)和认知解耦(如ORCA框架)。当前Agent框架生态呈现多元化竞争(如LangGraph、AutoGen、CrewAI),但可观测性与治理仍是薄弱环节。未来竞争壁垒将取决于外部基础设施的完善程度,而非单纯模型性能。

2601_95807009的博客 52

敏捷开发绩效管理之六:敏捷开发生产率(中)(功能点分析,FPA,简化的功能点)...

这是敏捷开发绩效管理的第六篇。(之一,之二,之三,之四,之五,之六,之七) 直接估天数或用故事点估天数,都很“程序员”。如果在项目的甚早期,面临与客户相关的报价问题,或高层领导要统计公司绩效并想进行项目乃至行业间的比较,这两种方法都很难使用。敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法,是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情,...

diaogan4202的博客 504

Allegro如何用自带的功能将线段变成铜皮操作指导

在做PCB设计的时候,有时根据设计需要将线段变成铜皮,可以借助辅助工具来实现这一操作,但是Allegro自身也自带这个功能,如下图。勾选Delete original objects。如何用自带的功能将线段变成铜皮操作指导。勾选Convert to shape,需要把这段走线变成铜皮。

weixin_54787054的博客 2946

【主题建模】一种基于深度学习的主题建模方法:BERTopic(理论篇)

在我的博客中已经写了很多关于主题建模的内容,当你准备了解 BERTopic 时,默认你已经知道了 LSA、pLSA、NFM、LDA 等传统的主题建模方法。关于主题建模的前置知识我在这里不做赘述,感兴趣的同学可以看看我前几篇博客。学习 BERTopic 需要一定的机器学习基础,让我们一起开始吧!

Data · Model · Agent · Repeat 9894

敏捷开发绩效管理之六:敏捷开发生产率(中)(功能点分析,FPA,简化的功能点)

这是敏捷开发绩效管理的第六篇。(之一,之二,之三,之四,之五,之六,之七) 直接估天数或用故事点估天数,都很“程序员”。如果在项目的甚早期,面临与客户相关的报价问题,或高层领导要统计公司绩效并想进行项目乃至行业间的比较,这两种方法都很难使用。敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法,是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情,比天数、故

陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》 1万+

【附代码】SSVEP解码算法 - 扩展典型相关分析(eCCA)

本文主要对SSVEP解码算法-eCCA进行复现和测试。本文提供程序的所有代码,只要在Matlab上即可运行。读者可以根据程序自主调整,方便学习以及初学者更好地了解SSVEP的经典算法。

计算机小白 1335

敏捷开发用户故事系列之九:用户故事早期估算

这是敏捷开发用户故事系列的第九篇。(栏目目录)本文适合听过MPD上《敏捷开发需求管理:用户故事分类、颗粒度及组织结构》,或参加过《火星人敏捷开发培训》听过第一天下午课程的读者。若您阅读过程中感觉缺少铺垫的信息,请先阅读:敏捷开发绩效管理之六:敏捷开发生产率(中)(功能点分析,FPA,简化的功能点)敏捷开发绩效管理之七:敏捷开发生产率(下)(简化功能点分析,NESMA,两级简化)若需要更详细情况,请

陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》 1万+

Probability and Statistics - 4th edition

Probability and Statistics - 4th edition

NTscan扫描工具

ntscan是一个扫描器,可以扫描没有密码和弱密码的共享,先到配置文件中填写猜测的用户名和密码,扫描过程中右侧出现的是扫描日志。

敏捷开发绩效管理之七:敏捷开发生产率(下)(简化功能点分析,NESMA,两级简化)...

这是敏捷开发绩效管理的第七篇。(之一,之二,之三,之四,之五,之六,之七) 续前文……功能点估算第一级简化上次说到只用数据+操作就能准确计算规模,听起来够简单了,但其实还不够。谁能在刚拿出2页纸的需求文档时(假设昨天老板在酒桌上刚从客户那记下来的),就猜出有多少个操作?而且还不遗漏?增删改查好猜,“加入角色”就不好猜了。NESMA早就遇到过这个问题了,他们这么解决:通过统计发现每个数据...

weixin_30736301的博客 219

ET2012新版免狗免安装绿色软件

ET2012新版免狗免安祖昂绿色软件。,新界面,新视觉,

敏捷开发绩效管理之七:敏捷开发生产率(下)(简化功能点分析,NESMA,两级简化)

这是敏捷开发绩效管理的第七篇。(之一,之二,之三,之四,之五,之六,之七) 续前文…… 功能点估算第一级简化上次说到只用数据+操作就能准确计算规模,听起来够简单了,但其实还不够。谁能在刚拿出2页纸的需求文档时(假设昨天老板在酒桌上刚从客户那记下来的),就猜出有多少个操作?而且还不遗漏?增删改查好猜,“加入角色”就不好猜了。NESMA早就遇到过这个问题了,他们这么解决:通过统计发现每个数据差不多有7

陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》 3万+

WINCC7.3破解文件

WINCC7.3硬件够破解文件,有需要的下载!WINCC7.3硬件够破解文件,有需要的下载!

敏捷开发一千零一问系列之十三:故事点好还是人天好?

这是敏捷开发一千零一问系列的第十三篇。(在这里提问,之一,之二,之三,问题总目录)问题这是课堂上提的一个问题,这是一家外企,PO在国外,研发在国内;PO希望大家用故事点估算,而团队习惯用人天估算,问用哪个好,或者两个都用好?分析先分析,后出方案。这个是一个典型的有关无我、无住的问题。所谓无我,就是先弄清楚为什么不同的人想要不同的东西,然后本着到底“谁应该要,应该优先满足谁”而非“我应该要,应该优先

陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》 9796
上一篇: 敏捷开发绩效管理之四:为团队设立外部绩效目标(目标管理,外向型绩效)
下一篇: 敏捷开发绩效管理之六:敏捷开发生产率(中)(功能点分析,FPA,简化的功能点)
火星人陈勇
博客等级 码龄18年 4899粉丝 381原创
评论 4
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值