Proyectos y desarrollo
Desarrollo ágil para principiantes: roles, eventos y artefactos de Scrum en tu primer sprint
Principiante | 2 páginas de pizarra · Tablero de tareas: 5 columnas (4 tareas principales y 12 subtareas)
Principiante: Sin términos técnicos. Basta con responder a las preguntas de la pizarra siguiendo los ejemplos para que tome forma.
Quien empieza con el desarrollo ágil o entra en su primer equipo Scrum entiende con esta plantilla para principiantes los 3 roles, 5 eventos y 3 artefactos y hace su primer sprint. La pizarra reúne la idea de fondo del desarrollo ágil, el recorrido de un sprint de dos semanas en 5 pasos, tres marcos para los 3 roles, tres marcos para los 3 artefactos, una tabla de los 5 eventos, cuatro columnas MoSCoW para elegir lo que entra en este sprint y una retrospectiva KPT. El tablero de tareas tiene cinco columnas - Product Backlog, Sprint Backlog, En desarrollo, Pendiente de revisión y Hecho - y arranca con 4 tareas principales y 12 subtareas, del vocabulario a la retrospectiva, todas sin empezar. Entrar en un equipo sin conocer Scrum es quedarse atrás por las palabras, así que recorre este tablero durante un sprint y sabrás qué decir en la daily. A diferencia de un tablero para equipos ya rodados, este trata del vocabulario y de la primera vuelta.
Con una cuenta gratuita, puedes copiar esta plantilla desde el mercado
Vista previa de la pizarra
Leer el contenido de la pizarra en formato texto
Kit de inicio ágil
Cómo usarlo: (1) Leer la idea de fondo → (2) Recorrer el sprint de dos semanas → (3) Comprobar los 3 roles y los 3 artefactos (tableros 3-8) → (4) Fijar las fechas de los 5 eventos (tablero #9) y repartir con MoSCoW lo que entra y lo que espera (tablero #10) → (5) Revisar con KPT (tablero #11)
1. Qué es el desarrollo ágil (construir, enseñar y corregir en plazos cortos)
- En una frase En un plazo corto de unas dos semanas, construir algo que funciona y enseñarlo, recoger opiniones y corregir. Y repetirlo.
- En qué se diferencia de lo de siempre ej. en vez de cerrar todas las especificaciones antes de construir, se fija el orden y se construye poco a poco desde arriba. El orden puede cambiar por el camino.
- Para qué sirve ej. como cada dos semanas se ve algo real, si la dirección se ha torcido te enteras en dos semanas. Solo hay que rehacer un sprint.
2. El recorrido del sprint de dos semanas (la daily se repite cada día)
- 1. Planificación del sprint Primer día del sprint. Repartir con MoSCoW en el tablero
- 2. Desarrollo (dos semanas) Construir solo lo elegido. Aunque llegue una petición nueva, por norma no entra en este sprint. ej. avanzar únicamente los 3 elementos de acceso, 13 puntos.
- 3. Daily Scrum (15 minutos al día) Cada día de esas dos semanas, 15 minutos a una hora fija. Cada persona cuenta qué hizo ayer, qué hará hoy y dónde está atascada. Se repite a diario en paralelo al desarrollo. ej. de pie, cada mañana a las 10.
- 4. Revisión del sprint Último día. Enseñar a los interesados algo que funciona y recoger sus opiniones. Hasta 2 horas. Enseñar la pantalla, no las diapositivas. ej. manejar en directo la nueva pantalla de acceso.
- 5. Retrospectiva Justo después de la revisión. Mirar la forma de trabajar y no lo construido. Hasta hora y media. Decidir el siguiente paso con KPT en el tablero
3. Product Owner
- La persona que decide qué se construye antes
- Responde del orden del Product Backlog
- ej. decide que la mejora del acceso va primero
- Es a quien se consulta cuando hay dudas de contenido
4. Scrum Master
- La persona que vela por que se respete la forma de trabajar
- Quita los atascos y hace respetar la duración de cada evento
- ej. recoge una petición imprevista y la reprograma
- No da órdenes ni es necesariamente un mando
5. Desarrolladores
- Quienes construyen, incluidos diseño, código y pruebas
- Lo que cabe en dos semanas lo estiman los propios desarrolladores
- ej. tres personas se reparten el Sprint Backlog
- Desarrollador es aquí el nombre de un rol, no un puesto
6. Product Backlog
- Todo lo que se quiere construir, ordenado por lo que va antes
- Cuanto más arriba, más pronto. El orden lo pone el Product Owner
- ej. mejora del acceso / ajustes de avisos / búsqueda en el panel
- Una lista sin final. Puede crecer por el camino
7. Sprint Backlog
- Solo lo que se ha acordado construir en estas dos semanas
- Se elige en la planificación y no se añade nada a mitad
- ej. los 3 elementos de acceso, 13 puntos en total
- Aquí también se ve quién lleva cada cosa
8. Incremento
- Lo que funciona y existe al final de las dos semanas
- Lo que no cumple la definición de terminado (las condiciones que el equipo acuerda de antemano para decir que algo está terminado) no cuenta
- ej. la mejora del acceso, probada y verificada
- Esto es lo que se enseña en la revisión del sprint
9. Los 5 eventos de un vistazo
| Qué se hace | Quién asiste | Duración | |
|---|---|---|---|
| Sprint | Sprint La caja de dos semanas que contiene los otros cuatro. Su duración no se alarga. | Todo el equipo Scrum (Product Owner, Scrum Master, desarrolladores) | Dos semanas Fija, un mes como máximo |
| Planificación | Planificación del sprint Elegir lo que se hará en dos semanas y formar el Sprint Backlog. | Todo el equipo Scrum | Hasta 4 horas Mañana del primer día |
| Daily Scrum | Daily Scrum Contar qué se hizo ayer, qué toca hoy y dónde hay atasco. | Desarrolladores (los otros dos roles escuchan) | 15 minutos Cada día, misma hora y mismo sitio |
| Revisión | Revisión del sprint Enseñar algo que funciona y recoger opiniones. La pantalla, no las diapositivas. | Equipo Scrum e interesados (quien pide, quien usa) | Hasta 2 horas El último día |
| Retrospectiva | Retrospectiva del sprint Mirar la forma de trabajar, no lo construido. | Todo el equipo Scrum | Hasta hora y media Justo después de la revisión |
10. Elegir lo que entra en estas dos semanas (MoSCoW)
Must (imprescindible)
- Solo aquello sin lo cual no se alcanza el objetivo del sprint. ej. corregir el fallo por el que no llega el correo para restablecer la contraseña
Should (importante)
- Importante, pero el objetivo se sostiene aunque se deje fuera esta vez. ej. reescribir los mensajes de error que no se entienden
Could (si sobra tiempo)
- Entra en el sprint, pero es lo primero que sale si falta tiempo. El objetivo se sostiene sin ello. ej. cambiar el logotipo de la pantalla de acceso
Won't (esta vez no)
- Se acuerda no hacerlo. No lo borres, déjalo en el Product Backlog (tablero #6). ej. pasar los ajustes de avisos y la búsqueda del panel a un sprint posterior
11. Retrospectiva del primer sprint (KPT)
Keep (lo que seguimos)
- Desde que la daily es a las 10 de la mañana, viene todo el mundo
- Como los atascos se dijeron en el momento, se resolvieron en medio día
Problem (lo que no salió)
- De los 13 puntos elegidos, 5 no se terminaron en dos semanas
- No supimos decir que no a lo que llegaba a mitad y el Sprint Backlog creció
Try (lo que probamos)
- Empezar el siguiente sprint con 8 puntos y añadir solo si sobra hueco
- Las peticiones imprevistas las recoge primero el Scrum Master
Contenido del tablero de tareas
Product Backlog 16 elementos
Términos de Scrum
El primer tropiezo siempre son las palabras. Si las aprendes en tres bloques, roles, eventos y artefactos, dejas de perderte en las conversaciones.
Anotar los 3 roles
Escribe con nombres y apellidos quién es Product Owner, quién Scrum Master y quiénes son los desarrolladores. Si alguien acumula dos roles, indícalo.
Ordenar 5 eventos
Coloca el sprint, la planificación, la daily, la revisión y la retrospectiva en orden cronológico y añade la fecha y la hora de cada uno.
Ver los 3 artefactos
Comprueba dónde están realmente el Product Backlog, el Sprint Backlog y el incremento.
Montar el 1er sprint
Memorizar palabras no basta. Fija el marco de dos semanas y llega hasta elegir solo lo que cabe dentro.
Fijar las fechas
Decide la fecha de inicio, la de fin y el día y la hora de cada evento. La duración no se alarga a mitad de camino.
Llenar el backlog
Saca todo lo que quieres construir a la columna Product Backlog y ordénalo según lo que se hará antes. Ese orden lo decide el Product Owner.
Elegir 2 semanas
Empezando por arriba, pasa al Sprint Backlog solo lo que termina en dos semanas. Si es demasiado, marca primero los Won't con MoSCoW en el tablero
Hacer la daily
La rutina diaria durante el sprint, también llamada stand-up. Que no se convierta en un informe de avance, sino en el sitio donde los atascos salen en el momento.
Ayer y hoy
Cada persona cuenta en un minuto qué hizo ayer y qué hará hoy. Las conversaciones largas se dejan para después de la daily.
Decir los bloqueos
Di siempre en voz alta dónde estás atascado. La solución la recoge el Scrum Master al terminar la daily.
Mover las tarjetas
Mueve las tarjetas a En desarrollo, Pendiente de revisión y Hecho para que lo que falta se vea de un vistazo.
Revisión y retro
El cierre de las dos semanas. Separar las opiniones sobre lo construido de las opiniones sobre la forma de trabajar forma parte del patrón de Scrum.
Mostrar el producto
En la revisión del sprint enseña a los interesados una pantalla que funciona de verdad en lugar de diapositivas y recoge sus opiniones.
Feedback al backlog
Devuelve las opiniones recibidas como tarjetas a la columna Product Backlog, como material para el próximo orden de prioridades.
Un Try con KPT
En la retrospectiva revisa la forma de trabajar y decide un único Try para probar en el siguiente sprint.
