Guía para identificar mejores criterios de aceptación en historias de usuario

Hola a todos,

Escribir criterios de aceptación, a pesar de ser un proceso de llegar a un acuerdo sobre lo que se quiere recibir, no deja de ser un reto. En este proceso surgen al menos tres preguntas:

• ¿Hasta cuándo es suficiente detalle?
• ¿Estoy dejando la descripción muy general?
• ¿Qué más debo incluir?

Ante esto, generalmente, a los Product Owners les digo:

• No te preocupes, que si falta detalle, los developers te lo recordarán.
• Si olvidaste algo, es porque aún no es importante.

Aún así, el pedido que constantemente recibo es:

"¿Podrías escribir una guía para hacer criterios de aceptación?"

Considerando que lo anterior lo he respondido de forma particular, voy a cambiar mi aproximación y hacerlo por medio de este artículo que, con seguridad, iré engrosando en la medida que la retroalimentación y la experiencia vayan llegando.

¿Qué son los criterios de aceptación?

Los criterios de aceptación son las condiciones que una historia de usuario debe cumplir para considerarse completada cuando es desarrollada y desplegada por el equipo. Funcionan como una guía para los desarrolladores y testers, asegurando que lo que se construye es realmente lo que el negocio necesita.

Es de considerar que el formato original de las historias de usuario no incluía los criterios de aceptación (1), y aunque no hay un acuerdo sobre quien los incluyó, Ron Jeffries hace referencia tácita a ellos en su artículo sobre las tres C (Card - Conversation- Confirmation) (2):

"Al comienzo de la iteración, el cliente comunica a los programadores lo que desea y les dice cómo confirmará que han hecho lo que se necesita. Define las pruebas de aceptación que se utilizarán para demostrar que la historia se ha implementado correctamente".(2)

No se habla de un formato específico, incluso se sugiere el uso de ejemplos para que estos sean más claros, algo que al final incluyó Behavior Driven Development (BDD) (3).

No confundir con la Definition of Done (DoD). Mientras que los criterios de aceptación son específicos para una historia de usuario, la Definición de Terminado es un estándar general del equipo para determinar cuándo una historia está terminada desde un punto de vista técnico y de calidad.

¿Por qué son clave en un desarrollo ágil? (4)

Los criterios de aceptación cumplen un papel fundamental en la comunicación entre los equipos de desarrollo y los stakeholders. Algunas razones por las que son esenciales incluyen:

• Evitan malentendidos: Reducen la ambigüedad y ayudan a alinear expectativas.
• Mejoran la calidad del producto: Definen el mínimo aceptable para el negocio.
• Facilitan la prueba y validación: Los testers pueden usarlos para diseñar pruebas.
• Permiten la automatización: Son la base para la creación de pruebas automatizadas.
• Pueden contener ejemplos que van a guiar a los desarrolladores: Basados en los ejemplos proporcionados, los desarrolladores encontrarán como cumplir con lo que se espera de la fucionalidad.

Cómo aceptar la funcionalidad con el usuario durante la escritura de historias de usuario

Para asegurarte de que la funcionalidad que estás definiendo en la historia de usuario es realmente lo que el usuario necesita, puedes involucrarlo en el proceso desde el inicio. Aquí hay una estrategia para lograrlo:

1. Validar la historia de usuario antes de escribir los criterios de aceptación

   • Explicar la historia de usuario en términos simples y preguntar:
   • “¿Esta historia realmente cubre tu necesidad?”
   • Preguntar si falta algo en la descripción de la historia.
   • Asegurar que la historia esté escrita en el lenguaje del usuario, no en lenguaje técnico. No incluyas llamado a bases de datos, nombres de tablas, etc.

2. Involucrar al usuario en la definición de criterios de aceptación

   • Preguntar cómo espera que funcione la funcionalidad en su día a día.
   • Plantear escenarios de uso y validar que cubran sus expectativas.
   • Escribir los criterios de aceptación junto con el usuario o validarlos con él antes de finalizar la historia.

