Desarrollo de software. Death March Project
Edward Nash Yourdon popularizó este término en su libro «Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects».
¿Qué es un Death March Project? Según Yourdon todo aquel proyecto en donde algunas de las variables necesarias para el éxito del proyecto exceden un porcentaje importante la norma (el mismo Yourdon comenta que no hay una fórmula, ya que son muchos las factores que pueden intervenir en un proyecto de desarrollo de software, si bien considera que fluctuaciones de un 10% sobre las métricas normales que debería tener el proyecto no debería ocasionar un trastorno sensible en el mismo).
Algunas situaciones que pueden dar lugar a Death March Projects las tenemos por ejemplo con un proyecto que se intenta hacer en la mitad del tiempo necesario para desarrollarlo o con un presupuesto que es la mitad del necesario para llevarlo a cabo.
Lo peor de todo es que generalmente un valor inadecuado de estos parámetros tiende a arrastrar a otros por lo que el problema se multiplica.
A veces, una mala estimación del alcance del proyecto o unos cambios en las especificaciones pueden provocar esta situación, sin embargo, en la mayoría de las ocasiones donde existe un Death March Project, se sabe prácticamente desde que se está planificando que es imposible cumplir los objetivos.
Es más, de los casos anteriores, desde que se hace una oferta a un cliente se sabe que no se va a cumplir, dejando el problema a los que después se van a encargar del proyecto.
Y lo triste es que son muy comunes…
Pingback: Desarrollo de software. Death March Project. Malas estimaciones « Jummp
Pingback: La imagen del desarrollo de software « Jummp
Pingback: Desarrollo de software. Death March Project. Tardar en darse cuenta « Jummp
Pingback: Desarrollo de software. Death March Project. Heridas mal curadas « Jummp
Pingback: Desarrollo de software. Death March Project. Cuando el problema viene de arriba « Jummp
Pingback: Desarrollo de software: La cohesión « Jummp
Pingback: Desarrollo de software: El framework no debe ser excusa « Jummp
Pingback: Desarrollo de software. Death March Project. Solicitud de más recursos « Jummp
Pingback: Desarrollo de software. Death March Project. Participar en la locura « Jummp
Pingback: Desarrollo de software. Death March Project. Cómo evitarlo. « Jummp
Pingback: Desarrollo de software. Death March Project. Habilidad en la negociación « Jummp
Pingback: Desarrollo de software. Death March Project. ¿Y si la negociación falla o no es suficiente? « Jummp
Pingback: Desarrollo de software. Presupuestos holgados y presupuestos excesivos « Jummp
Pingback: Desarrollo de software. Proyectos y errores « Jummp
Pingback: Desarrollo de software. Los desarrolladores y el valor de las personas « Jummp
Pingback: Desarrollo de software. El inicio del proyecto no es la programación « Jummp
Pingback: ¿Qué es el ciclo de vida del software? « Jummp
Pingback: Desarrollo de software. Sun Tzu. Gestión inicial del riesgo, condiciones iniciales para el desarrollo « Jummp
Pingback: Desarrollo de software. Las empresas de desarrollo de software, calidad, cambio de modelo « Jummp
Pingback: Desarrollo de software. Fuerza de rozamiento o fricción « Jummp
Pingback: Desarrollo de software. ¿Por qué existen gestores de proyectos? « Jummp
Pingback: Refactorizar como algo natural « Jummp
Pingback: Refactorizar y las falsas promesas « Jummp
Pingback: Tom DeMarco. ¿Apariencia o necesidad? « Jummp
Pingback: Tom DeMarco. Las planificaciones agresivas no suelen producir buenos resultados « Jummp
Pingback: Jim Highsmith. Su visión de la gestión de proyectos ágil « Jummp
Pingback: ¿Cómo voy a ponerme a pensar en la deuda técnica con el marrón que tengo? « Jummp
Pingback: Desarrollo de software. La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas I « Jummp
Pingback: Desarrollo de software. La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas III « Jummp
Pingback: Desarrollo de software. Antipatrón. Ventas deficitarias « Jummp
Pingback: Desarrollo de software. Antipatrón. Espíritu de Dunkerque « Jummp
Pingback: Desarrollo de software. Maleabilidad | Jummp
Pingback: Desarrollo de software. Maleabilidad | StackPointerBlog
Pingback: La agilidad y el alcance III | Jummp
Pingback: Calidad del software y valor VII | Jummp
Pingback: Escapar de la llave en mano, ¿quién asume el riesgo? | Jummp
Pingback: Desarrollo de software. ¿Quién gana el partido? | Jummp
Pingback: Agile Inception V | Jummp
Pingback: Agile Inception IX | Jummp
Pingback: Desarrollo de software. ¿Quién expone en los contratos? | Jummp
Pingback: Desarrollo de software. ¿Son las estimaciones una guerra perdida? | Jummp