Classic Mistakes Enumerated

Some ineffective development practices have been chosen so often, by so many people, with such predictable, bad results that they deserve to be called "classic mistakes." Most of the mistakes have a seductive appeal. Do you need to rescue a project that's behind schedule? Add more people! Do you want to reduce your schedule? Schedule more aggressively! Is one of your key contributors aggravating the rest of the team? Wait until the end of the project to fire him! Do you have a rush project to complete? Take whatever developers are available right now and get started as soon as possible!

Developers, managers, and customers usually have good reasons for making the decisions they do, and the seductive appeal of the classic mistakes is part of the reason these mistakes have been made so often. But because they have been made so many times, their consequences have become easy to predict, and they rarely produce the results that people hope for.

This section enumerates three dozen classic mistakes. I have personally seen each of these mistakes made at least once, and I've made many of them myself. You'll recognize many of them from Case Study 3-1.

The common denominator in this list is that you won't necessarily get rapid development if you avoid the mistake, but you will definitely get slow development if you don't avoid it.

If some of these mistakes sound familiar, take heart. Many other people have made the same mistakes, and once you understand their effect on development speed you can use this list to help with your project planning and risk management.

Some of the more significant mistakes are discussed in their own sections in other parts of this book. Others are not discussed further. For ease of reference, the list has been divided along the development-speed dimensions of people, process, product, and technology.

People

Here are some of the people-related classic mistakes.

#1: Undermined motivation. Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor (Boehm 1981). In Case Study 3-1, management took steps that undermined morale throughout the project--from giving a hokey pep talk at the beginning to requiring overtime in the middle and going on a long vacation while the team worked through the holidays to providing bonuses that work out to less than a dollar per overtime hour at the end.

#2: Weak personnel. After motivation, either the individual capabilities of the team members or their relationship as a team probably has the greatest influence on productivity (Boehm 1981, Lakhanpal 1993). Hiring from the bottom of the barrel will threaten a rapid development effort. In the case study, personnel selections were made with an eye toward who could be hired fastest instead of who would get the most work done over the life of the project. That practice gets the project off to a quick start but doesn't set it up for rapid completion.

#3: Uncontrolled problem employees. Failure to deal with problem personnel also threatens development speed. This is a common problem and has been well-understood at least since Gerald Weinberg published Psychology of Computer Programming in 1971. Failure to take action to deal with a problem employee is the most common complaint that team members have about their leaders (Larson and LaFasto 1989). In Case Study 3-1, the team knew that Chip was a bad apple, but the team lead didn't do anything about it. The result--redoing all of Chip's work--was predictable.

#4: Heroics. Some software developers place a high emphasis on project heroics, thinking that the certain kinds of heroics can be beneficial (Bach 1995). But I think that emphasizing heroics in any form usually does more harm than good. In the case study, mid-level management placed a higher premium on can-do attitudes than on steady and consistent progress and meaningful progress reporting. The result was a pattern of scheduling brinkmanship in which impending schedule slips weren't detected, acknowledged, or reported up the management chain until the last minute. A small development team held an entire company hostage because they wouldn't admit that they were having trouble meeting their schedule. An emphasis on heroics encourages extreme risk taking and discourages cooperation among the many stakeholders in the software-development process.

Some managers encourage this behavior when they focus too strongly on can-do attitudes. By elevating can-do attitudes above accurate-and-sometimes-gloomy status reporting, such project managers undercut their ability to take corrective action. They don't even know they need to take corrective action until the damage has been done. As Tom DeMarco says, can-do attitudes escalate minor setback into true disasters (DeMarco 1995).

#5: Adding people to a late project. This is perhaps the most classic of the classic mistakes. When a project is behind, adding people can take more productivity away from existing team members than it adds through new ones. Fred Brooks likened adding people to a late project to pouring gasoline on a fire (Brooks 1975).

#6: Noisy, crowded offices. Most developers rate their working conditions as unsatisfactory. About 60 percent report that they are neither sufficiently quiet nor sufficiently private (DeMarco and Lister 1987). Workers who occupy quiet, private offices tend to perform significantly better than workers who occupy noisy, crowded work bays or cubicles. Noisy, crowded work environments lengthen development schedules.

#7: Friction between developers and customers. Friction between developers and customers can arise in several ways. Customers may feel that developers are not cooperative when they refuse to sign up for the development schedule that the customers want, or when they fail to deliver on their promises. Developers may feel that customers unreasonably insisting on unrealistic schedules or requirements changes after requirements have been baselined. There might simply be personality conflicts between the two groups.

