Está listo, solo falta testarlo

 
Está listo, solo falta testarlo

Ken Schwaber y Jeff Sutherland definieron un artefacto muy importante en el Scrum: la Definition of Done (DoD), en español la Definición de Hecho. El objetivo de la DoD es describir de forma muy clara para el equipo Scrum cuáles son las condiciones necesarias para que un ítem del backlog (normalmente escrito en formato de historia de usuario) se considere hecho.

Cuando el ítem está listo, en principio, no hay más tareas que hacer. En empresas que utilizan buenas prácticas de Devops como la entrega continua, la única actividad por hacer debería de ser que el Product Owner (PO) presione un botón y mande todo el incremento de producto a las manos de los clientes.

Nosotros versus ellos

Desgraciadamente, a lo largo de los años, creamos especialistas y ponemos a esos especialistas en distintas unidades dentro de la organización. Acabamos con silos difíciles de resolver: Desarrollo, Tests, Banco de Datos, Producción, Middlewares, Arquitectura, etc.

Jerarquía organizativa reforzando los silos de especialistas.

El resultado común en diferentes empresas son discursos como «Está hecho, solo falta que lo compruebe el equipo de revisión»; «Está listo, solo falta que los de intervención permitan la llamada»; «Está listo, solo falta que los del banco de datos apliquen un script». Mi favorito: «Está listo, solo falta integrarlo».


Integración Tardía

Un equipo ágil es multidisciplinar. Esto significa que deben componerlo personas que tengan todas las habilidades y autorizaciones necesarias para que una necesidad de negocio se transforme en producto y la entregue en mano al usuario.

¡Compruebe los próximos entrenamientos de la K21!

¿Cuál es el problema del «solo falta…»?

Vamos a decir que el Equipo Azul, muy implicado, trabajó con ahínco durante la Sprint y consiguieron «entregar» 5 ítems que testará el Equipo de Calidad. Por algún motivo, imaginamos que los de Calidad cogerá nuestro encargo, lo pondrá en su backlog, que está vacío, y en algunas horas recibiremos el resultado de los tests.

Está listo solo falta testarlo Situación Imaginaria
Situación Imaginaria

Situación genial, pero falsa. Normalmente, cuando se da este paso del bastón de entrega, encontramos otros equipos atascados con tareas por hacer. Además de eso, tenemos un problema de priorización. Lo que es muy importante para el Equipo Azul, puede ser la cosa menos prioritaria para el Equipo de Calidad, que está recibiendo «entregas» de otros equipos distintos.

Está listo solo falta testarlo Situación real
Situación real

Sepa que este problema se repite para cada equipo que utiliza para completar la frase «Está listo, solo falta…». El atraso inducido por las dependencias es exponencial.

Sprint de Pruebas

No, no, no y no. No existe Sprint de Pruebas separada del desarrollo. La Sprint debe englobar todas las tareas necesarias para que su producto esté listo para facilitárselo al cliente. Separar la Sprint en partes creará reflujo de trabajo, falta de visibilidad, poca previsibilidad de la entrega y además reforzará la idea de subequipos dentro del equipo (nosotros versos ellos interno). Pregúntese: ¿Por qué estamos haciendo Sprints separadas? Llega a la causa original del problema y resuélvela.

Reflujo en el trabajo, causando problemas.
Reflujo en el trabajo, causando problemas.

¿Y cómo salgo yo de este embrollo?

Visibiliza y no escondas los problemas

En el caso de que tu entrega de valor al cliente dependa de personas externas al equipo, no escondas esa dependencia. Visibiliza este aspecto y da transparencia al proceso. Diseña todas las transiciones necesarias en la cadena de valor de tu producto. Barrer el problema para debajo de la alfombra traerá efectos terribles a largo plazo.

Transparencia en la Tabla de Tareas. Las dependencias externas se visualizan y se marcan en rojoTransparencia en la Tabla de Tareas. Las dependencias externas se visualizan y se marcan en rojo.

Me gusta utilizar la siguiente analogía. Imagina que te has roto el brazo. La solución para ese problema es trabajosa. Buscar un médico, hacer una radiografía, inmovilizar el brazo durante semanas, incluso operar. Estás tremendamente ocupado y no tienes tiempo para esto, así que decides tomar solo un medicamento para el dolor. Con el tiempo el dolor aumenta y tú estás ya tomando morfina, pero te niegas todavía a ver la situación real del problema y sigue tomando acciones puntuales y temporales. Cuando todo se vuelva insoportable podrá ser demasiado tarde.

Definition of Transition (DoT)

