Ing.

Rolando Martínez UAGRM

Un enfoque
de aplicación de
Scrum
como marco de trabajo
para el desarrollo de
software (Ver. 3.0)

por: Ing. Rolando Martínez Canedo

Docente FICCT-UAGRM

1
 Ing. Rolando Martínez UAGRM

Contenido

I. CICLO DE VIDA ........................................................................................................................................................... 3

II. ACTIVIDADES DE DEFINICION INICIAL (R-1) .............................................................................................................. 5
III. ACTIVIDADES A REALIZAR EN CADA SPRINT ......................................................................................................... 6
1) Evento  Tareas para realizar el Sprint Planning (R-2) ....................................................................................... 6
2) Evento  Actividades a realizar durante la ejecución del Sprint (R-3) ............................................................... 7
2.a) Cada desarrollador selecciona desde el Sprint Backlog que tareas realizará .................................................... 7
2.b) Generación del incremento y despliegue .......................................................................................................... 8
3) Evento  Scrum Diario (Daily Scrum) ................................................................................................................. 8
4) Evento  Revisión de Sprint (R-4) ........................................................................................................................ 9
5) Evento  Retrospectiva de Sprint (R-5) ............................................................................................................. 10
IV. OTROS EJEMPLOS DE FORMULARIOS ................................................................................................................. 11

2
 Ing. Rolando Martínez UAGRM

I. CICLO DE VIDA

3
Ing. Rolando Martínez UAGRM

4
 Ing. Rolando Martínez UAGRM

II. ACTIVIDADES DE DEFINICION INICIAL (R-1)

El objetivo principal del “Spint 0” es preparar el entorno y sentar las bases para el desarrollo del
proyecto en los siguientes Sprint y es conveniente realizarlo para: Proyectos complejos, Equipos
nuevos, Cambios tecnológicos significativos

Definiciones iniciales - Sprint 0 (opcional)

Id Tarea
a) Definir el equipo Scrum, multifuncional y auto gestionado
b) Definir el objetivo del producto
c) Identificar los requerimientos iniciales
d) Definir tiempo de duración de Sprint (ideal el mismo tiempo para todos de 2 a 4 semanas)
e) Definir infraestructura tecnológica (hardware y software) para la Gestión del
proyecto (Jira , Azure DevOps y similares ) como también para el proceso de
desarrollo del software
f) Definir patrón de desarrollo que definan actividades técnicas de desarrollo que
serán realizadas durante el sprint
g) Esbozar modelos inicial de: Contexto, de Datos y Arquitectura
h) Definición criterios de calidad
i) Generar el Product Backlog (artefacto) , ver ejemplo de formato F3

5
 Ing. Rolando Martínez UAGRM

III. ACTIVIDADES A REALIZAR EN CADA SPRINT

1) Evento  Tareas para realizar el Sprint Planning (R-2)

Tareas a realizar durante el Sprint Planning

Id Tarea
a) El Product Owner (PO) propone cómo el producto podría aumentar su valor y utilidad en
el Sprint actual explicando las Historias de Usuario (HU) candidatas a desarrollar durante
la ejecución del Sprint (usar las 3C Card, Conversation, Confirmation)
Comentario: Aquí acontece la actividad de análisis esencial para comprender los requerimientos,
por lo que si se ve conveniente y útil generar/actualizar el modelo de contexto (puede ser el diagrama
general de casos de uso) para tener una vista más abstracta de lo que proporciona las Historias de

Usuario
Ver ejemplo de formato para especificar historias de usuario F4
b) El equipo Scrum define objetivo del Sprint
c) Los desarrolladores estiman los Puntos de Historia de Usuario para cada HU para saber
con cuanto se pueden comprometer a completar en el Sprint (usar Planning Poker)
d) Los desarrolladores seleccionan las HU a desarrollar en el presente Sprint
e) Los desarrolladores definen la solución en términos de diseño esencial
a) Definir/Actualizar el diseño de la arquitectura de software
Modelos resultados sugeridos:
 Opción 1: Modelos en C4: Niveles 1, 2 y 3
 Opción 2: Modelos en UML: Diagrama de paquetes y Diagrama de despliegue
b) Definir/Actualizar el diseño de datos
Modelo resultado:
 Modelo conceptual: Diagrama de clases en UML

Comentario: Aquí acontece actividades diseño esencial para definir la solución y como será
implementado el software, también se puede detallar y/o actualizar el diseño durante la ejecución
del Sprint (R-3)