The primary effect of this friction is poor communication, and the secondary effects of poor communication include poorly understood requirements, poor user-interface design, and, in the worst case, customers' refusing to accept the completed product. On average, friction between customers and software developers is so severe that both parties consider canceling the project (Jones 1994). Such friction is time-consuming to overcome, and it distracts both customers and developers from the real work of the project.

#8: Unrealistic expectations. One of the most common causes of friction between developers and their customers or managers is unrealistic expectations. In Case Study 3-1, Bill had no reason to think that the Giga-Quote program could be developed in six months except for the fact that the company needed it in that amount of time. Mike's failure to correct that unrealistic expectation was a major source of problems. In other cases, project managers or developers ask for trouble by getting funding based on overly optimistic schedule estimates. Sometimes they promise a pie-in-the-sky feature set. Although unrealistic expectations do not in themselves lengthen development schedules, they contribute to the perception that development schedules are too long, and that can be almost as bad. A Standish Group survey listed realistic expectations as one of the top five factors needed to ensure the success of an in-house business-software project (Standish Group 1994).

#9: Lack of effective project sponsorship. High-level project sponsorship is necessary to support many aspects of rapid development including realistic planning, change control, and the introduction of new development practices. Without an effective project sponsor, other high-level personnel in your organization can force you to accept unrealistic deadlines or make changes that undermine your project. Australian consultant Rob Thomsett argues that lack of an effective project sponsor virtually guarantees project failure (Thomsett 1995).

#10: Lack of stakeholder buy-in. All of the major players in a software-development effort must buy in to the project. That includes the executive sponsor, team leader, team members, marketing, end-users, customers, and anyone else who has a stake in it. The close cooperation that occurs only when you have complete buy-in from all stakeholders allows for precise coordination of a rapid development effort that is impossible to attain without good buy-in.

#11: Lack of user input. The Standish Group survey found that the number one reason that IS projects succeed is because of user involvement (Standish Group 1994).

#12: Politics placed over substance. Larry Constantine reported on four teams that had four different kinds of political orientations (Constantine 1995a). "Politicians" specialized in "managing up," concentrating on relationships with their managers. "Researchers" concentrated on scouting out and gathering information. "Isolationists" kept to themselves, creating project boundaries that they kept closed to non-team members. "Generalists" did a little bit of everything: they tended their relationships with their managers, performed research and scouting activities, and coordinated with other teams through the course of their normal workflow. Constantine reported that initially the political and generalist teams were both well regarded by top management. But after a year and a half, the political team was ranked dead last. Putting politics over results is fatal to speed-oriented development.

#13: Wishful thinking. I am amazed at how many problems in software development boil down to wishful thinking. How many times have you heard statements like these:

"None of the team members really believed that they could complete the project according to the schedule they were given, but they thought that maybe if everyone worked hard, and nothing went wrong, and they got a few lucky breaks, they just might be able to pull it off."

"Our team hasn't done very much work to coordinate the interfaces among the different parts of the product, but we've all been in good communication about other things, and the interfaces are relatively simple, so it'll probably take only a day or two to shake out the bugs."

"We know that we went with the low-ball contractor on the database subsystem and it was hard to see how they were going to complete the work with the staffing levels they specified in their proposal. They didn't have as much experience as some of the other contractors, but maybe they can make up in energy what they lack in experience. They'll probably deliver on time."

"We don't need to show the final round of changes to the prototype to the customer. I'm sure we know what they want by now."

"The team is saying that it will take an extraordinary effort to meet the deadline, and they missed their first milestone by a few days, but I think they can bring this one in on time."

Wishful thinking isn't just optimism. It's closing your eyes and hoping something works when you have no reasonable basis for thinking it will. Wishful thinking at the beginning of a project leads to big blowups at the end of a project. It undermines meaningful planning and may be at the root of more software problems than all other causes combined.

Process

Process-related mistakes slow down projects because they squander people's talents and efforts. Here are some of the worst process-related mistakes.

#14: Overly optimistic schedules. The challenges faced by someone building a three-month application are quite different than the challenges faced by someone building a one-year application. Setting an overly optimistic schedule sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. It also puts excessive pressure on developers, which hurts developer morale and productivity. This was a major source of problems in Case Study 3-1.

#15: Insufficient risk management. Some mistakes have been made often enough to be considered classics. Others are unique to specific projects. As with the classic mistakes, if you don't actively manage risks, only one thing has to go wrong to change your project from a rapid-development project to a slow-development one. Failure to manage risks is one of the most common classic mistakes.

#16: Contractor failure. Companies sometimes contract out pieces of a project when they are too rushed to do the work in-house. But contractors frequently deliver work that's late, that's of unacceptably low quality, or that fails to meet specifications (Boehm 1989). Risks such as unstable requirements or ill-defined interfaces can be magnified when you bring a contractor into the picture. If the contractor relationship isn't managed carefully, the use of contractors can slow a project down rather than speed it up.

