Errores clsicos en el desarrollo software

Muchas veces, en alguna conversacin referente a algn proyecto software, cuando alguien nos pide una opinin, en alguna charla o cuando estudiamos los riesgos de algn proyecto, suele salir la lista de errores clsicos de McConnell. Debido al uso y utilidad de la misma, me ha parecido interesante dejarla resumirda en este post. En 1996 Steve McConnell public el libro Rapid Development, en mi opinin uno de los mejores libros que se han escrito en lo que refiere a la gestin de proyectos software, en el que introduca el concepto error clsico del desarrollo software. McConnell defini a los errores clsicos como aquellos que se han repetido tantas veces, y por tanta gente, que debieran ser previsibles y siempre se deberan gestionar. El libro describa 36 errores clsicos, que en 2007 se ampliaron a 42, sobre los que se realiz una encuesta sobre aproximadamente 500 profesionales con el objetivo de determinar su frecuencia y gravedad. A continuacin os resumo los errores que ocurren con mayor frecuencia, los que ocurren con menor frecuencia y los que de ocurrir tienen ms impacto: Errores que ocurren con mayor frecuencia 1. 2. 3. 4. 5. 6. 7. 8. 9. Planificaciones demasiado optimistas Expectativas no realistas (o pedirle a un proyecto algo imposible) Excesivas tareas (cuando, por ejemplo, los desarrolladores estn en muchos proyectos a la vez) Insuficiente aseguramiento de la calidad Oficinas ruidosas Incorporacin de caractersticas (por ejemplo, introducir nuevos requisitos a mitad de proyecto) Hacerse ilusiones (por ejemplo, cerrar los ojos a lo que se nos viene encima) Gestin del riesgo insuficiente Confundir estimaciones con objetivos (cuando por ejemplo el objetivo es tener el software en 3

meses, y de ah se fija que el desarrollo sern 3 meses) 10. Omitir tareas relacionadas con la estimacin (no guardar histricos para realizar mejores

estimaciones, al estimar obviar tareas como son las reuniones, etc.) Errores que ocurren con menor frecuencia 1. 2. 3. 4. 5. Cambio de herramientas en mitad del proyecto Falta de control automatizado del cdigo fuente Desarrollo dirigido por la investigacin Convergencia prematura o muy frecuente (forzar el cierre de una versin antes de que sea posible) Estimar obviando el uso de nuevas herramientas o mtodos (obviando, por ejemplo, el coste de

aprendizaje) 6. 7. 8. 9. Negociaciones y el tira y afloja (entre, por ejemplo, desarrollo y comerciales) El sndrome de la bala de plata Errores en la subcontratacin Llevar al equipo en la oscuridad (cuando, por ejemplo, los jefes de proyecto ocultan al equipo el

avance y plan de proyecto) 10. Problemas con el equipo

Errores que provocan problemas de mayor impacto 1. 2. 3. 4. 5. 6. 7. 8. Expectativas no realistas (o pedirle a un proyecto algo imposible) Equipo poco preparado Planificaciones demasiado optimistas Hacerse ilusiones (por ejemplo, cerrar los ojos a lo que se nos viene encima) Insuficiente aseguramiento de la calidad Diseo inadecuado Falta de apoyo al proyecto Confundir estimaciones con objetivos (cuando por ejemplo el objetivo es tener el software en 3

meses, y de ah se fija que el desarrollo sern 3 meses) 9. 10. Excesivas tareas (cuando, por ejemplo, los desarrolladores estn en muchos proyectos a la vez) Falta de involucracin del usuario