《人月神话》读后感

在刚刚进入软件工程学习时，老师总会时不时向我们提起一些关于“软件项目开发的完成与增加人员的问题”这句话听起来通俗易懂，但实现起来却遇到了相当大的困难，这是我在阅读完成《人月神话》时最大的感受，我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。 如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。

书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容涉及到了团队，人和沟通。对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。

总结一下这本书，讲的主要是软件工程方面的，如何配置人力进行开发 。虽然对于软件编程我们对其了解并不多，但是对于在软件功能的实现，程序设计人员面临的客观性的困难至少我可以站在略懂的角度上去理解他们，对于一个或多个项目来说，公司大多都会搞人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员旧人一一辞职，新人天天引进，做法没有改变，情况没有改观，公司没有发展，这就是问题。人月之所以不能成为神话，正是因为增加人手的同时也增加了人与人之间的交流。我们所有的进度都是以“人月”代码产量来衡量的. 而增加"人"并不能缩短"月"的量。这同样是作者的观点，布鲁克斯这个名字在中国知之者不多，但在美国却是大名鼎鼎。因为他在60年代初只有29岁时就主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360系列计算机的开发工作，取得辉煌成功，在计算机技术的诸多领域中都做出了巨大的贡献。作者在书中提到了他使用了很多年的经验法则：1/3计划1/6编码1/4构件测试和早期系统测试1/4系统测试，虽然布鲁克斯的这本书发表数十年，但他预计的这些问题并没有得到最终的大变革，软工领域仍在面临着多种作则提出的问题，不过令人欣慰的是，大家确实在向这方面改变。在第6章中作者又提到，系统架构师们应该在文档中描述所有外部特性，但是他应该避免干涉具体实现细节，实际上我们动脑想一想解决办法很简单：谁开发、谁决定，对于外部特性的形式化定义不应该扼杀实现人员的创造力。我认为任何事都应当先规划再执行，很多专家和

实践人员都同意这样一个观点：需要项目经理投入的最重要的一件事就是规划。只有详细而系统的由项目小组成员参与的规划才是项目成功的唯一基础。不能因为规划或进度计划不准确经常调整而不做计划。项目经理必须以自己的实际行动向项目小组成员传递一种紧迫感我想事情这样规划的话，由于项目在时间、资源和经费上都是有限的，项目最终必须完成。

刚刚读这本书时，我对作者的观点和他所用的一些专业术语或者一些形象的比喻都不太懂，没事做的时候我把它放在电子书里随时翻看，很多地方会给人想要继续读下去的感觉，因为我想要了解它，继续下去会给我们所有问题的解释，尤其是作者在拟题的时候用了很多奇怪的小标题，例如; 焦油坑、外科手术队伍、为什么巴别塔会失败等等一些似乎看起来跟软工方面并不贴边的题目，但作者恰恰用了这些吸引了我的眼球，这本书让我对软件工程的程序设计开发的认识有了巨大的改变，我知道布鲁克斯的成功不是一时的，所以我更相信他的经验足以我受用一生。

 

第二篇：人月神话(英)

2

The Mythical Man-Month

2

The Mythical Man-MonthGood cooking fakes time. If you are made to wait, it is toserve you better, and to please you.

MENU OF RESTAURANT ANTOINE. NEW ORLEANS

13

14 The Mythical Man-Month

More software projects have gone awry for lack of calendar timethan for all other causes combined. Why is this cause of disasterso common?

First, our techniques of estimating are poorly developed. Moreseriously, they reflect an unvoiced assumption which is quite un-true,i.e., that all will go well.

Second, our estimating techniques fallaciously confuse effortwith progress, hiding the assumption that men and months areinterchangeable.Third, because we are uncertain of our estimates, softwaremanagers often lack the courteous stubbornness of Antoine's chef.Fourth,schedule progress is poorly monitored. Techniquesproven and routine in other engineering disciplines are consideredradical innovations in software engineering.Fifth, when schedule slippage is recognized, the natural (andtraditional)response is to add manpower. Like dousing a fire withgasoline, this makes matters worse, much worse. More fire re-quires more gasoline, and thusbegins a regenerative cycle whichends in disaster.Schedule monitoring will be the subject of a separate essay.Let us consider other aspects of the problem in more detail.Optimism