f) Generar el Sprint Backlog (artefacto), Ver formato ejemplo F5

6
 Ing. Rolando Martínez UAGRM

2) Evento  Actividades a realizar durante la ejecución del Sprint (R-3)

El propósito de la ejecución del Sprint es que el equipo de desarrollo trabaje en las tareas del
Sprint Backlog para cumplir con el objetivo del Sprint y entregar un incremento de software
potencialmente entregable. Durante esta fase, el equipo se enfoca en consolidar la solución,
implementar, probar y refinar las funcionalidades comprometidas, asegurando que se cumpla
con los criterios de calidad y esté listo para ser revisado en el Sprint Review.

2.a) Cada desarrollador selecciona desde el Sprint Backlog que tareas realizará

Ejemplo de tareas para el desarrollo en la iteración del Sprint para generar un incremento

Actividad Ejemplo de tareas

Continua e incremental enfocándose en lo necesario para cumplir la H.U.
a) Actualizar si corresponde el diseño de la arquitectura de software
b) Actualizar si corresponde el diseño de la base de datos
Diseñar la c) Diseñar reglas de la lógica de negocio (opcional)
Historia de Modelo opcional resultado:
Usuario o Realizar estos modelos solo si es necesario y conveniente: Diagrama de secuencia y/o Diagrama de
estados y/o Diagrama de tiempo
seleccionada
d) Diseñar las interfaces de usuario
o Definir y seguir un patrón de interfaces definidas/ajustar si fuera necesario

Implementar Continua e incremental

la Historia de a) Implementar Back-end (servicios APIs RESTful o GraphQL, otros)
Usuario b) Implementar Fronte-end (WEB/MOVIL)
seleccionada c) Generar consultas SQL o adoptar ORM para interactuar con la BD, Scripts de migración para
actualizar el esquema de la BD
d) Implementar operaciones CRUD, sistemas de autenticación, roles, permisos y otros

 Trabajar sobre ramas individuales para facilitar colaboración, versionamiento e integración para poner en
producción, usar repositorios de código (GitHub)
 Seguir estándares de codificación

Testear la Continua e incremental

Historia de a) Aplicar pruebas de unidad , caja negra y otras técnicas de prueba de acuerdo a la aplicación
Usuario b) Revisar criterios de aceptación definidos para cada Historia de usuario
seleccionada c) Considerar usar herramientas como: JUnit, Postman, JMeter, OWASP ZAP, Firebase Test
Lab y otras

7
Ing. Rolando Martínez UAGRM

2.b) Generación del incremento y despliegue

A la finalización de la ejecución del sprint se debe generar el incremento (artefacto)
correspondiente al sprint, integrando el incremento resultante a la anterior para asegurarse
que funcionan correctamente juntos, tomar en cuenta consideraciones siguientes:
 El incremento debe cumplir con el criterio de “Definition of Done” (DoD
 Asegurarse de que todas las ramas de código estén integradas en la rama principal (main
o master).
 Asegurarse de que el código siga las mejores prácticas de estilo y estándares del equipo.
 Preparar/monitorear el entorno de producción
 Considerar usar Contenedores (docker), automatizar el despliegue, uso de pipelines
CI/CD (integración continua/despliegue continuo). Ejem. GitHub Actions, Jenkins, GitLab

3) Evento  Scrum Diario (Daily Scrum)

Durante la ejecución del Sprint (evento R-3), el equipo debería reunirse durante unos 15
minutos para sincronizan sus actividades cada día y crean plan para las siguientes 24 horas

 Intervención de cada integrante del equipo para coordinación en base a:

• ¿Qué hice ayer para contribuir al Sprint?
• ¿Qué voy a hacer hoy para contribuir al Sprint?
• ¿Veo algún impedimento que impida lograr el objetivo del Sprint?
 Otras actividades opcionales sugeridas
• Actualizar el tablero tipo Kanban
• Actualizar gráfico de trabajo pendiente (Burndown charts)

8
Ing. Rolando Martínez UAGRM

4) Evento  Revisión de Sprint (R-4)

El propósito de la revisión del Sprint es inspeccionar el resultado del Sprint y determinar
futuras adaptaciones. El equipo de Scrum presenta los resultados de su trabajo a las partes
interesadas clave y se discute el progreso hacia el Objetivo de Producto. (Validación)
 El Dueño de Producto explica qué elementos del Product Backlog se han terminado en
