When estimating tasks, how does one break from the grip of Hofstadter's law?
在估算任务时,如何摆脱Hofstadter定律的束缚?
12 个解决方案
#1
If you can politically: Estimate in small chunks, work in small iterations, and focus attention on what caused the deviation from the estimate to make the next estimate better.
如果你可以在政治上:在小块中进行估计,在小的迭代中工作,并将注意力集中在导致偏离估计的因素上,以使下一个估计更好。
One of the major causes of bad estimates in my experience is the lack of experience actually using the architecture planned for the project. By adjusting the estimates as things become more concrete and clear the estimates get better over time.
根据我的经验估算不佳的一个主要原因是缺乏实际使用项目计划架构的经验。通过调整估计值,事情变得更加具体和明确,估计值随着时间的推移会变得更好。
The other major cause of bad estimates is bogus estimates. Estimates kept artificially low to win a bid. The only way a consulting firm can break that cycle is give good estimates and win enough projects and deliver on the estimates to earn a reputation that they hit their estimates. Enough clients will respect that to make a reasonable business out of it, but building that up will be hard.
造成不良估计的另一个主要原因是虚假估计。估计人为压低,以赢得出价。咨询公司打破这一周期的唯一方法就是给出良好的估计并赢得足够的项目并实现估算,以获得他们达到预期的声誉。足够的客户会尊重这一点,以便从中获得合理的业务,但建立起来将很难。
#2
Hofstadter's Law is not meant to be taken seriously --- if it were true to the letter, every task would take an infinite amount of time if you took Hofstadter's Law into account.
霍夫施塔特定律不应该被认真对待 - 如果这封信是真的,如果考虑到霍夫施塔特定律,每项任务都会花费无限的时间。
#3
- Estimate how long time something should take to code.
- Multiply by pi.
- Be amazed by how often that is closer to how long it actually takes.
估计应该花多长时间来编写代码。
乘以pi。
令人惊讶的是它接近实际需要多长时间。
(This is also not to be taken as a scientific method, but it is another way of expressing how hard it is to correctly estimate time. I really use it sometimes, though...)
(这也不是一种科学方法,但它是表达正确估计时间有多难的另一种表达方式。我有时会使用它,尽管......)
:)
Edit:
A method that is a bit more scientific: Specify a time for the absolute minimum and maximum time for a task, for example that it will definitely take between 5 and 30 hours. (Divide into subtasks to possibly narrow the time span somewhat.) You get a very wide time span, but at least it's more reliable than a guesstimate.
编辑:一种更科学的方法:指定任务的绝对最小和最大时间的时间,例如,它肯定需要5到30小时。 (分为子任务可能会缩短时间跨度。)你得到的时间跨度很长,但至少它比猜测更可靠。
#4
While "Hofstadter's Law" is a bit tongue-in-cheek, there are a couple of practices that can help you, in particular for first-pass/large item estimation:
虽然“Hofstadter定律”有点诙谐,但有一些实践可以帮助你,尤其是首次通过/大项目估算:
-
Estimate in relative sizes. Meaning you don't say that an item takes X time, you say that an item A is twice as big as item B, and that item B is about 4 time as large as item C.
估计相对大小。意思是你没有说项目需要X时间,你说项目A是项目B的两倍,项目B大约是项目C的4倍。
-
Gather data from previous estimating rounds and use it as a base line. So that when you are estimating a project, and notice that item A is about as big as item B from a previous iteration/project, and you know that item B has taken 2 days, you know that item A will most likely take about as long
从先前的估算轮次中收集数据并将其用作基线。因此,当您估算一个项目时,并注意到项目A与前一个迭代/项目中的项目B一样大,并且您知道项目B花了2天时间,您知道项目A很可能需要长
-
Use "wisdom-of-the-crowds" to get higher quality estimates. I've used Planning Poker in a couple of projects and the outcomes are rather good.
使用“智慧的人群”来获得更高的质量估算。我在几个项目中使用了规划扑克,结果相当不错。
If you want to know more about this you can start by watch Mike Cohn's presentation (Part 1 and Part 2) and/or read his book. While it's not the end-all,be-all of estimation, he does present some good practices and best of all, the reasoning behind the practices.
如果您想了解更多相关信息,可以先观看Mike Cohn的演讲(第1部分和第2部分)和/或阅读他的书。虽然这不是最终目标,但总的来说,他确实提出了一些好的做法,最重要的是,这些做法背后的原因。
#5
See Evidence-Based Scheduling. There is already a SO discussion of some of its pitfalls here.
参见基于证据的调度。这里已经讨论了一些陷阱。
#6
I used dice. Openly. In front of my manager. Typically I use 3 standard six-sided dice.
我用过骰子。公然。在我的经理面前。通常我使用3个标准的六面骰子。
Boss: "How long is this going to take?"
老板:“要花多长时间?”
Me: (rolls) "About 11 days."
我:(卷)“大约11天。”
Boss: "No, seriously."
老板:“不,认真。”
Me: "Oh, seriously." (rolls) "About 7 days."
我:“哦,认真。” (卷)“大约7天。”
I also used to have a poster on my wall that said "Deadlines Amuse Me". Take from that what you will.
我曾经在我的墙上贴了一张海报,上面写着“Deadlines Am Me Me”。从那个你想要的东西。
#7
Base you estimates on past performance, not on best case scenarios. This does require you keep track of time spent on your projects. I don't care if you "know" that it will only take "6 weeks" to finish, if it took you 3 months to complete a similar project last time, it will probably take you 3 months the next time.
根据您对过去绩效的估计,而不是最佳案例情景。这确实需要您跟踪项目所花费的时间。我不在乎你是否“知道”它只需要“6周”才能完成,如果你上次完成一个类似的项目需要3个月的时间,那么下次你可能需要3个月。
#8
+1 for @Yishai - one of the benefits of an agile methodology like scrum is that people actually get feedback on the accuracy of their estimates.
@Yishai的+1 - 敏捷方法(如scrum)的好处之一是人们实际上可以获得有关其估算准确性的反馈。
You're never going to get better at something if you never know if you're wrong...
如果你不知道自己是不是错了,你永远不会变得更好......
#9
I like this method:
我喜欢这种方法:
- Make an honest estimate of the effort required for the task.
- Apply a multiplier to the estimate. At least 1.5 probably 2.0. With time comparing actual effort to estimated effort you will be able to calculate the true multiplier.
对该任务所需的工作做出诚实的估计。
对估计值应用乘数。至少1.5可能是2.0。通过将实际工作量与估计工作量进行比较,您将能够计算出真实的乘数。
Collecting the estimated and actual efforts are key to improving your estimates.
收集估计和实际工作是提高估算的关键。
#10
Agile estimation always uses "ideal hours" which implicitly takes into account Hofstadter's law. So you don't need to fudge.
敏捷估计总是使用“理想时间”,隐含地考虑了霍夫施塔特定律。所以你不需要捏造。
If you're answering as an employee ...
如果你作为一名员工回答......
"Gee, boss, In a perfect world it would take X days. Let's add a cushion to it and I'll do all I can to get it to you in that amount of time. If the estimate changes I'll let you know immediately."
“哎呀,老板,在一个完美的世界里,需要X天。让我们为它添加一个缓冲,我会尽我所能在这段时间内把它给你。如果估计有所改变,我会告诉你立即。”
That is music to a boss's ears!
这是老板耳朵的音乐!
If you're answering as the business owner ...
如果你作为企业主回答......
You only give estimates to your customers when backed into a corner. Then you use ideal days with clear disclaimers and be ready to adjust because you're aware of Hofstadter's law.
您只需在支持角落时向客户提供估算值。然后你使用明确免责声明的理想日子,并随时准备调整因为你了解Hofstadter定律。
#11
Estimating is an art, as you know and there is a sub art that is the art of estimating contingency. :) In order to properly estimate contingency (generally a % of a total estimate), one must understand risks and mitigations. Basically, you multiply the risk of something happening with the damage it can do to come up with a risk factor. Then, you sum up all your risk factors and estimate your total risk. Contingency should range from 15% for very low risk projects (I never go below 15% contingency) to 50% for very high risk (it has been my experience that very few customers will except a higher than 50% contingency estimate).
正如您所知,估算是一门艺术,并且有一种子艺术是估计偶然性的艺术。 :)为了正确估计意外事件(通常是总估计的百分比),必须了解风险和缓解措施。基本上,您将发生事件的风险与可能造成的损害相乘以提出风险因素。然后,您总结所有风险因素并估算您的总风险。对于非常低风险的项目(我从未低于15%的应急费用),应急率应该从15%到非常高风险的50%(根据我的经验,除了超过50%的应急预测外,很少有客户会这样做)。
#12
Hofstadter's law is just another implication of how notorious self-referencing is !..... the subtle humour has far reaching effects. In hindsight this law confirms that every law/principle/axiom which is structured by logic, is incomplete (Godel like), thus even taking such laws into concern, the logic may never be complete. The sense of infinity is again a play from Zeno's paradox (turtle vs. Achilles).... infinite time for Achilles to complete the race ....etc .... these are illustrations of the omnipotent evil of self referencing which contaminates all affine logical structure.
霍夫施塔特定律只是臭名昭着的自我引用的另一个含义!......微妙的幽默具有深远的影响。事后看来,这项法律确认了由逻辑构成的每一条法律/原则/公理都是不完整的(Godel喜欢),因此即使关注这些法律,逻辑也许永远不会完整。无限感再次成为芝诺悖论(乌龟与阿基里斯)的游戏......阿基里斯完成比赛的无限时间......等......这些都是自我引用的无所不能的邪恶的例证,污染了所有仿射逻辑结构。
#1
If you can politically: Estimate in small chunks, work in small iterations, and focus attention on what caused the deviation from the estimate to make the next estimate better.
如果你可以在政治上:在小块中进行估计,在小的迭代中工作,并将注意力集中在导致偏离估计的因素上,以使下一个估计更好。
One of the major causes of bad estimates in my experience is the lack of experience actually using the architecture planned for the project. By adjusting the estimates as things become more concrete and clear the estimates get better over time.
根据我的经验估算不佳的一个主要原因是缺乏实际使用项目计划架构的经验。通过调整估计值,事情变得更加具体和明确,估计值随着时间的推移会变得更好。
The other major cause of bad estimates is bogus estimates. Estimates kept artificially low to win a bid. The only way a consulting firm can break that cycle is give good estimates and win enough projects and deliver on the estimates to earn a reputation that they hit their estimates. Enough clients will respect that to make a reasonable business out of it, but building that up will be hard.
造成不良估计的另一个主要原因是虚假估计。估计人为压低,以赢得出价。咨询公司打破这一周期的唯一方法就是给出良好的估计并赢得足够的项目并实现估算,以获得他们达到预期的声誉。足够的客户会尊重这一点,以便从中获得合理的业务,但建立起来将很难。
#2
Hofstadter's Law is not meant to be taken seriously --- if it were true to the letter, every task would take an infinite amount of time if you took Hofstadter's Law into account.
霍夫施塔特定律不应该被认真对待 - 如果这封信是真的,如果考虑到霍夫施塔特定律,每项任务都会花费无限的时间。
#3
- Estimate how long time something should take to code.
- Multiply by pi.
- Be amazed by how often that is closer to how long it actually takes.
估计应该花多长时间来编写代码。
乘以pi。
令人惊讶的是它接近实际需要多长时间。
(This is also not to be taken as a scientific method, but it is another way of expressing how hard it is to correctly estimate time. I really use it sometimes, though...)
(这也不是一种科学方法,但它是表达正确估计时间有多难的另一种表达方式。我有时会使用它,尽管......)
:)
Edit:
A method that is a bit more scientific: Specify a time for the absolute minimum and maximum time for a task, for example that it will definitely take between 5 and 30 hours. (Divide into subtasks to possibly narrow the time span somewhat.) You get a very wide time span, but at least it's more reliable than a guesstimate.
编辑:一种更科学的方法:指定任务的绝对最小和最大时间的时间,例如,它肯定需要5到30小时。 (分为子任务可能会缩短时间跨度。)你得到的时间跨度很长,但至少它比猜测更可靠。
#4
While "Hofstadter's Law" is a bit tongue-in-cheek, there are a couple of practices that can help you, in particular for first-pass/large item estimation:
虽然“Hofstadter定律”有点诙谐,但有一些实践可以帮助你,尤其是首次通过/大项目估算:
-
Estimate in relative sizes. Meaning you don't say that an item takes X time, you say that an item A is twice as big as item B, and that item B is about 4 time as large as item C.
估计相对大小。意思是你没有说项目需要X时间,你说项目A是项目B的两倍,项目B大约是项目C的4倍。
-
Gather data from previous estimating rounds and use it as a base line. So that when you are estimating a project, and notice that item A is about as big as item B from a previous iteration/project, and you know that item B has taken 2 days, you know that item A will most likely take about as long
从先前的估算轮次中收集数据并将其用作基线。因此,当您估算一个项目时,并注意到项目A与前一个迭代/项目中的项目B一样大,并且您知道项目B花了2天时间,您知道项目A很可能需要长
-
Use "wisdom-of-the-crowds" to get higher quality estimates. I've used Planning Poker in a couple of projects and the outcomes are rather good.
使用“智慧的人群”来获得更高的质量估算。我在几个项目中使用了规划扑克,结果相当不错。
If you want to know more about this you can start by watch Mike Cohn's presentation (Part 1 and Part 2) and/or read his book. While it's not the end-all,be-all of estimation, he does present some good practices and best of all, the reasoning behind the practices.
如果您想了解更多相关信息,可以先观看Mike Cohn的演讲(第1部分和第2部分)和/或阅读他的书。虽然这不是最终目标,但总的来说,他确实提出了一些好的做法,最重要的是,这些做法背后的原因。
#5
See Evidence-Based Scheduling. There is already a SO discussion of some of its pitfalls here.
参见基于证据的调度。这里已经讨论了一些陷阱。
#6
I used dice. Openly. In front of my manager. Typically I use 3 standard six-sided dice.
我用过骰子。公然。在我的经理面前。通常我使用3个标准的六面骰子。
Boss: "How long is this going to take?"
老板:“要花多长时间?”
Me: (rolls) "About 11 days."
我:(卷)“大约11天。”
Boss: "No, seriously."
老板:“不,认真。”
Me: "Oh, seriously." (rolls) "About 7 days."
我:“哦,认真。” (卷)“大约7天。”
I also used to have a poster on my wall that said "Deadlines Amuse Me". Take from that what you will.
我曾经在我的墙上贴了一张海报,上面写着“Deadlines Am Me Me”。从那个你想要的东西。
#7
Base you estimates on past performance, not on best case scenarios. This does require you keep track of time spent on your projects. I don't care if you "know" that it will only take "6 weeks" to finish, if it took you 3 months to complete a similar project last time, it will probably take you 3 months the next time.
根据您对过去绩效的估计,而不是最佳案例情景。这确实需要您跟踪项目所花费的时间。我不在乎你是否“知道”它只需要“6周”才能完成,如果你上次完成一个类似的项目需要3个月的时间,那么下次你可能需要3个月。
#8
+1 for @Yishai - one of the benefits of an agile methodology like scrum is that people actually get feedback on the accuracy of their estimates.
@Yishai的+1 - 敏捷方法(如scrum)的好处之一是人们实际上可以获得有关其估算准确性的反馈。
You're never going to get better at something if you never know if you're wrong...
如果你不知道自己是不是错了,你永远不会变得更好......
#9
I like this method:
我喜欢这种方法:
- Make an honest estimate of the effort required for the task.
- Apply a multiplier to the estimate. At least 1.5 probably 2.0. With time comparing actual effort to estimated effort you will be able to calculate the true multiplier.
对该任务所需的工作做出诚实的估计。
对估计值应用乘数。至少1.5可能是2.0。通过将实际工作量与估计工作量进行比较,您将能够计算出真实的乘数。
Collecting the estimated and actual efforts are key to improving your estimates.
收集估计和实际工作是提高估算的关键。
#10
Agile estimation always uses "ideal hours" which implicitly takes into account Hofstadter's law. So you don't need to fudge.
敏捷估计总是使用“理想时间”,隐含地考虑了霍夫施塔特定律。所以你不需要捏造。
If you're answering as an employee ...
如果你作为一名员工回答......
"Gee, boss, In a perfect world it would take X days. Let's add a cushion to it and I'll do all I can to get it to you in that amount of time. If the estimate changes I'll let you know immediately."
“哎呀,老板,在一个完美的世界里,需要X天。让我们为它添加一个缓冲,我会尽我所能在这段时间内把它给你。如果估计有所改变,我会告诉你立即。”
That is music to a boss's ears!
这是老板耳朵的音乐!
If you're answering as the business owner ...
如果你作为企业主回答......
You only give estimates to your customers when backed into a corner. Then you use ideal days with clear disclaimers and be ready to adjust because you're aware of Hofstadter's law.
您只需在支持角落时向客户提供估算值。然后你使用明确免责声明的理想日子,并随时准备调整因为你了解Hofstadter定律。
#11
Estimating is an art, as you know and there is a sub art that is the art of estimating contingency. :) In order to properly estimate contingency (generally a % of a total estimate), one must understand risks and mitigations. Basically, you multiply the risk of something happening with the damage it can do to come up with a risk factor. Then, you sum up all your risk factors and estimate your total risk. Contingency should range from 15% for very low risk projects (I never go below 15% contingency) to 50% for very high risk (it has been my experience that very few customers will except a higher than 50% contingency estimate).
正如您所知,估算是一门艺术,并且有一种子艺术是估计偶然性的艺术。 :)为了正确估计意外事件(通常是总估计的百分比),必须了解风险和缓解措施。基本上,您将发生事件的风险与可能造成的损害相乘以提出风险因素。然后,您总结所有风险因素并估算您的总风险。对于非常低风险的项目(我从未低于15%的应急费用),应急率应该从15%到非常高风险的50%(根据我的经验,除了超过50%的应急预测外,很少有客户会这样做)。
#12
Hofstadter's law is just another implication of how notorious self-referencing is !..... the subtle humour has far reaching effects. In hindsight this law confirms that every law/principle/axiom which is structured by logic, is incomplete (Godel like), thus even taking such laws into concern, the logic may never be complete. The sense of infinity is again a play from Zeno's paradox (turtle vs. Achilles).... infinite time for Achilles to complete the race ....etc .... these are illustrations of the omnipotent evil of self referencing which contaminates all affine logical structure.
霍夫施塔特定律只是臭名昭着的自我引用的另一个含义!......微妙的幽默具有深远的影响。事后看来,这项法律确认了由逻辑构成的每一条法律/原则/公理都是不完整的(Godel喜欢),因此即使关注这些法律,逻辑也许永远不会完整。无限感再次成为芝诺悖论(乌龟与阿基里斯)的游戏......阿基里斯完成比赛的无限时间......等......这些都是自我引用的无所不能的邪恶的例证,污染了所有仿射逻辑结构。