想知道如何衡量开发人员的生产力？甚至有可能吗？阅读此处并找到十种创造性的方法来衡量开发人员的生产力并提高团队的效率。花椒壳-愿您平安健康

彼得·德鲁克曾说过一句名言：“得到衡量，得到管理。” 在当今竞争激烈的商业环境中，高管、利益相关者和项目经理都希望尽可能多地进行衡量。在许多情况下，这是正确的。观察指标可以让您了解自己在哪些方面表现良好以及哪些方面可以改进。指标向您展示您的团队或业务的哪些部分可以更高效，而如今效率比以往任何时候都更加重要。客户期待更多功能，项目变得越来越复杂，预算似乎在不断缩减。

将所有这些结合起来，企业想要衡量软件开发人员的生产力也就不足为奇了。但是真的可以衡量开发人员的生产力吗？有些人甚至认为 开发人员的生产力是一个神话。虽然可能很难通过代码行数或工作时间等传统指标来确定开发人员的工作效率，但还有其他可能的创造性方法来衡量开发人员的工作效率。通过正确关注并利用以下提示，您可能会发现开发人员的工作效率有所提高。阅读以下内容，了解如何衡量以及如何不衡量开发人员的生产力。   花椒壳-愿您平安健康

一些不衡量开发人员生产力的方法

组织和企业一直试图以多种方式衡量开发人员的生产力。以下是一些更传统的方法，它们并不总是能够对开发人员的生产力进行最佳分析。 花椒壳-愿您平安健康

工作时间

从表面上看，这似乎是衡量生产力的一种显而易见的方法。更多的时间意味着更高效的开发人员，对吧？不必要。最有生产力和效率的开发人员可以解决更复杂的问题，而且他们比生产力较低的开发人员可以更快地解决问题。

跟踪时间不仅是衡量开发人员生产力的一种糟糕方式，而且大量的时间实际上会导致生产力下降。当人们过度工作时，多项研究表明工人的生产力会降低。此外，随着工人开始变得紧张和筋疲力尽，更长的工作时间会导致士气下降。当我们使用工作时间来衡量开发人员的工作效率时，永远不会有足够的时间。尽量避免这个指标。

源代码行

与工作时间一样，从表面上看，这似乎是衡量开发人员生产力的另一种明显方式。一些项目经理和团队领导可能认为开发人员的生产力越高，他或她在给定的时间内可以编写的代码行数就越多。但是，与工作时间一样，这不一定正确。与成百上千的代码相比，更高效的开发人员可能能够用几行代码来制定解决方案。同样，问题的解决方案有时可能是删除代码行。

而且，与工作时间一样，将代码行作为衡量开发人员生产力的指标可能会适得其反。开发人员可能有意或无意地发现自己添加了额外的代码行只是为了看起来“更有效率”。随着工作人员加快他们的代码行速度，您也可能会开始发现更多错误，这一切都本着开发人员生产力的精神。测量代码行数可能会让您了解系统的复杂性，但这并不是衡量开发人员生产力的最佳指标。

故事要点和估计

敏捷故事点是相对度量单位，由软件开发 Scrum 团队决定，用于提供完成需求所需难度的相对估计。难度可能与复杂程度、所涉及的风险或所需的努力程度有关。

敏捷故事点可帮助团队估计完成项目特定部分所需的难度级别。这很重要，因为敏捷项目复杂且进展迅速，预测越准确，项目成功的可能性就越大。随着时间的推移，开发团队可以找到他们的平均速度，使他们能够做出更准确的估计。故事点和速度有助于开发团队衡量他们在冲刺或项目中的移动速度，但它们并不总是衡量开发人员生产力的最佳选择。

一方面，故事点是估计值，这些估计值因团队而异。一个团队将其视为一个故事点，而另一个团队将其视为两个或多个故事点。这是否意味着第一个团队更有效率？此外，理想情况下，随着时间的推移，团队将变得更加协作，并在冲刺或项目中更快地移动。简而言之，他们会找到一种节奏，虽然在短期内他们可以将这种节奏视为生产力的提升，但随着团队更好地预测他们的工作量，速度将开始趋于平衡。他们可能会根据自己的生产力开始调整故事点级别。