3. Revisar los criterios de aceptación con ejemplos

   • Presentar ejemplos de cómo funcionará la funcionalidad basados en los criterios de aceptación y preguntar:
   • Si esto se comporta así, ¿te parecería correcto?
   • ¿Cuáles son los campos que van a viajar en el formulario? ¿Cuáles serán las validaciones asociadas a cada campo?
   • ¿Cuáles son los campos que tendrá el reporte? ¿Tendrá filtros?
   • ¿Cuáles son los mensajes de éxito y de fracaso, según el resultado?
   • ¿La imagen o gráfico será interactivo? ¿Qué comportamientos tendrá?
   • ¿Se enviarán notificaciones? ¿De qué forma? ¿A quiénes?
   • Si usa formato Given-When-Then (más adelante cubriré este aspecto), leer los escenarios y validar con el usuario.

4. Usar prototipos o bocetos si es necesario

   • Si la funcionalidad es visual, mostrar wireframes o pantallas para confirmar que la historia refleja lo que el usuario espera.

5. Obtener aprobación antes de llevarla a desarrollo

• Preguntar directamente: “Si construimos esto con base en estos criterios de aceptación, ¿estarías satisfecho?”
• Si hay dudas o cambios, refinarlos antes de que el equipo empiece a desarrollarla.
6. Preguntas adicionales para descubrir criterios de aceptación

Si quieres mejorar la identificación de criterios de aceptación, aquí tienes más preguntas que puedes hacer al usuario o al equipo:

• Sobre el objetivo de la historia
• ¿Cuál es el problema exacto que queremos resolver con esta historia?
• ¿Cómo sabremos si la funcionalidad realmente cumple su propósito?
• ¿Hay métricas o indicadores que podrían ayudarnos a medir el éxito?
• Sobre los escenarios clave
• ¿En qué situaciones usarías esta funcionalidad?
• ¿Cuál es el flujo ideal desde tu perspectiva?
• ¿Existen variantes o excepciones que debamos considerar?
• Sobre las reglas de negocio
• ¿Existen restricciones específicas para esta funcionalidad?
• ¿Qué pasa si el usuario introduce datos incorrectos?
• ¿Hay algún comportamiento especial que deba seguir la funcionalidad en ciertos casos?
• Sobre la experiencia de usuario
• ¿Qué tan rápido esperas que responda el sistema?
• ¿Cómo te gustaría recibir la confirmación de que la acción se completó?
• ¿Prefieres una notificación visual, un correo, o algún otro mecanismo?
• Sobre seguridad y accesos
• ¿Todos los usuarios deberían poder acceder a esta funcionalidad?
• ¿Necesitamos permisos o restricciones especiales?
•  Sobre el manejo de errores y excepciones
• ¿Qué pasa si el sistema no puede completar la acción?
• ¿Cómo debería informarse al usuario en caso de error?
• Sobre la integración con otros sistemas
• ¿Esta funcionalidad afecta o depende de otros módulos o sistemas?
• ¿Qué datos necesitamos capturar o enviar a otras áreas del sistema?

Elementos esenciales de un buen criterio de aceptación

Para que los criterios de aceptación sean efectivos, deben cumplir con estas características:

• Claridad y precisión: No deben dejar espacio a interpretaciones.
• Independencia de implementación: No describen cómo hacerlo, sino qué resultado se espera.
• Testabilidad: Deben ser verificables con pruebas manuales o automatizadas.
• Alineación con las necesidades del usuario: Siempre deben responder a lo que el usuario final necesita.

Nota importante: Quisiera compartirles algo sobre lo que soy reiterativo cuando explico este concepto: aunque tu historia de usuario, con sus criterios de aceptación, quede bien definida, lo más importante es la conversación alrededor de la historia, el entendimiento común con el equipo.

Formatos comunes para escribir criterios de aceptación

Formato tradicional

Es el más simple: una lista de condiciones que deben cumplirse.

Ejemplo:

Historia de usuario:
Yo como usuario quiero poder restablecer mi contraseña para acceder a mi cuenta en caso de olvido.

Criterios de aceptación:

• El usuario debe recibir un correo con un enlace de restablecimiento.
• El enlace debe expirar en 30 minutos.
• La nueva contraseña debe cumplir con requisitos de seguridad.

Formato Given-When-Then (Gherkin)

Este formato, popular en BDD (Behavior Driven Development), ayuda a describir escenarios de manera estructurada:

• Given: Estado inicial.
• When: Acción del usuario.
• Then: Resultado esperado.

Ejemplo:

Given que el usuario olvidó su contraseña,
When ingresa su correo en la opción “Olvidé mi contraseña” y presiona enviar,
Then debe recibir un correo con un enlace de restablecimiento.

Este enfoque facilita la automatización de pruebas con herramientas como Cucumber.

Errores comunes al redactar criterios de aceptación

• Ambigüedad: Si no es claro, cada persona lo interpretará de manera diferente. Aunque invitan a la conversación en fases tempranas, próximos al desarrollo pueden convertirse en una fuente de incertidumbre, ejemplo: si la transacción no es exitosa se deberá confirmar al usuario. Surgen varias preguntas con lo anterior ¿Cómo? ¿Qué mensaje? ¿A través de que medios? ¿Proporcionaremos al usuario alguna forma de hacer reclamos?
• Demasiado técnico: No deberían describir cómo implementarlo, sino qué resultado se espera.
• No validarlos con el equipo: Deben ser revisados en sesiones de refinamiento del backlog.

Mejores prácticas para escribir criterios de aceptación efectivos

• Involucrar a todas las partes interesadas: No es solo tarea del Product Owner, los desarrolladores y testers también deben participar.
• Refinarlos en sesiones de backlog refinamiento con el equipo: Asegurar que sean claros antes de iniciar el desarrollo.
• Hacerlos testables: Si no se pueden probar, probablemente no están bien escritos.
• Utilizar el lenguaje del usuario final: Evitar tecnicismos innecesarios.

Cómo automatizar pruebas basadas en criterios de aceptación

Los criterios de aceptación bien definidos pueden traducirse directamente en pruebas automatizadas. Algunas herramientas que permiten hacer esto incluyen:

• Cucumber (BDD, Given-When-Then).
• Selenium (Pruebas UI basadas en escenarios).
• JUnit / TestNG (Pruebas unitarias automatizadas).

Esto permite que el equipo valide rápidamente si una historia cumple con los requerimientos sin depender exclusivamente de pruebas manuales.

Checklist final para validar criterios de aceptación

• Historia de usuario validada con el usuario o stakeholder.
• Criterios de aceptación basados en necesidades reales. Evita el desperdicio, es decir, poner criterios que no serán usados.
• Ejemplos o escenarios de uso confirmados.
• Información que se capturará o que retornará la funcionalidad, y el nombre de sus campos.
• Reglas de negocio y restricciones documentadas.
• Casos de error y manejo de excepciones definidos.
• Aprobación del usuario antes de pasar a desarrollo.

Nota importante: Un buen criterio de aceptación se puede convertir en un caso de prueba, directamente. Si el tester puede escribir una prueba automatizada o manual a partir de él, es una señal de que está bien definido.

Y si quedas con muchos criterios de aceptación

Si al final de todo este ejercicio, tu historia de usuario queda con entre seis y ocho criterios de aceptación (es mi actual heurística, puede que cambie con la IA), está perfecta de tamaño, pero si supera con creces este rango, pues. ¡Divide la historia y listo! Puedes tener más historias de usuario que ayuden con tu propósito de generar valor, la verdad, no hay lío con eso. 

El mejor criterio de división es: que la historia requiera del trabajo suficiente para ser completado en alrededor de 36 horas, por desarrolladores y testers.

Cerrando

Escribir buenos criterios de aceptación es clave en el desarrollo ágil. Mejoran la comunicación, reducen malentendidos y permiten entregar software de mejor calidad.

Si en tu equipo todavía no los documentan formalmente, este es un buen momento para comenzar. 

Notas. Aclaraciones Comentarios

1. De Colección: Ejemplos de Historias de Usuario de la Fuente: Los Libros de Extreme Programming (XP) - Clic aquí.
2. XP esencial: Tarjeta, Conversación, Confirmación - Clic aquí.
3. What's in a Story? - Clic aquí.
4. En este momento de la historia existe un boom sobre la Inteligencia Artificial y lo que puede proporcionarnos el uso de agentes; es posible que en el futuro cercano muchas o todas las tareas de desarollo y testing sean ejecutadas por Agentes de IA. Amanecerá y veremos.
5. La historia de las historias de usuario - Clic aquí.

