阅读 4

都 2020 年了,还在用代码行数评估开发工作量吗?

衡量开发人员的工作量一直是让很多管理者头疼的问题,开发工作的不易量化让对于开发人员个体的工作变得难以评估。这时许多管理者为了图方便,直接只用代码行数来评估开发人员的工作量,这让很多开发人员都苦不堪言。

在开发工作中,代码行数体现的数据最直观,这点我们不能否认,它一定是一个可以参考的维度。但是如果仅用代码行数来评估开发人员的工作量,甚至以代码行数来设定 KPI ,这无疑是非常错误的行为,其带来的后果也是非常严重的。

首先这并不是一种非常专业且科学的评估方式,甚至会让制定该规则的人显得有些「业余」。亲自有过项目经验的开发者和技术管理人员应该都知道,一个项目中真正耗费精力的地方是框架搭建、功能需求分解,以及后续的功能测试,真正去写代码的时间占比其实并没有多少。


其次,如果仅用代码行数来评估开发工作量的话,团队所面临的最大难题便是垃圾代码的增加。团队成员为了完成 KPI ,在本就能 20 行写完的功能上加入各种注释和无用的函数,甚至直接往项目里面贴源码,而不去考虑代码的耦合性、可读性、可维护性、重用性等。虽然 KPI 完成了,但开发人员逐渐降低的效率、延误越来越久的项目、质量越来越低的代码,团队在进行着完全没有必要的内耗,会让整个项目越来越艰难,和最初的目的背道而驰。


比尔盖茨曾经总结过这么一句话,“用代码行数来衡量编程的进度,就如同用重量来衡量飞机的制造进度”。没错的,代码数量并不等于代码质量,一味的追求写了多少行代码没有多大本质意义,关键在于是不是真的解决了实际问题。而只用代码行数来评估工作量,无疑是管理方式落后的表现。不客气的讲,这样的管理者思想仍旧停留在农耕时代,高产出=高价值,这样的等式在软件研发领域是不成立的。

那么,一个合格的管理者到底应该如何科学的评估开发人员的工作量呢?

目前比较常见的方法是基于 WBS(Work Breakdown Structure)的工作量估算,也称作自下而上法。通常的估算步骤如下:

  1. 寻找类似的历史项目,进行项目的类比分析,根据历史项目的工作量凭经验估计本项目的总工作量;
  2. 进行 WBS 分解,力所能及地将整个项目的任务进行分解;
  3. 参考类似项目的数据,采用类比法或专家法,估计 WBS 中每类活动的工作量;
  4. 汇总得到项目的总工作量;
  5. 与第1步的结果进行印证分析,根据分析结果,确定估计结果。

此外,也有 Putnam 模型、 COCOMOⅡ模型、IBM 模型等科学的估算方法,虽然看起来比较复杂,但比「一刀切」式的只看代码行数的评估方法要有效的多。

始终追求高效开发协作的 Gitee 企业版也在和大家一起探索更科学、合理、公正的工作量评估体系,Gitee 企业版刚上线不久的「统计」模块将多维度可视化的指标独立出来,让管理者更全面、直观、立体地了解项目进度级团队情况。

「统计」模块在未来仍将会是 Gitee 企业版的重点,后续我们会对该模块持续改进,提高大家的效率是我们不变的目标。


关注下面的标签,发现更多相似文章
评论