因此，就速度而言，稳定的平均速度可以被视为相对于不断提高速度的团队的优势。一个团队协作并全力以赴，但保持稳定的速度测量，实际上可能比另一个具有“更高”速度测量的团队创建越来越复杂的项目。

此外，当利益相关者和项目经理开始将估算视为衡量生产力的一个点时，帕金森定律开始发挥作用。帕金森定律指出，“工作会扩大，以填补可用于完成的时间。” 因此，如果一个团队估计一个项目需要两天时间，这个项目一般需要两天时间，在那里可能一天就可以完成。另一方面，利益相关者可能会提出不必要的要求，或者开发人员可能比他们应有的乐观。如果有能力的开发人员估计有一天，但发现项目比他们预期的更复杂，需要两天时间，这不一定是对开发人员生产力的衡量，而是对意外并发症或过于积极的估计的衡量。

衡量开发人员生产力的一些创造性方法

如果衡量开发人员生产力的传统方法不起作用，那么您能做什么？甚至可以衡量生产力吗？虽然衡量生产力可能很棘手，但有一些创造性的方法可以更好地了解您的团队的生产力。其中一些指标可能是衡量团队开发人员生产力的重要指标。其他人可能并不完全适合您的情况。通读这些提示并找到最适合您情况的提示。

1. 封闭式门票

衡量开发人员生产力的一种可能方法是通过关闭的票证。许多软件项目是通过一个系统来管理的，该系统监控个人开发人员凭票完成的工作。通过计算开发人员在特定时间段内关闭的工单数量，您可以查看正在关闭的工作量。

当然，这有可能成为简单的任务列表，并且一些开发人员可能会关闭大量票证并看起来富有成效，而没有完成很多有意义的工作。但是，如果任务编写得当，并且根据业务优先级进行分配，那么衡量已关闭的工单可能是您衡量开发人员生产力时要考虑的指标。如果有更多的工单被关闭，那么您可以推断该项目进展顺利。

但是，并非每张票都需要相同的工作量。有些可能需要更长的时间。其他人走得相对较快。因此，一些团队根据所需的努力量来得分。通过这种方式，您可以更好地衡量开发人员的生产力。如果一个开发人员正在处理更长更难的工单，而另一个开发人员正在处理更简单的工单，那么您可以确定第一个开发人员的工作效率更高。还有许多不同的方法可以衡量已关闭的工单，并且可以使用许多工具，例如 GitHub 和 Jira。关闭的工单只是衡量生产力的一种创造性方式。

2. 文件创建

文档可能是开发中最重要的部分之一，但经常被忽视，因此在考虑文档的情况下设置开发人员生产力目标可能会很有用。它可以采用多种形式，从评论到 READ ME 文本和更复杂的手册。但是，无论形式如何，它都会产生持久的影响，甚至可能在开发人员离开项目之后。

与代码行数一样，测量页数或文档行数可能会导致一些开发人员用额外的单词或冗长的语言填充他们的数字。或者他们可能为了文档而开始编写文档，所以一定要设置你自己的内部标准。使用像 Basecamp 这样具有页数并且可以将部分或整个页面归因于作者的工具可能会有所帮助。使用Sleeek 的任务描述联邦面板，您可以检查每个任务是否有足够的描述。

3. 部署

从最终用户那里获得反馈的最好方法是以他们可以使用的形式将工作呈现在他们面前。部署可能是一种有用的生产力衡量标准，因为您正在衡量与用户共享的项目中的更改。

与开发人员生产力的其他可能测量方法一样，当今有许多工具可以以简单、自动化的方式测量部署。这些工具中的大多数还可以让您查看部署中的工作。而且，虽然您希望鼓励您的团队快速且频繁地发布代码，但您还希望确保代码质量处于尽可能高的水平。因此，当使用部署作为开发人员生产力的衡量标准时，请努力确保部署人员正在部署最好的代码，而不仅仅是试图看起来富有成效。当您努力维护高水平的代码时，衡量部署可能是衡量生产力的一种创造性且富有洞察力的方式。

4. 站立会议涵盖的项目

您的团队很可能每天都举行站立会议。这些会议通常遵循回答相同的三个问题的模式：你昨天做了什么？你今天要完成什么？您面临哪些挑战？这些问题很好也很有用，但您也可以使用它们来创造性地衡量开发人员的工作效率。

当开发人员定期完成他们在站立会议中陈述的目标时，这表明了一致性。从这里您可以推断，开发人员正在高效工作。如果您的团队作为一个整体始终如一地满足或超出他们自己的期望，那么这可能表明团队正在协作并高效地工作。

将其记录为开发人员生产力的一种方法可能是让某人在站立期间做笔记。然后，在每次站立时，您可以与每个人一起回顾前一天的笔记。使用此度量需要注意的一个问题是，在团队成员解释某些项目未完成的原因时，可能会减慢每日站立会议的速度。这也是衡量开发人员生产力的一种相当公开的方式，即使他们有正当理由，您的团队中的某些成员也可能不愿意讨论某个项目未完成的原因。

此外，与前面提到的一些方法一样，开发人员有时可能对他们的预测过于乐观，他们可能会咬牙切齿。在使用这种衡量开发人员生产力的方法时，重要的是为您的团队创造一个安全的环境来发表意见。虽然这种讨论是一种很好的问责形式，但它不应该被用来惩罚开发人员或让他们无法理解。事先与您的团队讨论这种风格的开发人员生产力可能会有所帮助。如果团队成员仍然不愿分享他/她的任务的“真实状态”，那么工具可能会很有用。 Geekbot是一个简单的 Slack 聊天机器人，用于日常站立。Sleeek 还有一个 Slack bot 功能，可以做一个简单的调查团队成员对他们的任务状态的感受。

5. 总体进展

对于某些团队，前进可以用来衡量开发人员的生产力。这种类型的测量有助于奖励任何形式的积极运动。即使您的开发团队还没有找到完整的解决方案，他们也可以找到一些前进的步骤。

与您的日程安排或燃尽图相比，该项目在哪里？与预算相比如何？将这些项目考虑在内可以帮助您了解您的团队的实际工作效率。如果您的团队很忙，但落后于计划，您可能没有将时间花在正确的任务上。如果您的团队按时完成，这可能是您的团队富有成效的一个很好的例子。同样，Jira 或其他项目管理工具等工具将帮助您快速轻松地查看进度并根据任何变化进行调整。这可能有助于衡量开发人员的生产力。

6. 完成的代码审查

代码审查是任何高效软件开发团队的重要组成部分，还可以帮助您衡量开发人员的生产力。当您衡量完成的代码审查时，您正在计算团队成员提交的代码审查数量。

衡量完成的代码审查显示了您的团队对代码审查的认可程度，并且基本上可以用作前面提到的某些指标的替代衡量标准。如果您的开发人员正在提交代码审查，那么，据推测，工单正在关闭，您的项目正在向前推进。

代码审查是在部署之前提高代码质量的最简单方法之一。您可以在许多代码存储库中轻松测量它，例如 GitLab 或 GitHub。但是，与其他潜在指标一样，请确保您的开发人员确实花时间正确审查代码，而不仅仅是走动。如果您这样做，完成的代码审查可能有助于衡量开发人员的生产力。

7. 对话

一种可以帮助您衡量开发人员生产力的独特方法是量化与其他人（尤其是团队以外的人）的对话次数。最好的开发人员不会单独工作。即使是那些在团队中工作的人，如果不小心，也会开始屈服于群体思维。但是，您可以通过鼓励和创建围绕您的团队与非开发人员进行的对话的指标来帮助避免这种情况，无论是其他部门的同事，如营销或人力资源、客户或其他利益相关者。

您的团队与参与该项目的其他人交流得越多，他们对项目的了解和了解就越多。您的开发团队可能会从这些对话中想到新的和创造性的解决方案。他们可能会获得一些原本可能会错过的重要信息。这就是为什么鼓励您的团队尽可能多地了解项目很重要的原因。

