Errores clásicos en los proyectos de Software

1. Tecnología El resto de los errores clásicos están relacionados con el uso correcto o incorrecto de la tecnología moderna.

1.1. Síndrome de la panacea

1.1.1. Cuando un equipo de proyecto se aferra solo a una nueva técnica, una nueva tecnología o un proceso rígido, y espera resolver con ello sus problemas de planificación.

1.1.1.1. img

1.2. Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos

1.2.1. Un caso especial de sobreestimaciones de las mejoras se produce cuando se reutiliza codigo d e proyectos anteriores. Este tipo de reutilización puede ser una técnica muy efectiva, pero el tiempo que se gana no es tan grande como se espera.

1.2.1.1. img

1.3. Cambiar de herramientas a mitad del proyecto

1.3.1. Es un viejo recurso que funciona raramente. A veces puede tener sentido actualizar incrementalmente dentro de la misma linea de productos, de la versión 3 a la 3.1 o incluso a la 4. Pero cuando estamos a la mitad de un proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos con una herramienta totalmente nueva, normalmente anulan cualquier posible beneficio.

1.3.1.1. img

1.4. Falta de control automático del código fuente

1.4.1. Se desarrolla nuevo código con interfaces desfasadas, y después se tiene que re-diseñar el código al descubrir que se ha utilizado una versión equivocada de la interfaz.

1.4.1.1. img

2. Producto A continuación se muestran los errores clásicos relacionados con la forma en la que se define el producto.

2.1. Exceso de Requerimientos

2.1.1. Algunos proyectos tiene mas requerimientos de los que necesitan, desde el mismo inicio.

2.1.1.1. img

2.2. Cambio de las prestaciones

2.2.1. Incluso si hemos evitado con éxito los requerimientos excesivos, los proyectos sufren como media sobre un %25 de cambios en los requerimientos a lo largo de su vida.

2.2.1.1. im

2.3. Desarrolladores meticulosos

2.3.1. Los desarrolladores encuentran fascinante la nueva tecnología y el esfuerzo requerido para diseñar, implementar, probar, documentar o mantener estas prestaciones innecesarias alarga el plan.

2.3.1.1. img

2.4. Tiras y aflojas en la negociación

2.4.1. Cuando un directivo aprueba un retraso en el plan de un proyecto que progresa mas lento de lo esperado, y entonces añade tareas completamente nuevas después de un cambio en el plan, se produce una situación curiosa.

2.4.1.1. img

2.5. Desarrollo orientado a la investigación

2.5.1. Si el proyecto fuerza los limites de la informática por que necesita la creación de nuevos algoritmos o de nuevas técnicas de computación, no estamos desarrollando software; estamos investigando en software.

2.5.1.1. img

3. Personas Éstos son algunos de los errores clásicos relacionados con las personas.

3.1. Motivacion Debil

3.1.1. Estudio tras estudio se ha mostrado que la motivación probablemente tiene mayor efecto sobre la productividad y la calidad que ningún otro factor.

3.1.1.1. img

3.2. Personal Mediocre

3.2.1. La capacidad individual de los miembros del equipo, así como sus relaciones como equipo, probablemente tienen la mayor influencia en la productividad.

3.2.1.1. img

3.3. Empleados problemáticos incontrolados

3.3.1. Al tomar una decisión cuando se trata con un empleado problemático es una de las quejas mas comunes que tienen los miembros del equipo respecto de sus responsables.

3.3.1.1. img

3.4. Hazañas

3.4.1. Algunos desarrolladores de software ponen un gran énfasis en la realización de hazañas en los proyectos (Bach, 1995). Pero lo que hacen tiene mas de malo que de bueno.

3.4.1.1. img

3.5. Añadir mas personal a un proyecto retrasado.

3.5.1. Cuando un proyecto se alarga, añadir mas gente puede quitar mas productividad a los miembros del equipo existente de la que añaden los nuevos miembros.

3.5.1.1. img

3.6. Oficinas repletas y ruidosas.

3.6.1. La mayoría de los desarrolladores consideran sus condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad.

3.6.1.1. img

3.7. Fricciones entre los clientes y los desarrolladores.

