软件开发度量和报告

个人经历中的故事。 为长度道歉。

几年前,我们的开发团队试图为个人和团队领导设定“适当的”可衡量的目标。这项实验只持续了一年,因为对于个人目标而言,硬指标并不是很有效(参见 my question on the subject 以获取一些链接和进一步讨论)。

请注意,我是一名团队领导,与我的技术主管和其他团队领导一起参与计划,所以目标并不是由愚蠢的高层管理人员在高层下达的,当时我们真的希望他们工作。值得注意的是,奖金结构无意中鼓励了开发者之间的竞争。这是我对我们尝试的事情的看法。

客户可见问题

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

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

缺点: 没有那么多的中断——大约一整年每个开发人员一次——这意味着失败或超出目标是每个团队中发生的少数中断的“钉住责任”问题。这导致了不好的感觉和士气的丧失。

完成的工作量

优势: 这是唯一 积极的 措施。其他一切都是“坏事发生时我们注意到的”,这让人士气低落。它的加入也是必要的,因为没有它,一个整年无所作为的开发人员将超过所有其他目标,这显然不符合公司的利益。测量完成的工作量检查了开发人员在估计任务大小时的自然乐观,这是有用的。

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

新产品代码中发现的缺陷

我们测量了缺陷 介绍 在这一年的新的生产代码中,因为人们认为在今年的目标中,前几年的bug不应该与任何个人相提并论。内部质量团队发现的缺陷包括在计数中,即使它们不会影响客户。

优势: 出奇的少。引入缺陷和发现缺陷之间的时间延迟意味着实际上没有即时反馈机制来提高代码质量。团队层面的宏观趋势更有用。

缺点: 有一个重点是负面的,因为这个目标只有在发现缺陷时才被调用,我们需要有人为此负责。开发人员不愿意记录他们自己发现的缺陷,简单的计数意味着小错误和严重问题一样严重。由于每个人的缺陷数量仍然很低,小缺陷和严重缺陷的数量并没有像大样本那样平均。旧的缺陷不包括在内,因此集团在代码质量方面的声誉(基于 全部的 发现的错误)并不总是与今年引入的度量值匹配。

项目交付的及时性

我们以在规定的截止日期前交付给内部质量保证团队的工作百分比来衡量及时性。

优势: 与计算缺陷不同,这是一个由开发人员直接直接控制的度量,因为他们有效地决定了工作何时完成。目标的存在使人们的注意力集中在完成任务上。这有助于团队致力于实际的工作量,并提高内部客户对开发组实现承诺能力的认识。

缺点: 作为开发人员直接控制的唯一目标,它是以牺牲代码质量为代价实现最大化的:在最后期限的当天,考虑到在表示任务已完成或进行进一步测试以提高对其质量的信心之间的选择,开发人员将选择标记它已完成,并希望由此产生的任何错误不会出现在SURFA中。总工程师。

内部客户投诉

为了衡量开发人员在软件开发和后续支持过程中与内部客户的沟通情况,我们决定记录每个人收到的投诉数量。投诉将由经理确认,以避免任何可能的报复。

优势: 真的什么都想不起来了。在足够大的群体层面上衡量,这将成为一个更有用的“客户满意度”评分。

缺点: 不仅是高度消极的,而且是主观的衡量标准。与其他目标一样,每个人的数字都在零分附近,这意味着对某人的一次评论可能意味着“无限超出”和“未达到”之间的差异。

一般性意见

官僚主义: 虽然我们的任务管理工具保存了这些度量的大部分数据,但是仍然需要大量的手工工作来整理这些数据。获得所有数据所花费的时间并不令人愉快,通常集中在我们工作的消极方面,甚至可能没有被提高的生产力所回收。

士气: 对于那些因问题而被指责的人来说,不仅那些得分“差”的人感到被贬低,而且那些得分“好”的人也感到被贬低,因为他们不喜欢团队士气的损失,有时他们觉得自己排名更高不是因为他们更好,而是因为他们更幸运。

总结

那我们从这一集中学到了什么?在后来的几年里,我们试图重新使用一些想法,但以一种“软”的方式,在那里,人们很少强调个人的责任,更多地强调团队的改进。

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

当需要为单个开发人员设置可衡量的目标时,所有这些都没有帮助,但希望这些想法对团队改进更有用。

关于度量的关键是知道您使用它们的目的。你是否把它们当作改进的工具、奖励的工具、惩罚的工具等等。听起来你正打算把它们当作改进的工具。

设置度量标准时的首要原则是保持信息的相关性,以便接收信息的人可以使用它做出决策。最有可能的情况是,高级经理不能在微观层面上决定您是否需要更多的测试、更低的复杂性等,但团队领导可以做到这一点。

