我最近就软件开发指标进行了一些有趣的对话，特别是它们如何在一个相当大的组织中使用，以帮助开发团队更好地工作。我知道有一些关于哪些指标可以使用的Stack Overflow问题 - 比如this one，但我的问题更多的是关于哪些指标对哪些指标有用对哪些利益相关者，以及聚合程度。
作为一个例子，我的观点是代码覆盖率在以下方面（以及其他方式）是一个有用的指标：
但我不认为高级管理人员在逐个团队的基础上看到这一点是有用的，因为这鼓励人为尝试通过仅仅运动的测试来支持覆盖，而不是测试，代码。
我所在的组织在其管理层次结构中有几个层次，但绝大多数管理人员都具有技术头脑和能力（许多人仍然沾沾自喜）。一些开发团队在推动敏捷开发实践方面处于领先地位，但其他开发团队则落后，现在有一个严格的要求从最高层开始，以便组织的工作方式。我们中的一些人正在启动一项计划来鼓励这一点。在这种组织中，您认为哪种指标有用，对谁，为什么以及在什么级别的聚合？
我不希望人们根据他们可以人为影响的指标来评估他们的表现。与此同时，高级管理层将需要某种证据证明正在取得进展。根据您自己组织的经验，您可以提供哪些建议或警告？
修改
我们绝对希望将指标用作组织改进的工具，而不是作为个人绩效衡量的工具。
答案 0 :(得分：46)
答案 1 :(得分：18)
关于指标的关键是知道你正在使用它们。您是否将它们用作改进工具，奖励工具，惩罚工具等等。听起来您计划将它们用作改进工具。
设定指标时的首要原则是保持信息的相关性，以便接收信息的人可以使用它来做出决定。很可能高级经理无法决定你是否需要更多测试，更少复杂性等微观层面。但团队领导者可以做到这一点。
因此，我认为代码覆盖率不会对个别团队以外的管理有用。在宏观层面，该组织可能对以下内容感兴趣：
内部质量在他们要掩盖的事物清单中不会很高。开发团队的使命是明确内部质量（可维护性，测试覆盖率，自我记录代码等）是实现其他三个的关键因素。
因此，您应该将指标定位到更高级的管理人员，这些管理人员会覆盖这三个，例如：
在团队级别测量代码覆盖率，代码复杂度，削减'n'粘贴分数（使用flay或类似代码重复代码），方法长度等等，信息的接收者可以真正发挥作用。
答案 2 :(得分：4)
指标是回答有关项目，团队或公司的问题的一种方式。在开始寻找答案之前，您需要确定要问的问题。
典型问题包括：
我们的代码质量如何？
质量会随着时间的推移而提高或降低？
团队效率如何？是改善还是有辱人格？
我们的测试效果如何？
......等等。
每个问题都需要一组不同的指标才能回答。在不知道您想要回答什么问题的情况下收集指标最多只是浪费时间，最坏的情况是适得其反。
你还需要意识到工作中存在“不确定性原则” - 除非你非常小心，收集指标的行为会改变人们的行为，通常是出乎意料的，有时甚至是有害的。如果人们认为他们正在评估指标，或者更糟糕的是仍然将指标与某些奖励或惩罚计划相关联，那么尤其如此。
我建议阅读Gerald Weinberg的Quality Software Management Vol 2: First Order Measurement。他详细介绍了软件指标，但他说最重要的通常是他所谓的“零订单计量” - 询问人们对项目进展情况的看法。该系列中的所有四卷都很昂贵且难以掌握，但非常值得。
答案 3 :(得分：3)
软件编写
CPU使用，内存使用，内存缓存使用，用户时间使用，运行时代码大小，运行时数据大小，图形性能，文件访问性能，网络访问性能，带宽使用，代码简洁性和可读性，电力使用，（计数）使用的不同API调用，（计数）使用的不同方法和算法，可能更多。
必须优化通过验收测试，便于维护，便于审核和满足用户要求所需的最低合理数量（超出验收测试标准的区域除外）。
（“...适用于所有当前和未来测试集成方案的所有测试数据量和测试请求量的所有测试状态下的合法/非法输入测试数据和合法/非法测试事件。”）
因为优化的代码更难编写，因此成本更高。
编码标准，基本结构，验收标准和所需优化级别的指导。
如何衡量软件写作的成功？
在评估程序员的总体效果时应忽略哪些成本/时间？
但是这个成本/时间应该包含在评估团队（包括建筑师，经理）的总体绩效中。
如何衡量建筑师的成功？
其他措施加：
答案 4 :(得分：2)
正如我在What is the fascination with code metrics?中所说，指标包括：
我们正在使用能够提供的工具：
结果是一个可以深入分析的分析，从高级聚合域（安全性，体系结构，实践，文档......）一直到某些代码行。
目前的反馈是：
所以：
哪些指标对哪些利益相关方有用，以及在什么级别的聚合
高层：
较低级别：
答案 5 :(得分：2)
如果您有一些精益背景/知识，那么我会建议使用Mary Poppendieck recommends的系统（我已在此previous answer中提到过）。该系统基于三个整体测量，必须作为一个包：
聚合级别是产品/项目级别，我相信这些指标对每个人都有帮助（开发人员永远不要忘记他们不是为了好玩而编写代码，他们编写代码来创造价值和应始终牢记这一点）。
团队可以（并且实际上）使用技术指标来衡量质量标准一致性，这些一致性被整合到“完成定义”中（“不增加技术债务”）。但高质量本身并不是目的，它只是实现短周期时间（成为一家快速公司）的一种手段，这是真正的目标（具有商业案例实现和客户满意度）。
答案 6 :(得分：2)
这是对主要问题的一点注意事项，但我与Paul Stephensons的回答非常相似。我要补充的一件事是关于数据的收集和指标的可见性。
在我们的案例中，开发总监的目的是整理来自各种不同系统的大量数据，并每月分发一次单独的度量标准结果。这通常不会发生，因为这是一项耗时的工作而且他是一个忙碌的人。
结果如下：
不满意的开发者，因为绩效奖金是基于指标而且人们不知道他们是如何进行的。
多次将数据输入各种不同的系统需要花费一些时间。
如果您沿着这条路线走下去，您需要确保所有公制数据都能自动整理，并且对那些影响的人很容易看到。
答案 7 :(得分：1)
目前正在进行一些炒作的有趣方法之一是Kanban。它相当敏捷。特别有趣的是它允许应用“完成工作”的度量。我还没有在实际练习中使用/遇到过这个问题，但是我想努力让看板上的工作流向我的工作岗位。
答案 8 :(得分：1)
有趣的是，我刚读完PeopleWare，作者强烈反对让上级（甚至是直接经理）看到个别指标，但聚合指标应该非常明显。
就代码特定指标而言，我认为团队最好知道当前代码的状态，并了解影响代码成熟和发展的趋势。
问题显然不是专注于.NET，但我认为.NET产品NDepend已经做了很多工作来定义和记录有用的常用指标。
documentation section on metrics is educational读数，即使您没有使用.NET。
答案 9 :(得分：1)
软件指标已经在我们这里使用了很长时间 到目前为止，任何事情都无法单独或汇总地出现 能够在开发过程中指导项目。的坚果 问题是我们想要使用客观的措施和这些措施 只能衡量发生的事情， 不是发生或即将发生的事情。
当我们测量，分析和解释一些时 一系列指标我们正在对这些事情做出反应 已经出错了，或偶尔出错了。 我不想低估学习的重要性 客观指标，但我确实想 指出这是一种反应而非主动反应。
制定“置信指数”可能是一种更好的监控方式 项目是否正在进行中或遇到麻烦。尝试 建立一个合理数量的投票系统 询问每个感兴趣的项目区域的代表 匿名投票他们的 从时间到信心。信心在两个方面投票： 1）事情正在进行中2）事情将继续在轨道上或获得 回到正轨。 这些是来自最接近的人的纯粹主观测量 “行动”。 将结果反馈到看板类型图表中 列代表投票区域和你 应该有一个非常好的主意在哪里集中你的注意力。使用 问题1评估管理层是否对此作出反应 之前的投票周期恰当。使用问题2来识别 管理层应该关注的重点。
这个想法是基于我们每个人都有一个舒适的水平 在我们自己的责任范围内。我们的信心水平 是我们经验，知识的产物 专业领域，问题的数量和严重程度 我们正面临着，我们必须完成的时间 任务，我们正在使用的信息的质量和 一大堆其他因素。
MBWA（走路管理）经常被吹捧为 我们拥有的最有效的工具之一 - 这是它的一个变种。这种技术在水平上没有多大用处 个人团队因为它只反映了一般情绪 的团队。有点像用某人的手表告诉他们 时间。但是，在更高的管理水平上它应该 非常有用。