这可能是衡量开发人员生产力的一个棘手指标，但作为团队负责人，您可以在与开发人员的定期一对一会议中检查它。测量的精确程度取决于您。您可以正式记录开发人员每周的会议或对话次数。或者，也许您只是随便请他们给您一个大概的想法。但是，无论哪种方式，知道您每周都会在一对一会议中提出这个问题将鼓励您的开发人员寻找其他同事并与他们讨论项目。这可以有助于提高开发人员的生产力。

使用此指标时，重要的是要记住，某些团队成员可能不喜欢与其他人交谈。在这种情况下，确保团队中的每个人都感到舒适很重要。如果他们觉得他们“必须”与人交谈，这可能会导致过度的压力——实际上会导致开发人员生产力的下降。你最了解你的团队。如果你有很多社交蝴蝶，鼓励他们去和公司的其他人交谈。如果您的团队比较安静或害羞，也许可以鼓励他们，但不要要求这样做。同样，衡量您的团队对此开发人员生产力指标的兴趣。

8. 交货时间

提前期是从项目开发开始到项目交付给客户之间的时间段。一旦您拥有团队的交付周期历史，您就可以更准确地预测项目或项目何时完成并为客户做好准备。

理想情况下，交货时间应该较短。较短的交货时间意味着项目可以更快地交到客户手中。提前期也可以帮助作为其他指标的代理。如果您的提前期较短，这意味着您的团队正在关闭更多工单，部署更多，并且项目正在向前推进。

与开发人员生产力的其他可能指标一样，您希望确保交付给客户的产品具有尽可能高的质量。如果产品很差，那么短的交货时间是没有好处的。但是，较短的交付周期和出色的最终结果可以帮助您更多地了解团队的开发人员生产力。

9. 缺陷

缺陷逃逸率是生产中发现的缺陷数量与 QA 期间发现的缺陷数量之比。通过保持低费率，您可以帮助确保为最终用户提供优质产品。

当您记录和衡量发现的缺陷数量，并分析谁编写了有缺陷的代码时，这可以成为衡量开发人员生产力的一种方式。更高效的开发人员将拥有更少的缺陷。这个指标可能对你有用，但要小心。请记住，一些开发人员可能会处理项目中更复杂的部分。此外，您必须自己判断这是否是您团队的激励指标。许多开发人员可能会因为他们的代码中的缺陷数量而受到指责，而在这种压力下可能无法很好地工作。但是，如果您创建了一个安全的环境，将失败视为一种学习经验，那么这可能是衡量开发人员生产力的另一种创造性方法。

10. 使用工具

当然，您可以使用开发人员生产力工具自动衡量开发人员生产力。过去，这些工具通常依赖于前面提到的衡量开发人员生产力的传统方法，例如衡量代码行数或工作时间。但是今天，存在许多选项，这些选项已经演变为对您的情况可能有用。

• Pluralsight Pro ——Pluralsight Pro 使用四个主要指标来衡量开发人员的生产力：活跃天数、每天提交、影响和效率，以及许多不同的报告类型。

• GitClear ——Gitclear 允许项目经理查看开发人员在数据质量方面的活跃程度，让您可以从位置、资历、国家等许多细节进行比较。

• Pinpoint ——Pinpoint 是一种开发人员生产力工具，可帮助管理人员比较使用多个数据源的团队。Pinpoint 声称不仅仅是源代码，还可以从大量软件生命周期系统中合成数据。一些指标包括缺陷率、周期时间、准时交付等等。

  代码气候——代码气候的 Velocity 开发人员生产力工具具有大量功能，包括通过各种颜色和形状表示提交活动的提交活动日志。它还包括与公关相关的指标。

• Sleeek ——Sleeek 使用 API 连接到 JIRA、Git 等，结合来自 Slack 的用户情感数据，并使用原始算法分析用户行为，以提供有关软件项目状态的快速和最新信息。它解释了各种项目指标和通信数据，并为通常需要大量时间的项目经理提供有用的信息。

您如何知道正确的指标？定义它们。

