写点什么

软件开发项目指标

2009 年 7 月 29 日

从 2007 年开始,我就参与了一项工作,为软件开发项目的成败寻求无关方法论的度量,以便于向上级管理层汇报。这一努力是为了向更广泛的受众呈现我们遇到的挑战及应对的措施。下文描述了我在此次研究中的一些个人心得,它着重于绩效指标,而非进度指标,因为我个人相信后者那一套只关注当下,而对团队的未来成就影响寥寥。在我看来,进度指标只是一种帮助你的团队按时完成目标的方法,可是团队如果不反思其绩效,他们改善的机会就减少了。比如,如果一个项目经理总是拿出“进度计划对照表”之类的东西给人看,团队将忙于追回损失,而不会停下来思考问题出在哪里、如何改善——因为他们没那个闲功夫。我认为进度指标虽然有用,却并不完美,原因就在于此。

大家可能都记得这句名言:“若无法度量,则不可管理”。而如果一家公司无法管理软件项目,他们又该如何去了解怎样改善?何时获得了改善?引入流程的改变究竟增值几许?——比如他们软件实践和原则的转变——是不是有人提到“从瀑布模式转向敏捷”来着?软件项目的成功从来都是业内的目标,可是帮助我们衡量成功与否的指标却极为多样。建议采用的指标集取决于你所遵循的特定方法论,它们之间毫无共性可言。我们在惠普就面对这一挑战,因为我们有一组各式各样采用不同方法论的项目,所以上级管理层收到杂乱无章的指标,而这都取决于各部门自己想要汇报什么。

对有敏捷背景的读者,我们知道他们的项目尤为适合指标衡量,因为数据可以无缝收集,也不必让团队分心。但是,有些项目没有使用敏捷所信奉的原则和实践,建议使用的指标集可能就不适合它们。诸如速率、价值流累积和燃尽图可能对没有接受敏捷的团队来说毫无意义。那么,如果我们想衡量项目本身,而不是其采用的方法,又该如何呢?

软件开发流程的管理需要识别度量的能力,这些度量代表着内在因素的特性,用以控制项目并助其持续改善。我们在公司内外数次尝试和研究,结果纠结于一大批(约二十个)的拟议指标中。不过我们以一种很敏捷的方式与一组专家坐下来探讨,回顾每一个特定指标。我们首先淘汰所有与项目、文档、代码和交付物的大小相关的拟议指标,因为大公司要管理各种各样的项目,而我们确实扪心自问:我们真的要度量这个吗?答案是否定的,因为我们首先需要的是简单易行的指标集,它们不增加团队的负担,也更有助于确定团队成熟度与绩效。

最后我们决定简约至上,定义了普适整个 IT 业的三大核心指标如下:

人工投入,即产出可用产品或服务的任务的总时间量。计划的工时量称为“计划人工”,实际花费的工时量称为“实际人工”。人工投入可以用小时或天来度量,这取决于项目的规范。任务,是完结一个工作、问题或任务的一组行动的一部分。它在瀑布或敏捷项目中并无二致。但我们的确承认,采用不同方法论时对任务的管理有所不同,双方各有千秋。下图体现了这一指标是如何汇总至团队的。

图 1:累积人工可视图 & 实际人工按工期分布

人工投入是一项可直接观测量,它通过分派给特定资源的任务量累计得到,也能够在特定任务、里程碑或工期上计算。“计划人工”在计划特定任务的工作量时采集,并在该任务被分析或设计时修正。‘实际人工’在进行与特定任务相关的建造、测试和维护时采集。组织最初可能发现’估计值’和’实际值’ 间有巨大的不同和差异,但随着团队日益变得“成熟”,数据会渐趋一致。我们的经验是,如果 6 个月后人工投入的图表并未显示更加一致的趋势,团队必须进行回顾,找到根本原因,并与团队内外因素联系起来。正如 Poppendieck【5】建议的,定义约束条件将会是非常好的出发点。

生产效率,即每天可交付的"简单任务"的数量。可以在项目内的各个级别,如个人、工种、任务工期或项目上,对它进行计算。

简单任务”的定义总是引致争论;我们最终将其定义为:某人力资源交付某物的过程,所需时间 5 小时左右(当然有些简单任务需时更长或更短,但是我们最后决定使用这一时长)。

基于我们对生产效率的定义:“可以在 8 小时工作日交付的简单任务数量”,其计算公式为:

生产效率 = (( 计划人工 / 5) / 实际人工 ) * 8

下图体现了这一指标是如何汇总至团队的。

图 2:生产效率可视图

显然,这一指标有可商榷之处,我们下定义时也提出了大量有理有据的论点,但是正如每个良好的民主制度那样,我们需要最终统一于大多数人可接受的定义。而一旦有了这一指标,我们就发现了它在对比项目健康程度上的得力之处,不管是论周、论月还是论资源等等。

生产率指标产生在任务级别上,并可汇总至交付物、工期和项目级别。它明显依赖于做估计的技术和采集人工投入数据的工具。

图 3:生产效率可视图

上图显示了两个类似项目发布的生产率累积,它们由相同团队完成,成员相同,指标相同。一开始这个团队使用其所熟悉的瀑布型方法论(所有分析工作在前,所有编码工作居中,所有测试工作断后)工作 6 个月,然后采用敏捷方法在另 6 个月中完成另一发布。在两个项目中应用的生产效率公式,显示了敏捷专家们常说的典型趋势,即工作从一个项目阶段(如编码)成批地向另一阶段(如测试)移动,就无法让项目团队以可持续的步调交付高质量产品,因而降低了他们在前述公式定义下的生产效率(原因可能是从某一任务向下一任务的轮番转换——进行多任务处理的耗费)。相较于上一项目发布,同一团队在使用了敏捷原则与实践后,如迭代式开发、聚焦某一特定功能、试错开发(首先开发高风险需求)等,他们的生产效率得到了提高。

使用共同指标,我们就能够衡量敏捷项目所具备的交付上的可预测程度,以及项目成熟后估计的准确程度。

质量,即项目生命期内交付中的高、中、低级缺陷的数量。它有助于识别最终用户交付物的优良程度。每个团队都需要针对其特定项目来定义高中低级别的含义。应当在整个项目周期内报告质量情况:缺陷发现得越晚,对项目的影响越大。 下图体现了这一指标是如何汇总至团队的。

图 4:质量可视图

采集缺陷信息后,我们也追踪另一衍生指标,“缺陷移除”。其目标在于,相对于流程前期,评估流程后期所发现问题(显然代价更高)的百分比。我们在此比较敏捷和瀑布类项目时也发现了一些有趣的行为模式。

图 5:缺陷移除可视图

上图显示,敏捷项目在软件生命周期里具有相对可持续的缺陷率,而瀑布型项目在后期表现出一个波峰。该信息采集自同一团队的两次产品发布(需求集相当),而开发模式互不相同。

这一指标集被持续采集、分析和汇报。我们可以将他们包含在一个“项目仪表盘”内,从而建立一个全局视图,可以与利益相关方共享和解读成果。

如下表所示,指标间有明显的关联关系

指标 1 指标 2 积极趋势 消极趋势 生产效率 交付
缺陷
密度 高生产率伴随高缺陷密度,是项目中所计划的 QA 人工投入不足的标志。虽然高生产率是可取的,但是在总体效益上必须平衡生产率和质量。因此,具备高质量的最优生产率才是最合宜的。 高生产率伴随低缺陷密度,是好的行为模式,而团队可以在监控缺陷密度的同时,力求生产率的进一步提高。
高缺陷密度伴随低生产率,表明需要对测试进行调优、修改或自动化,来尽早查出问题。 生产效率 缺陷
移除
效率 高生产率伴随高缺陷移除效率,标志着生产效率与质量之间的很好平衡。团队可以在监控缺陷移除效率的同时,力求生产率的进一步提高。 高生产率伴随低缺陷移除效率,表明在项目中所计划的 QA 人工投入不足。
高缺陷移除效率伴随低生产率,表明在整个周期中需要对质量多加重视。我们在巴西研发部门的一位项目经理 Guilherme Souto,编纂了如下速效提示,帮助我们在采纳指标的过程中保持诚实和理性:

  • 指标需要与组织或项目目标相联系,才能体现我们是否达成了承诺。
  • 指标需要与日常工作流程(尽可能地)整合,以避免单为采集数据而花费时间。
  • 所选择的指标需要被核实是否覆盖各个领域,这些领域将决定项目结束时是否成功。
  • 指标就像单词,在成组造句时才真正表达含义。所以尽量避免过度分析单一指标的数据是很有必要的。当这一指标集引入后,我们总是看到团队过度关注生产效率,但是将指标孤立出来的观念,让我们无法在分析时考虑到其他变量,比如项目的困难和挑战程度或是团队(缘于其成熟度、遵循的流程或其他因素)所产出的质量高低。最终我们总不想重复过去的错误,以前我们只孤立地观察进度计划对照表之类的进度指标,导致我们牺牲了质量或者资源。
  • 如果一个指标无法被用来建立或定义行动计划,采用它就毫无用处。
  • 绩效之类的指标需要目标值。一旦要采取改正措施,团队必须明了预期的高低阈值区间。