#RespuestasAgiles ¿Y qué pasó con la Definition of Ready y la Definition of Done? ¿Pasaron de Moda?

¿Y qué pasó con la Definition of Ready y la Definition of Done?¿Pasaron de moda?

 

Hola a todos,

Hace rato no escribía, lo cierto es que sigo avanzando en diferentes proyectos con mi gran amigo Lucho Salazar, pero si algunos me siguen asiduamente, saben que continúo compartiendo notas, podcast y videos; pues este aprender y compartir es en doble vía, y siento un deber trabajar con la comunidad ágil para crecer y progresar juntos.

Bueno, quiero compartirles una disfunción que he visto emerger en muchos equipos Scrum y organizaciones ágiles, que uno supondría que está mitigada, pues en ellas se insiste insistentemente en los entrenamientos de Scrum y en los diferentes marcos de escalamiento que lo usan (y que también existe en el mundo Kanban (1)), y que por lo que estoy observando esta siendo ignorada o minimizada su importancia por los Scrum Masters, Facilitadores, Agile Coaches; y como lo "spoilié" con el título del artículo es: el no cumplir con la Definition of Ready (DoR) y la Definition of Done (DoD).

Continuamente en diversos escenarios, Product Owners y gerentes de área se me quejan de que sus equipos scrum no están funcionando, y para entender el contexto hago unas preguntas de rigor, como las del litmus test de la agilidad, y adicional incluyo estas cinco (entre muchas otras según me va llevando la conversación):

1. ¿Tienen Definition of Ready?
2. ¿La están cumpliendo?
3. ¿Tienen Definition of Done?
4. ¿La están cumpliendo?
5. ¿Y cada cuánto actualizan la Definition of Done? 

Siendo estas últimas en las que estoy encontrando mayor reincidencia, y casi todas teniendo como causa raiz la presión del negocio por entregar a como de lugar. Como se pueden imaginar, en estos escenarios de falla y queja, si se incumple en cualquiera de las primeras cuatro preguntas se esta incurriendo en errores de calidad que terminan pagando el producto, el cliente, el equipo y toda la organización, generando retrasos y reprocesos e inconformidad en todos los involucrados en el proceso Scrum; y si se incurre en la última pregunta, se tiene un equipo que no mejora sus estándares con el tiempo y en consecuencia se está desactualizando.

 

A continuación, comparto un listado de consecuencias de fallar en estos cinco aspectos:

Consecuencias de no tener o no cumplir la Definition of Ready

En Scrum, "Definition of Ready" (Definición de Listo) (2) es un criterio utilizado para determinar si un elemento del Backlog del Producto está en un estado adecuado para ser planificado y abordado en una próxima iteración o Sprint. Aunque ni en tradicional, ni en cascada, ni en ágil, Scrum o Kanban, etc., se recomienda trabajar con requisitos inestables o no definidos, pues¡No tiene sentido! ¡Es desperdicio de comienzo a fin!, veamos algunas consecuencias de no contar ni cumplir con la DoR

"Caminar sobre el agua y desarrollar software basado en especificaciones es fácil si ambos están congelados" - Edward V. Berard