All programmers are optimists. Perhaps this modern sorcery espe-cially attracts those who believe in happy endings and fairy god-mothers. Perhaps the hundreds of nitty frustrations drive away allbut those who habitually focus on the end goal. Perhaps it ismerely thatcomputers are young, programmers are younger, andthe young are always optimists. But however the selection processworks, the result is indisputable: "This time it will surely run," or"I just found the last bug."So the first falseassumption that underlies the scheduling ofsystemsprogramming is that all will go well, i.e., that each task willhike only as long as it "ought" to take.

Optimism 15

The pervasiveness of optimism among programmers deservesmore than a flip analysis. Dorothy Sayers, in her excellent book,The Mind of the Maker, divides creative activity into three stages:the idea, the implementation, and the interaction. A book, then,or a computer, or a program comes intoexistence first as an idealconstruct, built outside time and space, but complete in the mindof the author. It is realized in time and space, by pen, ink, andpaper, or by wire, silicon, and ferrite. The creation is completewhen someone reads the book, uses the computer, or runs theprogram, thereby interacting with the mind of the maker.

This description, which Miss Sayers uses to illuminate notonly human creative activity but also the Christian doctrine of theTrinity, will help us in our present task. For the human makers ofthings, the incompletenesses and inconsistencies of our ideasbecome clear only during implementation. Thus it is thatwriting,experimentation, "working out" are essential disciplines for thetheoretician.

In many creative activities the medium of execution is intract-able. Lumbersplits; paints smear; electrical circuits ring. Thesephysical limitations of the medium constrain the ideas that maybe expressed, and theyalso create unexpected difficulties in theimplementation.

Implementation, then, takes time and sweat bothbecause ofthe physical media and because of the inadequacies of the under-lying ideas. We tend to blame the physical media for most of ourimplementation difficulties; for the media are not "ours" in theway the ideas are, and our pride colors our judgment.

Computerprogramming, however, creates with an exceed-ingly tractable medium. The programmer builds from purethought-stuff: concepts and very flexiblerepresentationsthereof.Because the medium is tractable, we expect few difficulties inimplementation; hence our pervasive optimism. Because our ideasare faulty, we have bugs; hence our optimism is unjustified.

In a single task, the assumption that all will go well has

a

16 The Mythical Man-Month

for there is a probability distribution for the delay thatwill beencountered, and "no delay" has a finite probability. A large pro-gramming effort,however, consists of manytasks, some chainedend-to-end. The probability that each will go well becomes van-ishingly small.

The'Man-Month

The second fallacious thought mode is expressed in the veryunitof effort used in estimating and scheduling: the man-month. Costdoes indeed vary as the product of the number of men and thenumber of months. Progress does not. Hence the man-month as a unitfor measuring the size of a job is a dangerous and deceptive myth. Itimplies that men and months are interchangeable.Men and months are interchangeable commodities only whena task can be partitioned among manyworkers with no communica-tion among them (Fig. 2.1). This is true of reaping wheat or pickingcotton; it is not even approximately true of systems programming.

Men

Fig. 2.1 Time versus number of workers—perfectly partitionable task

The Man-Month 17

When a task cannot be partitioned because of sequential con-straints, the application of more effort has no effect on the sched-ule (Fig. 2.2). The bearing of a child takes nine months, no matterhow many women are assigned. Many software tasks have thischaracteristic because of the sequential nature of debugging.Fig. 2.2 Time versus number of workers—unpartitionable task

In tasks that can be partitioned but which require communica-tion among the subtasks, the effort of communication must beadded to the amount of work to be done. Therefore the best thatcan be done is somewhat poorer than an even trade of men formonths (Fig. 2.3).

