Hi,
This is a software management questions. If i asked to measure a software project task for my every task assigned to me, means how can i do that? Would it be in percentage (or) out of 10 (or) in man hours?
Any suggestions please?
thanks.
A:
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.
McKay
2009-11-11 16:49:42
Ok. When my boss says "provide outcome and measurement of each tasks assigned to me' means, what does mean here about 'measurement'. Is there anything like measuring software project tasks?
2009-11-11 16:57:37
I am talking about already finished project.
2009-11-11 17:38:15
+1
A:
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.
Thomas Owens
2009-11-11 16:49:52
All very well - but how do you answer "When will it be finished?"
Philip Wallace
2009-11-11 16:55:48
@PhilipW: Just make up a time (date), since it's never going to be accurate, anyway :)
HardCode
2009-11-11 17:03:04
HardCode's suggestion is the wrong thing to do. I've appended a few words on estimating to my answer. Hopefully that helps you address your issues.
Thomas Owens
2009-11-11 17:54:58
A:
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 :)
Jaime Soriano
2009-11-11 18:50:14
A:
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.
McKay
2009-11-11 20:03:43