为了获得对开发人员生产力的最佳衡量标准，您首先必须知道要衡量什么。虽然使用的确切指标因团队而异，但开发人员的生产力通常可以归结为评估两件事：

• 已完成工作的测量

• 衡量工作的重要性

这两个指标一起帮助您准确了解您的团队完成了多少工作，并帮助您确定该工作的级别。

在项目的生命周期中，指标可能会发生价值或质量的变化。在项目的一个部分中可能重要的内容在另一个部分中可能不那么重要。例如，技术债务通常被视为项目中不太理想的部分。但是，如果您的团队正在快速通过测试阶段并需要尽可能快地迭代尽可能多的想法，该怎么办？在这种情况下，开发人员可能需要或想要引入更多的技术债务。

当使用指标来衡量开发人员的生产力时，灵活是很重要的。当谈到开发人员生产力指标时，您可能无法简单地“设置并忘记它”。

一旦确定了适当的指标，就必须开始确定优先级。正如我们之前所说，完成工作不如完成正确的工作重要。这就是为开发人员的生产力设置优先顺序很重要的原因。完成许多小任务可能对自我有益，但这通常是真正推动项目前进的一大优先事项。你如何决定哪些任务是最重要的？一种常见且简单的方法是艾森豪威尔盒。

德怀特·D·艾森豪威尔总统曾经说过：“重要的事情很少紧急，紧急的事情很少重要。”他创造了一种方法来展示这一点。艾森豪威尔盒子是一个大方块，分为四个小方块：

• 重要且紧急——这些是你现在要做的任务。它可能是您今天需要推送的代码，也可能是您需要满足的最后期限。

• 重要但不紧急——这些是您需要决定的任务。为这些任务安排时间。一个例子是您的团队或企业的长期战略。

• 不重要，但紧急——这些是你最有可能委托给其他人的任务。安排面试或回复某些电子邮件之类的事情可能属于这一类

• 不重要也不紧急——这些是经常可以删除的项目。一些示例包括检查社交媒体或整理垃圾邮件文件夹。尽可能停止执行这些任务。

Eisenhower Box 是一种开始确定任务优先级的简单而清晰的方法。起初，养成习惯可能需要一些额外的时间，但一段时间后，它会成为第二天性，并提供一个简化的流程来显示最高优先级的任务，这将有助于支持您的开发人员生产力。

它还有助于促使您决定一项任务是否真的有必要，这最终将极大地帮助您的开发人员提高工作效率。一些开发人员可能会专注于较小的任务（实际上可以删除这些任务，以避免更大、更具挑战性的任务），从而看起来既忙碌又富有成效。忙碌并不一定是开发人员生产力的指标。在某些情况下，实际上可能恰恰相反！

衡量开发人员生产力的最佳指标是什么？ 

当谈到开发人员的生产力时，有许多可用的指标。传统的衡量方法，例如工作时间和编写的代码行数，通常无法全面反映实际开发人员的生产力。其他指标，例如已关闭的工单、已完成的代码审查，甚至与其他员工的对话，都可以让您更全面地了解团队中的开发人员生产力。由您决定哪些指标最适合您的团队。做到这一点的一种方法是确定需要完成的最重要的工作是什么。

虽然开发人员生产力的指标因团队而异，但对于每个项目的每个团队，都应始终考虑一个指标：客户满意度。您的最终客户对他们收到的东西满意吗？您是否为他们提供了超出他们预期的价值？他们是否很高兴再次与您合作？如果这些问题的答案是肯定的，那么无论其他指标可能怎么说，您的项目都是成功的。

许多项目经理和团队领导过度关注经典指标。当您每天观察它们时，这很容易做到。但这些数字可能是冷观测。最后，重要的是要记住，我们真正关心的是能够以安全的方式按时向客户交付高质量的产品。如果我们能做到这一点，那么客户就会很高兴。这可能是衡量开发人员生产力的最重要指标。 花椒壳-愿您平安健康

花椒壳-愿您平安健康 花椒壳资源网,资源下载,主要提供个人搜集资源、设计素材、音乐、视频、图片等一切与互联网有关的资源https://www.xinliu.vip/