#17: Insufficient planning. If you don't plan to achieve rapid development, you can't expect to achieve it.

#18: Abandonment of planning under pressure. Projects make plans and then routinely abandon them when they run into schedule trouble (Humphrey 1989). The problem isn't so much in abandoning the plan as in failing to create a substitute and then falling into code-and-fix mode instead. In Case Study 3-1, the team abandoned its plan after it missed its first delivery, and that's typical. The result was that work after that point was uncoordinated and awkward--to the point that Jill even started working on a project for her old group part of the time and no one even knew it.

#19: Wasted time during the fuzzy front end. The "fuzzy front end" is the time before the project starts, the time normally spent in the approval and budgeting process. It's not uncommon for a project to spend months or years in the fuzzy front end and then to come out of the gates with an aggressive schedule. It's much easier and cheaper and less risky to save a few weeks or months in the fuzzy front end than it is to compress a development schedule by the same amount.

#20: Shortchanged upstream activities. Projects that are in a hurry try to cut out nonessential activities, and since requirements analysis, architecture, and design don't directly produce code, they are easy targets. On one disaster project that I took over, I asked to see the design. The team lead told me, "We didn't have time to do a design."

Also known as "jumping into coding," the results of this mistake are all too predictable. In the case study, a design hack in the bar-chart report was substituted for quality design work. Before the product could be released, the hack work had to be thrown out and the higher quality work had to be done anyway. Projects that skimp on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it properly in the first place (Fagan 1976; Boehm and Papaccio 1988). If you can't find the 5 extra hours to do the job right the first time, where are you going to find the 50 extra hours to do it right later?

#21: Inadequate design. A special case of shortchanging upstream activities is inadequate design. Rush projects undermine design by not allocating enough time for it and by creating a pressure-cooker environment that makes thoughtful consideration of design alternatives difficult. The design emphasis is on expediency rather than quality, so you tend to need several ultimately time-consuming design cycles before you finally complete the system.

#22: Shortchanged quality assurance. Projects that are in a hurry often cut corners by eliminating design and code reviews, eliminating test planning, and performing only perfunctory testing. In the case study, design reviews and code reviews were given short shrift in order to achieve a perceived schedule advantage. As it turned out, when the project reached its feature-complete milestone it was still too buggy to release for five more months. This result is typical. Short-cutting a day of QA activity early in the project is likely to cost you 3 to 10 days of activity downstream (Jones 1994). This inefficiency undermines development speed.

#23: Insufficient management controls. In the case study, there were few management controls in place to provide timely warnings of impending schedule slips, and the few controls there were in place at the beginning were abandoned once the project ran into trouble. Before you can keep a project on track, you have to be able to tell whether it's on track.

#24: Premature or too frequent convergence. Shortly before a product is scheduled to be released there is a push to prepare the product for release--improve the product's performance, print final documentation, incorporate final help-system hooks, polish the installation program, stub out functionality that's not going to be ready on time, and so on. On rush projects, there is a tendency to force convergence early. Since it's not possible to force the product to converge when desired, some rapid development projects try to force convergence a half dozen times or more before they finally succeed. The extra convergence attempts don't benefit the product. They just waste time and prolong the schedule.

#25: Omitting necessary tasks from estimates. If people don't keep careful records of previous projects, they forget about the less visible tasks, but those tasks add up. Omitted effort often adds about 20 to 30 percent to a development schedule (van Genuchten 1991).

#26: Planning to catch up later. If you're working on a six-month project, and it takes you three months to meet your two-month milestone, what do you do? Many projects simply plan to catch up later, but they never do. You learn more about the product as you build it, including more about what it will take to build it. That learning needs to be reflected in the schedule.

Another kind of reestimation mistake arises from product changes. If the product you're building changes, the amount of time you need to build it changes too. In Case Study 3-1, major requirements changed between the original proposal and the project start without any corresponding reestimation of schedule or resources. Piling on new features without adjusting the schedule guarantees that you will miss your deadline.

#27: Code-like-hell programming. Some organizations think that fast, loose, all-as-you-go coding is a route to rapid development. If the developers are sufficiently motivated, they reason, they can overcome any obstacles. For reasons that will become clear throughout this book, this is far from the truth. The entrepreneurial model is often a cover for the old code-and-fix paradigm combined with an ambitious schedule, and that combination almost never works. It's an example of two wrongs not making a right.

Product

Here are some classic mistakes are related to the way the product is defined.

#28: Requirements gold-plating. Some projects have more requirements than they need right from the beginning. Performance is stated as a requirement more often than it needs to be, and that can unnecessarily lengthen a software schedule. Users tend to be less interested in complex features than marketing and development are, and complex features add disproportionately to a development schedule.

#29: Feature creep. Even if you're successful at avoiding requirements gold-plating, the average project experiences about a 25-percent change in requirement over its lifetime (Jones 1994). Such a change can produce at least a 25-percent addition to the software schedule, which can be fatal to a rapid development project.

#30: Developer gold-plating. Developers are fascinated by new technology and are sometimes anxious to try out new features of their language or environment or to create their own implementation of a slick feature they saw in another product--whether or not it's required in their product. The effort required to design, implement, test, document, and support features that are not required lengthens the schedule.

#31: Push me, pull me negotiation. One bizarre negotiating ploy occurs when a manager approves a schedule slip on a project that's progressing slower than expected and then adds completely new tasks after the schedule change. The underlying reason for this is hard to fathom because the manager who approves the schedule slip is implicitly acknowledging that the schedule was in error. But once the schedule has been corrected, the same person takes explicit action to make it wrong again. This can't help but undermine the schedule.

#32: Research-oriented development. Seymour Cray, the designer of the Cray supercomputers, says that he does not attempt to exceed engineering limits in more than two areas at a time because the risk of failure is too high (Gilb 1988). Many software projects could learn a lesson from Cray. If your project strains the limits of computer science by requiring the creation of new algorithms or new computing practices, you're not doing software development; you're doing software research. Software-development schedules are reasonably predictable; software research schedules are not even theoretically predictable.

If you have product goals that push the state of the art--algorithms, speed, memory usage, and so on--you should expect great uncertainty in your scheduling. If you're pushing the state of the art and you have any other weaknesses in your project--personnel shortages, personnel weaknesses, vague requirements, unstable interfaces with outside contractors--you can throw predictable scheduling out the window. If you want to advance the state of the art, by all means, do it. But don't expect to do it rapidly!

Technology

The remaining classic mistakes have to do with the use and misuse of modern technology.

#33: Silver-bullet syndrome. In the case study there was too much reliance on the advertised benefits of previously unused technologies (report generator, object oriented design, and C++) and too little information about how well they would do in this particular development environment. When project teams latch onto a single new methodology or new technology and expect it to solve their schedule problems, they are inevitably disappointed (Jones 1994).

#34: Overestimated savings from new tools or methods. Organizations seldom improve their productivity in giant leaps, no matter how good or how many new tools or methods they adopt. Benefits of new practices are partially offset by the learning curves associated with them, and learning to use new practices to their maximum advantage takes time. New practices also entail new risks, which you're likely to discover only by using them. You are more likely to experience slow, steady improvement on the order of a few percent per project than you are to experience dramatic gains. The team in Case Study 3-1 should have planned on, at most, a 10-percent gain in productivity from the use of the new technologies instead of assuming that they would nearly double their productivity.

A special case of overestimated savings arises when projects reuse code from previous projects. This can be a very effective approach, but the time savings is rarely as dramatic as expected.

#35: Switching tools in the middle of a project. This is an old standby that hardly ever works. Sometimes it can make sense to upgrade incrementally within the same product line, from version 3 to version 3.1 or sometimes even to version 4. But the learning curve, rework, and inevitable mistakes made with a totally new tool usually cancel out any benefit when you're in the middle of a project.

#36: Lack of automated source-code control. Failure to use automated source-code control exposes projects to needless risks. Without it, if two developers are working on the same part of the program, they have to coordinate their work manually. They might agree to put the latest versions of each file into a master directory and to check with each other before copying files into that directory. But someone always overwrites someone else's work. People develop new code to out-of-date interfaces and then have to redesign their code when they discover that they were using the wrong version of the interface. Users report defects that you can't reproduce because you have no way to recreate the build they were using. On average, source code changes at a rate of about 10 percent per month, and manual source-code control can't keep up (Jones 1994).

软件开发项目管理中的“经典错误”

　　有一些低效率的管理实践操作仍被许多人采用，造成了完全可以预期的不好的结果，这些实践操作就被称为“经典错误”。大多数“经典错误”都有一个具有诱惑力的外表。你需要拯救一个落后于进度的项目吗？那就增加人手吧。你想减少日程安排吗？那就把日程安排得更紧一些吧。团队中的一个关键人物激怒了其余队员？那就在项目结束后炒他鱿鱼吧。你有一个很紧急的项目要完成？那就把目前所有可用的人力资源召集起来开始工作吧，越快越好！

　　开发者、管理人员和顾客通常会有很好的理由来解释自己的所作所为，所以这些“经典错误”的具有诱惑力的外表也是解释为什么会再三犯下这类错误的原因。但是，由于“经典错误”已经发生过很多次了，因此它的结果是可以预期的，这些结果显然会和人们原来希望得到的结果不一致。

　　本章列举了36个“经典错误”，每个错误我本人至少见过一次，而且有许多是我自己也犯过的。你会从案例分析3-1中识别出这些错误。

　　这些错误的共性在于，如果你想避免它们，那么你的软件项目就肯定不能开发得很快。但如果你不去避免他们，你注定会开发得很慢。

　　如果有些错误看起来很熟悉，好像自己也犯过，不用担心，振作起来。因为有许多人犯过相同的错误，而且一旦你了解了这些错误给你的开发速度所带来的影响，你就可以在制订计划的时候进行风险控制。

　　有些错误会在本书的相应章节中进行讨论，有些则不会进一步讨论。为了便于查阅，这些“经典错误”被分类成了人员、过程、产品、技术等四个方面。

人员

　　这里是一些与人员有关的经典错误。

#1：不确定的激励措施

　　无数的调查研究表明，激励很可能是提高产品产量和质量的最有效的措施（Boehm 1981）。在案例分析3-1中，在管理的实施中充斥着不确定的激励措施。开头是一番虚情假意的激励性谈话，中间是要求员加班加点地工作，最后管理者去享受了一个长假，而员工却要在假期中继续工作，为的只是那些少得可怜的额外奖励。

#2：糟糕的人事管理

　　在激励之后，对产品产量有巨大影响的不是由团队队员个人的能力决定就是由队员之间的关系所决定（Boehm 1981, Lakhanpal 1993）。招募那些资历最差的员工将会威胁到企业为快速发展所付出的努力。在那个案例分析中，人事选拔的标准是谁能最快被找到，谁就被录取，而不是根据谁的能力最强来作为标准。这种做法虽然使项目迅速地开展，但不能快速地完成。

#3：不受控制的问题员工

　　不处理好问题员工同样会影响工作速度。这类错误在Geral Weinberg于1971年出版了《计算机编程心理学》一书后被管理者普遍理解。不处理好问题员工往往是团队队员抱怨他们的领导的最普遍的原因（Larson and LaFasto 1989）。在案例分析3-1中，整个团队都知道Chip这个人不是什么好东西，但团队领导却视而不见。其结果——重新完成Chip的工作——就可以预见了。

#4：英雄主义

　　有些软件开发者认为，在项目开发中强调英雄主义是非常重要的，认为英雄主义是非常有益的（Bach 1995）。但是我认为，以任何一种形式来强调英雄主义，其坏处往往要比好处多。在案例分析中，中层管理者对那些认为只要能做就能做成功的人给予了更高的奖励，而那些讲究稳定、长效的工作人员却得到了较低的奖励。其结果就是工作中实行的边缘政策直到最后一分钟才发现、认识了组织所面临的紧急的问题，并向上级报告。一个小的开发团队掌握了公司的生杀大权，因为他们不愿意承认不能按期完成任务。对英雄主义的强调促进了冒极大风险的趋势，而削弱了在软件开发的过程中，利益相关者之间的合作。

　　当有些管理者过分强调“能做就能成功”的态度时就会产生强调英雄主义的行为。当项目管理者视这种态度高于精准的状态报告时，他们就会不完全发挥自己的能力地去采取正确措施。他们甚至不认为自己需要采取正确措施，直到损失已经造成了。正如Tom Demarco所说，“能做就能成功”的态度将原本只是很小的障碍放大成一场真真正正的灾难。

#5：向即将到期的项目追加人手

　　这也许是最常见的“经典错误”了。当一个项目落后与进度时，不在现有队员中下功夫，而是以增加人手的方式来提高产量。Fred Brooks把这种行为比做“火上浇油”（Brooks 1975）。

#6：吵闹、拥挤的办公室

　　多数开发者对自己的工作环境是不满意的。约60%的人认为他们的工作环境不是不够安静就是不够私人化（DeMarco and Lister 1987）。拥有安静、私人的工作场所的工作人员会比那些处在吵闹、拥挤的地方的人要表现得更为出色。吵闹、拥挤的环境会拖延工作日程。

#7：开发者与顾客之间的冲突

　　这种冲突可以是来自多方面的。当开发者不愿意签定顾客制定的项目进度表时，或者开发者没有履行好他们的承诺时，顾客就可能会认为开发者不够合作。而开发者可能会认为顾客过于无理地坚持不现实的项目进度或修改明明已经确定下来的要求。于是这两拨人之间就可能发生人身攻击或诽谤。

