I prefer the done/not-done approach. Either a task that is assigned to me is "done", meaning it's been implemented and tested, or it's "not done". If I'm asked how long I've been working on it, I do track man-hours, but it's not a measure of completeness at all.
Another approach that some people use is "in progress", "implemented", or "complete". "In progress" means that they are currently designing and/or implementing a solution, "implemented" means they are done with code and testing (or waiting on QA to validate the fix) and "complete" means it's all coded and tested.
The problem with percentages is the 80/20 rule. The first 80% of the work will take 20% of the time. The other 20% will take 80% of the time. If you have been working on something for 9 hours and are "90% done" implementing functionality, it doesn't mean you'll be 100% done in 1 hour.
If you are working on something (or have been assigned something), and someone asks how long it will take to finish, give your best estimate in hours, days, weeks...whatever. However, don't estimate too soon - take a look at the problem and requirements and never give an off-the-cuff estimate - it'll (almost) always be wrong. When you estimate, look at similar problems that you have solved in the past and use how long it took you to solve them as a guideline or basis for your estimate.
This idea comes from proxy-based estimating, which is part of the Personal Software Process. It's suitable if you are working on a task on your own. I'm not sure how well it will scale for a team.
If you are talking about finished tasks, what you're probably being asked for is for the time (probably in hours) dedicated to each one of the tasks.
How do you know that? You should use some timetracking tool, so at the end of the project (or in any moment) you can know how much time you have dedicated to any of the tasks (and/or breaks, meetings...). If you haven't registered your times, you'll have to make up them, and pray :)
If the project is finished, and he needs to know how many hours were spent on a project to bill it to a customer or something, then you should be keeping very accurate track, maybe using a tool or something.
But he might be referring to how effective the task is. For Example, if he asked you to reduce the load on the foozit, then you should measure the load on the foozit before and after your fixes.
But I think what you're asking is "How do we measure tasks in software development?" And the only sensible way to measure a task is hours. Some people like to measure how many lines of code that have been written, how many bugs were found, or how many tests they've written, but in my opinion, those aren't things that should really be measured for most projects.
发布评论
评论（4）
我更喜欢“完成/未完成”的方法。分配给我的任务要么“完成”，意味着它已经实施和测试，要么“未完成”。如果有人问我已经为此工作了多长时间，我会跟踪工时，但这根本不是完整性的衡量标准。
有些人使用的另一种方法是“正在进行”、“已实施”或“完成”。 “正在进行”意味着他们当前正在设计和/或实施解决方案，“实施”意味着他们已完成代码和测试（或等待 QA 验证修复），“完成”意味着所有代码和测试都已完成。
百分比的问题在于80/20 规则。前80%的工作将花费20%的时间。另外20%需要80%的时间。如果您已经在某件事上工作了 9 个小时并且“完成了 90%”实现功能，这并不意味着您将在 1 小时内完成 100%。
如果您正在做某件事（或已被分配某件事），并且有人问需要多长时间才能完成，请以小时、天、周等为单位给出您的最佳估计。然而，不要估计得太早——看看问题和需求，永远不要给出即兴的估计——它（几乎）总是错误的。当你进行估算时，看看你过去解决过的类似问题，并使用你解决这些问题所花费的时间作为你估算的指南或基础。
这个想法来自基于代理的估计，它是个人软件流程的一部分。如果您正在独自完成一项任务，那么它很适合。我不确定它对于团队的扩展效果如何。
I prefer the done/not-done approach. Either a task that is assigned to me is "done", meaning it's been implemented and tested, or it's "not done". If I'm asked how long I've been working on it, I do track man-hours, but it's not a measure of completeness at all.
Another approach that some people use is "in progress", "implemented", or "complete". "In progress" means that they are currently designing and/or implementing a solution, "implemented" means they are done with code and testing (or waiting on QA to validate the fix) and "complete" means it's all coded and tested.
The problem with percentages is the 80/20 rule. The first 80% of the work will take 20% of the time. The other 20% will take 80% of the time. If you have been working on something for 9 hours and are "90% done" implementing functionality, it doesn't mean you'll be 100% done in 1 hour.
If you are working on something (or have been assigned something), and someone asks how long it will take to finish, give your best estimate in hours, days, weeks...whatever. However, don't estimate too soon - take a look at the problem and requirements and never give an off-the-cuff estimate - it'll (almost) always be wrong. When you estimate, look at similar problems that you have solved in the past and use how long it took you to solve them as a guideline or basis for your estimate.
This idea comes from proxy-based estimating, which is part of the Personal Software Process. It's suitable if you are working on a task on your own. I'm not sure how well it will scale for a team.
你是什么意思？
如果你的意思是“我的老板要我估计每项任务将如何完成”。那么这可能应该在几个小时内完成。
如果你还有别的意思，你就得澄清一下。
What do you mean?
If you mean "My boss wants me to estimate how each task will take me." Then that should probably be done in hours.
If you mean something else, you'll have to clarify.
如果您正在谈论已完成的任务，那么您可能会被要求的是专门用于每一项任务的时间（可能以小时为单位）。
你怎么知道的？您应该使用一些时间跟踪工具，因此在项目结束时（或在任何时刻）您可以知道您在任何任务上投入了多少时间（和/或休息、会议...）。如果你还没有登记你的时间，你就得补上，然后祈祷:)
If you are talking about finished tasks, what you're probably being asked for is for the time (probably in hours) dedicated to each one of the tasks.
How do you know that? You should use some timetracking tool, so at the end of the project (or in any moment) you can know how much time you have dedicated to any of the tasks (and/or breaks, meetings...). If you haven't registered your times, you'll have to make up them, and pray :)
如果项目完成了，并且他需要知道在项目上花费了多少小时才能向客户开具账单或其他东西，那么您应该保持非常准确的跟踪，也许使用工具或其他东西。
但他可能指的是这项任务的有效性。例如，如果他要求您减少 foozit 上的负载，那么您应该在修复之前和之后测量 foozit 上的负载。
但我认为你问的是“我们如何衡量软件开发中的任务？”衡量任务的唯一合理方法是时间。有些人喜欢衡量已经编写了多少行代码，发现了多少错误，或者编写了多少测试，但在我看来，对于大多数项目来说，这些并不是真正应该衡量的事情。
If the project is finished, and he needs to know how many hours were spent on a project to bill it to a customer or something, then you should be keeping very accurate track, maybe using a tool or something.
But he might be referring to how effective the task is. For Example, if he asked you to reduce the load on the foozit, then you should measure the load on the foozit before and after your fixes.
But I think what you're asking is "How do we measure tasks in software development?" And the only sensible way to measure a task is hours. Some people like to measure how many lines of code that have been written, how many bugs were found, or how many tests they've written, but in my opinion, those aren't things that should really be measured for most projects.