Good cooking fakes time. If you are made to wait, it is to serve you better, and to please you.
（美酒的酿造需要年头，美食的烹调需要时间，片刻的等待，它将给你最好的，）
More software projects have gone awry for lack of calendar time than for all other causes combined.
（在众多软件项目中，缺乏合理的项目进度是造成项目滞后的最主要的原因，它比其它所有因素加起来的影响还大）
they reflect an unvoiced assumption which is quite untrue,i.e., that all will go well.
（它反应了一种悄无声息，但并不真实的假设--一切都将运作良好）
Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
（第二，我们采用的估算技术隐含的假设人和月可以互换，错误的将进度和工作相互混淆）
Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef.
（第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续的进行估算这项工作）
Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.
（第四，计划的过程缺乏监测。其它工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动）
Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower.
（第五，当意识到进度的偏移时，下意识的反应是增加人力）
Optimism
Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers.
（可能这种现代魔术特别吸引那些相信结局美满的人）
Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal.
（也可能是成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人）
But however the selection process works, the result is indisputable:
（无论是什么样的程序，结果是毋庸置疑的）
The pervasiveness of optimism among programmers deserves more than a flip analysis.
（对这种弥漫在程序员中间的乐观主义，理应受到慎重的分析）
This description, which Miss Sayers uses to illuminate not only human creative activity but also the Christian doctrine of the Trinity, will help us in our present task.
（以上Sayers的阐述不仅可以描绘人类的创造性活动，而且可以类似于“基督的教义”，能指导我们的日常工作）
For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation.
（对于创造者来说，只有在实现期间我们才能发现，我们的构思的不完整性和不一致性）
Thus it is that writing, experimentation, "working out" are essential disciplines for the theoretician.
（因此，对于理论家而言，书写、试验以及“工作实现”是非常基本和必要的）
In many creative activities the medium of execution is intractable.
（在许多创造性活动中执行起来是非常难以驾驭的）
Lumber splits; paints smear; electrical circuits ring.
（例如木头切割、油漆、电器安装等）
These physical limitations of the medium constrain the ideas that may be expressed, and they also create unexpected difficulties in the implementation.
（这些介质的物理限制约束了思路的表达，它们同样在实现中制造了出乎意外的困难）
Implementation, then, takes time and sweat both because of the physical media and because of the inadequacies of the underlying ideas.
（由于物理介质和思路隐含中的不确定性，实际实现起来需要花费大量的时间和函数）
We tend to blame the physical media for most of our implementation difficulties;
（为了我们实现中的困难，我们试图责怪物理介质）
for the media are not "ours" in the way the ideas are, and our pride colors our judgment.
（因为他们不顺应“我们”设定的思路，其实这不过是我们的骄傲是我们的判断带上了主观主义色彩）
Computer programming, however, creates with an exceedingly tractable medium.
（计算机编程，然而，开发起来非常适合处理）
The programmer builds from pure thought-stuff: concepts and very flexible representations thereof.
（程序员通过非常纯粹的思维活动--概念以及灵活的表现形式来开发程序）
In a single task, the assumption that all will go well has a probabilistic effect on the schedule.
（在单个的任务中，“一切都将运转的很好”的假设在时间进度上具有可实现性）
for there is a probability distribution for the delay that will be encountered, and "no delay" has a finite probability.
（因为所遇的延迟是一个概率分布曲线，不会延迟仅具有有限的概率）
The'Man-Month
The second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month.
（第二个错误的想法是在估计和进度安排中使用的工作量单位：人月）
Cost does indeed vary as the product of the number of men and the number of months.
（成本的确随开发产品的人数和时间的不同，有着很大的变化）
Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth.
（因此我认为用 人月作为一种可测量的工作的大小是一种危险和带有欺骗性的神话）
It implies that men and months are interchangeable.
（它意味着人月是可相互替换的）
人员和时间之间的关系 -- 完全可以分解的任务
Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (Fig. 2.1).
（人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流）
This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.
（这在割小麦或者收棉花的工作中是可行的；而在系统编程中几乎不可能）
人员和时间之间的关系 -- 无法分解的任务
When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule(Fig. 2.2).
（当任务由于次序上的限制不能分解时，人手的添加对进度没有任何帮助）
The bearing of a child takes nine months, no matter how many women are assigned.
（无论多少个母亲，孕育一个小孩都需要10个月）
Many software tasks have this characteristic because of the sequential nature of debugging.
（由于调试、测试的次序特性，许多软件都有这个特征）
人员和时间之间的关系 -- 需要沟通可分解的任务
In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done.
（对于可以分解，但子任务之间需要相互沟通交流的任务，必须在沟通计划中考虑沟通的工作量）
Therefore the best that can be done is somewhat poorer than an even trade of men for months
（因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些）
人员和时间之间的关系 -- 复杂关系下的任务
The added burden of communication is made up of two parts, training and intercommunication.
（沟通所增加的负担由两部分组成，培训和互相交流）
Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work.
（和工作计划 每一个员工都需要在技术、项目目标、总体策略以及工作计划上进行培训）
This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.
（这个培训不能被分解，因此这部分增加的工作量随人员的数量而呈线性的增长）
Intercommunication is worse. If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2.
（相互交流是不好的。如果每一部分必须和其它部分单独协作，则工作量按照n(n-2)/2递增）
Three workers require three times as much pairwise intercommunication as two; four require six times as much as two.
（三个员工的工作量是两个人的三倍，4个人的工作量是两个人的六倍）
If, moreover, there need to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet.
（而对于需要在三四个人之间召开会议，进行协商，一同解决的问题，情况会更加恶劣）
The added effort of communicating may fully counteract the division of the original task and bring us to the situation of Fig. 2.4.
（所增加的用于沟通的工作量可能会抵消对原有任务分解所产生的作用，此时我们会被带到图2.4的境地）
Since software construction is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning.
（因为软件开发本质上就是一件系统工作 -- 错综复杂关系下的一种实践 -- 沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间）
Systems Test
No parts of the schedule are so thoroughly affected by sequential constraints as component debugging and system test.
（在时间进度中，顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到的牵涉更彻底）
Furthermore, the time required depends on the number and subtlety of the errors encountered.
（这个时间需要依赖于所遇到的错误、缺陷数量以及扑捉它们的程度）
For some years I have been successfully using the following rule of thumb for scheduling a software task:
（为了计划软件任务，我已成功使用下面的规则）
l/3 planning
l/6 coding
l/4 component test and early system test
l/4 system test, all components in hand.
This differs from conventional scheduling in several important ways:
（在许多重要的方面，它与传统的进度安排不同）
1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification, and not enough to include research or exploration of totally new techniques.
（分配给计划时间要比平常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳全新技术的研究和探索）
2. The half of the schedule devoted to debugging of completed code is much larger than normal.
（计划的一半时间用来调试代码，比平常安排的多很多）
3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.
（一部分很容易估算，例如：编码、占了计划的1/6）
In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose.
（在检查传统的进度工程中，我发现很少项目允许1/2的时间都是用来测试，但是大多数为了达到目的确实花费了实际进度一半的时间）
Many of these were on schedule until and except in system testing.
（或者说，除了系统测试，其它基本都能完成）
Failure to allow enough time for system test, in particular, is peculiarly disastrous.
（特别需要提到，不为系统测试分配足够多的时间，将会是一场灾难）
Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date.
（在进度的最后延迟来了，直到项目的发布日期，才有人发现项目上的进度问题）
Bad news, late and without warning, is unsettling to customers and to managers.
（坏消息、延迟、无警告，对客户和管理者来说会感到不安）
Furthermore, delay at this point has unusually severe financial, as well as psychological, repercussions.
（另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应）
The project is fully staffed, and cost-per-day is maximum.
（项目已经配置了非常充足的人员，每天的人力成本也已经达到了最大程度）
More seriously, the software is to support other business effort (shipping of computers, operation of new facilities, etc.) and the secondary costs of delaying these are very high, for it is almost time for software shipment.
（更严重的是，这个软件需要支持其他业务（计算机硬件到货、新设备、服务上线等等）时，这些活动延误出现即将发布前，那么将付出相当高的商业代价）
Indeed, these secondary costs may far outweigh all others.
（这些发布成本可能远远超过其它东西）
It is therefore very important to allow enough system test time in the original schedule.
（在初始的计划中分配足够多的测试时间是非常重要的）
Gutless Estimating
Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.
（通过观察程序员，你会发现和厨师一样，某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况）
An omelette, promised in two minutes, may appear to be progressing nicely.
（煎一个鸡蛋，可以在两分钟内完成，可能出现令人满意的过程）
But when it has not set in two minutes, the customer has two choices—wait or eat it raw.
（但是当它在两分钟内没有完成，这个顾客就有两种选择 -- 等待或者生吃）
Software customers have had the same choices.
（软件用户也是同样的选择）
The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save—burned in one part, raw in another.
（顾客还有其它的选择；他可以选择大火。不过结果是常常无法挽救的煎蛋 -- 而且已经焦了，而另外一面还是生的。）
Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers.
（现在我不认为软件管理者相比于厨师来讲有缺乏内在勇气和坚持，或者不如其他的工程经理）
But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering.
（但为了满足顾客的期望时间而造成的不合理进度安排，在软件领域中比起其他任何工程领域要普遍的多）
It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
（非阶段化方法的采用、少的可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出健壮可靠和规避风险的估计）
Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on.
（需要明确两种解决方法。我们需要开发并推行生产率图表、缺陷率和估算规则等等）
The whole profession can only profit from sharing such data.
（整个组织最终会从这些共享的数据上获益）
Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wishderived estimates.
（或者在基于可靠基础的估算之前，项目经理需要挺直腰杆、坚持他们的估计，确信自己的经验和直觉总比期望派生出的结果要强得多）
Regenerative Schedule Disaster （再生计划的灾难 -- assume、add people、madness、reschedule、trime the task、）
What does one do when an essential software project is behind schedule? dd manpower, naturally.
（当一个软件项目落后于进度时，通常的做法是什么呢？ 自然是加派人手）
Assume that the whole estimate was uniformly low, so that Fig. 2.7 really describes the situation.
（假定整个的估值偏低，图2-7能实际的反应形式）
That is, allow enough time in the new schedule to ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.
（也就是说，在新的进度安排中分配充足的时间，以确保工作能彻底、仔细的完成，从而无需重新确定时间进度表）
Trim the task.
（消减任务）
In practice this tends to happen anyway, once the team observes schedule slippage.
（在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行消减）
Where the secondary costs of delay are very high, this is the only feasible action.
（当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法）
The manager's only alternatives are to trim it formally and carefully, to reschedule, or to watch the task get silently trimmed by hasty design and incomplete testing.
（项目经理的相应措施是仔细、正式地调整项目，重新安排进度，或者是默默的注释着任务由于轻率的设计和不完整的测试而被剪除）
In the first two cases, insisting that the unaltered task be completed in four months is disastrous.
（在之前的两个例子中，坚持把不经调整的任务在四个月内完成将是灾难性的）
Consider the regenerative effects, for example, for the first alternative (Fig. 2.8).
（考虑到重复生成的工作量，以第一种为例（图2-8））
The two new men, however competent and however quickly recruited, will require training in the task by one of the experienced men.
（不论在多短的时间内，聘请到多么能干的两位新员工，他们都需要接受一个有经验的职员培训）
If this takes a month, 3 man-months will have been devoted to work not in the original estimate.
（如果培训需要耗费一个月，每月三人的计划将会投入原有进度安排以外的工作中）
Furthermore, the task, originally partitioned three ways, must be repartitioned into five parts; hence some work already done will be lost, and system testing must be lengthened.
（另外，原先划分为三个部分的工作，会重新划分为五个部分；某些已经完成的工作必定会丢失，系统测试必须被延长。）
So at the end of the third month, substantially more than 7 manmonths of effort remain, and 5 trained people and one month are available.
（因此在第三个月的月末，仍然残留着7个人月的工作，但此时只有五个有效的人月）
thus such aspects as team organization and task division are different in kind, not merely in degree.
（并且小组的组织和任务的划分在类型上都不尽相同，这已经不是程度上的差异问题）
The temptation is very strong to repeat the cycle, adding yet more manpower. Therein lies madness.
（添加更多人力，结果往往会是上述循环的重复。这简直就是一种疯狂、愚蠢的做法）
If on March I one makes the conservative assumption that the whole schedule was optimistic, as Fig. 2.7 depicts, one wants to add 6 men just to the original task.
（如果在三月一日，项目经理做出了比较保守的假设，即整个估计过于乐观了，就像图2-7所示，6个人手需要添加到原先的任务中。）
Without a doubt, the regenerative disaster will yield a poorer product, later, than would rescheduling with the original three men, unaugmented.
（但是毫无疑问，重现“灾难”所开发出的产品，比没有增加人手，而是重新安排开发进度所产生的产品更差。）
Adding manpower to a late software project makes it later.
（添加人手解决软件落后的问题，只会使软件进度更加落后）
The number of months of a project depends upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks.
（项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量）
More software projects have gone awry for lack of calendar time than for all other causes combined.
（总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要的原因，它比其它所有因素加起来的影响还要大）
--多花时间在计划进度上，胜过多分配人在进度上，而少花时间在进度上。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