• Entregas inconsistentes: El equipo puede encontrarse trabajando en elementos que no están bien preparados, lo que lleva a resultados inconsistentes y posiblemente de baja calidad.
• Ambigüedad en las expectativas: Si los elementos del Backlog del Producto no están claramente definidos antes de comenzar el trabajo, puede haber confusión en cuanto a las expectativas y los criterios de finalización, lo que puede llevar a malentendidos y retrabajos.
• Mayor tiempo de Sprint Planning: La falta de definición puede conducir a discusiones prolongadas durante la planificación del Sprint, ya que el equipo debe aclarar los requisitos y detalles de cada elemento.
• Riesgo de incluir elementos poco relevantes: Si los elementos no están bien definidos, existe la posibilidad de que se planifiquen tareas que no aporten un valor significativo al producto final.
• Acumulación de elementos no terminados: Si el equipo acepta elementos no preparados en el Sprint, existe una mayor probabilidad de que no puedan completarlos dentro del marco de tiempo del Sprint, lo que resulta en elementos no terminados y afecta la capacidad de entrega. Es frecuente ver que el Product Owner resuelve las inconsistencias o dudas durante el sprint y el equipo al estimarlas o trabajar desbordan la capacidad del equipo impactando otros elementos del sprint backlog o incluso el objetivo del sprint..
• Desperdicio de tiempo y esfuerzo: Trabajar en elementos no preparados puede dar lugar a un desperdicio de tiempo y esfuerzo, ya que el equipo podría descubrir problemas o requisitos faltantes durante el Sprint.
• Falta de transparencia: Una Definition of Ready clara es esencial para mantener la transparencia en el proceso de desarrollo. Sin ella, puede ser difícil para las partes interesadas y el equipo comprender el progreso y el estado del proyecto.
• Frustración y desmotivación del equipo: Si el equipo se ve constantemente lidiando con elementos mal definidos, esto puede llevar a la frustración y la desmotivación, lo que afecta negativamente la moral y la productividad.
• Frustración de los interesados: Se genera un producto de baja calidad y no se tienen claras las reglas de interacción con el equipo, generando expectativas que no son cumplidas frecuentemente.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum y los interesados trabajen juntos para establecer una Definition of Ready 
• cumplir estrictamente la DoR y actualizarla cuando se observe pertinente.
• que los próximos elementos candidatos a ser sumados al sprint backlog se encuentren correctamente refinados y definidos.
• se realicen sesiones de refinamiento previas a la sprint planning.
• las dependencias con otros componentes sean resueltas y construidas al menos con un sprint de antelación.
• se trabajen en ítems de backlog pequeños (historias de usuario), pues esto permite la fácil identificación de áreas, escenarios, o criterios de aceptación, evitando áreas grises o no resueltas en el sprint planning.
• no incluir historias por presión del negocio que no complan la DoR.

Consecuencias de no tener o no cumplir con la Definition of Done

 La "Definición de Terminado" (3)(4) es un conjunto de criterios acordados que establece cuándo un incremento del producto se considera terminado y listo para ser entregado. Algunas de las consecuencias de no tener o no cumplir con esta definición son las siguientes:

"Cuando algo esta DONE, no me tengo que volver a preocupar de ello" - Alan Cyment

• Entregas de baja calidad: Si el equipo no cumple con los criterios de la "Definición de Terminado", es probable que los incrementos entregados no cumplan con los estándares de calidad requeridos. Esto puede llevar a problemas de funcionamiento, errores y dificultades para el usuario final.
• Acumulación de deuda técnica (6): Si se permite que el equipo entregue incrementos que no están completamente terminados, es probable que se acumule deuda técnica. La deuda técnica representa trabajo adicional que se requerirá más adelante para resolver problemas y mejorar la calidad del producto.
• Retraso en la entrega: La falta de cumplimiento con la "Definición de Terminado" puede llevar a retrasos en la entrega de incrementos completos y funcionales. Esto puede afectar la confianza del cliente y la capacidad del equipo para cumplir con los plazos establecidos.
• Dificultades en la planificación: Si el equipo no puede estimar con precisión el tiempo necesario para completar los incrementos debido a la falta de una "Definición de Terminado" clara, la planificación de futuros Sprints puede volverse complicada y menos confiable.
• Dificultades en la revisión del Sprint: Durante la revisión del Sprint, los incrementos se evalúan para determinar si cumplen con los criterios de la "Definición de Terminado". Si no se cumple, se pueden generar discusiones y conflictos innecesarios entre los interesados.
• Falta de transparencia: Una "Definición de Terminado" clara es esencial para mantener la transparencia en el proceso de desarrollo. Sin ella, puede ser difícil para las partes interesadas y el equipo comprender el progreso y el estado real del producto.
• Desmotivación del equipo: Si el equipo se ve obligado a entregar incrementos que no cumplen con los estándares de calidad, es probable que se sientan desmotivados y frustrados por no poder ofrecer un trabajo de alto nivel.
• Problemas de integración: Incrementos que no cumplen con la "Definición de Terminado" pueden generar problemas de integración con otros componentes del sistema, lo que dificulta el progreso general del desarrollo.
• Desconfianza de los interesados en el equipo y en el proceso Scrum: Al observar que el equipo Scrum no cumple entregando con calidad, se pierde confianza en el equipo y el proceso Scrum.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum adopte y cumpla la DoD de la organización.
• en su defecto, el equipo Scrum la defina y todos responsablemente la promuevan, comenzando por el Scrum Master como agente de cambio.
• no contar como Done, algo que no fue finalizado.
• usar la retrospectiva como fuente de indagación para comprender por qué no se cumplió la DoD.
• por presión de agenda o del negocio, evitar a toda costa declarar como DONE algo que no lo es. 

