it-swarm.cn

使开发人员负责的度量

我每小时对代码行问一个问题,然后又撕了一个新的代码。所以我成熟的后续问题是这样的:

如果不是代码行,那么用什么好的方法(按小时/天/时间单位)衡量远程程序员的效率呢?

72
Kyle

在16年中,我从未真正找到您想要的那种可行指标。

从本质上讲,任何东西都必须是可度量的,具有代表性的和不可游戏的(也就是说,聪明的开发人员不能玩该系统)。在软件开发中,变量太多,以至于无法通过这种方式对其进行度量。

您得到的最接近的是估计进度-即在商定的估计范围内它们要完成多少任务。这里的诀窍是(a)获得良好而公正的估算,以及(b)了解由于某些原因而超出/超过了估算值,而开发人员无法/不应责怪开发人员(这确实比预期的要复杂)。最终,如果您对开发人员过于用力,您可能会发现估算值逐渐攀升到一个始终能满足的水平,这并不是因为生产力提高,而是由于时间尺度的增加。

从估计的角度考虑,反之亦然(减少它们以产生交付压力),您会创建电话截止日期,研究表明这些截止日期不会提高生产力,并且可能会对团队士气产生影响(有关更多信息,请参见Peopleware)。 )。

但本质上,我想知道您是否正在寻找一个稍微错误的问题。在衡量生产率时,为什么远程程序员与其他程序员不同?您如何衡量非远程程序员的生产力?

如果是关于不信任他们可以远程工作,那么这基本上是一个更广泛的信任问题。如果您不信任他们在家工作,那么您要么需要建立信任关系,要么不让他们在家工作,或者找到某种让自己满意的方式,使他们确实在工作时就可以工作。

101
Jon Hopkins

度量标准在工厂中效果最好,而程序员不在组装线上工作。

我完全理解衡量生产率的愿望。

但是您会为家庭医生和心脏病医生使用相同的度量标准吗?对于米开朗基罗为西斯廷教堂作画,又有墨西哥的某个家伙在创作黑色天鹅绒猫王画作得怎么样?

路易斯·德布罗意(Louis de Broglie)撰写的博士论文太短,审查员将拒绝该论文-除了德布罗意是一位举足轻重的贵族,他们需要一个很好的借口。因此,考官将其发送给爱因斯坦,爱因斯坦不仅没有拒绝,而且将其转给了诺贝尔奖委员会,德布罗意在五年后获得了诺贝尔物理学奖。

数值测量最适合重复性工作,例如铸铁或车门上的螺栓。但是,如果您要重复之前完成的代码,则不需要程序员,只需要复制粘贴即可。编程从根本上说是一门创造性的学科,而生产力完全取决于您的工作。

有几天,我编写了1000行代码。今天,我将要修复坐标几何错误,并且代码可能会缩小。如果必须修复Linux内核驱动程序中的错误,则我可能会花一整天时间进行调试,而不用编写任何新代码。

衡量程序员的生产率非常非常非常主观

如果您想了解Joe的工作效率,请找到Sally和Ralph,他们知道Joe的工作并且精通同一领域,然后问他们。

我见过的最好的数字系统是敏捷的计划扑克积分。这只是询问乔,萨利和拉尔夫他们认为乔的即将到来的工作有多么困难的一种奇特的方式。然后,您可以衡量每个团队成员的每周生产率。但是即使那样,校准团队的估计仍需要花费一些时间,而且这些数字很模糊并且很容易被抛弃。

许多人都需要生产率估算,以便他们可以进行计划计划。有点像“将其插入MS Project,查看关键路径,并确定您的发货日期”理论。我从未见过这样的作品-太多的未知数。如果需要,请使用Waterfall,预先设计所有内容,不允许任何变更单,并且随时准备感到失望。

48
Bob Murphy

我使用的唯一度量标准是他为给定的我投资的钱量产生的工作软件量

无论时间表如何,无论她/他是否在远程工作,他/她需要停顿的次数,她/他使用的方法或工作时间的数量。

通过工作软件,我的意思是:

用户/客户定义的符合所需质量级别的功能列表

金额

用户/客户为定义的功能+维护费用支付了多少

因此,它直接决定了它的构建方式和工作质量,但不受任何源代码行指标的约束。

42
user2567

您需要一个经验丰富的开发人员或团队负责人(与那些远程程序员无关)来估计某些任务可能花费的时间,并通过将他们所需的时间与估计的时间进行比较来评估有效性。为确保估算结果正确,您可以随机选择一些任务,并由您控制下的内部团队执行。

23
user281377

衡量生产率的另一种有趣的方法是计算每天由经理审查的自动化测试。开发人员得到:

  • 编写自动测试(并通过审核)并将其添加到回归测试套件中的要点,
  • 在不导致任何其他回归测试失败的前提下,使它们通过。

开发人员和管理人员可以通过以下方式共同改进系统:

  • 共同商定开发和测试的重要领域
  • 独立审查和运行测试套件。
  • 决定不构建业务收益有限但需要大量开发和测试才能交付该功能的功能。 (最有生产力的代码行是您决定不编写的代码行,因为它没有任何商业利益)。
  • 将系统划分为一个体系结构(例如model-view-controller),该体系结构可在不破坏整个系统的情况下促进增量功能的开发。

开发者无法使用该指标,因为:

  • 多余的测试将被经理审查阻止。
  • 经理审查可能会阻止细粒度的测试。
  • 细粒度的测试将改善系统的质量。

管理员无法使用该指标,因为:

  • 拒绝过多的测试将导致开发人员消耗。
  • 请求太多的测试将很难拒绝以后的截止日期。

开发人员无法将经理搞砸,因为

  • 每个交付的带有测试的功能单元也必须通过回归套件。即,这迫使开发人员在不破坏其他代码的情况下进行仔细的开发。
  • 任何工作主张都必须通过新的测试和回归测试来证明。

经理不能拧开发者,因为。

  • 每个请求的功能单元必须包括关键的测试用例,以及完成工作所需的测试用例数量的估计。
  • 当您显然需要很多工作时,很难要求一个激进的时间表和/或免费加班。

经理的另一个大好处是,他可以招募新的开发人员,并且知道他们将无法交付无声地破坏系统的代码(因为回归测试套件抓住了这一点)。

经理的最大缺点是,这迫使他不得不承认他的系统比该功能的1页描述中看上去的还要复杂。另一个缺点是这种方法的透明性将使其很难将开发失败归咎于开发人员。

7
Jay Godse

当然,可以设计出各种复杂的指标来评估性能,但是最终,您的判断的很大一部分必须依赖于主观性以及来自接近代码库的人员的输入。

例如,某些团队很有可能以非常快的速度解决内部可怕的难以维护的问题,这甚至可以满足要求的期限和规格。但是,从这种工作方式中产生的技术债务是否比团队精心制作出一些健壮且可维护的项目但将截止日期拖延了几周还差呢?这取决于。

如果问题的目的是解决某种类型的生产力问题,我会说经理为促进团队工作所做的实际工作同用于评估团队的任何衡量技术一样重要或更重要。这是一条双向路。换句话说,我说的是指标很不错,但是如果您想从团队中获取更多,最终的问题是经理是否会尽一切可能确保团队生产力。

这远远超出了编写规格,找到团队,将规格“扔在墙上”和单击秒表的范围。

6
Angelo

一些想法:

  1. 实现的功能
  2. 已修复的错误(也考虑了后来由质量检查人员重新打开的错误)
  3. 用户投诉得到解决(请注意,它与2不同-一个严重的错误可能是颈部疼痛,而100个错别字可能并不那么重要)

也可能要跟踪:

  1. 测试的代码覆盖率
  2. 内部文档覆盖代码
  3. 外部(用户)文档的功能涵盖范围
2
StasM

以与客户测量相同的方式进行测量。就功能代码而言,但规模较小。

制定短期目标(一两个星期),看看程序员是否达到目标,并以令人满意的方式实现目标。

我强烈建议对代码进行同行评审,因为这可以让您提前捕获不良代码。

2
user1249

产品/服务的销售率如何?.

有时我听说这被称为佣金/总收入的百分比

人们买好的产品,不是吗?

企业想要销售产品(或服务,与此相同)

因此,如果这是您想要的,请对其进行测量。

有点像说设计能够获得良好评价和良好销售的汽车的人确实做得很好。

现在采用此度量标准,并且编程团队将要与销售人员互动,有两个原因。

  • 承诺无法实现

  • 没有有效地向客户销售产品

1
Tim Williscroft

编写代码/编程并不像用锤子钉钉子。总体上来说,类似于“编写”,您也不能通常应用指标。

您不能简单地查看他们的签到,或他们通过同行评审,代码评审所做的事情吗?

或者您知道,如果他们确实产生了可解决问题的有效代码和解决方案?

0
Jack Marchetti