Can anyone recommend the maximum number of hours a task should be in a project estimate breakdown? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

开发者_开发百科

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

What I mean is if I am breaking a programming project estimate down into tasks as much as possible would there be a good maximum to make the tasks. Meaning if I say the max is 4-6 then if any task is more hours than that it needs to be broken down into more tasks. I feel like there is a point where this becomes not much more useful though and think that a max of 10-12 hours is acceptable, the boss does not agree. The idea here is to be able to know as well as possible how much time is needed to complete the task but at the same time I think there is a point where too much breakdown is meaningless until you actually dive into the code. Any thoughts or common practice?

Make the breakdown structure detailed enough to allow you make a proper estimation, but not too detailed so you'll have trouble maintaining and tracking it later, when things change (not if things change, but when things change).

It doesn't really matter the number of hours a task in WBS is estimated.

When I was writing my own time breakdowns for a task, I found the most useful number to go with as a goal for a single task to be max'd at about 4 hours. Then, if it turned out to be really difficult and take a lot longer than I expected, it wasn't so terrible.

I don't think it is useful to actually hold any of these projects as meaningful unless: 1.) The person performing the task created the projection. 2.) The person creating the projection is familiar enough with the work.

At my last job, I didn't even start projecting tasks until I had been there for three months. After that, it was another month or two before my projections were meaningful.

I think that this is a very individual thing. If you are used to thinking about things at an extremely detailed level, it makes more sense to have lots of small tasks. If you like to think of things in more general terms, it makes sense to have a few big tasks. I believe if you and your boss try and enforce this sort of personal preference into task projection, you will find that your projections are meaningless at best and a creator of hostility at worst.

I hope my experiences and expression of them is useful to you.

-Brian J. Stinar-

What does a task look like?

write a document? Write a chapter of document? Write a sentence in a document?

Write a programme? Write a class? Write a method?

I think the following need to be true:

1). A task is big enough so that you know you've finished it. A single sentence or method doesn't stand alone. You typically can't deliver something that small in isolation, the receiver can't "test" it.

So, for example, you can unit test, document and check some code into an SCM that's a task.

I can't imagine tasks smaller than one hour, and typically for me they are half-days.

2). A task is small enough that you can be confident you can do it in the estimated time. You've analysed the problem well enough to understand the chunks.

People are not machines.

Having that said, the way I see it there are two main development modes:

develop
Maintain/fix

For the second one you can gain experience on how long tasks should take - the developer knows the code and most of the times he can give a good prediction what is wrong and what should be done to make it work (in that case tight monitoring + buffer to keep getting good cooperation is in order, if the developer can't get a good estimation - that is an indication of a very big problem)

For the first one - it's more complicated:

if this is hard labor job - one that requires no brain and just take the program from point a to point b than... you can define tight schedule.

If you need the developer to get creative, to think about good implementation etc... You can not wait forever for a masterpiece, yet you will not get much from a developer that have only survival thoughts :)

Learn about Agile -where the team leaders and the developers sets the goals together- the goals may be very demanding but within the development period the developer which feels as responsible as the manager... can manage his time.

So sometimes, with the correct management system - tasks can and perhaps should be a week long.

There is no magic number. Understand your type of programing and find an appropriate management management system.

Good luck