Scrum敏捷项目管理

为软件开发人员衡量喜悦

如果软件开发社区广泛了解诸如代码行或代码覆盖率之类的指标,那么衡量软件开发团队的喜悦程度肯定是很少讨论的事情了。在本文中,Doc Norton提出了一种简单的方法来利用您现有代码的质量来评估软件开发人员的满意度。这样,您可以降低Scrum团队的营业额并获得有关重构需求的提示。

作者: OnBelay联合创始人Doc Norton //onbelay.co/

几年前,我正在与一个客户合作,该客户围绕工作中的Joy发起了一项倡议。他们设计了一个简短的调查表,定期将其发送给员工,以衡量他们在工作中的快乐程度。公司范围内的响应率相对较低,但是在软件工程方面却令人讨厌。从感到不安,到认为问题与工作无关,到感觉到无论如何都没有人对数据做任何事情,人们为什么不对调查做出回应,原因有很多。

我们从软件团队收集的大多数指标都是相对被动的。它们是对工作流程的度量,例如提前期和周期时间,或者是通过静态分析对输出本身的度量。基本上,开发人员在正常的一天里就忙着采取措施,而不会影响他们的日常工作。但是,我们团队的快乐措施是一个破坏。他们不适应正常的一天。

代码屏幕编程

我们认为,如果我们想出一种方法来调查他们的工作流程,也许可以增加参与度。我已经通过诸如时间跟踪之类的东西看到了这一点,在时间跟踪中,我们使用了一个软件,每次保存文件以更新日志时,该软件都会启动自动测试。然后,开发人员使用该日志数据来帮助他们填写时间表。

但是,如何被动地衡量员工的快乐呢?经过讨论,我们决定尝试一些非常简单的方法。所有软件源代码都在称为git的版本控制系统中进行管理。 git和其他版本控制软件的思想是允许开发人员在团队中管理对共享源代码的更改。以控制批准哪些更改并将其更改为最终版本,并在出现问题时轻松地将代码还原为先前的工作版本。每次开发人员对源代码提交更改时,他们都会将其签入源代码管理工具以考虑作为正式更改。每次签入都包含一些注释,以指示更改的目的,无论是添加新功能还是修复缺陷。

Git是源代码管理工具,是由开发人员为开发人员编写的软件。因此,它具有向其添加新功能的相对简单的方法。我们对其进行了更新,以便它可以解释每次签到中包含的开发人员消息。对于这些团队,他们已经制定了在每个签到消息开头都包含工作订单编号的政策。这使得跟踪与工作相关的变更请求变得容易。典型的签到消息如下所示:

AAA12345 – Corrects tax calculation for food items.

连字符前的第一位是工单号。剩下的就是对工作本身的快速描述。

我们只是将消息的格式更改为包含代表开发人员的数字(从0到5)’对代码的看法是0表示“此代码太糟糕了”,而5表示“此代码太棒了”。

好吧,也许那不是’精确的比例,但您明白了。分数为0表示开发人员发现该代码很难使用-它不符合格式标准,并且在尝试添加功能时很难理解或轻易破坏。 5分意味着开发人员发现该代码非常易于使用–它符合格式标准,易于理解,并且易于添加功能。

现在,相同的签到消息可能看起来像这样:

AAA12345 -4- Corrects tax calculation for food items.

在此签到消息中,我们可以看到开发人员发现该代码相对容易使用,但并没有感觉到这是团队所能提供的最高质量。
我们的理论是,由于开发人员花了很多时间编写代码,因此他们对代码本身的看法可能会代表他们对工作的喜悦或满意。在代码上花了很多天,您认为这很难阅读,并且容易破解,并且您可能不太喜欢这项工作。代码本身会妨碍您处理当前的问题。另一方面,如果您作为开发人员的大部分时间都花在易于阅读和更改的代码上,那么您将能够更好地专注于解决手头的问题,并且可能会更享受工作。

将签到分数与一对一会议的数据进行比较,我们发现分数与员工对工作的喜悦或沮丧感之间存在正相关关系。随着时间的流逝,我们看到了分数与员工流动性或离职率之间的相关性。而且非常有价值的是,我们将开发人员的喜悦视为领先指标。如果喜悦分数下降,那么在几周内,我们几乎总是可以看到逃脱的缺陷有所增加,吞吐量受到打击或团队中面临挑战的其他迹象。如果喜乐有所下降,最好在其中谈谈 回顾性 看看我们能否找到根本原因。在许多情况下,明确地将有关代码的清理作为工作项不仅可以提高工作效率,而且可以改善许多代码质量指标。

关于作者

OnBelay联合创始人Doc Norton十分热衷于与团队合作,以改善交付并建立出色的组织。 Doc与众多公司(从初创公司到财富100强公司)合作,运用敏捷,精益,系统思维和仆人领导的租户来发展高效的文化,并极大地提高了他们提供有价值的软件和产品的能力。 Doc是Pluralsight的作者,Clean Coders的撰稿人,频繁的博客作者,国际主题演讲者和教练,在业余时间,Doc一直在研究他的最新著作《逃逸速度:敏捷团队的更好衡量标准》。您可以在以下位置找到有关LeanPub的书 www.leanpub.com/EscapeVelocity

2评论为软件开发人员衡量喜悦

  1. 一种评估代码和幸福感的有趣方法。完全同意有更多需求“passive”与软件开发人员的指标。让他们感觉更多形式通常是不成功的方法; O)

  2. 问题在于,必须对0到5的数字进行排名。是1高于5还是5高于1?为什么不使用一个词来形容体验,例如。 。 。很棒,不错,可以,很糟糕或其他描述符

评论被关闭。