打开APP
userphoto
未登录

开通VIP,畅享免费电子书等14项超值服

开通VIP
王小波:资本主义居然用代码行发工资,真虚伪!

1982年,王小波在美国留学,主业是数学,课余就给导师打工,写程序。

他在《革命时代的爱情》中对这段经历做了精彩的描述:

第一次从系里领来了编软件的活儿时,我想道:好!总算有了一个我施展才华的机会了!

虽然那是个大型软件,好几个人合编,但是我想这样更好,可以显出我比别人强。

越是这样想,就越是心绪纷乱,一行源码也写不出来。

所以我就对我老婆说,你出门时,把我锁在屋子里。我就是这样一个变态分子,但是我老婆一点没觉察出来。

锁在房子里时,精力能够集中。所以我编的第一批软件极有诗意,李后主有词云:红豆啄残鹦鹉粒。我的软件就曲折和弹性而言,达到了此句的境界。

后主又有残句云:细雨流湿光。我的软件就有这么简约,别人编十行,我只用一行。

等到交活时,教授看了吃一惊:这么短!能跑(run)吗?

我说你试试嘛。试完了他和我握手道:谢谢!

但是到了开支时,我的钱比别人都少。原来是按行算钱,真把我气死了。

等到交第二批软件时,我就吃棉花屙线屎。古诗云:一个和尚独自归,关门闭户掩柴扉。

我的第二批软件到了这种境界。简言之,别人编一行,我就编了二十行。

等到交活时,教授根本不问能不能run,只说:你这是捣蛋!就打回来让我改短。

资本主义就是这么虚伪。

王小波难题

王小波当年遇到的难题,表面上是:如何给程序员“发钱”?

实质上是:如何评定程序员的绩效。

这个问题很大,从当年到现在,中外组织发明了和演进了很多解决方案:KPI、PBC、OKR……,可谓:引无数英雄竞折腰。

1970年代之前,西方工程界普遍参考了“文字工作者”的经验——作家与记者是按照“字数”来计算产量的;

所以,程序员可以按照代码行来计算产出规模,然后根据规模“发钱”。

但是,这种办法无意地混淆两个重要的概念:工作量与规模

1975年,实践并思考了多年的Brooks发表了著名的《人月神话》,这篇文章反思:用“人月”来度量软件“规模”是“神话”。不过在这篇著名的文章里,他其实也没有给出明确的解决方案。                                      

也就同一个时期,他的同事Allan Albrecht先生正在解决这个“神话”,最后形成即是:“功能点分析”(FPA)方法。

什么是功能点?

功能点分析的“第一性原理”是:

对用户有价值的是软件的功能,这个才是“规模”;而不是过程中的消耗与成本(代码行、工作量)。

功能点分析是站在“用户视角”(而不是开发者视角),将软件的功能需求分解为一系列最基础的功能单元(BFC,basic function component)。

这些基本功能单元,主要分为两大类、五小类。每类功能组件都有逻辑严谨的定义,是最小的、不能再细分的“软件原子”。

数据+行为,是不是有点面向对象的感觉?

我拿在用户在手机上点外卖举个例子,外卖app的BFC如下表:

从这个例子可以看出,“功能点”其实是每类BFC大小的“计量单位”。

上图的例子,就是在我国最常使用的“估算功能点”方法,约定了1个“ILF(内部逻辑文件)”值10个功能点,1个“EI(外部输入)”值4个功能点。

可能有同学马上就想到:同样是ILF,有的业务对象包含了50多个“字段”,有的只有5-6个。难道大小一样,都值10个功能点吗?

答案:在“估算功能点”方法中,就是一样大小的。BFC的固定功能点数值,是经过统计分析、并实证校验得出的。在统计学上来看,50个字段的ILF与5个字段的,其规模大小是没有差别的。

功能点有什么用?

软件度量师只要先分析某个软件包含多少个BFC,然后将他们的功能点数值汇总加起来,就能够数字化这个软件的规模。

就像是在乐高世界,软件就是由五类乐高积木搭成的,每一类乐高积木的重量(质量)都知道;我们只要统计出某个软件各类积木的数量,就能够计算出其总重量。

在统计学上,如此度量出的软件“规模”与开发实际投入的“工作量”之间,有较强的“相关性”。

(国外的文献显示,两者之间的R^2=0.89,spearman相关系数为0.85,对应的P值都低于0.0001。)

在国内也有很多的实践,证明规模与工作量之间的相关性普遍也很高。

由于定义逻辑严谨,且有这些“数字化”证据,功能点分析的方法发布后,很快就被ISO/IEEE认定为国际标准。在我国,基于功能点方法的“软件研发成本度量规范”,也先后成为了工信部标准(2013年)与国家标准(2018年)。

目前,在国内政府、金融、电信等领域,软件的客户购买(或租用)软件,很多都是基于功能点来计算软件规模,在以此计算工作量、合同(预算、结算)金额。

在个体绩效管理层面,很多工程师也承认:在众多KPI中,只有功能点是比较客观的。

当年,如果王小波也知道了这个方法,就可以给他的导师“上一课”了。

我的公司怎么没用功能点呢?

不过可能大家有疑问了:这么好的东西,为什么在互联网公司没用起来呢?为什么大家都习惯用人天来估算工作量呢?

我想主要的原因还是功能点分析法略显复杂,把需求分解成基本功能单元本身就有难度,需要经过一定的训练才可以。

“人天”就简单多了,任何人,拍拍脑袋,想想其中代码实现的难度,很快就能估算出来。

互联网公司的需求变化也快,还没等你实现完,估计又变了,用功能点分析法分析来分析去,累死人。

再说了,互联网公司也擅长工期倒逼法:别给我扯什么方法,下个月必须上线!

这时候,什么方法都不管用了......

(完)

本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请点击举报
打开APP,阅读全文并永久保存 查看更多类似文章
猜你喜欢
类似文章
使用功能点简单估算开发成本
关于软件系统定制开发成本估算方法的研究
《信息化项目软件运维费用测算规范》报批稿
软件研发造价成本计算V1.0
竞争情报
软件定义汽车 (第九集) : 危机是如何酿成的
更多类似文章 >>
生活服务
热点新闻
分享 收藏 导长图 关注 下载文章
绑定账号成功
后续可登录账号畅享VIP特权!
如果VIP功能使用有故障,
可点击这里联系客服!

联系客服