Sprint ágil de software – planificar, construir, probar, publicar
InformáticaProfesiones en informáticaEdades 17–18
Cargando…
Inicia sesión para usarUn pequeño equipo de software realiza un sprint ágil para crear una app de clubes escolares: elige del backlog las historias de usuario que caben en la capacidad del equipo y simula el sprint día a día. Las tarjetas avanzan por las columnas Por hacer, En curso, Pruebas y Hecho, un gráfico burndown sigue los puntos restantes y los errores creados al programar se detectan en las pruebas o llegan a los usuarios. El sprint termina con una revisión que puntúa la satisfacción del cliente.
Lección: Profesiones de desarrollo de software: el proceso ágil y los roles del equipo
Qué muestra
Esta simulación muestra cómo trabaja un equipo de software real durante un sprint ágil. El propietario del producto ha ordenado por valor las historias de usuario de una app de clubes escolares; el equipo se compromete con las que caben en su capacidad, estimada como desarrolladores × días × 0,8 puntos. Cada día se construyen historias, aparecen errores en el código nuevo y las pruebas o la revisión de código detectan parte de ellos. Saltarse las pruebas acelera la construcción, pero llegan más errores a los usuarios. Un gráfico burndown sigue el avance y la revisión del sprint puntúa la satisfacción del cliente. Los coeficientes son supuestos ilustrativos.
Cómo usarla
Elige una opción de Planificación o marca tú las historias, ajusta Desarrolladores, Testers, Días y Tiempo en pruebas, y activa o desactiva la revisión de código. Pulsa Avanzar 1 día para recorrer el sprint o Ejecutar el sprint para animarlo, y observa el tablero, la línea burndown y el contador de errores. Compara la revisión del sprint tras cambiar un ajuste y usa Otro escenario para ver la variación aleatoria.
Parámetros que puedes cambiar
- Planificación del sprint Ajustado a la capacidad, Todo el backlog, Elegir a mano
- Número de desarrolladores 2–6 personas
- Número de testers 0–2 personas
- Duración del sprint 5–15 días
- Tiempo de los desarrolladores en escribir pruebas 0–40 %
- Revisión de código entre compañeros
Preguntas para explorar
- ¿Cuánto más rápido construye el equipo sin tiempo en pruebas, y cuántos errores más llegan a los usuarios?
- ¿Por qué tomar todo el backlog suele bajar la satisfacción del cliente?
- ¿Qué aporta cada rol (propietario del producto, desarrollador, tester) a un buen sprint?