这些指标只提供了部分历史情况,而它们在决策中的适用性,取决于对触发团队趋势特定改变的事件链的了解。这一举措和所定义的指标,对您的特定团队不一定是最佳的,但这是我们至今采取的,对我们来说也管用。希望对某些读者能有帮助,当然我也可能错得离谱。

参考文献

下面这些是本文所涉主题的很好出发点。

【1】. H T. Goranson,敏捷虚拟企业:案例、指标、工具。 Quorum Books. 2003.

【2】. Tom DeMarco,控制软件项目:管理、度量和估计。Prentice Hall. 1986

【3】. Dr. Cem Kaner,软件工程指标:它们衡量什么,而我们又如何了解?第十届国际软件指标研讨会. 2004

【4】. R¨¹diger Lincke, Jonas Lundberg, Welf L?we,软件指标工具之对比。软件测试与分析国际研讨会. 2008

【5】. Poppendieck and Poppendieck,实施精益软件开发:从概念到实利。Addison Wesley Professional, 2003.

阅读英文原文: Project Metrics for Software Development


感谢郑柯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2009 年 7 月 29 日 22:215997

评论

发布
暂无评论
发现更多内容

【STM32】CubeMX+HAL 输出PWM

AXYZdong

硬件 stm32 2月春节不断更

IO 模型知多少 | 理论篇

圣杰

io

区块链农产品溯源系统开发,区块链公共服务平台建设方案

WX13823153201

区块链农产品溯源系统开发

Instana:如何评价可观察性方案?

行人23

实例详解Linux下ulimit每个参数

运维研习社

Linux ulimit linux系统资源管理 open file

做出赋能其他人的产品是技术牛人最好的证明

刘华Kenneth

敏捷 平台

Nginx如何监控各server的流量

运维研习社

nginx Prometheus zabbix upstream

第十三周 数据应用二 作业 「架构师训练营 3 期」

feiyun123

阿里+腾讯+字节+滴滴+美团java面试题及答案(2021版)1353道题全部开源

Java架构追梦

Java 架构师 面试题总结 金三银四 大厂面试真题

1353道,阿里+腾讯+字节+滴滴+美团java面试题及答案(2021版)

Java架构师迁哥

你好,2021~

数据社

程序员 2021年展望

牛启新春|优质文章人气大挑战

InfoQ写作平台官方

活动专区

学习 Java 语言,你必须知道的 Java 简史

白色蜗牛

Java spring 程序员

测试技术

牛鬼蛇神VS魑魅魍魉

京东方“8K+5G”技术助力牛年春晚 开启超高清视频直播时代

爱极客侠

iOS BAT面试对答题

ios 面试题

二、MongoDB基础知识

Kylin

读书笔记 七日更 分布式数据库mongodb 二月春节不断更

如何解决Nginx实现动静分离或反向代理时资源路径不匹配

运维研习社

nginx 反向代理 动静分离

为什么做这样一个产品之容量评估篇

数列科技杨德华

28天写作

面试官一上来就问我Chrome底层原理和HTTP协议(万字长文)

魔王哪吒

前端 后端 chorme 28天写作 2月春节不断更

2021年目标,我打算这样去实现

谙忆

BOE(京东方)全面发力8K 成为央视8K超高清技术合作伙伴

爱极客侠

说说规则引擎

张老蔫

28天写作

关于Linux系统中Message中的Session日志详解

运维研习社

Centos 7

抓包带你详解TCP的11种状态

运维研习社

三次握手 四次挥手 TCP/IP 抓包

为行动而读书-《麦肯锡精英高效阅读法》读书笔记

代码技艺

读书笔记

创业公司人力资源体系建设的几点思考

一笑

人力资源 28天写作

一文搞懂Linux下Ulimit资源限制

运维研习社

Linux linux命令 ulimit

翻译:《实用的Python编程》02_02_Containers

codists

Python 人工智能 容器 后端 数据结构与算法

Nginx加密套件配置不当,造成SSL无法建立连接

运维研习社

nginx zabbix SSL证书 证书监控

Kafka.03 - Message 介绍

insight

kafka 2月春节不断更

技术为帆,纵横四海- Lazada技术东南亚探索和成长之旅

技术为帆,纵横四海- Lazada技术东南亚探索和成长之旅

软件开发项目指标-InfoQ