De BDD a SDD: cómo quitar la ambigüedad escribiendo las historias de usuario en Markdown

En el blog de la cátedra ya hemos publicado varias entradas sobre cómo escribir buenas historias de usuario a partir de una épica, cómo redactar criterios de aceptación claros y cómo transformar esos criterios en tests con Cucumber. Esa serie cubre, en esencia, una forma de trabajar en BDD (Behaviour Driven Development): comportamiento primero, escenarios Given-When-Then, validación conjunta con negocio.

Blog · Cátedra Viewnext-USAL en Metodologías Ágiles

Este artículo es la tercera entrega de la serie sobre Dual Track Agile con IA. Si no has leído los anteriores, te recomendamos empezar por la introducción al modelo y el caso práctico de organización: https://viewnext.usal.es/blog/dual-track-agile-con-ia-un-caso-pr%C3%A1ctico-paso-paso

Blog · Cátedra Viewnext-USAL en Metodologías Ágiles

Este artículo forma parte de una serie sobre Dual Track Agile con IA. Si aún no has leído la introducción al modelo, te recomendamos empezar por ella: http://viewnext.usal.es/blog/dual-track-agile-con-ia

Un equipo de alto rendimiento no nace, se hace. El modelo de madurez de Bruce Tuckman es uno de los marcos más utilizados en agilidad para entender cómo evolucionan los grupos humanos. Su principal objetivo es ayudar a los líderes y al propio equipo a identificar en qué fase se encuentran para acelerar su crecimiento y efectividad.

¿Cómo se consigue esto?

En lugar de ver al equipo como una entidad estática, Tuckman descubrió que todos los grupos atraviesan 4 etapas fundamentales para alcanzar la excelencia:

En el desarrollo de software, el mayor riesgo no es construir algo mal, sino construir algo que nadie necesita. Para evitar este "desperdicio", el enfoque Dual-Track Agile se ha convertido en el estándar de los equipos de alto rendimiento.

En la anterior publicación desglosamos qué medir, pero el verdadero arte de un equipo ágil no está en recoger datos, sino en saber qué hacer cuando estos "gritan" que algo va mal. A veces, las métricas parecen indicar éxito cuando en realidad esconden problemas de fondo.

Para cerrar nuestra serie, identificamos 1 problema común y su solución, para cada uno de los 5 grupos de métricas que identificamos en la publicación 2/3 de la serie de Métricas de Scrum.

En la primera publicación establecimos qué son las métricas en Scrum y los beneficios de basar las decisiones del equipo en datos objetivos. En esta segunda publicación, vamos a ver cuáles son las métricas más utilizadas y su clasificación en 5 grandes grupos en función de lo que pretende medir cada métrica. Estos cinco grupos son:

1. Métricas de Productividad y Capacidad.

2. Métricas de Flujo.

3. Métricas de Eficacia y Valor.

4. Métricas de Calidad del Producto.

5. Métricas de Salud del Equipo.

Dentro del desarrollo de software bajo el marco de trabajo Scrum, comprender cómo funciona el equipo de desarrollo es un requisito fundamental. El objetivo de medir el trabajo no es únicamente mejorar la eficiencia diaria, sino permitir que las estimaciones de tiempo y esfuerzo se basen en datos históricos sólidos, eliminando las suposiciones o el "instinto".

Como señalaba Peter Drucker: "Lo que no se puede medir, no se puede mejorar". Esta premisa es la base de la mejora continua en cualquier metodología ágil.

El pasado 6 de marzo, en el curso de Gestión Ágil de Proyectos con Scrum, realizamos la dinámica del Airplane Game. Los equipos organizaron el trabajo en tres Sprints de 3 minutos para fabricar aviones de papel bajo criterios específicos, aplicando los roles y ceremonias de Scrum de forma cronológica:

Introducción y Planificación Inicial

En la gestión de proyectos, especialmente en entornos ágiles, es fundamental que la información fluya de manera transparente entre el equipo técnico y los responsables de negocio. Sin embargo, a menudo nos encontramos con un fenómeno conocido como el “Efecto Sandía”.