Blog de Antonio Manuel Muñiz

Desarrollo, Ingeniería y Calidad del Software

Guía práctica para hacer fracasar un proyecto

Si tenemos por objetivo que un proyecto fracase estrepitosamente, no tenemos más que cumplir las siguientes directrices (o buenas prácticas) de forma escrupulosa:

  1. No usar un sistema de control de versiones, lo mejor es que cada desarrollador trabaje en su propia máquina.
  2. No documentar absolutamente nada, el propio código es la mejor documentación.
  3. Cada desarrollador debe hacer lo que quiera, sin nadie que coordine su trabajo y sin ningún tipo de comunicación entre ellos.
  4. Es fundamental que no se defina ningún tipo de prueba, y prohibir terminantemente el uso de sistemas de integración continua.
  5. No compilar de forma frecuente, a lo sumo, una vez a la semana.
  6. Si el proyecto comprende bloques funcionales independientes, es imprescindible no realizar ninguna prueba de integración, solamente se hará una, el día antes de poner la aplicación en producción.
  7. Asegurar que nunca se sabrá quién hizo qué, de esta forma, a falta de documentación (véase punto 2), mantendremos los indices de inmantenibilidad en los valores deseados.
  8. El proceso de despliegue de la aplicación debe ser lo más complejo posible, por supuesto indocumentado y ligado a la máquina en la que se desarrolló.
  9. Y claro está, lo más importante, las palabras “Quality Assurance” jamás serán pronunciadas.

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 )

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 )

Google+ photo

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

Conectando a %s

A %d blogueros les gusta esto: