BDD ¿Qué es? y ¿cómo y cuándo utilizarlo en Scrum?

08/05/2023
BDD o el desarrollo orientado por comportamiento (Behavior-Driven Development) es una práctica colaborativa que permite colaborar a los desarrolladores (Programmers, QA, UX, etc.) con las personas de negocio (o representante de los mismos), algo que puede permitir reducir el gap que suele haber entre estos perfiles o roles.
bdd en scrum

Es verdad que BDD estaba o está pensando como una parte desarrollo de software, principalmente la parte de Testing, no obstante tiene tantos beneficios, que no se debe de marginar o ver como solo una práctica o proceso de testing o calidad de producto.

BDD permite escribir los requisitos (en este caso se refiere a Historias de usuario) y sobre todo los criterios de aceptación en una manera fácil de entender (desde la perspectiva del negocio o usuario) por todas las partes. Y se pueden escribir así (seguro que resulta familiar 🙂):

Given [context], when [event occurs], then [outcomes]

Para crear estos criterios, es importante intentar responder a las siguientes preguntas:

  • ¿Quién es el usuario (rol, perfil, etc.) de esta historia?
  • ¿Sabemos qué esperan estas personas de esta historia o feature?
  • ¿Habrá combinaciones/variaciones en la interacción?
  • ¿Qué acciones realizan los usuarios?
  • etc.

Luego veremos cómo aterrizar esto o como Gherkin nos permite aterrizar a algo programable y como se pueden automatizar estos criterios

Beneficios de utilizar BDD en el desarrollo de producto

El desarrollo dirigido o guiado por comportamientos ( BDD ) tiene muchos beneficios a nivel de calidad de producto y de desarrollo del mismo, además de muchos otros beneficios y ventajas que mencionaremos a continuación:

Colaboración

Bdd es una manera excelente para colaborar el PO u/y otros stakeholders de negocio con los desarrolladores en refinar algunos Product Backlog Items (PBIs) (en las sesiones de refinamiento del Product Backlog  o las propias Sprint Planning). Una manera que puede ayudar para trabajar este refinamiento utilizando BDD (da igual que utilices el marco de trabajo Scrum o  el método Kanban ) es utilizar la práctica de Three Amigos

Se puede considerar que bdd es una mejora o evolución de Three amigos ya que nos permitirá aterrizar los criterios de aceptación a posibles pruebas que se pueden automatizar. Esta automatización es una inversión a medio y largo plazo, es verdad que al inicio del desarrollo del producto puede existir la sensación de poco valor o impacto de esta práctica, pero conforme avanzan los desarrollos y saltan los BUGs nos acordaremos de ellas.

Transparencia

Cada comportamiento del producto nos lleva a un escenario con un posible resultado e interacción del usuario. Algo que permite contarnos la experiencia o el comportamiento específico del usuario con el producto. Esto resulta en un entendimiento común entre el Product Owner, Stakeholders y Developers sobre lo que se espera de este PBI y en concreto este criterio de aceptación. Algo muy positivo a la hora de dividir PBIs en los refinamientos 😉  

Una buena organización

BDD está pensado para acelerar el ciclo o proceso de desarrollo de software y de producto. Para ellos todas las personas de desarrollo deben de tener la misma base de escenario, que se crearán utilizando el lenguaje Gherkin ( mencionaremos más adelante ). Al utilizar Gherkin para escribir estos escenarios permite agilizar el proceso de automatización de pruebas, detección de fallos en el sistema de un modo temprano, recoger el feedback y mejorar.

Shift Left

Desplazar la parte de pruebas a la izquierda para poder poner foco en las pruebas y su automatización antes del desarrollo, algo que permitirá detectar errores pronto y ajustar. 

¿Cómo utilizar Gherkin y BDD?

Primero aclaremos que es Gherkin, Gherkin es un domain-specific language (DSL) que permite definir el comportamiento de un usuario con el producto sin necesidad de llegar a implementarlo. Gherkin utiliza una sintaxis simple y sencilla, es una sintaxis entendible por cualquier persona involucrada en el producto (de negocio o técnica): 

Feature:

Scenario:

Given

When

Then

Veamos algún ejemplo de Gherkin

Feature: Buscar vuelo

#Opcional : Como viajero, quiero buscar vuelos disponibles entre Madrid y París para poder reservar un viaje en una fecha determinada.

Scenario: Buscar todos los vuelos disponibles basados en fecha, origen y destino

Given la fecha de viaje «01/01/2023» y el origen «Madrid» y el destino como «Paris».

When clic en el botón Buscar

Then La página de búsqueda mostrará todos los vuelos disponibles 

And proporcionar la opción de reservar el vuelo

Un pequeño tip: a la hora de dividir las historias de usuario a veces puede resultar muy complejo dividirlas en unos PBIs que se pueden entregar durante el Sprint, pues cada criterio de aceptación y cada And se pueden convertir en una nueva historia

Ver también como implementar BDD utilizando cucumber

También te puede interesar el tema de Desarrollo dirigido por pruebas o TDD

¿Te ha gustado este contenido?

¡Valora este contenido!

Promedio de puntuación 4.3 / 5. Recuento de votos: 6

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Otras publicaciones

Agile Product Management

Agile Product Management

Diferencia entre Project mindset y Product mindset El Project Mindset fomenta e impulsa el éxito utilizando métricas internas (esas KPIs) que...

leer más
Apúntate a la newsletter

Apúntate a la newsletter

Manténte informado sobre todo lo relacionado con Agile Product Management, Scrum, Management 3.0 y Kanban

¡Mensaje enviado!

Applying Flow Metrics for Scrum

By ProKanban.org

Código de descuento (21 %) QAF1UZZ1

You have Successfully Subscribed!