Si sois aficionado a los hermanos Scott esto os sonará. La reforma empieza y surgen problemas. Cosas imprevistas hacen que la obra se retrase. También hay cosas que se dejan de hacer y cosas que inicialmente no estaban pensadas se hacen. Al final de todo este proceso el resultado es maravilloso y los dueños reciben la casa de sus sueños.
Pero qué pasaría si un capítulo fuera distinto. Imaginemos que los propietarios entran en casa y los hermanos Scott comentan que la escalera no cumple la normativa. Además el parquet está sin encolar, solo lo habían colocado para el rodaje del capítulo. Por último los propietarios abren un grifo y una bombilla estalla. En este momento los hermanos solicitan a los propietarios un tiempo para solucionar lo que falta. ¿Qué pensais que dirían los propietarios? ¿Estarían dispuestos a seguir esperando? ¿Seguirán confiando en los hermanos Scott?.
Esta situación que parece surrealista es más común de lo que parece en el mundo del software y tiene un nombre: Hardening. En este post vamos a hablar de los problemas que acarrea esta práctica así como de como evitarlo.
Tabla de contenido
¿Qué tiene de malo el hardening?
El hardening es un periodo de tiempo necesario para endurecer el software. Es decir, corregir bugs críticos, añadir seguridad, mejorar rendimiento, etc. En definitiva un tiempo durante el que preparamos nuestro producto para ser realmente usado.
Esta situación puede producirse de dos formas. Una es debida a una inminente puesta en producción. La otra, menos crítica pero igualmente indeseable, se realiza en cualquier momento del desarrollo, paralizando de esta forma la entrega de valor.
En ambos casos se producirá una pérdida de confianza, tan necesaria en cualquier marco Agile. Si pensamos en Scrum, Review tras Review tenemos que entregar software potencialmente producionable. La necesidad de hardening pone en duda dicha cualidad. Es natural que en las siguientes reviews tengamos dudas sobre si lo que estamos viendo es real.
Otro de sus grandes males es que rompe la predictibilidad del equipo, lo cual vuelve a incidir en pérdida de confianza. El hardening se produce cuando la cantidad de errores o la necesidad de refactorizar se hace insoportable. Una vez llegados a ese punto el esfuerzo necesario para reconducir la situación tiene demasiada incertidumbre. Es decir, sabemos cuando iniciamos el hardening pero es difícil saber cuándo lo vamos a terminar.
Por último, estos periodos son muy desmotivantes. El equipo tiene que volver a realizar trabajo que suponía finalizado, repensar soluciones y buscar problemas en un código que no es fácil de seguir. Esto aumenta la posibilidad de conflictos dentro del equipo y pone a prueba la cohesión del mismo. En muchas ocasiones es más fácil buscar un culpable que buscar una solución al caos que existe.
En este escenario de falta de confianza el Agilismo está en riesgo, Por otro lado, el conocimiento adquirido hasta la fecha no nos vale. La experiencia acumulada no nos vale ante esta nueva situación. En estos momentos se suele pensar que kanban es la solución. En mi opinión pasar a un sistema kanban no soluciona los problemas de raíz, es un parche que termina dejando de lado todo el mindset Agile.
¿Cómo hemos llegado a esta situación?
Iniciar un periodo de hardening no es deseable pero en muchas ocasiones no hay más solución. Para evitar que llegue ese momento tenemos que tener indicadores leading que nos alerten del peligro de caer en un hardening.
Uno de los principales indicadores es el nivel de testing y cobertura. Como cualquier indicador debemos ver la cobertura como una tendencia y no como un número absoluto. Un 100% de cobertura no nos indica nada de forma aislada pero sí su evolución. También podemos prestar atención a la evolución que del número de veces que se rompen los test.
Obviamente el ratio de número de bugs encontrados entre resuelto es también un buen indicador. Si este ratio aumenta con el tiempo es probable que el hardening esté cerca.
Otro indicador puede ser el número de tareas que somos capaces de realizar en un periodo de tiempo. Si este número decrece puede deberse a que la arquitectura se está resintiendo y necesitamos realizar un refactor.
Una vez que detectamos lo que está pasando tendremos que ir a la causa raíz del problema ¿El equipo tiene suficiente tiempo para realizar su trabajo con calidad? ¿Tenemos las habilidades necesarias? De no ser así ¿Vamos a formar al equipo, incluir más personas?. Obviamente cada caso es distinto y esto son solo algunos ejemplos.
Siendo consciente del peligro del hardening y tomando las acciones adecuadas para evitarlo es más probable que nuestros usuarios terminen igual de satisfechos que propietarios de las casas reformadas por los hermanos Scott
Entradas relacionadas
Product Mastery, de buen a gran Product Owner0 (0)
Comentarios recientes