代码质量
And*_*rsK 21 development-environment process
我在一家软件开发公司工作,我们有大约100人从事产品工作,其中1/3是QA.最近管理层希望有一种更好的方式来评估个别程序员的表现,因此建议使用错误报告作为衡量标准.关于开发人员的错误报告越多,他就越糟糕.由于更多的原因,这似乎是不明智的,因为它是一种主观的测量方法,开发人员在不同复杂程度的项目上工作.此外,如果根据他们生成的错误报告的数量来衡量质量保证,那么将会有很多关于错误报告有效性的讨论.
在这样的环境中衡量开发人员绩效的更好方法是什么？
一个建议是不使用来自QA的错误报告作为衡量标准,而是使用来自外部的错误报告,例如beta测试人员,然后当发布此类公开错误报告时,也要让QA通过它来衡量.
编辑:#1在阅读了一些优秀的回复后,我认为上述指标的一般问题是它是负面的报告错误 - 它不鼓励产生高质量的代码.
编辑:#2我认为问题在于它是两个世界.一方面有非程序员基本上将程序员视为工人,他们最好需要度量单位/分钟.然后我们让程序员想要把自己视为艺术家或工匠,"请不要打扰我,我正在编码":)我不认为测量质量可以通过指标来完成,而不是适得其反.相反,一个人如何对错误做出反应,改变意愿,创造力以及最重要的工作质量是重要的,但大多数情况下不一定是可衡量的.
Chr*_*rch 23
尝试使用错误报告来衡量程序员的表现是一个坏主意.但是,尝试使用几乎任何其他指标来衡量性能也是如此.无论你做什么,人们都会想出如何游戏并给你你正在测量的东西而不给你你真正想要的东西.
来自Joel的其他文章之一:
Robert Austin在其"衡量和管理组织绩效"一书中说,当您引入新的绩效指标时,有两个阶段.起初,你实际上得到了你想要的东西,因为没有人知道如何作弊.在第二阶段,你实际上会变得更糟,因为每个人都想出最大化你正在测量的东西的技巧,即使以毁掉公司为代价.
- 我不同意.衡量开发人员的年度目标,他们取得的里程碑,以及技能的整体提升是可能的,但不仅仅是数字.经理必须参与其中. (3认同)
- 我想你们两个正在将苹果与橙子进行比较 (3认同)
- 我把克里斯指的是原始的数字指标 - 错误/代码行/签到的数量等等......他们都没有说什么.你已经明确表示"经理必须参与其中".他们还需要能够理解/讨论代码并帮助设定合法的可衡量目标. (2认同)
tva*_*son 11
我对此类评级系统的根本问题在于,您最终会与您的团队相互竞争,而不是彼此合作.如果您知道可能会支付罚款,那么在代码的难点部分工作的动机是什么？只需挑选容易出错的简单事物.为什么帮助您的同事改进他们的代码,这样做有利于他们,并可能对评级系统造成伤害.
我认为你最好使用同伴压力来提高代码质量:没有人想写垃圾,没有人想以写垃圾而闻名.用TDD做出真正的努力来减少缺陷 - 或者至少用单元测试.转向持续集成并宣传谁破坏了构建.在创建任何新代码之前,让构成破坏构建的人员负责修复它.这样的事情将推动质量提升.
一旦每个人都参与质量目标,就要对团队进行评分,而不是对个人进行评分.使合作工作真正受益.如果你有利用团队的懒鬼 - 每个人都会知道他们是谁 - 与他们合作改善,如果他们不能或不能,减少你的损失并找到一个更适合团队的人.如果你有合适的人选,它可能永远不会达到这一点.如果他们是错误的人,你和他们都会更好地了解它并且更好地适应.
如果团队中的某些人真的超越了他们,那就给他们额外的奖励,但要确保这真的是超出团队其他成员的非凡努力.如果是这样的话,团队就不会介意(太多),因为他们会知道他们的共享奖励在很大程度上是由于该人的努力.
显然,上述所有内容都应作为一般规则.虽然他们喜欢称之为管理科学,但它更像是一门艺术.了解你的团队的动态是复杂的业务,但我认为一般规则应该是鼓励和奖励团队合作.
我从现场的bug报告中看到的一个大问题是,程序员可能已经按照他给出的规格编程了100%,然后该领域的问题是由于规格不佳或不完整.
让我举个例子:你在Windows Vista 32位上开发和测试应用程序,然后在运行64位WIndows XP的coustomer站点失败.这是程序员的错(特别是如果你从来没有给他一台机器运行XP 64位进行测试)？
一旦你意识到错误可能由于很多原因而出现,只有程序员可以控制的一些,你需要非常小心,不要设置一个导致指责和指责的环境.团队的所有成员需要共同努力使产品更好,而不是花费他们的一天试图将错误归咎于其他人.
无论你做什么,都不要创建一个激励系统,在这个系统中,有人获得奖励积分,以证明这是别人的错.需要将错误视为整个组织所拥有的错误.