Consecuencias de no actualizar la Definition of Done

"Entre más maduro y DevOps sea un equipo, más robusta es su Definition of Done" - Jorge Abad

No revisar y mejorar con cierta frecuencia la "Definición de Terminado" como lo sugiere la guía de Scrum puede tener varias consecuencias negativas que afectan al equipo de desarrollo y al producto final a lo largo del tiempo. Aquí están algunas de las consecuencias de no realizar revisiones y mejoras periódicas:

• Estancamiento de la calidad: Si la DoD no se revisa y actualiza regularmente, es probable que la calidad del producto se estanque. Los criterios pueden volverse obsoletos o insuficientes para mantener el nivel de calidad deseado.
• Deuda técnica: La falta de revisión puede conducir a la acumulación gradual de deuda técnica. A medida que el producto se desarrolla sin mejoras en la DoD, es más probable que se tomen atajos y se sacrifique la calidad para cumplir con los plazos, lo que crea deuda técnica que debe abordarse más adelante.
• Mayor incidencia de errores: Si la DoD no se ajusta a las necesidades cambiantes del producto o del cliente, es más probable que se produzcan errores y problemas que afecten negativamente la experiencia del usuario.
• Dificultades en la entrega: Si la DoD no se actualiza para reflejar las nuevas expectativas o requisitos del cliente, el equipo puede tener dificultades para cumplir con las demandas cambiantes del mercado.
• Conflictos con los interesados: Si la DoD no se revisa en función del feedback de los interesados, puede haber conflictos y desacuerdos sobre el nivel de calidad aceptable para el producto.
• Pérdida de transparencia: Si la DoD no se revisa y comunica de manera efectiva, puede haber una falta de transparencia en el proceso de desarrollo, lo que dificulta que los interesados comprendan el estado real del producto.
• Desmotivación del equipo: La falta de revisión y mejora puede llevar a que el equipo se sienta frustrado y desmotivado, ya que pueden enfrentar problemas recurrentes y dificultades para cumplir con los objetivos de calidad.
• Estancamiento en la mejora continua: La revisión y mejora de la DoD son esenciales para la mejora continua del equipo. Sin esta práctica, el equipo puede dejar de buscar oportunidades para optimizar su proceso de desarrollo y entregar un producto de mayor calidad.
• Trabajar en un producto obsoleto: Sin el ejercicio de revisión frecuente de la DoD, se puede incurrir en trabajar en un producto que se va desactualizando y quedando obsoleto con el tiempo.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum revise con cierta cadencia su DoD, al menos una vez cada trimestre en una retrospectiva.
• revisar el entorno del mercado (realizar vigilancia tecnológica) para identificar mejoras al producto, prácticas o proceso que deban ser incluidas en la DoD.
• identificar qué prácticas de calidad se encuentran al final del proceso de desarrollo (por ejemplo: prebas especializadas previos a la salida a producción) que puedan ser includias tempranamente (shift-left) para mejorar la velocidaddel equipo y del producto.

Cerrando

Scrum tiene dos puntos de control de calidad clave, que son: la entrada de lo que se quiere construir y la salida o increments; el compromiso del equipo Scrum en hacer cumplir la DoR y la DoD, garantizan la calidad del producto, menos errores, mayor velocidad, más transparencia, menos deuda técnica, mejor satisfacción de todos los involucrados, planeaciones y ejecuciones más efectivas, en consecuencia un mejor Scrum y una entrega de calidad de impacta positivamente la generación de valor.

Deteriorar el cumplimiento de la DoR y la DoD generará, como lo vimos, desconfianza en el producto, el equipo y el proceso; consecuentemente deteriora el entorno de agilidad que se quiere construir.

"Agilidad sin calidad, son incrementos de desperdicio entregados en ciclos cortos" - Jorge Abad

Volver a lo básico e insitir sobre lo esencial, garantizará una mejor agilidad y desempeño de los equipos construyendo productos exitosos.

Saludos ágiles.

Jorge Abad.

Referencias, notas, aclaraciones y comentarios

1. En el mundo Kanban, la Definition of Ready y la Definition of Done conocen como Politicas y consiste en que una tarjeta no mueve hacia la derecha (o en la dirección del flujo) si las políticas no se cumplen.
2. Definition of ready (scrumbook) - https://scrumbook.org/value-stream/product-backlog/definition-of-ready.html
3. Definition of done (scrumbook) - https://scrumbook.org/value-stream/definition-of-done.html
4. Definition of done (Scrum guide)- https://scrumguides.org/scrum-guide.html.
5. Deuda Técnica - http://www.lecciones-aprendidas.info/search/label/deuda%20t%C3%A9cnica
6. Algunos textos acá presentados fueron curados utilizando IA.

Acomodando o Forzando Scrum para Equipos de Testing

Hola a todos (hace tiempo no escribía, discúlpen lo perdido que he estado)

Hoy hablare un poco de como he visto que se hacen proyectos de testing bajo el marco de Scrum o al menos ser ayudados por el marco. Comencemos.

------

PROLOGO

La tradicional forma de ver el software en cascada entre empresas,  en donde:

La empresa “X” construye el software (entregándolo probado),

y la empresa “Y” lo prueba y certifica

Va seguir viva en nuestro entorno por un tiempo más y la causa raíz de esto es sin duda la desconfianza, pues ya sea por procedimiento, requerimientos corporativos de seguridad ponemos a un tercero a que pruebe, generando la calidad de la calidad.*

NUDO

Recordemos, “en Ágil la idea es hacer la menor cantidad de software con calidad que genere el mayor valor de negocio**”, pero muchas veces, debido a estos  esquemas de desconfianza “CASCADIZAMOS ÁGIL” y se cae en que:

• un equipo hace desarrollo ágil cumpliendo su DEFINITION OF DONE
•  y otro prueba el DONE del anterior, cayendo en la calidad de la calidad, el proceso y reproceso, y por ende el desperdicio

Bajo esta premisa el equipo adicional de testing – de la empresa “Y” –

dice: “yo voy a probar usando Scrum”

¡ ¡ ¡OMG!!!

Seamos claros, ese equipo usará del framework de Scrum para realizar la gestión del proyecto realizando:

• Planeación
• Ejecución
• Revisión
• y Retrospectiva

Pero bajo este esquema “LOS EQUIPOS DE TESTING QUE EMPLEAN EL PROCESO DE SCRUM PARA PROBAR, REALMENTE NO HACEN SCRUM” pues Scrum sirve para construir productos, y bajo este esquema solo lo estamos probando.

Pero a pesar de lo anterior, procedamos a homologar lenguaje que equivaldría en este esquema:

• El Product Backlog es todo lo que hay que probar
• Casos de uso
• Historias de usuario
• Requisitos no funcionales
• El sprint backlog
• Es lo que se selecciona a probar durante el ciclo
• El team es un equipo de testing
•  Product Owner y Scrum Master conservan sus definiciones.

Entonces cual es la DEFINITION OF DONE de un equipo de testing bajo estas características

• Todos los casos de prueba de la HU o del CU diseñados
• Las evidencias asociadas a casos fallidos o exitosos registradas en el repositorio
• Reporte de incidencias encontradas actualizado.

Y la DEFINITION OF READY:

• Casos de uso o historias de usuario desarrollados y congelados en un ambiente para testing
• Documentación asociada congelada.

No dudo que este esquema sea efectivo, lo he visto:

• Potencializa más el trabajo en equipo, pero no se nota la fortaleza e interacción de un equipo multidisciplinario que construye software.
• Se mejora la predictibilidad de diseño y ejecución de casos de pruebas

Conclusión