cumplimiento con el objetivo definido para el sprint
 Los Desarrolladores presenta el incremento para facilitar la retroalimentación
 Recoger feedback de todos los invitados a la revisión
 Actualizar el Product Backlog marcando con “done” lo concluido y entre todos colaborar
para determinar qué podría ser lo siguiente a desarrollar.
 Revisión de cuál podría ser el valor en el siguiente incremento, según los cambios del
mercado.

Resultado: Al finalizar el Sprint Review, el equipo Scrum tendrá un Product Backlog revisado
y actualizado para el siguiente Sprint.

 (F1) Ejemplo de formato de revisión de sprint

Revisión de Sprint
Nombre del proyecto y numero de revisión:

Objetivo de la revisión:
[
Lugar, fecha, hora:
Participantes
Nombre Rol

Presentación del incremento

Función presentada Retroalimentación
[Elemento de trabajo a presentar] [Preguntas y comentarios]

Tareas completadas
[Marque los elementos de trabajo como "Terminado" que cumplieron con los criterios de aceptación. Para los
elementos que necesitan más trabajo, determine si pasarán al siguiente sprint o volverán a la Product Backlog]

Para lo que viene

[Agregar elementos de acción para actualizar el Product Backlog y futuros sprint en relación al entorno del negocio]

9
Ing. Rolando Martínez UAGRM

5) Evento  Retrospectiva de Sprint (R-5)

El propósito de la retrospectiva Sprint es planificar formas de aumentar la calidad y la eficacia
para ello el Equipo Scrum se inspecciona a sí mismo, reflexionan sobre forma de trabajo para
crear plan de mejoras para siguiente Sprint, inspeccionar cómo fue el Sprint en cuanto a
personas, interacciones, procesos, herramientas y su definición de “done” (Verificación)

¿Qué ha fallado y qué se puede mejorar?

 Recolectar información: Construir una imagen de lo que ha sido el Sprint, resultando una
imagen conjunta de equipo
 Generación de ideas: Identificar acciones que ayuden a mejorar el rendimiento del
equipo durante el siguiente Sprint
 Decidir qué hacer: Se proponen acciones que el equipo pueda implementar en el
próximo Sprint

 (F2) Ejemplo, de formato de retrospectiva sprint

Retrospectiva de Sprint
Nombre del proyecto y numero de retrospectiva:

Objetivos de la retrospectiva:

Lugar, Fecha y hora:

Participantes


Discusión

¿Que salió
bien?

¿Que no salió
bien?
Qué problemas se
encontró y cómo
esos problemas
fueron (o no
fueron) resueltos

¿Qué
debemos
cambiar para
mejorar?

10
 Ing. Rolando Martínez UAGRM

IV. OTROS EJEMPLOS DE FORMULARIOS

 (F3) Ejemplo de Formato de Product Backlog

Product Backlog
Proyecto
Product Owner
Versión Fecha
Nombre corto del Descripción del requerimiento funcional
id requerimiento usando <como> …. <quiero> … <para> Prioridad
Pb-1 Registrar de eventos Como organizador, quiero registrar eventos para realizar el Alta
seguimiento y control
Pb-2 Retirar dinero de cuenta Como cliente quiero retirar dinero de mi cuenta para
proceder a realizar pagos baja

11
 Ing. Rolando Martínez UAGRM

 (F4) Ejemplo de plantilla para especificar historia de usuario

Historia de usuario
Logo del proyecto
Id. Nombre corto de HU Prioridad PHU Estado

Como :
Quiero :
Para :
Criterios de Lista de condiciones que deben cumplirse para que la historia se considere terminada.
aceptación .
.
Conversación/Reglas (opcional)

Prototipo/Mockup (opcional)

Desarrollador

12
 Ing. Rolando Martínez UAGRM

 (F5) Ejemplo de formato para las tareas del Sprint Backlog

Sprint Backlog
Objetivo del Sprint:
Sprint numero : Tiempo programado :
Fecha de inicio del Sprint : Fecha de finalización del Sprint:
Id Tarea Estimación Responsable Estado
Sp-1 Instalar y configurar framework laravel 4hrs Juan En proceso
Sp-2 Diseñar formulario de registro de cliente 2 hrs Pedro Por hacer
Sp-3 Implementar API de registro de cliente 5 hrs Maria Por hacer

13