因此,我不认为代码覆盖率的度量对于单个团队之外的管理是有用的。在宏观层面上,组织可能对以下方面感兴趣:

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

内部质量在他们要掩盖的事情清单上不会很高。明确内部质量(可维护性、测试覆盖率、自记录代码等)是实现其他三个目标的关键因素,这是开发团队的使命。

因此,您应该将指标瞄准更多的高级经理,这些经理涵盖了这三个方面,例如:

• 总速度(注意团队之间的速度比较通常是人为的)
• 按约定时间交付的预期范围与实际范围
• 生产缺陷数量(可能为人均)

在团队级别上测量代码覆盖率、代码复杂性、剪切粘贴分数(使用flay或类似方法重复代码)、方法长度等,在团队级别上,信息接收者可以真正发挥作用。

度量是回答有关项目、团队或公司的问题的一种方法。在你开始寻找答案之前,你需要决定你想问什么问题。

典型问题包括:

• 我们的代码质量如何?

• 质量是否随着时间的推移而提高或降低?

• 团队的工作效率如何?它是在改善还是在退化?

• 我们的测试有多有效?

• 等等…

每个问题都需要一组不同的指标来回答。收集指标而不知道你想要回答什么问题,充其量是浪费时间,最坏的情况是适得其反。

你还需要知道,工作中有一个“不确定性原则”——除非你非常小心,否则收集度量标准的行为会改变人们的行为,通常是以意想不到的、有时是有害的方式。尤其是当人们相信他们正在根据度量标准进行评估,或者更糟的是,度量标准仍然与一些奖励或惩罚方案相关联时。

我建议你读杰拉尔德·温伯格的 Quality Software Management Vol 2: First Order Measurement . 他详细介绍了软件度量,但他说最重要的通常是他所谓的“零阶度量”——询问人们对项目进展的看法。这一系列的四本书都很贵,很难买到,但很值得。

软件写作

• 必须优化什么?

CPU使用、内存使用、内存缓存使用、用户时间使用、运行时的代码大小、运行时的数据大小、图形性能、文件访问性能、网络访问性能、带宽使用、代码简洁性和可读性、用电,(计数)使用的不同API调用,(计数)使用的不同方法和算法,可能更多。

• 必须优化多少?

必须优化通过验收测试、方便维护、方便审计和满足用户要求所需的最小合理数量(除了需要超过验收测试标准的区域)。

(“……”对于所有测试状态的合法/非法输入测试数据和合法/非法测试事件,在所有当前和未来测试集成方案的所有所需测试数据卷和测试请求卷上。”)

• 为什么是最低合理金额?

因为优化的代码更难编写,所以成本更高。

• 需要什么领导?

编码标准、基本结构、验收标准和所需优化水平指南。

如何衡量软件写作的成功?

• 成本
• 时间
• 验收试验通过
• 超过验收试验的程度
• 用户批准
• 易于维护
• 审计简易性
• 缺乏过度优化的程度

在评估 程序员 ?

• 由于需求(inc体系结构)更改而导致的浪费成本/时间
• 因平台/工具缺陷而产生的额外成本/时间

但该成本/时间应包括在评估 团队 (包括建筑师、经理)。

如何衡量架构师的成功?

其他措施及:

• “避免过早”受到平台/工具缺陷影响的实例
• 建筑没有变化的程度

正如我所说的 What is the fascination with code metrics? ,指标包括:

• 不同人群 ,这意味着开发人员或经理的利益范围不相同。
• 趋势 这意味着任何度量本身没有关联的趋势是没有意义的,以便做出对其采取行动或忽略它的决定。

我们使用的工具能够提供:

• 许多 微观指标 (开发人员感兴趣),有趋势。
• 具有多级(UI、数据、代码)静态分析功能的许多规则
• 许多 聚合规则 (也就是说,这些大量的度量标准被浓缩为 域 利益,足以满足更高层次的人口)

结果是一个可以从高层聚集中钻取的分析 域 (安全性、体系结构、实践、文档等)一直到某一行代码。

目前的反馈是:

• 当一些规则不受尊重时,项目经理可以很快采取防御措施,并使其全球关注度显著降低。
  每项研究都必须重新调整以尊重每个项目的要求。
  利益是合同的定义,其中承认例外,但规定了应遵守的规则。
• 更高级别(IT部门、利益相关者)使用全球注释作为对所取得进展进行评估的一个要素。
  实际上,他们将更密切地关注基于交付周期的其他元素:我们多久能够迭代并将应用程序投入生产?,在该版本发布之前,我们必须解决多少错误?(对于合并,或者对于生产前环境没有正确设置),应用程序的新版本会产生什么即时反馈?

所以:

哪些指标对哪些利益相关者有用,以及在什么级别的聚合上有用

高水平:

• (静态分析)度量实际上是低级度量聚合的结果,并按域组织。
• 其他指标(更多) operational-oriented “,基于应用程序的发布周期,而不是 只是 在代码的静态分析中)被考虑在内。
• 实际的投资回报率是通过其他措施(如 six-sigma 研究)

在较低水平:

• 静态分析已经足够了(但必须包含多层应用程序,有时还需要多语言开发)
• 这些行动是由趋势和重要性决定的。
• 研究必须得到所有层级的批准/支持,才能被接受/采取行动(特别是,必须验证后续重构的预算)。

如果你有一些精益的背景/知识,那么我建议玛丽·波彭迪克 recommends (我已经提到过了 previous answer )该系统基于必须作为一个整体进行的三个整体测量:

1. 循环时间
   • 从产品概念到首次发布或
   • 从功能请求到功能部署或
   • 从错误检测到解决
2. 业务案例实现( 没有这个,其他一切都无关紧要 )
   • 保洁公司或
   • 投资回报率或
   • 投资目标
3. 顾客满意
   • 例如 Net Promoter Score

聚合级别是产品/项目级别,我认为这些指标有助于 每个人 (开发人员永远不应该忘记他们不是为了好玩而写代码,他们写代码是为了创造价值,并且应该时刻牢记这一点)。

团队可以(并且实际上可以)使用技术度量来度量质量标准的一致性,这些一致性集成在“完成”的定义中(即“不增加技术债务”)。但高质量本身并不是目的,它只是一种实现的手段。 短周期时间 (成为一家快速公司)这是真正的目标(商业案例实现和客户满意度)。

这是一个有点旁注的主要问题,但我有一个非常类似的经验,保罗斯蒂芬森回答以上。我要补充的一件事是数据的收集和度量的可见性。

在我们的例子中,开发主管打算整理来自不同系统的大量数据,并每月分发一次单独的度量结果。这经常没有发生,因为这是一项耗时的工作,他是一个忙碌的人。

结果如下:

1. 不高兴的开发人员,因为绩效奖金是基于指标的,人们不知道他们是如何发展的。

2. 将数据多次输入到不同的系统中需要一些时间。

如果您沿着这条路线走,您需要确保所有度量数据都可以自动进行整理,并且对其影响的那些数据很容易看到。

其中一个有趣的方法,目前正在得到一些炒作是 Kanban . 它相当灵活。特别有趣的是,它允许应用“完成的工作”的度量标准。我还没有在实际工作中使用过/遇到过这种情况,但我想努力让我的工作中有一种看板式的流程。

有趣的是我刚刚读完了 PeopleWare 并且作者强烈反对让上级(甚至是直接经理)看到个别指标,但是这些指标的总和 应该 非常明显。

就特定于代码的度量而言,我认为对于团队来说,了解当前代码的状态以及随着代码的成熟和增长,了解影响代码的趋势是很好的。

这个问题显然没有集中在.NET上,但我认为.NET产品 NDepend 已经做了很多工作来定义和记录有用的公共度量。

这个 documentation section on metrics is educational 阅读,即使你不在做.NET。

软件指标已经和我们在一起很长时间了,作为最好的 无法判断到目前为止是否有个别或整体出现 能够在开发过程中指导项目。坚果 问题是我们想要使用客观的度量标准 只能测量发生了什么, 不是正在发生或即将发生的事情。

当我们测量、分析和解释 一系列的指标,我们对那些 已经出错了,或者偶尔会出错。 我不想低估学习的重要性 目标指标,但我确实想 指出这是一种反应而不是主动的反应。

制定“信心指数”可能是一种更好的监测方法。 这个项目是在进行中还是有麻烦。尝试 开发一个投票系统,其中 请各感兴趣的项目领域的代表 匿名投票 随时保持自信。信心有两个方面: 1)事情在轨道上2)事情将继续在轨道上或得到 回到正轨。 这些纯粹是来自最接近 “行动”。 将结果输入看板类型的图表,其中 列代表投票区域,而您 应该有一个很好的主意把你的注意力集中在哪里。使用 问题1:评估管理层是否对 上一个投票周期适当。使用问题2确定 管理层下一步应该关注的地方。

这个想法是基于我们每个人都有一个舒适的水平 在我们自己的责任范围内。我们的信心水平 是我们的经验和知识的产物 专业领域,问题的数量和严重程度 我们面对的是,我们必须完成的时间 任务,我们正在处理的信息的质量,以及 一大堆其他因素。

MBWA(步行管理)经常被吹捧为 我们拥有的最有效的工具之一——这是它的一个变体。

这种技术在 单个团队,因为它只反映总体情绪 团队成员。有点像用别人的手表告诉他们 时间。但是,在更高的管理层,它应该 要有相当的信息量。