Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Bomberos y Brigadas preventivas.

3 comments
Bomberos y Brigadas preventivas.

Los apagafuegos y la calidad.

Hay equipos de desarrollo que viven en un continuo estado de alerta debido a la  necesidad de tener que estar apagando fuegos permanentemente.

Pueden ser muy distintas las causas o los olores a “humo” que pueden provocar que una aplicación tenga un permanente estado de alerta, como veremos más adelante, pero es peligroso no darse cuenta de ello y no actuar para remediarlo.

La solución no es una cuestión inmediata y requerirá de tiempo y esfuerzo para mejorar esa sensación de estar continuamente en el alambre, con las llamas quemándonos la planta de los pies cada vez que se hace un deploy en producción.

Las personas que viven en este estado de excepción continuamente son conocidos como “los bomberos“. Esos individuos que por su conocimiento de los sistemas que mantienen o gestionan, tienen que lidiar con los fuegos que se originan en producción.

Además, aunque reniegan de la situación, sufren una adicción al fuego y esa adrenalina que se genera  en su cuerpo, junto con el reconocimiento que su labor anti-incendios provoca en sus superiores, les impide enfocarse en trabajar para que mejore la situación. Así, la adrenalina que provoca el peligro actúa como inhibidor de la mejora y salvo que alguien desde fuera aplique técnicas de prevención la situación no tendrá visos de cambiar.

Siguiendo con el símil de los incendios, hay entonces que considerar distintos perfiles en los equipos :

Los bomberos: expertos y técnicos que resuelven incidencias de manera continua y están siempre ocupados, al pie del cañón, haciendo lo que se llama “programación heróica”  asumiendo unos grandes riesgos, pero viéndose sin embargo recompensados por ello como los “salvadores” del sistema.

y

Brigadas preventivas: son más necesarios aún pues en periodo de menos peligro de incidencias se encargan de limpiar los montes para tratar de evitar que se produzcan nuevos fuegos.

¿Cuales son los olores a humo que deben hacernos reaccionar?

  • Código heredado y falta de conocimiento del sistema a mantener.
  • Altos niveles de deuda técnica provocada por tener que implantar funcionalidad sin tiempo suficiente por exigencias del guión.
  • Aplicaciones obsoletas.
  • Falta de test unitarios.
  • Pocas pruebas funcionales.
  • Poco tiempo para realizar pruebas de integración en entornos preproductivos.
  • Entrega de software nuevo durante las fases de regresión.

¿Como evitarlo?

¿Que tienen que hacer los equipos y como deben actuar las brigadas de prevención?

Hay algunas recetas que pueden aplicarse para prevenir estos fuegos :

  • Mantener un ritmo sostenible del equipo.
  • Aumentar el nivel de pruebas unitarias, y formar a las personas en las técnicas y frameworks de testing  que se adapten a su proyecto. Promover desde los líderes de equipo la necesidad de mejorar las pruebas unitarias.
  • Cada bug un test.
  • Aplicar prácticas de integración continua por parte del equipo y garantizar que todo el código nuevo compila e integra de manera correcta en los entornos de desarrollo.
  • Entregar lotes de trabajo pequeños con los que será más fácil encontrar problemas tempranos evitando grandes despliegues y apreturas de última hora.
  • Crear un radiador de información en el cual situar toda la deuda técnica identificada. Deuda técnica que provocará fuegos si no hacemos algo. Una vez identificada y hecha visible el equipo vota cual de las mejoras ha de acometer para mejorar el sistema y prevenir errores.
  • Establecer (si trabajas con releases y no con despliegue continuo) un criterio de “Release Train” , esto es : todo el sw que esté en la estación en el momento que llega el tren ( fecha de congelación de versión)  sube al tren y se dirige al deploy. En otro caso , salvo imponderables deberá esperar a que pase el siguiente convoy. Así se evita la entrega de sotware a última hora , con prisas y sin las suficientes pruebas.
  • Emplear una estrategia de pruebas de regresión de cuanta más funcionaldidad desplegada hasta ese momento, mejor, evitando efectos colaterales de nuevas subidas de versión deficientemente testadas.

Con todo y con eso, es muy difícil evitar los incendios y para apagarlos siempre harán falta los bomberos , pero debemos pensar como medida de calidad imprescindible en constituir en el seno del equipo una brigada preventiva que se encargue de la calidad mejorando de manera continua la calidad del software y evitando tener que llamar a los apagafuegos.

¿Eres Bombero?. Aunque no tengas más remedio que hacerlo, apúntate o fomenta la creación de la brigada preventiva.

 

  1. muy interesante y útil, gracias por el artículo desde http://www.riesgoslaboralesprevencion.com

  2. He leido Bomberos y Brigadas preventivas. | GestiondeProyectosIT con mucho interes y me ha parecido ameno ademas de bien redactado. No dejeis de cuidar este blog es buena.

    • Pepe Vázquez says:

      Muchas gracias por tus comentarios. Compartir experiencias y conocimientos con mayor o menor acierto es lo que trato de hacer con el Blog. Por supuesto que aprendo mucho también con los comentarios que hacéis en el blog ,por lo que espero verte por aquí 😉 más veces.

      Gracias de nuevo.

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*