3.7.1. Las fricciones entre los clientes y los desarrolladores pueden presentarse de distintas formas. Ya sean que los clientes piensan que los desarrolladores no cooperan cuando rehúsan comprometerse con el plan de desarrollo que desean los clientes o cuando los desarrolladores puede parecerles que los clientes no son razonables porque insisten en planes irreales.

3.7.1.1. img

3.8. Expectativas poco realistas.

3.8.1. Una de las causas mas comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas.

3.8.1.1. img

3.9. Falta de un promotor efectivo del proyecto.

3.9.1. Es necesario un promotor del proyecto de alto nivel, incluyendo una planificación realista, el control de cambios y la introducción de nuevos métodos de desarrollo.

3.9.1.1. img

3.10. Falta de participación de los implicados.

3.10.1. Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto.

3.10.1.1. img

3.11. Política antes que desarrollo

3.11.1. Los políticos están especializados en la gestión, centrándose en las relaciones con sus directivos. Los investigadores se centran en explorar y reunir información.

3.11.1.1. img

3.12. Ilusiones

3.12.1. Las Ilusiones al comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo una planificación coherente y pueden ser la raíz de mas problemas en el software que todas las otras causas combinadas.

3.12.1.1. img

4. Proceso Los errores relacionados con el proceso ralentizan a los proyectos por que malgastan el talento y el esfuerzo del personal.

4.1. Planificación excesivamente optimista

4.1.1. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la planificación efectiva y reduciendo las actividades criticas para el desarrollo.

4.1.1.1. img

4.2. Gestión de riesgos insuficientes

4.2.1. Si no ejercemos una gestión activa de los riesgos, con que solo vaya mal una cosa se pasara de tener un proyecto con un desarrollo rápido a uno con un desarrollo lento.

4.2.1.1. img

4.3. Fallos de los contratados

4.3.1. Los contratados frecuentemente entregan su trabajo tarde, con una calidad inaceptable o que falla al no coincidir con la especificación.

4.3.1.1. img

4.4. Planificación insuficiente

4.4.1. Si no planificamos para conseguir un desarrollo rápido, no podemos esperar obtenerlo.

4.4.1.1. img

4.5. Abandono de la planificación bajo presión

4.5.1. Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificación.

4.5.1.1. img

4.6. Perdida de tiempo en el inicio difuso.

4.6.1. El inicio difuso es el tiempo que trascurre antes de que comience el proyecto; este tiempo se pierde en el proceso de aprobar y hacer el presupuesto.

4.6.1.1. img

4.7. Escatimar en las actividades iniciales

4.7.1. Los proyectos que se aceleran intentando acortar las actividades no esenciales.

4.7.1.1. img

4.8. Diseño inadecuado

4.8.1. Proyectos acelerados generan un diseño indeterminado, no asignando suficiente tiempo para él y originando un entorno de alta presión que hace difícil la posibilidad de considerar alternativas en el diseño.

4.8.1.1. img

4.9. Escatimar en el control de calidad

4.9.1. Acortar en un día las actividades de control de calidad al comienzo del proyecto supondrá de 3 a 10 días de actividades finales, esta reducción va contra la velocidad de desarrollo.

4.9.1.1. img

4.10. Control insuficiente de la directiva

4.10.1. Poco control de la directiva para detectar a tiempo los signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se abandonan cuando el proyecto comenzó a tener problemas.

4.10.1.1. img

4.11. Convergencia prematura o excesivamente frecuente.

4.11.1. Bastante antes de que se haya programado entregar un producto, hay un impulso para preparar el producto para la entrega, modificando diversos detalles.

4.11.1.1. img

4.12. Omitir tareas necesarias en la estimación

4.12.1. Se presenta que se olvidan las tareas menos visibles, pero son tareas que se han de añadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un %20 o %30.

4.12.1.1. img

4.13. Planificar ponerse al día mas adelante

4.13.1. En muchos proyectos simplemente se plantea recupera el retraso mas tarde, pero nunca se hace. Otro tipo de error en la reestimación se debe a cambios en el producto.

4.13.1.1. img

4.14. Programación a destajo

4.14.1. Algunas empresas piensan que si los desarrolladores están lo suficientemente motivados, pueden solventar cualquier obstáculo.

4.14.1.1. img