【发布时间】:2011-03-17 09:41:36
【问题描述】:
我被提升为项目经理。这对我来说是一个新角色,刚开始我觉得这份工作很难。
您能否举一些我可以用来衡量团队成员质量和生产力的指标示例?我需要为开发人员和测试人员衡量这一点。
【问题讨论】:
我被提升为项目经理。这对我来说是一个新角色,刚开始我觉得这份工作很难。
您能否举一些我可以用来衡量团队成员质量和生产力的指标示例?我需要为开发人员和测试人员衡量这一点。
【问题讨论】:
你可以衡量很多东西
生成的代码行。
击键。
喝了咖啡。
产生了垃圾。
然而,这只是数量——为了有数字而数字。
在衡量您的团队之前,请了解如何衡量您。
了解如何衡量您的整体开发组织。
找出整个组织正在尝试优化哪些度量。
然后 - 并且只有在那时 - 尝试找到一种方法将大局目标映射到您的团队。如果您没有衡量组织总体目标的进展情况,那么您只是在收集数字。
如果您要收集数字,每天早上称量咖啡可能是完成工作的最佳指标。严重地。
【讨论】:
这是一个很好的链接,表明您选择的大多数指标最终可能不会以您想要的方式工作。 Developer Metrics - Useful or Harmful?
例如,
您选择的任何指标都可能最终被您要衡量的人“玩弄”。
【讨论】:
交付的价值。与您的客户(产品所有者)合作,找到一种方法来衡量您组织中的价值并衡量该价值。经常(每天、每周、每月)交付它,你会没事的。
【讨论】:
您能否举一些我可以用来衡量团队成员质量和生产力的指标示例。
敏捷团队衡量生产力的几个指标示例:
故事点/速度点:这是一个相对较大的单位,可用于衡量待完成工作的复杂性。
Sprint Burndown:这可用于衡量迭代或 Sprint 期间的进度(以小时为单位)
发布燃尽图:这可用于衡量发布期间故事点的进度。
敏捷团队衡量质量的几个指标示例:
Hudson CI:您可以使用持续集成工具,自动为您持续关注代码库。一些可以使用的质量检查插件可能是: 科尔贝图拉 PMD 检查样式
【讨论】:
首先找出贵公司对采用 Scrum 感兴趣的原因。
如果要生成质量更好的代码,那么您可以专注于测试覆盖率、错误计数等。我喜欢CRAP index。
许多公司采用 Scrum 是因为他们的大部分问题(包括低质量代码、紧迫的期限和返工)都是因为他们一开始就产生了错误的代码。要么需求被误解,要么利益相关者不太清楚他们想要什么。如果这是您的问题,您可能想要测量吞吐量(一个故事从分析到发布平均需要多长时间)或反馈(您需要多长时间才能知道您所做的工作是否实际可用,或者不 - 请记住,当它不可用时,您想尽快知道)。
我尽量避免衡量生产力之类的东西。成为productive without being effective 非常容易。关注the Goal。 Kanban 中的大多数指标都可以与 Scrum 一起使用,在这里会有所帮助。我非常喜欢累积流程图,因为它们显示了系统中的各种反馈循环和约束。
哦,无论你做什么 - 衡量团队,而不是个人。一旦人们认为他们被作为个人衡量,他们就会停止与团队相处。
【讨论】:
生产力是衡量成功的唯一重要标准:我的团队是否在指定的时间范围内完成了我们所说的我们可以做的事情,并且达到了高质量(通过 UAT)?如果不是,为什么不呢?
“衡量”这一点的一个好方法是衡量团队的速度,然后将其用作基准。速度既代表了团队可以做什么,也代表了他们计划自己的工作水平的准确程度。
这里有几篇关于速度及其计算方法的好文章:
http://www.versionone.com/Agile101/velocity.asp
http://michaellant.com/2010/07/23/calculating-the-velocity-of-your-agile-projects/
【讨论】:
十年前,当我第一次被提升为 PM 时,我试图追踪一切。最终只有一件事真正重要,那就是团队的幸福感(团队包括客户)。如果每个人都对项目的进度、质量和环境感到满意,那么您只需要调整有助于团队改进的任何指标。您可以在回顾中与团队一起确定这些指标。无论他们发现速度、功能点、领先和周期时间、测试覆盖率还是任何其他有用的指标——这些都是你应该帮助他们衡量的东西。我认为新 PM 可以关注的最强大的事情是沟通,而不是衡量。
【讨论】: