Antipatrones II: Antipatrones de gestión de proyectos

Gracias al trabajo de recopilación de varias personas (que recuerde ahora al menos Ahmad, Miguel, Jesús, Juanma y María) puedo postear esto ;).

Los antipatrones son soluciones erróneas que presentan más problemas que los que solucionan.

Son una extensión natural a los patrones de diseño.

Los antipatrones pueden dividirse en 3 grandes categorías:

  • Desarrollo de Software: Se centran en problemas asociados al desarrollo de software a nivel de aplicación.
  • Arquitectura de Software: Se centran en la estructura de las aplicaciones y componentes a nivel de sistema y empresa.
  • Gestión de Proyectos de Software: En la ingeniería del software, más de la mitad del trabajo consiste en comunicación entre personas y resolver problemas relacionados con éstas. Los antipatrones de gestión de proyectos de software identifican algunos de los escenarios clave donde estos temas son destructivos para el proceso de software

Antipatrones de gestión de proyectos

Nombre Concepto
smoke and mirrors Mostrar cómo será una funcionalidad antes de que esté implementada.
bad management Gestionar un proyecto sin tener suficientes conocimientos sobre la materia.
software bloat Permitir que las sucesivas versiones de un sistema exijan cada vez más recursos.
Death march Todo el mundo sabe que el proyecto va a ser un desastre, excepto el director, para el que la verdad se oculta para evitar la cancelación inmediata del proyecto (aunque el director a menudo lo sabe y lo hace de todas formas para maximizar el beneficio). Sin embargo, la verdad permanece oculta y el proyecto se mantiene artificialmente con vida hasta que finalmente llega el día cero.

Los empleados son presionados para trabajar por las noches y fines de semana en un proyecto con plazos poco razonables.

Groupthink Los miembros del grupo evitan que transcienda los diferentes puntos de vista fuera de la “zona de consenso”
Overengineering: Exceso de ingeniería: se usan recursos para hacer el proyecto más robusto pero más complejo de lo necesario
Waterfall model Un modelo de desarrollo de software un poco antiguo que no gestiona adecuadamente los cambios inesperados
Analysis paralysis Parálisis del análisis: dedicar esfuerzos desproporcionados a la fase de análisis de un proyecto, eternizando el proceso de diseño iterando sobre la búsqueda de mejores soluciones o variantes.
Death by plannin Morir planificando
Irrational management Las indecisiones habituales y otros malos hábitos de gestión provocan que no se tomen decisiones ineludibles en el momento adecuado
Project mismanegement La falta de atención en la gestión de los procesos de desarrollo de software puede causar ausencia total en la dirección del proyecto. El seguimiento y el control en los proyectos de software es necesario para conseguir un desarrollo satisfactorio. El desarrollo se convierte en una tarea tan difícil como construir un rascacielos (implica demasiados pasos y procesos). A menudo, las actividades clave se pasan por alto o se minimizan

2 comentarios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s