Al poner un cuadro en la pared, define cuáles son las condiciones necesarias para que un ítem del backlog avance en las etapas del proceso. Para cada taya de su cuadro, puedes hacer una pequeña definición de transición. Utilizando como ejemplo la imagen anterior, podríamos tener las siguientes DoT:

• Desarrollo.
– El código-fuente del programa está versionado
– Los tests automáticos garantizan la cobertura necesaria
– El Código fue revisado por par
– El producto está aprobado en el 100% de los tests automatizados

• Equipo de Calidad
– Equipo de Calidad
– No hemos encontrado ningún bug impeditivo, crítico o relevante.

• Equipo de Seguridad
– Aprobado en los tests de vulnerabilidad
– No hemos encontrado ningún bug impeditivo, crítico o relevante.
– Logs de auditoría añadidos
• …

Fíjese en que la suma de sus DoT ayudó a componer su DoD.

Métricas para tomar como base en los debates

Jamás entres en una reunión con el discurso: «Yo creo que…». Esto solo te va a desgastar políticamente sin necesidad. Utiliza métricas como Customer Lead Time, System Lead Time, Waiting Time, Cost of Delay para cimentar este tipo de debate.

Mejora continua

En reuniones como las ceremonias de Retrospectiva, saca los retos que hacen que los equipos sean incapaces de hacer la entrega de punta a punta. En algunos casos, puede ser necesario que tengas que subir los niveles de la jerarquía organizativa para resolver el problema. Haz esto siempre basándote en números y demostrando las consecuencias de los retos propuestos.

Equipos multidisciplinar

Por qué no tenemos todas las competencias necesarias para hacer una entrega de punta a punta Las respuestas a dicha pregunta deben ayudar a crear estrategias concretas que transforme los equipos en equipos multidisciplinario.

Algunas otras preguntas que pueden ayudar al equipo a diseñar las acciones: ¿Cuáles son las competencias que no tenemos y que necesitamos? ¿Tenemos personas interesadas en desarrollar esas competencias? ¿Qué silos deben romperse para tener un equipo al 100%? ¿Cuál es la competencia que no tenemos y que más impacta en nuestra entrega? Y así un día tras otro.

Autorización

«Modificar una tabla en el banco de datos. Bien. Para eso necesitas: rellenar el formulario A-35. B-57 y D-3, tener la firma de 3 administradores de Nivel 1, abrir una solicitud de cambio, certificar una firma en la notaría, dar 7 vueltas a la Plaza de la Catedral andando para atrás, tener la bendición del Papa…»

En muchas empresas lo que retrasa la entrega no es la falta de competencias en el equipo, sino la falta de autorización para hacer el trabajo necesario. Las respuestas que deben guiar las estrategias concretas deben venir de preguntas como: ¿Por qué no tenemos autorización para hacer tal cosa (sé específico)? ¿Qué traumas tuvieron lugar en el pasado y llevaron a esa falta de autorización?

Trabajo por parejas

«Ah! Pero no todo el mundo sabe hacer el trabajo que hace el Equipo de Pruebas / Seguridad / xpto».

Trabaja en parejas para que el conocimiento sobre prácticas, tecnologías y el contenido se difunda entre los miembros del equipo o sea traído al equipo. El trabajo por parejas es una forma excelente para la constante transformación del conocimiento del equipo y una práctica para estimular la colaboración.

Práctica de Devops

Muchas empresas aún poseen unidades enteras para ejecutar procesos manuales y burocráticos que, si no son automatizables al 100%, pueden ver su burocracia reducida significativamente por automatización. Busque la forma de utilizar prácticas como tests automatizados, integración continua, entrega continua, versionamiento, TI escalable, etc.

Definición Real de Hecho

No estoy creando un artefacto nuevo. Solo proponiendo que la Definición de Hecho del equipo debería incluir todo el trabajo necesario para que la única cosa que quede entre la entrega del equipo de desarrollo y el paso del producto a la mano del cliente sea una decisión de negocio y nada más.

Si su producto debe ser aprobado por el dueño de la empresa antes de ponerlo a disposición del cliente, entonces esa aprobación debe incluirse en la Definición de Hecho. Si se exige un manual del usuario, entonces la escritura y puesta a disposición del manual deben estar en la Definición de Hecho. Si la entrega debe aprobarse en tests de seguridad, entonces el Aprobado en los tests de seguridad debe componer su Definición de Hecho.

Haga que la Definición de Hecho de su equipo cumpla su propósito y describa exactamente las condiciones necesarias para que el cliente reciba el producto que necesita.

«
»

Deja un comentario

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