blocks|key|1438709|text|你可以测量很多东西|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1438710|1438711|生成的代码行。|unordered-list-item|1438712|keystrokes.|1438713|coffee已消耗。已生成|1438714|垃圾。|1438715|1438716|然而，这只是数字--为了拥有数字而数字。|1438717|在你衡量你的团队之前，先弄清楚你的是如何被衡量的。|1438718|了解您的整体开发组织是如何衡量的。|1438719|找出整个组织试图优化的度量标准。|1438720|然后--也只有到那时--试着找到一种方法，将总体目标映射到你的团队。如果你不是在衡量组织总体目标的进展，那么你只是在收集数字。|1438721|如果你要收集数据，每天早上称量咖啡的重量可能是工作完成的最佳指标。我是认真的。|1438722|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|13|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|15|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|19|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1B|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|Z|$]]

You can measure a lot of things

<ul>
<li>lines of code produced. </li>
<li>keystrokes.</li>
<li>coffee consumed. </li>
<li>trash produced. </li>
</ul>

However, that's just numerosity -- numbers for the sake of having numbers.

Before you measure your team, find out how you are measured. 

Find out how your overall development organization is measured.

Find out what measurements the overall organization is trying to optimize.

Then -- and only then -- try to find a way to map the big picture goals down to your team. If you're not measuring progress toward the organization's overall goals, then you're just collecting numbers.

If you're going to collect numbers, weighing the coffee every morning may be the best indicator of work being done. Seriously.

blocks|key|1438823|text|这是一个很好的链接，表明您选择的大多数指标最终可能不会以您想要的方式工作。Developer+Metrics+-+Useful+or+Harmful?|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1438824|例如,|1438825|1438826|衡量代码的行数，会对代码|unordered-list-item|1438827|造成详细影响|1438828|你选择的任何指标很可能最终都会被你试图衡量的人“玩弄”。|1438829|entityMap|0|LINK|mutability|MUTABLE|url|http://geekswithblogs.net/Optikal/archive/2007/02/21/106916.aspx^0|11|12|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|10|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|11|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

This is a good link suggesting most metrics you choose will probably not end up working in the way you want. <a href="http://geekswithblogs.net/Optikal/archive/2007/02/21/106916.aspx" rel="nofollow">Developer Metrics - Useful or Harmful?</a> 

For example, 

<ul>
<li>measure lines of code, the impact will be verbose code</li>
</ul>

Any metric you choose will likely end up being 'gamed' by the people you are trying to measure.

blocks|key|3505561|text|交付的价值。与您的客户(产品所有者)合作，找到一种方法来衡量组织中的价值，并衡量该价值。经常交付它(每天，每周，每月)，你就会很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3505562|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Value delivered. Work with your customers (product owner) to find a way to measure value in your organization and measure that value. Deliver it frequently (daily, weekly, monthly) and you'll be just fine.

blocks|key|2069954|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2069955|你能给我一些衡量标准的例子，我可以用来衡量我的团队成员的质量和生产力。|blockquote|2069956|2069957|2069958|下面是一些敏捷团队衡量生产力的指标示例：|2069959|故事点/速度点：这是一个相对较大的单位，可以用来衡量要完成的工作的复杂性。|offset|length|style|BOLD|2069960|Sprint+Burndown：这可以用来在迭代或冲刺期间以小时为单位测量进度|2069961|Release+Burndown：这可以用来测量在发布期间的故事点的进度。|2069962|下面是一些敏捷团队衡量质量的指标示例：|2069963|Hudson+CI：您可以使用持续集成工具，它会自动持续关注代码库。一些可以用于质量检查的插件可以是:+Corbertura+PMD+CheckStyle|2069964|entityMap^0|0|0|0|0|0|0|8|0|0|F|0|0|G|0|0|0|9|0^^$0|@$1|2|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|Y|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|11|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|12|7|@$J|13|K|14|L|M]]|8|@]|9|$]]|$1|N|3|O|4|5|6|15|7|@$J|16|K|17|L|M]]|8|@]|9|$]]|$1|P|3|Q|4|5|6|18|7|@$J|19|K|1A|L|M]]|8|@]|9|$]]|$1|R|3|S|4|5|6|1B|7|@]|8|@]|9|$]]|$1|T|3|U|4|5|6|1C|7|@$J|1D|K|1E|L|M]]|8|@]|9|$]]|$1|V|3|-4|4|5|6|1F|7|@]|8|@]|9|$]]]|W|$]]

<blockquote>
 Can you give me some example of metrics that I could use to measure the quality and productivity of my team members.
</blockquote>

A few examples of metrics for an Agile Team to measure PRODUCTIVITY:

Story Points / Velocity Points: This is a relatively sizable unit which can be used to measure complexity of the work to be done.

Sprint Burndown: This can be used to measure progress in hours during an iteration or Sprint

Release Burndown: This can be used to measure progress in story points during a release.

A few examples of metrics for an Agile Team to measure QUALITY:

Hudson CI: You could use a continuous integration tool which constantly keeps an eye on the code base for you automatically. Some plugins for quality checks that can be used could be:
Corbertura
PMD
CheckStyle

blocks|key|5105408|text|首先，了解您的公司为什么对采用Scrum感兴趣。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5105409|如果它是为了产生更高质量的代码，那么你可以专注于测试覆盖率，错误计数等事情。我喜欢CRAP+index。|offset|length|5105410|许多公司采用Scrum是因为他们的大多数问题--包括低质量的代码、紧迫的截止日期和返工--都是因为他们一开始就产生了错误的代码。要么是需求被误解了，要么是涉众不太清楚他们想要什么。如果这就是你的问题，你可能想要测量吞吐量(平均来说，一个故事从分析到发布需要多长时间)或反馈(你需要多长时间才能知道你所做的工作是否真的有用--记住，当它不可用时，你想尽快知道)。|5105411|我尽量避免测量像生产力这样的东西。成为productive+without+being+effective很容易。关注the+Goal。Kanban中的大多数指标都可以与Scrum一起使用，这将对此有所帮助。我非常喜欢累积流程图，因为它们显示了系统中的各种反馈循环和约束。|5105412|哦，不管你做什么--衡量团队，而不是个人。一旦人们认为他们是作为个人来衡量的，他们就会停止与团队友好相处。|5105413|entityMap|0|LINK|mutability|MUTABLE|url|http://googletesting.blogspot.com/2011/02/this-code-is-crap.html|1|http://dannorth.net/2009/11/12/the-lady-in-the-taxi-a-parable-of-metrics/|2|https://rads.stackoverflow.com/amzn/click/com/0884271781|3|https://rads.stackoverflow.com/amzn/click/com/0984521402^0|0|15|A|0|0|0|J|Y|1|1N|8|2|1W|6|3|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]|$D|19|E|1A|1|1B]|$D|1C|E|1D|1|1E]]|A|$]]|$1|J|3|K|5|6|7|1F|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]|T|$5|O|P|Q|A|$R|U]]|V|$5|O|P|Q|A|$R|W]]|X|$5|O|P|Q|A|$R|Y]]]]

Find out why your company was interested in adopting Scrum in the first place.

If it was to produce better quality code, then you could focus on things like test coverage, bug count, etc. I like the <a href="http://googletesting.blogspot.com/2011/02/this-code-is-crap.html" rel="nofollow noreferrer">CRAP index</a>.

Many companies adopt Scrum because most of their problems - including low quality code, tight deadlines and rework - are caused because they produce the wrong code in the first place. Either requirements are misunderstood, or the stakeholders don't quite know what they want. If that's your problem, you might want to measure throughput (how long it takes a story, on average, to go from analysis through to release) or feedback (how long it takes you to know whether the work you did is actually usable, or not - bearing in mind that when it's not usable, you want to know as soon as possible).

I try to avoid measuring things like productivity. It's very easy to be <a href="http://dannorth.net/2009/11/12/the-lady-in-the-taxi-a-parable-of-metrics/" rel="nofollow noreferrer">productive without being effective</a>. Focus on <a href="https://rads.stackoverflow.com/amzn/click/com/0884271781" rel="nofollow noreferrer" rel="nofollow noreferrer">the Goal</a>. Most of the metrics in <a href="https://rads.stackoverflow.com/amzn/click/com/0984521402" rel="nofollow noreferrer" rel="nofollow noreferrer">Kanban</a> can be used alongside Scrum and will help here. I very much like Cumulative Flow Diagrams, because they show all kinds of feedback loops and constraints in the system.

Oh, whatever you do - measure the team, not individuals. As soon as people think they are being measured as individuals, they'll stop playing nice with the team.

blocks|key|2070035|text|生产力是衡量成功的唯一重要标准:我的团队是否在指定的时间范围内完成了我们所说的我们可以做的事情，并且达到了高质量水平(通过UAT)？若否，原因为何？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2070036|“衡量”这一点的一个好方法是测量团队的速度，然后将其作为基准。速度既代表了团队可以做什么，也代表了他们能够计划自己的努力水平的准确性。|2070037|这里有一些关于速度和如何计算速度的好文章：|2070038|http://www.versionone.com/Agile101/velocity.asp|offset|length|2070039|http://michaellant.com/2010/07/23/calculating-the-velocity-of-your-agile-projects/|2070040|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|0|0|1B|0|0|0|2A|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$H|X|I|Y|1|Z]]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@$H|11|I|12|1|13]]|A|$]]|$1|L|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|G]]|S|$5|O|P|Q|A|$R|K]]]]

Productivity is the only important measure of success: did my team accomplish what we said we could do, within the timeframes specified, and to a high level of quality (passing UAT)? If not, why not? 

A good way to "measure" this is by measuring the team's velocity and then using that as a benchmark. Velocity represents both what the team can do as well as how accurately they are able to plan their own level of effort. 

Here are a few good articles on velocity and how to calculate it:

<a href="http://www.versionone.com/Agile101/velocity.asp" rel="nofollow">http://www.versionone.com/Agile101/velocity.asp</a>

<a href="http://michaellant.com/2010/07/23/calculating-the-velocity-of-your-agile-projects/" rel="nofollow">http://michaellant.com/2010/07/23/calculating-the-velocity-of-your-agile-projects/</a>

blocks|key|2072784|text|十年前，当我第一次被提拔为首相时，我试图跟踪所有事情。归根结底，只有一件事是真正重要的，那就是团队的幸福(团队包括客户)。如果每个人都对项目的速度、质量和环境感到满意，那么您只需要调整任何有助于团队改进的指标。您可以在回顾中与团队一起确定这些指标。无论他们是否发现速度、功能点、提前期和周期时间、测试覆盖率或任何其他指标有用-这些都是您应该帮助他们衡量的东西。我认为一个新的PM可以关注的最强大的事情是沟通，而不是测量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2072785|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

When I was first promoted to PM, a decade ago, I tried to track everything. Only one thing really matters in the end and that is the team's happiness (the team includes the client). If everyone is content with the pace, quality, and environment of the project then you only need to adapt whatever metrics help the team to improve. You can identify those metrics with the team in retrospectives. Whether they find velocity, functional points, lead and cycle time, test coverage, or any other metrics useful - those are the things you should help them to measure. I think the most powerful thing a new PM can focus on is communication, not measurement.

I was promoted as a project manager. This is a new role for me and at the beginning I find this job pretty hard.

Can you give me some example of metrics that I could use to measure the quality and productivity of my team members? I need to measure that for developers and for testers.

Project management evaluate quality and productivity

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我被提升为项目经理。这对我来说是一个新的角色，一开始我发现这份工作很难。你能给我一些衡量标准的例子，我可以用来衡量我的团队成员的质量和生产力吗？我需要为开发人员和测试人员衡量这一点。

问项目管理评估质量和生产力
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问项目管理评估质量和生产力EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问项目管理评估质量和生产力
EN