我们正在记录我们的软件开发过程。对于技术人员来说,这很容易:迭代开发,内部里程碑每 4 周一次,外部每 3 个月一次。
然而,这个练习的目的是用他们可以理解的方式为我们的项目管理揭示事物。具体来说,这些非技术经理需要他们能够理解的指标。
我非常了解我们的指标选项,并提出了一整套建议(满足要求和实际成本与预算成本是我最喜欢的两个)。但是,我们确实有一些老手参与其中,他们倾向于坚持使用 SLOC 等指标。
我理解 SLOC 的诱惑:对于非软件人员来说,它似乎很容易理解,而且它似乎是最接近物理事物的模拟物(就像在过去计算打孔卡一样!)。
那么问题来了:我如何向非技术人员解释 SLOC 的危险?
这里有一些具体的动机:我们在一个相当成熟的部署系统上工作,它背后有多年的历史。当我们添加功能时,SLOC 往往会保持大致水平甚至下降(重构会删除旧/死代码,新功能实际上只是对现有功能的调整等)。对于非程序员经理来说,开发项目中不增加的 SLOC 充其量是令人困惑的......
澄清以下最近的回答:请记住,我认为 SLOC 是衡量项目进度的糟糕指标。我并不是说这是一个不值得收集的数字。它需要广泛的上下文才能使用它做任何有用的事情,而大多数项目经理都没有这种上下文。