Errores comunes en desarrollo software (III)
Escrito por Luix hace 1 años
bajo una licencia de Creative Commons
880 visitas. Etiquetas: gestion, software, desarrollo, proyecto
- Actividades fundamentales acortadas. En cierto modo, una consecuencia del error anterior. Cuando hay prisa, se recortan las tareas que no producen código directamente. Habitualmente las candidatas son: análisis de requisitos, diseño y elección de la arquitectura, curiosamente las fases con mayor riesgo y más claves del proyecto.
- Diseño inadecuado. Viene un poco en consonancia con lo que acabamos de anotar: diseños realizados con prisa, no atendiendo debidamente al tiempo requerido conducen a malos productos. Un diseño completo requiere varios ciclos.
- Acortar tareas de calidad. Cuando hay prisa, tratan de acortarse tareas de revisión de código y testing. Eliminar un sólo día de tareas de calidad puede alargar el proyecto entre 3 y 10 días más.
- Controles de gestión insuficientes. Antes de tratar de mantener un proyecto en el buen camino, pregúntate si el proyecto está en dicho momento en el buen camino.
- Convergencia prematura o demasiado frecuente. Cuando se acercan fechas de entrega del producto, es necesario realizar tareas de mejora de desempeño, documentación, preparación de la instalación del producto, etc. Se suele tender a converger demasiado pronto en el sentido de empezar a preparar la release demasiado pronto, lo cual es contraproducente porque luego habrá que volver a converger alguna vez más con nuevas mejoras producidas y además condiciona negativamente al proyecto. Realmente es complicado cómo decidir cuándo converger: no puede ser demasiado tarde porque hay un buen número de tareas propias de fase de release, como las que hemos apuntado antes, que deben ser realizadas, pero si se trata de integrar el trabajo demasiado pronto luego habrá que integrar nuevas funcionalidades y bug fixing realizado.
- Omitir tareas necesarias de las estimaciones. Es fácil olvidar tareas menos visibles pero necesarias, que luego añaden tiempo a la calendarización. Una buena medida sería guardar información histórica de anteriores proyectos para tener algo más de información acerca de qué se necesitó realizar y poder estimar con más conocimiento de causa.
- Planear ponerse al día más adelante. Si una estimación resulta no ser adecuada en la realidad, las estimaciones de las tareas dependientes de ella deben ser reajustadas en consonancia, y no esperar que el proyecto avance más deprisa a partir de tal momento. Es razonable fallar una estimación: uno aprende del proyecto a medida que éste avanza. Es necesario reajustar estimaciones también cuando cambian los requisitos.
- Programar a lo loco. Olvidarse de realizar un diseño bien trabajado. Sin razonar. Al más puro estilo ensayo y error. Esto conduce a tirar mucho trabajo que no vale, a perder mucho tiempo en experimentación poco productiva. Esto, que parece un error de novato, es a lo que conducen las calendarizaciones ambiciosas, cosa que está a la orden del día en muchas empresas.
Referencias:
Steve McConnell: Rapid Development, Taming Wild Schedules
Más información en:
http://luixrodriguezneches.wordpress.com
Artículos Relacionados
- Errores comunes en desarrollo software (I)
- Errores comunes en desarrollo software (II)
- 10 Buenas prácticas de Testing
- Gestión de Proyectos Software
- Gestión de proyectos Software (II)
Grupos relacionados
Ingeniero Informático por la Universidad de Valladolid (España). Me interesa la programación, gestión de proyectos, patrones, metodologías..., la seguridad y la administración de redes y sistemas operativos. Actualmente trabajo en Códice Software, una empresa vallisoletana que desarrolla PlasticSCM, una herramienta de control de versiones, además de consultoría a clientes sobre temas relacionados con la Gestión de Configuraciones. http://luixrodriguezneches.wordpress.com
© Copyright 2008-2009 debug_mode=ON | Aviso legal | Contacto | FAQ | ¿Quiénes somos?
|