18 The Mythical Man-Month

Men

Fig. 2.3 Time versus number of workers—partitionable task requiringcommunication

The added burden of communication is made up of two parts,training and intercommunication. Each worker must be trained inthe technology, the goals of the effort, the overall strategy, and theplan of work. This training cannot be partitioned, so this part ofthe added effort varies linearly with the number of workers.1Intercommunication is worse. If each part of the task must beseparately coordinated with each other part/ the effortincreases asn(n-I)/2. Three workers require three times as much pairwiseintercommunication as two; fourrequire six times as much as two.If, moreover, there need to be conferences among three, four, etc.,workers to resolve things jointly, matters get worse yet. The addedeffort of communicating may fully counteract the division of theoriginal task and bring us to the situation of Fig. 2.4.

Systems Test 19

Men

Fig. 2.4 Time versus number of workers—task with complex interrela-tionships

Since software construction is inherently a systems effort—anexercise in complex interrelationships—communication effort isgreat, and it quickly dominates the decrease in individual task timebrought about by partitioning. Adding more men then lengthens,not shortens, the schedule.

Systems Test

No parts of the schedule are so thoroughly affected by sequentialconstraints as component debugging and system test. Further-more, the time required depends on the number and subtlety ofthe errors encountered. Theoretically this number should be zero.Because of optimism, we usually expect the number of bugs to be

20 The Mythical Man-Month

smaller than it turns out to be. Therefore testing is usually themost mis-scheduled part of programming.For some years I have been successfully using the followingrule of thumb for scheduling a software task:

l

l/3 planning/6 codingl/4 component test and early system testl/4 system test, all components in hand.

This differs from conventional scheduling in several importantways:

1. The fraction devoted to planning is larger than normal. Evenso, it is barely enough to produce a detailed and solid specifi-cation, and not enough to include research or exploration oftotally new techniques.

2. The half of the schedule devoted to debugging of completedcode is much larger than normal.3. The part that is easy to estimate, i.e., coding, is given onlyone-sixth of the schedule.

In examining conventionally scheduled projects, I have foundthat few allowed one-half of the projected schedule for testing,but that most did indeed spend half of the actual schedule for thatpurpose. Many of these were on schedule until and except insystem testing.2

Failure to allow enough time for system test, in particular, ispeculiarly disastrous. Since the delay comes at the end of theschedule, no one is aware of schedule trouble until almost thedelivery date. Bad news, late and without warning, is unsettlingto customers and to managers.Furthermore,delay at this point has unusuallysevere finan-cial, as well as psychological, repercussions. The project is fullystaffed, and cost-per-day is maximum. More seriously, the soft-ware is to support other business effort (shipping of computers,operation of new facilities, etc.) and the secondary costs of delay-ing these are very high, for it is almost time for software shipment.

Regenerative Schedule Disaster 21

Indeed, these secondary costs may far outweigh all others. It istherefore very important to allow enough system test time in theoriginal schedule.

Gutless Estimating

Observe that for the programmer, as for the chef, the urgency ofthe patron may govern the scheduled completion of the task, butit cannot govern the actual completion. An omelette, promised intwo minutes, may appear to be progressing nicely. But when it hasnot set in two minutes, the customer has two choices—wait or eatit raw. Software customers have had the same choices.The cook has another choice; he can turn up the heat. Theresult is often an omelette nothing can save—burned in one part,raw in another.Now I do not think software managers have less inherentcourage and firmness than chefs, nor thanother engineering man-agers. But false scheduling to match the patron's desired date ismuch more common in our discipline thanelsewhere in engineer-ing. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitativemethod, supported by little data, and certified chiefly by thehunches of the managers.Clearly two solutions are needed. We need to develop andpublicize productivity figures, bug-incidence figures, estimatingrules, and so on. The whole prof ession can only profit from sharingsuch data.Until estimating is on a sounder basis, individual managerswill need to stiffen their backbones and defendtheir estimateswith the assurance that their poor hunches are better than wish-derived estimates.

