写点什么

软件开发项目指标

  • 2009-07-29
  • 本文字数:3874 字

    阅读完需:约 13 分钟

从 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-07-29 22:217483

评论

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

分库分表 vs NewSQL 数据库

xcbeyond

分库分表 6月日更

获5项大奖,发布《云计算开放应用架构标准》,阿里云持续领航云原生

阿里巴巴中间件

Overbit Flash|5 月加密货币市场风暴抹去了 90% 以上的 NFT 交易量

Overbit学院

比特币 加密货币 NFT Overbit 保证金交易

什么是交叉编译

IT蜗壳-Tango

IT蜗壳教学 6月日更

C++多线程强制终止

华为云开发者联盟

c++ 安全 线程 多线程 可信

亮相Google I/O,字节跳动是这样应用Flutter的

字节跳动技术团队

Qcon全球软件开发大会 融云分享SDK交付质量保障经验

融云 RongCloud

Java日志的心路历程

程序猿阿星

Java log4j logback log4j2框架 Java日志

前后端分离浅析以及分离教程

北游学Java

前后

华云大咖说 | 安超OS全面升级 最新亮点解密

华云数据

ETL工程师必看!超实用的任务优化与断点执行方案

敏捷调度TASKCTL

大数据 ETL算法 ETL ETL任务 ETL系统

新手小白必须知道的Linux基础:常用命令(1)

学神来啦

Linux linux命令 linux运维 linux 文件权限控制 Linux教程

从一面就被拒到收割字节offer,我花了一年时间,功夫不负有心人

Java架构师迁哥

C 语言数据结构的封装方法

实力程序员

裕民银行 x mPaaS | 移动应用“适老化”改造,可不止是字体变大

蚂蚁集团移动开发平台 mPaaS

移动开发 mPaaS APP开发

【Flutter 专题】113 图解自定义 ACEPieWidget 饼状图 (二)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 6月日更

难忘阿里,4面技术5面HR附加笔试面,走的真艰难真心酸

Java 编程 程序员 面试 架构师

有点难的知识点:Webpack Chunk 分包规则详解

范文杰

webpack 6月日更

🏆【声网Agora】「WebRTC-如何搭建语音认证服务」

洛神灬殇

WebRTC RTC征文大赛 Agora 6月日更

音视频学习--弱网对抗技术相关实践

Fenngton

音视频 网络 视频编解码 弱网下的极限实时视频通信 实时视频

踩准时钟节拍、玩转时间转换,鸿蒙轻内核时间管理有妙招

华为云开发者联盟

鸿蒙 时间管理 计数器 时间转换 计时

和12岁小同志搞创客开发:如何驱动各类型传感器?

不脱发的程序猿

DIY 传感器 如何驱动各类型传感器? 创客

华为云IoT设备接入服务全体验

华为云开发者联盟

物联网 IoT 华为云 智能IoT边缘服务 华为云IoT云服务

☕【JVM技术之旅】全流程化分析Java对象的创建过程

洛神灬殇

JVM 6月日更 对象布局 内存结构

GitHub火到糊!这份阿里内部10W字Java面试总结,让你薪资翻倍

Java架构追梦

Java 架构 面试 跳槽

【融云技术】超大规模并发下自定义属性的设置与分发

融云 RongCloud

6000年,看懂了「硬核山东」!

云计算

详解浏览器跨域访问的几种办法

华为云开发者联盟

安全 浏览器 跨域 WEB安全 跨域访问

anyRTC Web SDK 实现音视频呼叫功能

anyRTC开发者

音视频 WebRTC RTC sdk

【LeetCode】连续数组Java题解

Albert

算法 LeetCode 6月日更

为鸿蒙OS说两句公道话(我对鸿蒙OS的一些看法)

Phoenix

软件开发项目指标_研发效能_Carlos Sirias_InfoQ精选文章