　　这种冲突的最主要的影响是使交流和沟通变得匮乏，其中又包含了对需求的缺乏理解，用户界面设计不够理想，更糟糕的情况则是顾客拒绝接受已经完成的产品。平均地来说，顾客和软件开发者之间的冲突往往会严重到双方要撕毁合同取消项目的开发（Jones 1994）。这种冲突是非常耗时的，而且会把双方的精力从真正的工作中吸引出来。

#8：不现实的期望

　　最可能引起开发者和消费者或管理者之间冲突的原因之一是不现实的期望。在案例分析3-1中，如果不是公司需要那么多时间，Bill没有理由相信Giga-Quote项目可能在6个月内开发完毕。Mike没有纠正这个不现实的期望是问题的主要来源。在其他情况下，项目管理者或开发者会根据过于乐观的项目日程估计来申请项目资金。有时候他们会作出不能保证实现的承诺。虽然不现实的期望并没有自发地造成项目日程的增长，但它仍会形成开发时间过长的假象，这会使事情变得非常糟糕。Standish Group的一个调查表明，贴近现实的期望是保证商业软件开发项目成功的五大要素之一（Standish Group 1994）。

#9：缺乏有效的项目赞助

　　高级别的项目赞助可以在许多方面保证项目的高效开发，包括现实的计划、权变控制，以及新的开发实现操作。如果没有这样一种有效的项目赞助，那么其他更高级别的人事管理就会在组织里迫使你去接受不现实的最后期限，或被迫接受一些削减项目的变化。澳大利亚咨询师Rob Thomsett说，缺少有效的项目赞助事实上注定了项目的失败（Thomsett 1995）。

#10：缺乏利益相关者的入伙

　　软件开发中所有的主要成员都要入伙该项目，其中包括执行赞助、团队领导、团队成员、市场部、最终用户、消费者以及其他所有利益相关方。密切的合作只在所有的利益相关者入伙时才会发生，从而保证了项目的顺利进行。

#11：缺乏用户的参与

　　Standish Group的调查表明IS项目获得成功的最主要的原因是其用户积极参与了项目的开发（Standish Group 1994）。

#12：将权术置于本质之上

　　Larry Constantine就四个团队进行了报道，并称他们分别具有四种权术中心（Constantine 1995a）。“政治型”团队倾向于“向上管理”，即更关注与其上层领导之间的关系。“研究型”团队专注于侦察和收集信息。“隔离型”团队以自我为中心，他们会与非团队成员划清界线。而“通用型”团队则每件事都做一些：他们和上级搞好关系，进行研究和收集信息的工作，并在工作流程中和其他团队进行协调。Constantine报道称，一开始是“政治型”和“通用型”团队能够被上级领导重视，但在一年半以后“政治型”团队被打入冷宫。所以说将权术置于成果之上对高效开发来说是致命的。

#13：一厢情愿的想法

　　我很惊讶，为什么在软件开发中有许多问题最后都归结为一厢情愿的想法。你听过几次类似下面的说法：

　　“团队中没有一个成员认为他们可以按期完成任务，但他们却想如果每个人都努力功能，没有一件事会出错，再加上几次幸运的休假，相信他们就能顺利完成任务。”

　　“我们团队还没有将产品的几个部分进行融合，但我们会在其他发面进行有效的沟通，而且这些部分之间的接口是比较简单的，所以应该只要一两天的时候来修复其中存在的问题。”

　　“我们以谎报低价的方式和他们签订了数据库子系统的承包合同，而要完成这些任务就需要相当的人力资源，这对他们来说是很困难的，因为他们并没有这方面的资历，但也许他们可以用更多的精力来弥补经验上的不足。也许他们可以按时完成任务。”

　　“我们不需要想顾客展示程序的最终原型，我很确定这就是他们想要的。”

　　“这个团队称他们会非常努力地按期完成任务，虽然他们在第一个关键时间点上延误了几天，但我相信他们可以按时完成的。”

　　一厢情愿的想法不是乐观，而是闭上了你的眼睛去期望一些根本没有理由相信其存在的东西。这种想法会在项目的最后阶段带来巨大的麻烦。它不仅削弱了有意义的计划，而且很有可能这项软件工程有着更多更复杂的问题。

过程

　　与过程相关的错误会降低项目的开发速度，因为他们会浪费人们的智慧和精力。以下列举一些影响最坏的错误。

#14：过于乐观的项目进度

　　一个要在三个月内完成项目的人与一个要在一年内完成项目的人所面临的压力和挑战是不同的。过于乐观的项目进度会使项目被过分重视，削弱了有效的计划，并缩减了上层开发活动如需求分析和设计，这将使项目面临失败。这还会对开发者连续施加压力，使他们的士气和产能受挫。这也是案例分析3-1中问题的一个主要来源。

#15：风险管理不足

