您使用哪些衡量标准来改进流程？[关闭]

Question

这个问题最初是问“您在软件开发组织中使用什么 KPI”。不幸的是，似乎 关键绩效指标 是一个四个字母的单词，直接的假设是 KPI 总是被误用（也许是这样？）。

因此，我希望改进这个问题，以了解我最初认为 KPI 有用的基本目标。假设您（或您的组织）有一些如何开发软件的流程。其次，假设您（或您的团队）希望在开发和交付软件方面变得更好。最后，假设改进的方法之一是改进流程。

鉴于这一切，您如何知道您的流程改进是否产生了积极影响？如果这些是 关键绩效指标, ，或[智能目标](http://en.wikipedia.org/wiki/SMART_(project_management) 请提供您认为有效的单个或一组 KPI/SMART 目标。如果是其他机制，请解释它是什么。最后，我想，如果您认为改进流程不是一件有用的事情，我想您也可以解释一下。

我认为有用的改进领域是：质量、发布的及时性、生产力、灵活性。如果个人或开发团队还有其他方面的知识，那么了解这一点将会很有趣。

澄清注释：

问题不在于如何最好地适应或改变流程，也不在于什么是好的流程改进流程（无论是改善、回顾等）。它也不是关于根本原因分析或用于确定应改进流程的哪些具体方面的其他方法。

使用措施来确定是否已实现流程改进不应与正在进行的流程改进相混淆。（这是一件好事，但这不是问题的所在！）

这 过程 可以是任何东西；Scrum、敏捷、极端、瀑布、临时。这个问题不是关于哪种流程最适合某些类型的软件开发，而是关于如何随着时间的推移改进该流程。

显然，具体指标将取决于所涉及的流程以及试图改进的感知问题。这个问题只是为了获取所使用的指标的示例，这些指标显然涵盖了许多不同的流程和改进领域。

度量不一定是使用的东西 每时每刻, 例如，它可以在测试流程更改是否有效时使用。（例如，始终进行测量和跟踪可能会太昂贵（时间或金钱方面），因此您只需跟踪它就会调整流程）。

众所周知，如果实施不当，指标的使用可能会产生有害影响，因为开发人员会玩弄系统或其他方式。假设实施流程变更的人员已经意识到这个问题并已采取有效措施来缓解该问题。

所有软件组织都是不同的，它们融入公司的方式也不同，因此公司内部对它们的具体期望也不同，但我认为产品质量、生产力、灵活性和发布的及时性适用于大多数组织（如果不是所有组织）。（根据具体组织的不同，侧重点明显不同。）

这个问题与 源代码行！特别是，我对衡量程序员的生产力不感兴趣，尤其是在 SLOC 或修复的错误数量或任何其他幼稚的衡量方面。我对团队或个人衡量其进步的更高层次的方式感兴趣。我对使用单一 KPI 来衡量任何人的绩效不感兴趣。我 是 有兴趣使用一系列 KPI 来衡量和改进我团队的软件开发流程。

我知道有关 KPI 被滥用和无效的恐怖故事（您不需要非常努力地搜索它们），但我不敢相信没有人试图不断改进他们的流程，所以必须有一些 KPI 的好例子。

我非常了解应用于个体软件程序员的简单化指标的缺点。我真的希望获得人们认为有用的 KPI 或替代策略的示例，而不是我不应该使用 KPI 的所有原因。

我最感兴趣的是与大公司内的开发组织相关的流程和绩效，而不是整个软件开发公司。例如，软件公司应该确保产品具有适合市场的功能，但通常这是产品管理的角色，而不是工程的角色。是的，关于工程师为什么以及在多大程度上应该参与产品管理，还有一个完整的其他讨论，但这是一个单独的讨论。

Answer 1

到目前为止，最好的单个指示器“功能测试和交付接受”。在敏捷的世界里，我们通常测量的“用户故事”，术语“功能性”，但它可以是任何方便的形式，只要它是测量实际功能递送和测试，可接受给客户。

通常的其他措施，如SLOC，SLOC /员工小时，等会失败，因为管理的查理的第一定律，它是：

  

人们将提供一切他们   被奖励，提供

设置您的措施，SLOC，你会得到很多SLOC的。使用SLOC /小时，你会得到大量的SLOC / HT的。给他们的奖金加班，你会得到很多加班。

喔，并记住correlary，也：

  

什么人提供什么   他们认为将是值得的   递送

如果你没有得到你想要的东西，问为什么它的回报要做到这一点是越来越做的东西。

Answer 2

当我听到关键绩效指标时，我有点担心，因为通常接下来要做的事情是将绩效与奖励联系起来，然后你很快就会摆脱困境。我总是想起一家软件公司，该公司决定围绕错误修复建立奖励系统——测试人员因发现错误而获得奖励，开发人员因修复错误而获得奖励。由于围绕错误的插入、检测和纠正的黑市立即形成，开发陷入停滞。

您的组织 KPI 应该以客户为中心。根据您制作的软件产品的类型，您可以通过以下方式进行衡量：

• 销售 - 您的产品满足客户要求吗？您可以通过软件演示与销售的比率或网站购买页面的访问与实际购买的比率来衡量这一点
• 质量 - 您的软件易于理解且可靠吗？每个客户每天接到多少个支持电话？问题是关于如何做某事还是关于错误？
• 客户满意度 - 您的客户对您的产品的满意度如何？调查你的客户，找出你可以采取哪些措施来提高他们的满意度，然后稍后再次调查他们，看看你是否有所改进。（不要问太多问题或太频繁地惹恼你的客户）

是的，这些指标似乎与基本级别的软件指标（例如发现的错误和生成的代码行数）无关。然而，发现错误的问题是你必须对错误的严重程度进行分级，而重构通常会减少你的代码行数。仅当您满足客户对及时交货的期望时，及时性才重要。

专注于业务目标。如果您有客户购买您的软件，他们不需要太多支持就可以使用它并且他们很高兴，那么您的软件组织就是成功的。如果你没有做好这三件事，那么检测到的错误、进度表或其他任何事情的衡量标准都将变得无关紧要。

如果您的软件项目与大多数软件项目一样，那么它就会迟到、超出预算、交付的功能少于预期并且存在错误。不要因为这些事情而责备自己，解决它们并继续前进。是的，您需要错误数据库、源代码控制、测试和衡量项目速度的方法，但最终如果您达不到业务成果，那么您就无法成功，无论您的代码多么精美和闪亮以及如何它有几个错误。

更新 尝试解决修改后的问题

当交付无形产品（而且通常也是不断变化的目标）时，您希望使用的 KPI 会很困难。当您明年实施文档管理系统时，您今年在会计系统上使用的 KPI 是否具有相同的含义？

我们以一个广泛使用 KPI 的职业——律师为例。衡量律师使用的 KPI 包括：每天平均计费工作时间；按月计费的小时数；债务人分类账的年龄；未开票工作的平均年龄；注销费用的百分比；等等。您应该注意到这里的一个趋势 - 所有这些 KPI 都与客户是否愿意（或不愿意）为所提供的服务付费有关。这是成功的最终仲裁者，也是我建议（上面）一些方法的原因，您可以使用这种类型的测量作为软件业务的 KPI。

当您试图认真考虑与客户是否愿意为您提供的价值付费无关的 KPI 时，我们就会认真考虑我们正在衡量的内容、您如何衡量它以及它们之间存在哪些差异。与去年相比，今年的测量或测量内容。

“客户支付的美元”每年都有一个固定值——“软件错误”、“发布的及时性”和“灵活性”等任意指标没有固定值，KPI 的增加可能不会产生直接的影响。与 KPI 衡量的基本价值的关系，例如“错误越多意味着质量越低”。

例如，之后 哥伦比亚灾难, 我记得调查组提出了数百条建议和调查项目。这些新发现的“bug”是否意味着航天飞机的质量突然下降了很多？事实上，经过调查，航天飞机的质量更高。因此，围绕错误的 KPI 很容易被广泛的 QA 会议所扭曲，并且报告的错误越多，实际上可能意味着您的软件具有更高的质量。

发布及时性方面的生产力很容易受到商业因素的影响，例如客户向您砸钱，让您为他们进行一些定制开发。您的发布时间表将会推迟，但您的业务将会改善。

至于灵活性，我什至无法猜测如何衡量如此无形的东西。

我能想到的唯一对客户钱包有价值的衡量标准是 项目速度 - 我们预计上次迭代/周期/发布会完成多少工作，以及我们实际完成了多少工作？然后将此数字代入下一次迭代/周期/发布的可用时间，以估计这次您可能能够完成多少工作。您可以显示剩余时间 燃尽图 或迭代过程中类似的情况。

其余的都归结为流程，我认为您无法将其固定为 KPI。您所能做的就是确保您的开发人员知道每个人在做什么（每日开发人员会议），您的扩展团队获得输入（每周或每两周一次的团队会议），您了解上次哪些有效，哪些无效（回顾），最重要的是你们有透明有效的沟通。

不幸的是，我认为没有像您所追求的任何神奇的 KPI（但不要忽视从客户那里获得资金作为 KPI 的相关性）。

Answer 3

本诺，我回答您的意见，但对答案没有足够的文字呢。

这取决于你要解决的问题。例如假设的问题是，从当代码开发人员的检查，直到它实际上是放在生产的时间似乎太长了。然后，你会得到它正在有多长基线测量。那么你会放在你的变化，然后测量一段时间，看它是否需要较少的时间。你也可以检查类似的时间确定的解决方案不工作的数量和发回返工之前和之后，以及确保该解决方案并不快，但质量较低。

现在用这些测量在IT的问题是，它可能需要相当长的一段时间来积累足够的数据，有些问题不会频繁地重新出现。在这种情况下，你可能必须依靠主观数据开始，直到你可以积累足够的数据来知道变化是好还是不好。但是，如果事情是，直到用户已经习惯了它的改进不问。一个新的进程的第一个星期或两个，你会遇到阻力变化，因此，如果你问得太早会得到不好的结果，主观

警惕的另一件事是，如果人们知道你正在测量的东西，他们将他们的个人业绩进行测量，从而将游戏的系统，以获得良好的效果害怕。它往往是最好的，如果你可以根据某些系统上进行测量已经到位（我们有一个软件修改管理要求AA制，我们可以查询数据库，找出许多请求历史如何错过了最后期限，我们是经过多少重开关闭或涉及到过去的请求等，其开发整理和代码之间的时间差被移动到生产等都是）。您可能还需要考虑消除严重的异常，特别是当时间跨越两个新旧系统的时间。例如，我们有一个要求，即已经在QA超过100几天没becasue它是坏的，而是因为QA有avaliability的问题，这是一个最低优先级，因此不断得到撞更高prioroity工作。这一次不会是测量时间的改进，becasue使时间这么长的因素可贵的是不是你正在尝试修复的过程。如果图中的数据，你会很容易看到，可能需要剔除异常值。

Answer 4

立足左右的成本，质量和进度的关键绩效指标将是一个良好的开端。考虑什么是每个你所要测量的属性。

如果能够拆分每项措施，以显示错误的成本将是有益的 - 大量的bug修复工作在项目后期意味着成本/进度井喷。能够分析哪些代码库的部分是越野车能够靶向额外的测试和可能的代码重新写帮助 - 通常是错误的80％将来自码的20％。知道哪里是可以让你的团队更好地集中。

修改：看像质量（辅酶Q）的成本和低质量（COPQ）的成本的措施。

，如生产力的措施总是很难量化 - 例如，使用LOC /天导致约究竟是一个代码在线辩论？它也可以导致愚蠢的代码格式化为“升压”生产力如果开发商不明白为什么这些东西正在被跟踪或者认为他们的量度。即使LOC /天没有在开发水平上测量，你仍然可以得到球队的竞争导致了同样的结果。

编辑：有史蒂夫·麦康奈尔的 Construx 网站上可以找到一些很好的讨论。 [对，就是代码完成名声的史蒂夫奈尔]

Answer 5

没有过程会帮助你提高，除了实际上得到大家一起搞清楚什么是工作，什么是不工作你做什么。对于球队我目前领先的，我们这样做是通过一系列的作品回顾展（其中我强烈推荐的）。球队一般都知道他们要改进的地方部分 - 诀窍就是给他们权力实际测量和改进这些事情

。

是的，你肯定还是需要有人在看宏观层面。如果你看看像丰田的组织，他们有一个总工程师谁横跨商业和生产（之间的线一个很好的解释，参见Scott Bellware的的博客文章）。在我们的组织，我们有相似的人 - 我的老板是我们的产品最初开发一个近20年前，并在技术方面保持高度活跃，但投入巨资在客户端也是如此。我的工作也为球队看成一个整体，提出改进意见。

要衡量，我们首先要确保我们努力改进的任何事情，我们的团队能真正改变，然后用一个类似于到的 SMART目标的，以便任何改进是可测量的。我们有一个大，可视墙我们从回顾发布的注意事项。这恰好也是我们保持我们的日常站立会议，所以这给了我们专注于正在发生的事情。

有关统计数据汇总到我们的行政会议上，我们注重的代码提交 - 代码没有行交付。我故意踢出球队断测量模糊不清单元这意味着我们不报道了，我们工作数小时或数天，或任何x个。他们做了什么看到的是我们如何提供我们的特点，以及我们如何被提高的趋势图。我们还将包括有趣的花絮，当团队认为他们想要分享。

有关这一切的最好的部分是，我们可以尝试的东西了一个月，然后只需4周后重新评估它。这对于尝试新事物产生更低的门槛，因为他们也知道，如果它正在影响他们，我们就可以立即取消它，否则我们将重新评估并找到下一个回顾性更好的方式。

坏的部分是，它不完全是你在找什么。没有一个指标或一组指标，我们不断地遵循。看趋势，在任何时候，和衡量我们认为是有趣的 - 但只有一点点，只有当团队正着手实现的，因为他们的具体目标。但在一般情况下，我与它的工作原理很高兴，我已经看到在改善的过程中团队的参与显着改善。我们不太持续改善，但我们每天都在好起来。

Answer 6

我没有专业的14年过程改进。这里是我的建议，停止尝试量化，并开始与人交谈。测量工作正常针对特定问题（一旦你知道的问题，你有更好的想法是什么来衡量）和像制造repeatble过程。你的人确切地知道问题出在哪里地区，所以做你的客户和用户（从一个非常不同的角度）。流程图（使用工业工程符号不是计算机编程符号）出实际的过程，其中有顾虑的区域（不是我们装过程中，您将需要观察和提问）。一旦你看到过程的全流程看延误，所在区域的工作是重复的，地方有不必要的进程（通常是由于加入了更多的过程步骤来解释人类的错误，从而为人类更多的潜在领域错误）。质疑每一步是否有更好的方法做每一步的需要。测试潜在的变化，看看是否其实他们是imporvement（太多次，他们会使情况变得更糟而不是更好）。不要在任何情况下得到一个感受的问题，或当流量图表时只跟经理。你不会得到一个真实的画面，从而将解决错误的问题。

Answer 7

了解浪费和价值流图会告诉你，你需要做出改进，并通过这些知识，您将了解你需要什么来衡量。精益和看板原则适用于此。了解垃圾和它在软件生产的影响将开始你失望的具体路径，以改善是必然特定于组织。你不能采取千篇一律的做法。阅读（或听）“目标”和“精益思想”为更多关于这真是太神奇了，并开眼界了什么问题以及如何解决它的观点。

Answer 8

对于关键绩效指标的最佳用途是用于驱动（或转向，如果你愿意）。对于实时的航向校正。

（参见仪表板是用于驱动了解喋喋不休了解这个子。主题买者：我是喋喋不休文章的作者）

所以，问题回到你的是：你想评价的事实的后性能的当它的来不及做这件事的东西，或者是你试图找到关键绩效指标，可以帮助你的留在课程的？

如果是前者，任何指标你的组织关心（Bug数，船日期延误，与意见，客户退货百分比等行代码），将被罚款。测量路程，好运气让航运产品和升级之间更好; - ）

如果是后者，选择速度。假设使用的是测试驱动开发（TDD）当然。

编辑：所以这是前者。那么，这里就是为什么你可能是出于运气：

假设你决定“质量”最好是通过测量顾客为你的后处理KPI报告的错误的数量进行量化。让我们假设你正在使用TDD，并说你的团队提供6个月产品＃1，和6个月的中后场，你发现你有10个用户报告的错误。所以，现在，究竟是什么，你打算怎样提高你的过程？测试吗？专门针对更像报告的错误的原因的东西测试？在我看来，你应该已经测试，当错误被发现 - 无论是客户还是没有 - 你添加一个回归测试的特定错误和额外的单元测试，以确保不再有类似的错误。换句话说，的您的后期工艺改进响应不会比你在过程改进响应的不同，所以这个KPI是在提高你的过程中没有显著的帮助真的。问题的关键是，在您改善过程的方式仍然是一样的，不管错误是否被发现发布后6个月，两天到的编码。因此，尽管这可能是一个闪亮的KPI穿上经理的墙壁或一个部门的通讯，它真的不会改变你的流程改进机制。 （和小心把太多的股票在这个KPI，因为它可以通过你无法控制的因素的影响，疯狂的！）。总之，的知道臭虫的数量并不能帮助你提高的。

（这里有另一种危险，一个常见的不仅仅是在做生意，而且在军事上，那就是事后分析发现有价值的信息的错觉，所以教训验尸正在积极应用到下一个项目，这可能是不一样的最后一个项目的。这被称为“战斗的最后一战”。）

假设客户退货/退款的号码是您的“质量”选择的KPI - 如果这个数字是5，这是什么告诉你吗？为什么客户要求退款可能是质量问题的一些指示的具体原因（“太慢了”，等“不与XYZ系统接口”），但的此类事件的单纯的号码告诉你什么。针对预期收益率方差可能会告诉你，如果质量提高，但同样的的数量并不能帮助你提高的。你需要比数的详细信息可以给你。

因此，对于“发布的及时性”是什么测量将是适当的？船日期延误的天数？根据最初的估计百分比溢出？ 没关系的，因为再次的数字不会帮助你改善的。

如果你能衡量“生产力”的产品完成后，那么你也许可以衡量它，而产品正在开发（例如速度），所不同的是生产率小于开发期间预期而显影后测得的整体生产力数目完成过毛可以立即改善，也平均化，而没有任何用途的。人们只能猜测为何低于预期6个月后...

我不知道人们可能会如何衡量“灵活性”，这听起来像营销术语; - ）

我希望我没有捣烂这个指甲太硬或太远，但我不认为有任何的有用的，你可以测量后 - 事实上，你无法衡量< EM>而进行。并且也有很多后 - 事实测量的是不知道的原因无用。

Answer 9

您可以得到很多有关KPI的理念和仪表盘在的 http://www.dashboardzone.com

它已通过产业及功能区的KPI。