这个问题最初是在询问“你在软件开发组织中使用什么KPI”。不幸的是，似乎 KPI 是一个四个字母的单词，并且直接的假设是KPI总是被误用（也许它们是？）。
所以，我希望能够改进这个问题，以实现我最初认为KPI有用的基本目标。假设您有一些流程来说明您（或您的组织）如何开发软件。其次假设您（或您的团队）希望在开发和交付软件方面做得更好。最后，假设改进的方法之一是改进您的过程。
鉴于这一切，您如何知道您的流程改进是否产生了积极影响？如果这些是 KPI 或[SMART目标]（http://en.wikipedia.org/wiki/SMART_(project_management)，请提供您认为有效的KPI / SMART目标的个人或团体。如果是其他机制，请解释它是什么。最后，我想，如果你不认为改进过程是有用的，我想你也可以解释一下。
我认为有用的改进领域是：质量，发布的及时性，生产力，灵活性。如果个人或开发团队的其他方面，那么知道这将是有趣的。
澄清笔记：
问题不在于如何最好地适应或改变一个过程，或者一个好的过程改进过程（无论是Kaizen，回顾等）。也不是关于根本原因分析或用于确定应该改进过程的哪些具体方面的其他方法。
使用措施来确定是否已实现流程改进，不应与正在进行的流程改进相混淆。 （这是一件好事，但这不是问题所在！）
进程可以是任何东西; scrum，敏捷，极端，瀑布，ad-hoc。这个问题不是关于哪种过程最适合某些类型的软件开发，而是关于如何随着时间推移改进该过程。
显然，具体指标将取决于所涉及的流程以及试图改进的感知问题。这个问题只是为了获得使用的指标的例子，这显然会跨越许多不同的流程和改进领域。
度量标准不一定是一直使用的东西，例如，它可以在测试过程变更是否有效时使用。 （例如，在任何时候进行测量和跟踪都可能太昂贵 - 无论是时间还是金钱 - 因此您只需跟踪它就会调整过程。）
如果实施不当，使用指标可能会对开发人员游戏系统或其他方面产生不利影响。假设实施流程更改的人员已意识到此问题，并已采取有效措施来缓解此问题。
所有软件组织都有所不同以及它们如何适应公司，因此公司内部会有不同的具体内容，但我认为发布的产品质量，生产力，灵活性和及时性适用于大多数情况所有组织。 （明显不同的重点取决于具体的组织。）
此问题与源代码行无关！特别是，我对测量程序员的工作效率不感兴趣，特别是在SLOC或固定的错误数量或任何其他天真的测量方面。我对团队或个人衡量他们改进的更高层次方式感兴趣。我对使用单个KPI来衡量任何人的表现并不感兴趣。我我有兴趣使用一系列KPI来衡量和改进我的团队的软件开发流程。
我知道关于KPI被滥用和无效的恐怖故事（你不需要非常努力地找到它们），但我无法相信没有人试图不断改进他们的流程，所以必须有一些很好的KPI示例。
我知道应用于各个软件程序员的简单指标的缺点。我真的希望得到人们认为有用的KPI或替代策略的例子，而不是我不应该使用KPI的所有原因。
我最感兴趣的是与大型公司内的开发组织相关的流程和性能，而不是整个软件开发公司。例如，软件公司应该确保产品具有适合市场的功能，但通常是产品管理的角色，而不是工程。是的，关于工程师应该参与产品管理的原因和程度，还有一个完整的其他讨论，但这是一个单独的讨论。
答案 0 :(得分：8)
答案 1 :(得分：6)
到目前为止，最好的单一指标是“测试功能已交付和接受”。在敏捷世界中，我们通常根据“用户故事”来衡量“功能”，但它可以采用任何方便的形式，只要它能够测量交付和测试的实际功能，并为客户所接受。
通常的其他措施，如SLOC，SLOC /员工小时等，由于查理的第一管理法律而失败，即：
人们会提供他们所能做的一切 得到回报。
将您的度量设置为SLOC，您将获得大量SLOC。使用SLOC / hr，你会得到很多SLOC / ht。给他们加班的奖金，你会得到很多加班费。
哦，还记得相关内容：
人们提供的是什么 他们认为会有所回报 递送
如果你没有得到你想要的东西，那就问为什么做完这些事情会有所回报。
答案 2 :(得分：2)
Benno，我正在回答你的评论，但没有足够的人物来回答。
这取决于您正在解决的问题。例如，假设问题是从开发人员检查代码到实际投入生产的时间似乎太长。然后，您将获得一个基准测量值，表明它需要多长时间。然后你会投入你的变化，然后测量一段时间，看它现在是否需要更少的时间。您还可以检查解决方案被确定为无法工作的次数，并在之前和之后返回返工以确保解决方案不会更快但质量更低。
现在，使用这些测量结果的IT问题是，由于某些问题不会频繁发生，因此可能需要相当长的时间来积累足够的数据。在这种情况下，您可能必须首先依赖主观数据，直到您可以积累足够的数据来了解更改是否良好。但是，在用户习惯之前，不要问是否有什么改进。在新流程的第一周或第二周，您将遇到阻力变化，因此如果您过早地提出要求会产生糟糕的主观结果。
另一件要警惕的事情是，如果人们知道你在测量某些东西，他们会害怕他们的个人表现正在被衡量，因此会对系统进行游戏以获得良好的效果。通常最好是你可以根据现有的某个系统进行测量（我们有一个管理软件变更请求的系统，我们可以查询数据库，找出错过最后期限的请求数量，以及我们重新开放的数量关闭或与过去的请求等相关，开发人员完成和移动到生产等的代码之间的时间差是多少。您可能还必须考虑消除严重的异常值，特别是如果时间跨越旧系统和新系统的时间段。例如，我们有一个请求已经在Qa超过100天而不是因为它是坏的但是因为质量保证有可用性问题而且这个问题是最低优先级因此它不断受到更高的优先级工作的影响。这个时间对于衡量时间的改善没有价值，因为这个时间长的因素并不是你想要解决的过程。如果您绘制数据图表，您将很容易看到可能需要排除的异常值。
答案 3 :(得分：1)
根据成本，质量和成本来制定关键绩效指标时间表将是一个良好的开端。考虑每个要测量的属性的属性。
能够分割这些措施以显示错误的成本将是有用的 - 项目后期的许多错误修复工作意味着成本/进度井喷。能够分析代码库的哪些部分是错误的，可以帮助定位额外的测试＆amp;可能的代码重写 - 通常80％的错误来自20％的代码。了解它的位置将使您的团队更好地专注。
编辑：查看质量成本（CoQ）和劣质成本（CoPQ）等指标。
像生产力这样的衡量标准总是难以量化 - 例如，使用LOC / day会引发关于一行代码究竟是什么的争论？如果开发人员不理解为什么跟踪这些东西或将其视为个人测量，它还可能导致愚蠢的代码格式化以“提高”生产力。即使未在开发人员级别测量LOC /日，您仍然可以获得团队竞争，从而产生相同的结果。
编辑：Steve McConnell的Construx网站上有一些很好的讨论。 [是的，这就是代码完全成名的Steve McConnell]答案 4 :(得分：1)
没有任何流程可以帮助您改善您所做的事情，除非实际上让每个人都在一起并弄清楚什么是有效的，什么是无效的。对于我目前领导的团队，我们通过一系列回顾来做到这一点（我强烈推荐this book）。团队通常知道他们想要改进哪些部分 - 诀窍是赋予他们实际测量和改进这些东西的能力。
是的，你当然还需要有人在寻找宏观层面。如果你看一下像丰田这样的组织，他们就会有一位总工程师跨越商业和生产之间的界限（有一个很好的解释，请参阅Scott Bellware的blog post）。在我们的组织中，我们有类似的人 - 我的老板是近20年前我们产品的最初开发人员之一，并且在技术方面保持高度活跃，但也在客户方面投入了大量资金。我的工作也是看整个团队提出改进建议。
为了衡量，我们首先要确保我们努力的任何改进都是我们团队实际可以改变的事情，然后使用类似于SMART goals的东西，以便任何改进都是可衡量的。我们有一个Big, Visible Wall，我们会在回顾会上发布这些笔记。这恰好也是我们每天站立的地方，所以它让我们专注于正在发生的事情。
为了向我们的执行会议汇总统计数据，我们专注于代码交付 - 而不是提供的代码行。我故意将团队踢出nebulous units，这意味着我们没有报告我们工作了x个小时，几天或者其他什么。他们看到的是一个趋势图表，表明我们如何提供我们的功能以及我们如何改进。当团队觉得他们想要分享它时，我们还会包含有趣的花絮。
关于所有这一切的最好的部分是我们可以尝试一个月，然后在4周后重新评估它。这为尝试新事物创造了更低的门槛，因为团队知道如果影响他们，我们将立即取消它，或者我们将在下一次回顾中重新评估并找到更好的方法。
不好的一点是，它并不是你想要的。我们不断遵循一个指标或一组指标。我们始终关注趋势，并衡量我们认为有趣的趋势 - 但仅限于一点点，并且只有在团队开始实现特定目标的时候才会这样。但总的来说，我对它的运作方式非常满意，并且我看到团队参与改进流程的情况有了明显改善。我们不是Kaizen，但我们每天都在变得更好。
答案 5 :(得分：1)
我专业地进行了14年的流程改进。这是我的建议，不要试图量化并开始与人交谈。测量适用于特定问题（一旦您知道问题，您可以更好地了解测量内容）以及制造等可重复的过程。您的员工确切地知道问题所在的位置，您的客户和用户也是如此（从非常不同的角度来看）。流程图（使用工业工程符号而不是计算机编程符号）表示存在问题的区域的实际过程（不是我们假装过程是什么，您需要观察并提出问题）。一旦你看到流程的整个流程都在寻找延迟，工作重复的区域，那里存在不必要的流程（通常是由于为流程增加了更多的步骤来解决人为错误，从而为人类创造了更多潜在的领域错误）。质疑每个步骤的必要性以及是否有更好的方法来完成每个步骤。测试潜在的变化，看看实际上它们是否是一种变形（太多次，它们使情况变得更糟，而不是更好）。在任何情况下，在遇到问题或流程图时，都不要只与经理交谈。你不会得到真实的图片，因此会解决错误的问题。
答案 6 :(得分：1)
了解废物和价值流图谱将向您显示您需要进行改进的地方，从这些知识中，您将了解需要衡量的内容。精益和看板的原则适用于此。了解浪费及其对生产软件的影响将使您了解改进的具体路径，这种路径不可避免地特定于您的组织。你不能采取千篇一律的方法。阅读（或倾听）“目标”和“精益思维”，了解更多关于错误和如何解决问题的惊人和令人瞩目的观点。
答案 7 :(得分：0)
关键绩效指标的最佳用途是驾驶（或转向，如果您愿意）。对于实时校正。
（请参阅Dashboards are for Driving了解更多关于这个子主题的内容。告诫：我是这篇文章的作者。）
所以，回答你的问题是：你是否试图在之后评估性能，当为时已晚做任何事情，或者你是试图找到可以帮助你保持正确的KPI？
如果是前者，您的组织关注的任何指标（错误计数，发货日期延误，带注释的代码行，客户退货百分比等）都可以。在运输产品和升级之间进行衡量并获得更好的运气; - ）
如果是后者，请选择velocity。假设您正在使用测试驱动开发（TDD）。
编辑：所以这是前者。好吧，这就是你可能运气不好的原因：假设您通过衡量客户报告的错误数量作为您的后处理KPI来确定“质量”是最佳量化的。假设您正在使用TDD，并说您的团队在6个月内交付产品＃1，并且在现场6个月后您发现您有10个客户报告的错误。那么现在你要做些什么来改善你的过程呢？测试更多？是否针对更多内容进行了测试，例如报告错误的原因？在我看来，您已经在测试，并且当发现错误时 - 无论是否由客户 - 您为特定错误和其他单元测试添加回归测试，以确保没有更多类似的错误。换句话说，您的流程后改进响应与您的流程内改进响应没有什么不同，因此此KPI对改进流程没有任何重大帮助。重点是，无论是在发布后6个月还是在编码后两天发现错误，您改进流程的方式都保持不变。因此，虽然这可能是一个闪亮的KPI，可以放在经理人的墙上或部门时事通讯上，但它确实不会改变你的流程改进机制。 （并注意在此KPI中投入过多的股票，因为它可能会受到您无法控制的因素的极大影响！）。简而言之，知道错误的数量并没有帮助您改进。
（这里还有另一个危险，一个不仅在商业中而且在军队中也常见，这就是验尸分析揭示了有价值信息的错觉，因此验尸后的经验教训被大力应用于下一个项目，可能与上一个项目不一样。这被称为“打击上一场战争”。）
假设客户退货/退款的数量是“质量”的首选KPI - 如果此数字为5，这会告诉您什么？客户要求退款的具体原因可能是质量问题的一些迹象（“太慢”，“不与XYZ系统接口”等），但仅此类事件的号告诉什么都没有与预期回报百分比的差异可能会告诉您质量是否有所改善，但该数字无法帮助您改进。您需要的信息量超过号码可以提供的信息。
那么对于“发布的及时性”，哪种测量方法合适？发货日期滑点的天数？根据原始估计值超支的百分比？ 没关系，因为再次这些数字无法帮助您改进。
如果您可以在产品完成后测量“生产率”，那么您可以在产品开发过程中测量它（例如速度），不同之处在于可以立即提高开发过程中的生产率，同时提高整体效率开发完成后测量的生产率数字太粗糙，太平均，无任何用途。人们只能猜测为什么它在6个月之后低于预期......
我不知道人们如何衡量“灵活性”，这听起来像营销术语; - ）
我希望我没有把这个指甲砸得太厉害或太远，但我不认为有什么有用的可以衡量你无法衡量的事实< em>正在进行中。并且有许多事后测量在没有了解原因的情况下是无用的。
答案 8 :(得分：0)