　　有些错误可以被视作经典错误，有些则只在特定的项目中发生。在经典错误中，如果不注意主动地进行风险管理，就会将一个快速开发项目变成慢速的。风险管理失败是最普遍的经典错误之一。

#16：承包人失职

　　公司有时候会因为项目太紧急不能自己完成就把项目的一部分交给承包人来做。但是承包人通常会迟交任务，且质量很差，甚至没有达到指定的要求（Boehm 1989）。当程序的需求不够确定，或是程序结果设计得不好，那这其中的风险将会在寻找承包人时得到放大。如果与承包人之间的关系处理得不够好，就会降低项目的开发速度，而不是加快。

#17：计划不足

　　如果你不计划快速地完成项目，那就不可能快速地完成。

#18：在压力中放弃计划

　　当项目进度遇到麻烦，开发者就会放弃原先制定好的计划（Humphrey 1989）。问题的严重性并不在于放弃了计划，而在于没有建立一个备用方案，从而陷入编写-修复的循环中。在案例分析3-1中，团队因为按时进行第一次发布（这很正常），因而放弃了他恩的计划。结果是，这一时间点之后的工作都是无计划的，甚至Jill开始用一部分时间来为她以前的队员工作，且没有一个人知道。

#19：在“模糊的前端”中浪费时间

　　“模糊的前端”指的是在项目开始之间所进行的验证和预算阶段。不少项目会花上几个月甚至几年的时间来进行这项工作，然后制定出一个非常紧迫的项目进度。从“模糊的前端”中节约几个星期或几个月的时间要比在经过压缩后的项目进度中节约时间容易、便宜和有保障得多。

#20：不充足的前期工作

　　比较紧急的计划会尝试着缩减一些不必要的工作，所以诸如需求分析、建构和设计等不能产生代码的工作就成为了缩减的首要目标。有一次我接手了一个非常糟糕的项目，我说我想看一下项目的设计图，团队领导却说他们没有时间做出设计图。

　　这个错误还被称为“直接跳进编码阶段”，其结果是可以料想到的。在案例分析中，条状设计图被质量设计工作所代替。在产品可以被发布之前，设计图的工作只能被否决，更高的质量工作必须要立刻完成。缩减了前期工作的项目肯定要在后期工作中弥补这些工作，而花费的精力却是10倍甚至100倍的（Fagan 1976; Boehm and Papaccio 1988）。如果你没有额外的5个小时去把第一项工作做好，难道你能找到额外的50个小时去做接下来的工作吗？

#21：不充足的设计

　　在不充足的前期工作中，不充足的设计是一个特例。紧急的项目会使用来进行项目是设计的时间减少，同时高压的环境会让提出替代方案变得非常困难。项目设计的目的在于权宜而不是质量，所以在项目完成之前你需要一些非常耗时的项目设计周期。

#22：不充足的质量保证

　　一个紧急的项目会通过减少设计和编码的检查、减少测试计划并只进行简单地测试。在案例分析中，设计回顾和编码回顾都只花了很少的时间以完成项目进度。而结果是，当项目进行到关键的地方，仍有过多的程序错误导致推迟5个多月发布。这种后果是很典型的。在质量保证过程中减少了一天的工作，就会在后期增加3到10天的工作量（Jones 1994）。这会降低项目开发的速度。

#23：不充足的管理控制

　　在案例分析中，有一些管理控制措施会用来对即将发生的工作失误进行警告。但是，当项目出现了问题，这些管理控制就被放弃了。如果你想让项目一直保持在轨道上，那你就必须知道项目是否在轨道上，即有一个评定的标准。

#24：过早的或过于频繁的整合

　　在产品即将发布之前，应该做一些准备，如提高产品的星等、打印最终使用文档、组织最终的帮助系统挂钩、修饰一下安装程序、找出不能完成任务的组件等。在紧急的项目中，人们喜欢把项目过早地整合起来。由于在完成之间不能进行组合，于是有人就在工作过程中对项目进行许多次的整合，直到成功。这些额外的整合并没有使项目受益，而只是浪费时间和拖延进度罢了。

#25：忽略了某些任务

　　如果人们不对已经完成的项目作仔细的记录，而忘记了其中某些不显眼的任务，那这些任务会越积越多。这些被忽略的工作会累计到整个进度的20%到30%。

#26：计划以后再抓紧

　　如果你要完成一个6个月的项目，而用了3个月的时间完成了2个月的工作，你会怎么做？许多开发人员会说他们计划以后再抓紧，但是他们从来没有这样做过。你在建立项目的时候你会知道得越多，其中包括还需要多少时间去完成它。所以这些信息也需要反映在项目日程中。