Regenerative Schedule Disaster

Whatdoes one do when an essential software project is behindschedule? Add manpower, naturally. As Figs. 2.1 through 2.4 sug-gest, this may or may not help.

22 The Mythical Man-Month

Let us consider an example.3 Suppose a task is estimated at 12man-months and assigned to three men for four months, and thatthere are measurable mileposts A, B, C, D, which are scheduled tofall at the end of each month (Fig. 2.5).

Now suppose the first milepost is not reached until twomonths have elapsed (Fig. 2.6). What are the alternatives facingthe manager?

1. Assume that the task must be done on time. Assume thatonlythe first part of the task was misestimated, so Fig. 2.6 tells thestory accurately. Then 9 man-months of effort remain, andtwo months, so 4V￡ men will be needed. Add 2 men to the 3assigned.

2. Assume that the task must be done on time. Assume that thewhole estimate was uniformlylow, so that Fig. 2.7 reallydescribes the situation. Then 18 man-months of effort remain,and two months, so 9 men will be needed. Add 6 men to the3 assigned.

Figure 2.5

Regenerative Schedule Disaster 23Figure 2,6

Figure 2.7

24 The Mythical Man-Month

3. Reschedule. I like the advice given by P. Fagg, an experiencedhardware engineer, "Take no small slips." That is, allowenough time in the new schedule to ensure that the work canbe carefully and thoroughly done, and that rescheduling willnot have to be done again.

4. Trim the task. In practice this tends to happen anyway, oncethe team observes schedule slippage. Where the secondarycosts of delay are very high, this is the only feasible action.The manager's only alternatives are to trim it formally andcarefully, to reschedule, or to watch the task get silentlytrimmed by hasty design and incomplete testing.

In the first two cases, insisting that the unaltered task becompleted in four months is disastrous. Consider the regenerativeeffects, for example, for the first alternative (Fig. 2.8). The two newmen, however competent and however quickly recruited, will re-quiretraining in the task by one of the experienced men. If thistakes a month, 3 man-months will have been devoted to work not in theoriginal estimate. Furthermore, the task, originally partitioned threeways, must be repartitioned into five parts; hence some workalready done will be lost, and system testing must be lengthened.So at the end of the third month, substantially more than 7 man-months of effort remain, and 5 trained people and one month areavailable. As Fig. 2.8 suggests, the product is just as late as if noone had been added (Fig. 2.6).

To hope to get done in four months, considering only trainingtime and not repartitioning and extra systems test, wouldrequireadding 4 men, not 2, at the end of the second month. To coverrepartitioning and system test effects, one would have to add stillother men. Now, however, one has at least a 7-manteam, not a3-man one; thus such aspects as team organization and task divi-sion are different in kind, not merely in degree.Notice that by the end of the thirdmonth things look veryblack. The March 1 milestone has not been reached in spite of all

Regenerative Schedule Disaster 25

Figure 2.8

the managerial effort. The temptation is very strong to repeat thecycle, adding yet more manpower. Therein lies madness.The foregoing assumed that only the first milestone wasmisestimated. If on March I one makes the conservative assump-tion that the whole schedule was optimistic, as Fig. 2.7 depicts, onewants to add 6 men just to the original task. Calculation of thetraining, repartitioning, system testing effects is left as an exercisefor the reader. Without a doubt, the regenerative disaster willyield a poorer product, later, than would rescheduling with theoriginal three men, unaugmented.Oversimplifying outrageously, we state Brooks's Law:

Adding manpower to a late software project makes it later.

This then is the demythologizing of the man-month. Thenumber of months of a project depends upon its sequential con-

26 The Mythical Man-Month

straints. The maximum number of men depends upon the numberof independent subtasks. From these two quantities one can deriveschedules using fewer men and more months. (The only risk isproduct obsolescence.) One cannot, however, get workable sched-ules using more men and fewer months. More software projectshave gone awry for lack of calendar time than for all other causescombined.