En la medida que hagamos mejor ágil, un mejor DONE (procesos y practicas técnicas que aseguren los productos) estos esquemas comenzarán a desaparecer, al igual que los testers evolucionarán a testers que no solo hacen pruebas funcionales, sino que automatizan, realizan pruebas no funcionales y hacen parte crucial del equipo de desarrollo.

Notas

*si vamos a ser sensatos esto tiene todo el sentido en proyectos donde a la empresa “X” construía el software haciendo cascada, generando grandes cantidades de software, que  talvez entregado a la fuerza y en consecuencia, obligando al cliente a contratar a un tercero que le certifique que lo que le entregaron muchos meses después si sirve.

**y saliendo a producción lo antes posible, para generar el mayor RETORNO DE INVERSION (ROI)

Una versión inicial de Definition of Done (Definición de Hecho / Terminado / Realizado)

La  Definition of Done -  DoD - (Definición de Hecho / Terminado / Realizado) es el estándar de calidad que debe cumplir el equipo Scrum, es aquello que les garantiza que han cumplido lo que se han comprometido y que el "Incremento"  de funcionalidad es realmente "potencialmente entregable"

La mejor definición de "done" la leí de Alan Cyment:

 "ALGO ESTA HECHO CUANDO NO TENGO QUE VOLVER A PREOCUPARME DE ELLO"

Si el equipo de desarrollo o alguien del equipo siente que no esta totalmente hecho y ejemplo:

• falta un despliegue
• falta una validación
• duda si se realizaron toda la documentación comprometida
• o le da "susto" salir a producción con el desarrollo realizado (el incremento de software) por que sabe que tiene unos "pendientes" o cree que le van a reventar en producción muchos bugs

entonces no esta realmente "Done"

La DoD debe estar publica y disponible para el equipo, debe ser un acuerdo entre todos:

• Product Owner
• Teaam Developer
• Scrum Master

Este acuerdo se realiza inicialmente en el sprint cero y se va revisando en cada sprint planning (como fruto de nuevas necesidades o resultado de las retrospectivas), Si hay cambios en la DoD,  es casi seguro que impliquen nuevas tareas en cada sprint.

Aunque el Team Developer (Equipo de Desarrollo) debe ser responsable de cumplir la DoD, el que debe velar por que se logre este compromiso es el Scrum Master.

A continuación les comparto una versión inicial que puede ser evolucionada, corregida, mejorada o aumentada por cada equipo Scrum:

DEFINICIÓN DE HECHO

• Cada historia de usuario/funcionalidad este codificada, compilada, desplegada por el servidor de integración continúa.
• Las historias de usuario/funcionalidades cumplan todos los criterios de aceptación acordados con calidad(QA), el Product Owner al inicio del sprint.
• Las historias de usuario/ funcionalidades construidas no afecten a las funcionalidades ya entregadas, por lo que las pruebas de regresión deben ser satisfactorias.
• Las funcionalidades/historias de usuario comprometidas funcionen en todos los ambientes comprometidos, ej:
• Laboratorio
• Pruebas
• Preproducción
• Las funcionalidades/historias de usuario cuentan con pruebas funcionales automatizadas y despues de correr estas el resultado es exitoso.
• No se tienen advertencias en Rojo en la verificación de código del servidor de integración continua (Sonar) - en caso que estemos trabajando con Jenkins y Sonar - .
• Las clases de negocio cuentan con pruebas unitarias que verifican su correcto funcionamiento.
• El Código desarrollado se comentado y estandarizado.
• Código en el repositorio de control de versiones.
• El porcentaje de cobertura de pruebas unitarias al código es >= a un XX%
• El porcentaje de cobertura de pruebas funcionales automatizadas a las funcionalidades/historias de usuario es >= a un XX%
• Se genere y/o actualice la documentación comprometida para el Sprint
• Documento de arquitectura
• Documento de diseño
• Manual de Usuario
• Plan de pruebas
• u otro documento del proceso de desarrollo que le agregue valor al proyecto o que contractualmente estemos comprometidos a entregar
• [nuevo] Se cumpla con los requisitos no funcionales, por ejemplo:
• Estándares gráficos
• Estándares de usabilidad y UX
• Navegadores y versión de los mismos sobre los que debe funcionar
• Servidores de base de datos y de aplicaciones sobre los que funcionará
• Tipo de servicios a emplear
• etc.