BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

软件开发项目指标

| 作者 Carlos Sirias 关注 0 他的粉丝 ,译者 顾全 关注 0 他的粉丝 发布于 2009年7月31日. 估计阅读时间: 12 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

从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中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT