Una de las claves de Scrum es la entrega. Cuando entregamos, podemos validar que estamos aportando valor, que vamos por el camino correcto. Es más, en el caso de que nuestras hipótesis sean incorrectas, podemos adaptarnos rápidamente para tomar otras decisiones y abrir la posibilidad al acierto. Pero todo esto solo ocurre al entregar, sin entrega, nuestra capacidad de aprender del mercado se nos cae. ¿Cómo garantizar una buena entrega? ¡Lo analizamos!
¿Cómo conseguimos entregar?
Para entregar con garantías, necesitamos poner sobre la mesa varios conceptos clave. En primer lugar, debemos entregar incremento terminado, es decir, evitar el entregar partes con errores o incorrectas de manera consciente. La filosofía tradicional de “en la fase dos lo arreglamos” o “le cobramos el mantenimiento al cliente” debe estar fuera. Un producto debe aportar valor en cada entrega y ese valor debe estar limpio de errores.
En segundo lugar, es esencial entregar valor usable, que alguien lo pueda validar y darnos feedback. De esta manera, tratamos de evitar el planteamiento clásico de construir una arquitectura o un análisis funcional durante meses sin que el usuario final reciba valor.
Además, necesitaremos una buena división del producto en “trozos” que aporten valor. Esto es lo que conocemos como Vertical Slicing y es clave para evitar hacer desarrollos tan largos que, tras meses de trabajo, acabamos entregando mucha cantidad de producto sin haberlo validado.
Por último, además de que nuestro incremento cumpla con aquello que nos han pedido o que hemos decidido hacer, debe superar toda clase de pruebas que hayamos definido. No tiene sentido construir un producto Sprint a Sprint para descubrir que no soporta más de 100 usuarios porque hemos diseñado mal la base de datos. Es decir, pruebas de rendimiento, escalabilidad… deben estar superadas.
Criterios de aceptación, ¿qué vamos a hacer?
La ambigüedad es uno de los grandes males en los equipos que desarrollan producto en entornos complejos, sobre todo en el desarrollo de software. Hace años, en un cliente, nos pidieron un “login” para la aplicación, lo estimamos y lo introdujimos en la oferta comercial. La sorpresa vino cuando fuimos a desarrollarlo y el cliente dijo “¿pero no hay recordar contraseña?, ustedes son expertos y deberían saber que un login debe tenerla”. ¡Empezaron los problemas!
La ambigüedad existe y, por desgracia, debemos aprender a convivir con ella. Principalmente es fruto de la complejidad y, como bien sabemos, Scrum propone inspeccionar y adaptar en periodos cortos de tiempo. Al inspeccionar cada poco tiempo, podemos evaluar si estamos entendiendo bien la información recibida y si estamos siendo capaces de entregar valor.
Los Criterios de Aceptación luchan contra este problema. Los CdA sirven para definir cuándo un determinado elemento del Product Backlog (Product Backlog Item o PBI) está finalizado y se considera “aceptado”. Es clave que sean concretos y que expliquen muy bien todos los casos que conozcamos tanto positivos como negativos. Por ejemplo, si tenemos un determinado PBI que habla sobre el pago con tarjeta no solo debemos describir el proceso del pago sino también qué ocurre si no ha saldo en la tarjeta o un tipo de tarjeta que no es válido.
Los Criterios de Aceptación se pueden utilizar a nivel Historias de Usuario, a nivel Item, a nivel de Release o de Épica. Cuando mayor sea el nivel de lo que estamos describiendo, menos detalle tendrá. Por ejemplo, si una épica es “registro de usuarios”, podemos definir varios criterios que expliquen, a nivel general, cómo finalizamos dicha épica. Sin embargo, las Historias de Usuario o PBIs que tengamos definidas estarán mucho más detalladas y serán más concisas.
¿Cómo definir buenos Criterios de Aceptación?
Los CdA deben surgir de una conversación entre nuestro customer y los developers. Muchos agilistas defienden que sea el propio usuario final el que participe en estas conversaciones. Aunque esto es difícil, nuestra propuesta es que cuanto más cerca estén los Developers de los usuarios, el valor será mayor.
Es importante que definamos todas las situaciones que se puedan presentar tanto positivas como negativas. Utilizar el formato Gherkin es útil si hablamos de Historias de Usuario (que son funcionales principalmente) pero suele ser menos útil en Items con un gran componente técnico.
Respecto a cuántos CdA son necesarios hay muchas opiniones. Hay quien propone que como mínimo haya cinco criterios para garantizar que has reflexionado sobre todas las situaciones que se podrían presentar. Hay autores que defienden que no debemos superar diez CdA por Item para evitar que sea excesivamente grande y que dividamos. Nuestra opinión es que depende mucho del contexto de trabajo.
Definition of Done
La Definition of Done es un elemento clave de Scrum debido a que está íntimamente relacionado con la entrega y, como hemos dicho, Scrum necesita de la entrega para funcionar.
La Definition of Done se utiliza para explicar cuándo consideramos que existe incremento porque hemos determinado un trabajo. A diferencia de Los Criterios de Aceptación, que se centran en la parte funcional del item, la DoD se centra en todos los criterios tanto funcionales como no funcionales. Por ejemplo, un criterio puede ser que un compañero valide nuestro código o que, después de cada subida a producción, hay que enviar un email a cierta persona.
La DoD tiene un impacto directo en cómo trabajamos, por tanto, se revisa en la Sprint Retrospective. Debe indicar también todas aquellas pruebas transversales a la aplicación, como pueden ser el rendimiento o la seguridad. Por tanto, es clave poder automatizar estas pruebas de cara a ir más rápido.
¿Cómo hacer un buen DoD?
La primera cuestión que hay que saber en una Definition of Done es si existe normativa interna, en nuestra organización, respecto a la calidad de los productos. Es clave para los equipos cumplir las reglas de la empresa. Además, hacerlo transparente nos ayudará a que todo el Scrum Team sea consciente. Después, cada equipo puede trabajar con una Definition of Done más restrictiva que las normas organizativas en caso de serle útil.
Para constituir la Definition of Done debemos de contar con todo el Scrum Team, ya que estamos definiendo el límite entre lo que está terminado (se puede entregar) y lo que aún no está finalizado (no se puede entregar). Si decimos que cada funcionalidad tiene que cumplir un nivel de calidad, no entregamos nada que no lo cumpla. A su vez, esto es mejor, porque nos permite gestionar expectativas con stakeholders. Además de que es más fácil medir el trabajo terminado, que aquel que se queda a medias.
La mayoría de DoDs tienen como primer criterio el que se cumplan los criterios de aceptación del item. Por otro lado, debemos pensar en qué tipos de test queremos cumplir y cómo vamos a trabajar: revisiones de código entre compañeros o de estructura.
Diferencia entre la Definition of Done y los Criterios de Aceptación
La DoD es un elemento mucho más amplio que los Criterios de Aceptación y, generalmente, está pensada a nivel de producto o de release. Pueden existir DoDs por tipo de tarea aunque es más inusual. Por ejemplo: “en el módulo de pagos tenemos que cumplir una revisión de código por parte de tres compañeros y en el resto no es necesario…”
Los Criterios de Aceptación están muy relacionados con el cierre de un determinado item concreto y suelen ser mucho más detallados. Evidentemente, la DoD suele incluir los criterios de aceptación que estén cumplidos para validarlos.
Definition of Ready
No quisiera cerrar este artículo sin comentar la Definition of Ready. La DoR es un elemento ajeno a Scrum pero que algunos equipos utilizan. Consiste en una definición para determinar cuándo un ítem está listo para ser abordado en el Sprint.
La DoR puede contener el que un determinado ítem tenga todos los criterios de aceptación escritos y validados. La DoR suele ser un elemento clave para la persona que ejerce de Product Owner o Product Manager para entender qué trabajos tiene que realizar de cara al Sprint siguiente. Dado que el resultado de la DoR son items pendientes de hacer, Scrum no cuenta con esta práctica ya que Scrum deja mucha libertad en cómo tomamos los requisitos y gestionamos esa información.
Y tú, tienes bien definidos la ¿Definiton of Done y los Criterios de Aceptación?
