Errores Comunes En El Desarrolo De Software

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 yourkey 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 thesemistakes 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 commondenominator 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 riskmanagement. 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 shownthat 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 adollar 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 whocould 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 publishedPsychology 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 developersplace 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...