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

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

相关推荐

Python 静态导入与动态导入

python中模块的静态导入 与 动态导入(运行时指定模块),以及具体对应示例。

慢也好,步子小也好,往前走就好~ 717

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

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

weixin_39713841的博客 317

skywalking各项指标说明

skywalking各项指标说明

没有简介 2487

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

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

weixin_34240657的博客 163

Open3D:读写点云与可视化(C++)

迭代 //Open3D #include "Open3D/Open3D.h" //Eigen #include "Eigen/Dense" void testOpen3D::xjGetInformation(const QString &pcPath) { /* read PC */ auto cloud_ptr = std::make_shared<open3d::geometry::PointCloud>(); if (!open3d::io::ReadPointCl

累了就要打游戏 1万+

因果推断(二):因果推断涉及的ITE、ATE、CATE等效应

因果效应也称为**处理效应(Treatment effect)**是用于评判干预与否的结果差异的指标(处理变量对结果变量的影响)。比如在接受治疗组中,如果这些人不接受治疗,这组人接受治疗和不接受治疗的效应差异是多少。定义为实验组中每个个体的处理效应差异,比如一个个体在接收治疗和不接受治疗的两个处理方式的健康程度得分的差。但是一个人因为不可能。比如我们想探究接受治疗的男性用户和不接受治疗的男性用户的平均效果差异就是CATE。前面说ITE是无法观测的,是因为一个人不能同时接受治疗又不接受治疗,这里关键的就是。

Y1n的博客 3713

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

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

hdfyhf的博客 351

Unity 实现动态网格地图生成与交互组件

本文详细介绍了在Unity中实现动态网格地图生成与交互组件的完整方案。从基础网格单元实现到高级交互功能,涵盖网格生成器核心逻辑、事件驱动架构、性能优化技巧以及六边形网格等特殊实现。特别适合游戏开发者学习如何构建战棋、模拟经营类游戏的可交互地图系统,提升开发效率与用户体验。

weixin_29015483的博客 1068

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

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

diaogan4202的博客 504

【系列06】端侧AI:构建与部署高效的本地化AI模型 第5章:模型剪枝(Pruning)

结构化剪枝移除的是模型中的整个结构,比如一个完整的神经元、一个卷积核或一个通道。修剪后的模型权重矩阵仍然是稠密的,因此能够充分利用现代硬件和软件的并行计算优势,从而显著提升推理速度。非结构化剪枝是最细粒度的剪枝方法。对于需要极致压缩但对推理速度要求不高的场景,非结构化剪枝是好的选择。它就像修剪一棵树,通过移除模型中不必要的“枝叶”,让模型变得更精简、更高效,从而适应资源受限的设备。,开发者可以方便地对模型的不同层进行剪枝,并根据需求进行微调,从而在不影响太多性能的前提下,获得一个更轻量、更高效的模型。

学习,输出==》再学习再输出 649

新手必看:C#调用YOLO模型完成图片/视频目标检测(上位机版)

新手学习C#调用YOLO模型,核心是先把基础流程跑通,再逐步优化。图片检测是基础,视频检测就是在图片的基础上加循环和线程,而上位机的实际项目,就是在这个基础上适配工业硬件和业务需求。本文的代码都是新手能直接复制运行的,如果你运行时遇到问题,先检查前期准备是否到位,再看避坑指南。记住,新手别追求一步到位,先实现功能,再慢慢优化性能和界面。等你能熟练调用YOLO模型后,再去研究模型训练、量化优化等进阶内容,会轻松很多。

这里只有干货:从 Modbus 通信到 MES 对接,从 YOLO 训练到工控机部署,带你搞定工业软件开发全流程。 987

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

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

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

VS2019编译配置Easy3D

VS2019编译配置Easy3D

dayuhaitang1的博客 2596

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

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

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

OV9734 DATASHEET,完整规格书

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

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

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

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

weixin_30736301的博客 219

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

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

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

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

Data-Structures-and-Algorithm-Analysis-in-Java.pdf

作者: Weiss, Mark A. 出版社: Addison Wesley Data Structures and Algorithm Analysis in Java is an “advanced algorithms” book that fits between traditional CS2 and Algorithms Analysis courses. In the old ACM Curriculum Guidelines, this course was known as CS7. This text is for readers who want to learn good programming and algorithm analysis skills simultaneously so that they can develop such programs with the maximum amo...

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

这是敏捷开发一千零一问系列的第十三篇。(在这里提问,之一,之二,之三,问题总目录)问题这是课堂上提的一个问题,这是一家外企,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、付费专栏及课程。

余额充值