ÉnKép - takacsot

• #1: Undermined motivation. Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor
• #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. Failure to take action to deal with a problem employee is the most common complaint that team members have about their leaders
• #4: Heroics. Some software developers place a high emphasis on project heroics, thinking that the certain kinds of heroics can be beneficial
• #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.
• #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.
• #8: Unrealistic expectations. One of the most common causes of friction between developers and their customers or managers is unrealistic expectations.
• #9: Lack of effective project sponsorship.
• #10: Lack of stakeholder buy-in. 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
• #12: Politics placed over substance.
• #13: Wishful thinking. I am amazed at how many problems in software development boil down to wishful thinking. 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.
• #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.
• #15: Insufficient risk management. 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.
• #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.
• #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.
• #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.
• #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
• #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.
• #27: Code-like-hell programming.
• #28: Requirements gold-plating. Some projects have more requirements than they need right from the beginning.
• #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.
• #32: Research-oriented development.
• #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
• #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
• #35: Switching tools in the middle of a project. T
• #36: Lack of automated source-code control.

Original