Basically the idea is to observe how much it takes in your team to complete similar tasks to estimate how long it might take for another one of those to be finished.
I recommend reading Waltzing With Bears by Tom DeMarco and Tim Lister - it goes into schedule estimating in some depth.
As a rule of thumb I would say the probability of finishing any project within the lowest estimated time is approximately zero. This is both from the analysis they give in the book, and from personal experience.
I don't think you have the information to make that call. To do so you'd need to know whether the probability curve was normalised (probably) and whether it was skewed (almost certainly) plus what the various statistical values associated were (mean, standard deviation and so on).
If you have those I don't think you'd be asking. In addition to that your skill in estimating, the assumptions you've made and their accuracy and so on are all factors, most of which are very hard to quantify.
It's why evidence based scheduling is good - you don't have to understand exactly why things take a certain amount of time, you just know that they do.
A couple of simple things I'd say you should think about:
1) In my experience the realistic chances of it being your lowest estimate are roughly zero. Shit happens on software projects, most people aren't that good at estimating and things will go wrong. If you want a good estimate then go with that.
2) Think very carefully about what you want the number for. If you're going to give it to a client or most managers then:
(a) they won't remember the caveats, the won't remember the top end of the range and the won't remember the probabilities or the theory. They'll remember the nice low number you gave them and the rest is just "wah wah wah".
(b) clients and managers want certainty so you need to give them something you're certain about. If you assume that your estimate is normally distributed and you have your best case and worst case values, if you give them an average of the two you will miss your deadline 50% of the time. From a managers perspective that's bad. If you want to hit your deadline 95% of the time then you need to be giving the mean + 2 standard deviations. Again if you want a rough estimate then your worst case is probably the easiest number to grab.
Generally under promise and over deliver. Be the guy who never misses deadlines and often delivers early. That doesn't involve changing the way you work, you just have to manage expectations.
I suggest using Three Point Estimating. Assign Minimum, Most Likely, and Maximum time and type of Random Distribution (Pert, Triangle, Beta, etc. depending on the characteristics or historical data) to every of your tasks within the Project. Simulate with Monte Carlo for a number of times (e.g. 5000 times) and see what adds up. You can also go further by incorporating element of Risk (and also correlation between Risks if you wish) to get a better picture of what might happen. A tool such as Palisade @Risk might be able to help you.
Poisson has been done so many times, with the same low rate of success. I second evidence based scheduling, because it's self-correcting and works on actual data.
发布评论
评论（5）
基于证据的调度
基本上，这个想法是观察你的团队完成类似的任务，以估计完成另一项任务可能需要多长时间。
Evidence Based Scheduling
Basically the idea is to observe how much it takes in your team to complete similar tasks to estimate how long it might take for another one of those to be finished.
我建议阅读 Tom DeMarco 和 Tim Lister 撰写的 与熊跳华尔兹 - 它已按计划进行进行一定深度的估计。
根据经验，我会说在最短的估计时间内完成任何项目的概率大约为零。这既来自他们在书中给出的分析，也来自个人经验。
I recommend reading Waltzing With Bears by Tom DeMarco and Tim Lister - it goes into schedule estimating in some depth.
As a rule of thumb I would say the probability of finishing any project within the lowest estimated time is approximately zero. This is both from the analysis they give in the book, and from personal experience.
我认为你没有足够的信息来拨打这个电话。为此，您需要知道概率曲线是否标准化（可能）以及它是否倾斜（几乎肯定）以及相关的各种统计值（平均值、标准差等）。
如果你有这些，我想你就不会问了。除了你的估计能力之外，你所做的假设及其准确性等等都是因素，其中大部分是很难量化的。
这就是为什么基于证据的调度是好的——你不必确切地理解为什么事情需要一定的时间，你只需要知道它们确实如此。
我想说你应该考虑一些简单的事情：
1）根据我的经验，它是你的最低估计的现实可能性大约为零。软件项目中总会发生糟糕的事情，大多数人都不擅长估计，事情就会出错。如果你想要一个好的估计，那就这么做吧。
2) 仔细考虑一下你想要这个号码的用途。如果您打算将其交给客户或大多数经理，那么：
（a）他们不会记住警告，不会记住范围的上限，也不会记住概率或理论。他们会记住你给他们的低数字，剩下的只是“哇哇哇”。
(b) 客户和经理想要确定性，因此您需要向他们提供您确定的东西。如果你假设你的估计是正态分布的，并且你有最好情况和最坏情况的值，如果你给它们两者的平均值，你将有 50% 的时间错过最后期限。从管理者的角度来看，这很糟糕。如果你想在 95% 的时间内达到截止日期，那么你需要给出平均值 + 2 个标准差。同样，如果您想要粗略估计，那么最坏的情况可能是最容易获取的数字。
一般情况下，承诺不足，交付超额。成为一个永远不会错过最后期限并经常提前交付的人。这并不涉及改变你的工作方式，你只需要管理期望。
I don't think you have the information to make that call. To do so you'd need to know whether the probability curve was normalised (probably) and whether it was skewed (almost certainly) plus what the various statistical values associated were (mean, standard deviation and so on).
If you have those I don't think you'd be asking. In addition to that your skill in estimating, the assumptions you've made and their accuracy and so on are all factors, most of which are very hard to quantify.
It's why evidence based scheduling is good - you don't have to understand exactly why things take a certain amount of time, you just know that they do.
A couple of simple things I'd say you should think about:
1) In my experience the realistic chances of it being your lowest estimate are roughly zero. Shit happens on software projects, most people aren't that good at estimating and things will go wrong. If you want a good estimate then go with that.
2) Think very carefully about what you want the number for. If you're going to give it to a client or most managers then:
(a) they won't remember the caveats, the won't remember the top end of the range and the won't remember the probabilities or the theory. They'll remember the nice low number you gave them and the rest is just "wah wah wah".
(b) clients and managers want certainty so you need to give them something you're certain about. If you assume that your estimate is normally distributed and you have your best case and worst case values, if you give them an average of the two you will miss your deadline 50% of the time. From a managers perspective that's bad. If you want to hit your deadline 95% of the time then you need to be giving the mean + 2 standard deviations. Again if you want a rough estimate then your worst case is probably the easiest number to grab.
Generally under promise and over deliver. Be the guy who never misses deadlines and often delivers early. That doesn't involve changing the way you work, you just have to manage expectations.
我建议使用三点估计。为项目中的每个任务分配最小、最可能和最大时间以及随机分布类型（Pert、三角形、Beta 等，具体取决于特征或历史数据）。使用蒙特卡罗进行多次模拟（例如 5000 次），看看加起来是什么。您还可以进一步合并风险元素（如果您愿意，还可以合并风险之间的相关性），以更好地了解可能发生的情况。 Palisade @Risk 等工具也许可以帮助您。
I suggest using Three Point Estimating. Assign Minimum, Most Likely, and Maximum time and type of Random Distribution (Pert, Triangle, Beta, etc. depending on the characteristics or historical data) to every of your tasks within the Project. Simulate with Monte Carlo for a number of times (e.g. 5000 times) and see what adds up. You can also go further by incorporating element of Risk (and also correlation between Risks if you wish) to get a better picture of what might happen. A tool such as Palisade @Risk might be able to help you.
泊松已经做了很多次了，成功率同样很低。我第二个基于证据的调度，因为它是自我纠正的并且适用于实际数据。
Poisson has been done so many times, with the same low rate of success. I second evidence based scheduling, because it's self-correcting and works on actual data.