为什么开发人员不能估算时间？
Why can't developers estimate time?
为什么开发人员不能估算时间？
We can't estimate the time for any individual task in software development because the nature of the work is creating new knowledge.
在软件开发中，我们不能估算单项任务所需的时间，因为工作的本质是创造新的知识。
The goal of software development is to automate processes. Once a process is automated, it can be run repeatedly, and in most cases, in a predictable time. Source code is like a manufacturing blueprint, the computer is like a manufacturing plant, the inputs (data) are like raw materials, and the outputs (data) are like finished goods. To use another analogy, the reason Starbucks makes drinks so quickly and repeatably is because they invested a lot of time in the design of the process, which was (and is, ongoing) a complex and expensive task. Individual Starbucks franchises don't have to re-discover this process, they just buy the blueprint. I'll leave it as an exercise to the reader to infer my opinion of the Costa coffee-making process.
软件开发的目标是使流程自动化，流程一旦自动化，多数情况下可以在可预测的时间内重复执行。源代码就像蓝图，计算机像工厂，输入（数据）像原材料，输出（数据）像成品。另一个比喻是，星巴克可高效地重复生产饮料，原因是他们投入了大量的时间去做流程设计，这曾经（仍然、继续）是一项复杂且高消耗的任务。星巴克的个人经营者不需要重新研发此流程，他们只需要购买蓝图即可。至于Costa咖啡制作流程的隐喻，且让读者来推测我的看法。
It's not actually always a problem that development time is unpredictable, because the flipside is that so is the value returned. A successful piece of software can make or save vastly more than its cost. Tom DeMarco argues for focussing on the high value projects for exactly this reason. Note that this does require a value-generation mindset, rather than the currently-prevalent cost-control mindset. This is a non-trivial problem.
开发时间不可预计不一定导致问题，因为另一方面你有价值回报。一款成功的软件可以创造或节省远远大于成本的价值，因此，Tom DeMarco 呼吁要把重点放在高价值回报的项目。注意，这需要一种创造价值的理念，而不是当前流行的成本控制的理念。这是一个值得正视的问题。
By far the best explanation I've read of variability and how to exploit it for value is Don Reinertsen's Principles of Product Development Flow, which is pretty much the adopted "PatchSpace Bible" for day-to-day process management. And when I say "by far the best", I mean by an order of magnitude above pretty much everything else I've read, apart from the Theory of Constraints literature.
至今为止，关于变数和如何将它转化为价值的最好解析是Don Reinertsen的《产品开发流程的原则》，它是日常流程管理中最应该被采用的圣经（PatchSpace Bible）。我说的"至今为止"，意思是我的认知范围中的最好，而不是根据什么原则。
Here is the data from my last development project. (Histogram generated in R with 5-hour buckets: the horizontal axis shows the duration in hours for the user stories - 0-5 hours, 5-10 hours, etc; the vertical axis is the number of stories that took that duration). We worked in 90 minute intervals and journaled the work on Wave, so we knew task durations to a pretty fine resolution. (We did this for both client communication and billing purposes.) The result: our development times were about as predictable as radioactive decay, but they were very consistently radioactive. Correlation with estimates was so poor I refused to estimate individual tasks, as it would have been wilfully misleading, but we had enough data to make sensible aggregates.
下面是我最近一个项目的数据，直方图的每一柱横跨五小时：横坐标指示用户素材（user stories）的工作量，0-5小时，5-10小时等；纵坐标指示相应的用户素材的数量。我们每工作90分钟做一次记录，所以我们对任务的工作时间有清楚的认识（我们这样做源于客户交流与开账单）。结果是：我们的开发时间的可预测就像放射性衰变那样，但它们始终如一放射。估算的精确度如此差，会严重误导人，以致我拒绝估算单项任务，但我们有足够的数据来对总体任务做明智的估算。
Rule of thumb: take the estimates of a developer, double it and add a bit
经验法则：采取开发人员的评估时间，翻倍再加一点
The double-and-add-a-bit rule is interesting. When managers do this, how often are tasks completed early? We generally pay much more attention to overruns than underruns. If a team is not completing half of its tasks early, it is padding the estimates, and that means trading development cycle time for project schedule. Cycle time is usually much more valuable than predictability, as it means getting to market sooner. Again, see Reinertsen's work, the numbers can come out an order of magnitude apart.
"翻倍再加一点"的规则很有意思。若管理者这样做，任务提前完成的概率有多大？我们通常更注重高估时间而不是低估时间。如果团队不能尽早完成一半任务，很可能将超出估算，这意味着要拿项目计划的开发周期做代价。开发周期（Cycle time）比可预测性（predictability）更有价值，它意味着更早把产品推向市场。借用Reinertsen的结论，可能相差一个数量级。
Also, this is the basis for Critical Chain project management, which halves the "safe" estimates to condense the timescale, and puts the remaining time (padding on individual tasks) at the end, as a "project buffer". This means that Parkinson's Law doesn't cause individual tasks to expand unduly. I'm unconvinced that Critical Chain is an appropriate method for software though, as the actual content of development work can change significantly, as feedback and learning improves the plan.
并且，这是关键链（Critical Chain）项目管理的基础，把"安全"估算减半来压缩时间跨度，把后期的剩余时间（单项任务的增补时间）作为"项目缓冲期"。这意味着Parkinson法则不会引起单项任务过度延期。我不赞同关键链是一种软件的适当方法，由于开发工作的实际内容可能差异极大，反馈、学习可以改善工作计划。
People in general just make shit up
大部分人都是在忽悠（make shit up）
It's not just developers that are bad with estimates either. Everyone at some point is just winging it because it's something they've never done before and won't be able to successfully make a judgement until they have.
不仅仅是开发人员才估算失准，某种程度上人人都会失准，因为事情之前没有做过，难以做正确的估算，除非已经做过。
As a community we need to get away from this. If we don't know, we don't know, and we need to say it. Clients who see regular progress on tasks they were made aware were risky (and chose to invest in) have much more trust in their team than clients whose teams make shit up. It's true! Srsly. Don't just take my word for it, though - read David Anderson's Kanban.
作为一个团体，我们须要避免这种情况。如果我们不清楚，我们就真不清楚，我们要说出来。对于意识到有风险（并选择投资）的任务，看见正常的进度的客户比被团队忽悠的客户对团队更加信任。这是真的！但是，不要总相信我的话——请看David Anderson的Kanban。
Estimating is a very important skill and should be taught more in junior dev roles
