Vista previa de la pizarra
1. Qué es el desarrollo ágil (constru...
2. El recorrido del sprint de dos sem...
3. Product Owner
4. Scrum Master
5. Desarrolladores
6. Product Backlog
7. Sprint Backlog
8. Incremento
9. Los 5 eventos de un vistazo
Kit de inicio ágil
Cómo usarlo: (1) ...
Definición de Ter...
Roles y acuerdos
Bloqueos y obstác...
Aprendizajes y me...
En una frase En un plazo corto de unas dos semanas, construir algo que funcio na 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 constru ir, se fija el orden y se construye poco a poco desde arriba. El ord en 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. 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 ll egue una petición nueva, por norma n o 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 min utos a una hora fija. Cada persona c uenta qué hizo ayer, qué hará hoy y dónde está atascada. Se repite a dia rio en paralelo al desarrollo. ej. d e pie, cada mañana a las 10. 4. Revisión del sprint Último día. Enseñar a los interesado s algo que funciona y recoger sus op iniones. Hasta 2 horas. Enseñar la p antalla, no las diapositivas. ej. ma nejar en directo la nueva pantalla d e acceso. 5. Retrospectiva Justo después de la revisión. Mirar la forma de trabajar y no lo constru ido. Hasta hora y media. Decidir el siguiente paso con KPT en el tablero 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 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 Quienes construyen, incluidos diseño, código y pruebas Lo que cabe en dos semanas lo estiman los propios desarrollado res ej. tres personas se reparten el Sprint Backlog Desarrollador es aquí el nombre de un rol, no un puesto 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 Own er ej. mejora del acceso / ajustes de avisos / búsqueda en el pan el Una lista sin final. Puede crecer por el camino 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 Lo que funciona y existe al final de las dos semanas Lo que no cumple la definición de terminado (las condiciones q ue el equipo acuerda de antemano para decir que algo está term inado) no cuenta ej. la mejora del acceso, probada y verificada Esto es lo que se enseña en la revisión del sprint 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 B acklog. 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 pantall a, 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...
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 a unque se deje fuera esta vez. ej. reescribir los mensajes de error que n o se entienden Could (si sobra tiempo) Entra en el sprint, pero es lo primero que sale si falta tiempo. El objetivo se sost iene sin ello. ej. cambiar el logotipo de la pantalla de… Won't (esta vez no) Se acuerda no hacerlo. No lo borres, déjal o en el Product Backlog (tablero #6). ej. pasar los ajustes de avisos y la búsqu eda del panel a un sprint posterior 11. Retrospectiva...
Keep (lo que seguimos) Desde que la daily es a las 10 de la mañana, viene todo el mu ndo 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 sob ra hueco Las peticiones imprevistas las recoge primero el Scrum Master Arrastra para mover y usa la rueda para hacer zoom