　　另一种错误来自于项目的变更。如果你的项目变了，那你需要完成该项目的时间也会发生变化。在案例分析3-1中，项目的主要需求改变了，而项目开发团队却没有制定相应的措施来对进度表作出调整。面对日益增多的新要求，而不在项目进度中反映出来，一定会导致不能按期交货。

#27：糟糕的编码

　　有些组织认为快速、随意的编码是同样快速开发的捷径。他们争辩道，如果开发者被充分地激励了，他们就能克服万难。这远远不是实施，本书的其他章节会阐述其中原因。“企业家模式”通常是守旧的“编码-修复”模式的幌子，而且这种模式几乎不管用。这也是“错加错不等于对”的一个例子。

产品

　　以下列举一些在定义产品的时候所容易犯的错误。

#28：过高的需求

　　有些项目从一开始就被提出了过高的需求。项目需求的提出往往会超过实际的需求，这无疑会增长项目的进度。用户对市场和开发速度的需求要比那些复杂的特性来得高，而且复杂的特性会大大改变项目的开发进度。

#29：过低的需求

　　即使你成功避免了过高的需求，平均每个项目都会在其生命周期中发生25%的改变（Jones 1994）。某一个改变至少会增长25%的开发进程，这对快速开发来说是致命的。

#30：开发者画蛇添足

　　开发者会被新科技所吸引，有时会想要在项目开发中尝试一些新的特性，或者参照别的程序里的组件，自己写出它的实现，即使项目没有这样要求。这些设计、实现、测试、撰写文档的经历都是不需要的，且会增长项目进度。

#31：来回推搡的谈判

　　有一种奇怪的谈判策略，管理者在确认了进度上的失误后，即没有按时完成任务，就在进度更改后又加上新的任务。这样做的理由耐人寻味，因为确认了进度上失误的这个管理者也表示承认了项目进度是有错误的。但是当项目进度重新调整正确后，同一个人又用明显的举动将其再一次搞错。这无疑将拖延开发进度。

#32：以研究为中心的项目开发

　　Cray超级计算的设计师Seymour Cray说，他从来没有试图过同时跨越两个领域进行开发，因为那样做风险太高了（Gilb 1988）。许多软件项目开发人员可以从Cray那里好好学一学。如果你的项目着眼于研究出新的算法或实践方式，那你就不是在进行软件开发，你是在做软件研究。软件开发进度是可预测的，而软件研究的进度即使从理论上讲也是不可测的。

　　如果你的产品目标中包括了研究出新的算法、提高速度、内存使用等，那你就得预见项目进度是非常不确定的。如果你的项目中还有其他弱点，如人员的短缺，人员资历不足，模糊的需求，于承包人之间不稳定的接洽，那就把项目进度扔到窗外去吧。如果你真的想要完成那些研究，那就不要期望进度会很快！

技术

　　剩下的经典错误是和现代技术的使用和误用有关的。

#33：银弹综合症

　　在案例分析中，人们把太多的期望寄托在所谓的新技术中（报告生成器，面向对象编程，C++），而它们是否能在此项目中发挥效用还不得而知。当项目开发团队决定使用一种新的方法或技术，其他它能解决目前所面临的问题时，他们一定会非常失望（Jones 1994）。

#34：对新工具和方法太过犹豫

　　在技术革新时，组织很少会大幅度提高他们的产能，不管他们引进了多少先进的技术。先进的技术所带来的好处基本上不在他们的学习范围之内，而要学习这些新的技术以发挥其最大效能是需要花费时间的。新的技术同时会包含新的风险，只有使用后才会发现。人们宁愿使用慢速的稳定的提高，而不是经历起伏过大的收获。案例分析3-1中的开发团队应该已经计划到使用了新技术后会使产能提高10%，而不是乐观的相信这会使开发速度提高一倍。

　　有一个特例，当在使用过去项目的代码时，这种犹豫会更加明显，但时间的节省并没有想像中的多。

#35：在项目开发过程中更换工具

　　这是一种惯常的备用手段但很少奏效。有时这对于相同产品线内的升级会有效，如3.0版、3.1版甚至4.0版。但其中的因为使用新工具而产生的学习时间、重复劳动和不可避免的错误往往会抵消掉在项目中途更换工具的好处。

#36：缺少自动化的源代码控制

　　不进行自动化的源代码控制会使关键项目遭受不必要的风险。如果没有它，当两个程序员在开发同一个部件时，他们就需要进行手工整合。他们也许会达成约定，把修改好的文件存入一个主文件夹，并在修改时注意查看文件时间信息。但是有些人总是会覆盖他人的工作。当人们用过时的结构来编写程序，在发现之后又必须进行重写。当用户举报程序的错误时间，你就不能重新编译项目。源代码平均每个月要更改10%，而手工的源代码控制是跟不上的（Jones 1994）。