软件开发指标和报告

Question

最近我有一些关于软件开发指标的有趣对话,特别是它们如何在一个相当大的组织中使用,以帮助开发团队更好地工作.我知道有一些关于哪些指标可以使用的Stack Overflow问题 - 比如这个,但我的问题更多的是关于哪些指标对哪些利益相关者有用,以及在什么级别的聚合.

作为一个例子,我的观点是代码覆盖率在以下方面(也可能是其他方式)是一个有用的指标:

• 当与其他测量结合使用时,团队自己的内部使用.
• 对于促进/启用/指导团队而言,在逐个团队的基础上考虑作为趋势可能是有益的(例如,如果团队A和B在本月75和50的覆盖范围内,我会更关心团队如果前一个月他们有80和40,那么比B还要多.
• 对于高级管理人员,在多个团队或整个部门中作为汇总统计数据呈现.

但我不认为高级管理层在逐个团队的基础上看到这一点是有用的,因为这鼓励人为尝试通过仅运用而不是测试代码的测试来支持覆盖.

我在一个管理层次结构中有几个级别的组织中,但绝大多数管理人员都具有技术头脑和能力(许多人仍然沾沾自喜).一些开发团队在推动敏捷开发实践方面处于领先地位,但其他开发团队则落后,现在有一个严格的要求从最高层开始,以便组织的工作方式.我们中的一些人正在启动一项计划来鼓励这一点.在这种组织中,您认为哪种指标有用,对谁,为什么以及在什么级别的聚合？

我不希望人们根据他们可以人为影响的指标来评估他们的表现.与此同时,高级管理层将需要某种证据证明正在取得进展.根据您自己组织的经验,您可以提供哪些建议或警告？

编辑

我们绝对希望将指标用作组织改进的工具,而不是作为个人绩效评估的工具.

Answer 1

个人经历的故事. 道歉的长度.

几年前,我们的开发小组试图为个人和团队领导者设定"适当的"可衡量目标.该实验仅持续了一年,因为硬指标对于个人目标并没有真正起作用(有关链接和进一步讨论,请参阅我关于该主题的问题).

请注意,我是一名团队领导,并且与我的技术老板和其他团队领导一起参与计划,所以目标不是由无能为力的高层管理人员决定的 - 当时我们真的希望他们工作.值得注意的是,奖金结构无意中鼓励了开发者之间的竞争.以下是我对我们尝试的事情的观察.

客户可见的问题

在我们的案例中,我们计算了我们向客户提供的服务中断.在收缩包装产品中,可能是客户报告的错误数量.

优势:这是高层管理人员可见的唯一真正措施.它也是最客观的,在开发组之外进行测量.

缺点:没有那么多的中断 - 全年每个开发人员只有一个 - 这意味着失败或超出目标是对每个团队中发生的少数中断的"责备".这导致了不良情绪和士气低落.

完成的工作量

优点:这是唯一的积极措施.其他一切都是"我们注意到坏事发生时",这令人沮丧.它的包含也是必要的,因为如果没有它,一年没有做任何事情的开发商将超过所有其他目标,这显然不符合公司的利益.测量完成的工作量检查了开发人员在估算任务大小时的自然乐观,这很有用.

缺点: "完成工作"的衡量标准是基于开发人员自己提供的估算(通常是一件好事),但将其作为目标的一部分鼓励系统博弈以夸大估算.我们没有其他可行的工作措施:我认为衡量生产力的唯一可能有价值的方法是"对公司底线的影响",但大多数开发商远离直接销售,这在个人层面很少实用.

新生产代码中发现的缺陷

我们测量了年内在新生产代码中引入的缺陷,因为我们认为前几年的缺陷不应该与今年的目标中的任何个人相比.内部质量团队发现的缺陷包括在计数中,即使它们不影响客户.

优点:令人惊讶的是很少.引入缺陷与发现之间的时间间隔意味着确实没有立即反馈机制来提高代码质量.团队层面的宏观趋势更有用.

缺点:人们非常关注负面因素,因为只有在发现缺陷并且我们需要有人为此负责时才会调用此目标.开发人员不愿意记录他们发现的缺陷,而简单的计数意味着小错误与严重问题一样糟糕.由于每个人的缺陷数量仍然很少,因此较小和严重缺陷的数量甚至不会像更大的样本那样均匀.旧的缺陷不包括在内,因此该组的代码质量声誉(基于发现的所有错误)并不总是与可衡量的引入本年度数相匹配.

项目交付的及时性

我们将时效性视为在规定截止日期前交付给内部QA团队的工作百分比.

优点:与计算缺陷不同,这是一种由开发人员直接控制的措施,因为他们有效地决定了工作何时完成.目标的存在使人们关注完成任务.这有助于团队承诺实际工作量,并提高内部客户对开发团队兑现承诺能力的看法.

缺点:作为直接受开发人员控制的唯一目标,它以代码质量为代价最大化:在截止日期当天,在任务完成或进行进一步测试以提高其质量信心之间做出选择,开发人员会选择将其标记为完整,并希望任何由此产生的错误都不会浮出水面.

内部客户的投诉

为了衡量开发人员在开发和随后支持他们的软件期间与内部客户沟通的程度,我们决定记录收到的关于每个人的投诉数量.投诉将由经理验证,以避免任何可能的报复.

优点:我真的没什么可回忆的.在足够大的群体水平上测量,它变成更有用的"顾客满意度"分数.

缺点:不仅高度消极,而且是主观措施.与其他目标一样,每个人的数字都在零标记附近,这意味着对某人的单一评论可能意味着"无限超越"和"不满足"之间的差异.

普通的留言

官僚主义:虽然我们的任务管理工具掌握了这些指标的大部分数据,但仍需要相当多的手动工作来整理所有这些指标.获得所有数字所花费的时间并不令人愉快,通常侧重于我们工作的消极方面,甚至可能无法通过提高生产率来回收.

士气:对于个人因问题而受到指责的措施,不仅那些"坏"分数的人感到失去动力,但那些"好"分数的人也是如此,因为他们不喜欢团队士气的损失,有时觉得他们是排名更高不是因为他们更好,而是因为他们更幸运.

摘要

那么我们从剧集中学到了什么？在后来的几年里,我们尝试重新使用一些想法,但是以"更软"的方式,不再强调个人责任,而是更多地关注团队改进.

• 不可能为个别开发者定义客观可衡量的目标,为公司增值并且不能被游戏,所以不要费心去尝试.
• 如果缺陷的位置明确地是该团队的责任,那么客户问题和缺陷可以在更广泛的团队层面进行计算- 也就是说,您不必玩"责备游戏".
• 一旦仅在代码模块的责任级别上测量缺陷,您就可以(并且应该)测量旧错误以及新错误,因为消除所有缺陷是该组的兴趣所在.
• 在组级别测量缺陷计数会增加每组的样本量,因此可以消除轻微和严重缺陷之间的异常,并且简单的"错误数量"度量可能意味着什么,例如,看看您是否正在逐月改善月.
• 包括高层管理人员关心的事情,因为让他们满意是您作为开发团队的主要目的.在我们的案例中,它是客户可见的中断,所以即使该措施有时是任意的或看似不公平,如果这是老板正在测量的,那么你也需要注意.
• 高层管理人员不需要查看他们在自己的目标中没有的指标.这样就避免了将个人归咎于错误的诱惑.
• 衡量项目交付的及时性确实改变了开发人员的行为,并将重点放在完成任务上.它改善了估算并使该集团能够做出现实的承诺.如果收集及时性信息很容易,那么我会考虑在团队层面再次使用它来衡量一段时间内的改进.

当您需要为个别开发人员设置可衡量的目标时,所有这些都无济于事,但希望这些想法对团队改进更有用.

Answer 2

关键指标的关键是知道您使用它们的内容.您是否将它们用作改进工具,奖励工具,惩罚工具等等.听起来您正计划将它们用作改进工具.

设置指标时的首要原则是保持信息的相关性,以便接收它的人可以使用它来做出决定.很可能高级经理无法决定您是否需要更多测试,更少复杂性等微观层面.但团队领导者可以做到这一点.

因此,我认为一定程度的代码覆盖对个人团队之外的管理无益.在宏观层面,该组织可能对以下方面感兴趣:

• 交货成本
• 交货及时
• 交付范围和外部质量

内容质量在他们的名单上不会很高.开发团队的使命是明确内部质量(可维护性,测试覆盖率,自我记录代码等)是实现其他三个的关键因素.

因此,您应该将指标定位到更高级管理人员,这些管理人员可以覆盖这三个因

• 总体速度(请注意,比较团队之间的速度通常是人为的)
• 预计与实际范围交付到商定的时间表
• 生产缺陷数量(可能是人均)

并且在团队级别测量诸如代码覆盖率,代码复杂性,削减'n'粘贴分数(使用flay或类似的代码重复),方法长度等等,其中信息的接收者可以真正发挥作用.