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.
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.
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.
发布评论
评论（4）
使分解结构足够详细，以便您做出正确的估计，但不要太详细，这样当事情发生变化时，您将难以维护和跟踪它（不是如果事情发生变化，而是当事情发生变化时）。
WBS 中任务的估计小时数并不重要。
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.
当我为一项任务编写自己的时间分解时，我发现最有用的数字可以作为单个任务的最大时间约为 4 小时的目标。然后，如果事实证明这真的很困难并且花费的时间比我预期的要长得多，那也没有那么可怕。
我认为让这些项目真正有意义是没有用的，除非：
1.) 执行任务的人创建了投影。
2.) 创建投影的人对作品足够熟悉。
在我的上一份工作中，我什至直到三个月后才开始计划任务。此后，又过了一两个月，我的预测才变得有意义。
我认为这是一个非常个人化的事情。如果你习惯于非常详细地思考事情，那么做很多小任务就更有意义。如果你喜欢从更笼统的角度思考问题，那么承担一些大任务是有意义的。我相信，如果你和你的老板尝试将这种个人偏好强制执行到任务预测中，你会发现你的预测充其量是毫无意义的，最坏的情况是会产生敌意。
我希望我的经历和表达对你有用。
-布莱恩·J·斯蒂纳尔-
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-
任务是什么样的？
写一个文件？写一章文档？在文档中写一句话？
写个程序？写个类？写个方法？
我认为以下几点必须正确：
1）。任务足够大，以至于您知道自己已经完成了。单个句子或方法并不是孤立的。您通常无法单独交付这么小的东西，接收者无法“测试”它。
例如，您可以对某些代码进行单元测试、记录并将其签入 SCM 中，这就是一项任务。
我无法想象少于一小时的任务，对我来说通常是半天。
2）。任务足够小，您可以确信自己可以在预计的时间内完成它。您已经很好地分析了问题，能够理解其中的各个部分。
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.
人不是机器。
话虽如此，我认为有两种主要的开发模式：
对于第二种模式，您可以获得任务应该花费多长时间的经验 - 开发人员知道代码，并且大多数时候他可以给出很好的建议预测出了什么问题以及应该采取什么措施才能使其正常工作（在这种情况下，严格的监控+缓冲以保持良好的合作是必要的，如果开发人员无法得到良好的估计 - 这表明存在一个非常大的问题）
对于第一个 - 它更复杂：
如果这是一项艰苦的劳动工作 - 一个不需要大脑并且只需将程序从 a 点到 b 点的工作，那么你可以定义紧凑的时间表。
如果您需要开发人员发挥创造力，考虑良好的实施等...您不可能永远等待杰作，但您不会从只有生存想法的开发人员那里得到太多:)
了解敏捷 - 团队在哪里领导者和开发人员共同设定目标——目标可能非常苛刻，但在开发期间，感觉与经理一样负责的开发人员......可以管理他的时间。
因此，有时，通过正确的管理系统，任务可以而且也许应该持续一周。
没有神奇的数字。了解您的编程类型并找到合适的管理系统。
祝你好运
People are not machines.
Having that said, the way I see it there are two main development modes:
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