Mierda entra, mierda sale

0

La situación más habitual hoy en día es la de tener un producto con una lista de funcionalidades solicitadas compitiendo con una lista de incidencias detectadas. La lista de incidencias suele ser grande, con grandes cantidades de tickets de mierda que nunca se resolverán. Pero bueno, esto no es nuevo. Ya os conté que todo es una mierda a nuestro alrededor. Esta situación genera un conflicto continuo entre los distintos interesados, muchos de ellos frustrados porque sus incidencias no se resuelven, otros frustrados porque no se cumplen las expectativas de nuevos desarrollos, y los programadores frustrados porque entre tanta incidencia, no son capaces de entregar lo que se comprometen en cada sprint.

El enfoque que veo dar muchas veces, y que considero un error, es el de equiparar incidencias con nuevas funcionalidades, compitiendo por la prioridad. Creo que este enfoque es el que genera esta situación de mierda en la que viven muchos equipos de desarrollo.

Mi visión es que el equipo debe ser responsable de su producto. Es su mierda, tanto si la ha cagado ese equipo, como si se ha tenido que comer la mierda de otro. Si el equipo se siente responsable y dueño de ese producto, le sentará mal que haya incidencias. Es su culpa si hay incidencias. Si tuviese un producto perfecto no habría esas incidencias. Y no me vale la excusa “es que eso lo programó otro” cuando el equipo lleva meses gestionando ese producto. Ha tenido tiempo de arreglarlo. Es su mierda y le toca limpiarla.

Cuando he tenido algún equipo que sí ha creído esa máxima, se ha aplicado una política de cero errores de forma natural. Básicamente lo que hace ese equipo es que en el momento que le indican una incidencia, deja lo que tiene entre manos y la resuelve. Casi siempre el mismo día. Y vuelve a cero bugs. O lo que es lo mismo, Mierda entra, mierda sale.

Y creedme, he estado en varias ocasiones en ese estado con algún equipo. Y en los proyectos en los que he estado yo sólo programando, siempre he estado en esa situación. Cero errores, siempre. Creedme, es posible.

Si estamos en situación de cero errores, cada vez que llega una incidencia se debería hacer lo siguiente:

  • Según entra la incidencia se investiga qué pasa. Muchas veces podemos verlo en minutos.
  • Cuando vemos que sucede, puede ser que se arregle con una simple operación (borro un registro de BBDD), reinicio la aplicación, … -> Incidencia resuelta. Si se repite, entonces tendremos un problema, que ya competirá con las funcionalidades.
  • Otras veces vemos un error de código. Hay que plantearse ¿Merece la pena resolverlo?
    • Si merece la pena, dejamos lo que estamos haciendo y lo resolvemos. Hot fix al canto.
    • Si no merece la pena, mejor informar al usuario de que el mundo es así. No creamos un ticket de mierda.

Una de las claves para que esto funcione es que el equipo debe considerar que resolver una incidencia no es añadir trabajo a su lista de tareas pendientes. Es arreglar lo que tendría que estar arreglado de antes. Así que no es excusa para no cumplir. A veces no se cumple y punto, pero la excusa de “es que ha habido muchas incidencias” no debería ser válida. No te quejes de que has tenido que estar toda la tarde limpiando en el salon si el día anterior te cagaste en el sofá en vez de ir al WC.

A ver si me explico, e intentando aterrizarlo un poco, imaginemos un equipo que trabaja por sprints. Este equipo intenta reservar un 20% de su tiempo, “para lo que pueda venir”. El producto que llevan, se cae en producción varias veces y llegan un par de incidencias. Lo que suele ser una mierda de semana. Así que el equipo se dedica a resolver lo que tiene en producción, investiga por qué ha pasado para que no se repita, y resuelve las incidencias, pero no consigue hacer más que la mitad de lo que se había comprometido. En esta situación, el equipo puede decir que no ha podido llegar porque ha sido una semana complicada. De la misma forma que puede decirlo si un miembro del equipo se pone mano o si detrás de una historia de usuario tiene mucha más mierda que la que se esperaba; se puede justificar un sprint. Pero el equipo lo tiene que ver como que “no hemos llegado” e intentar poner medidas. Lo que no puede ser es que si llegan incidencias tengo la carta de “salir de la carcel” y no cumplo este sprint. Las incidencias llegan porque nuestro producto tiene algo mal. Un sprint se puede torcer. 10 seguidos: algo estamos haciendo mal.

Sé que muchos no estaréis de acuerdo conmigo, pero creo que la filosofía de mierda entra, mierda sale, es una prueba de compromiso del equipo por limpiar su mierda.

En honor a la verdad tengo que decir que la expresión “mierda entra, mierda sale” tiene otro significado en este mundillo, que no es el que yo os he dicho. Shit In, Shit Out; Gargabe In, Garbage Out; o simplemente Mierda Entra; Mierda Sale quiere decir que si a un sistema le entra mierda, le saldrá mierda. Si en un experimento metes datos de mierda, tendrás resultados de mierda. Si unas pruebas tienen casos de mierda, tendrás una cobertura de mierda. Si en un equipo pones programadores de mierda, tendrás programas de mierda.

Pero yo suelo usar esta expresión como la filosofía de quitarse la mierda según entra. Quizás es ese perfil ITIL que tengo, en el que una incidencia es una patata caliente que hay que quitarse corriendo.

Conclusiones

Vivir sin mierda es algo agradable. ¿Por qué acumular la mierda? Entra una incidencia y nos planteamos si hay que resolverla. Si no merece la pena, la borramos. Si merece la pena, la resolvemos al momento.

Mierda entra, mierda sale, y nada de mierda en mi mesa.

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios