Evidencia AA2-EV01.
Estudio de caso, asignando roles y ciclo de vida
Liliana Aragón Delgado
Curso:
Aplicación del marco de trabajo Scrum para proyectos de desarrollo de software
SENA
2025
Evidencia AA2-EV01. Estudio de caso, asignando roles y ciclo de vida
Teniendo en cuenta el estudio de caso anterior y lo desarrollado en dicha evidencia
(Informe de historias de usuario que representan los requerimientos del cliente. AA1-
EV01) realice un documento con la asignación de roles y ciclo de vida, con las siguientes
características:
✔ Imaginar un equipo de desarrollo.
✔ Describir y relacionar según el estudio de caso, el ciclo de vida, describiendo cómo
aplicaría los roles y artefactos del proyecto y del sprint.
SOLUCIÓN
Según lo estudiado es válido afirmar que un equipo scrum para obtener mejores
resultados debe estar conformado por un número corto de funcionarios, a fin de poder
distribuir el trabajo equitativamente, comprometer a los involucrados y dar soluciones
inmediatas a las interrogantes que se vengan presentando a lo largo del desarrollo del
proyecto. De tal manera distribuiría mi equipo scrum de la siguiente manera:
equipo de desarrollo está conformado por un Product Owner, el Scrum Master, y 4
desarrolladores.
1 producto Owner
1 Scrum master
2 a 3 Development Team (Dt2 QA junior o Analista)
Stakeholder: Rector “Colegio Formación del Mañana”
En el cual cada una de esta persona asume diferentes responsabilidades y tareas.
Producto Owner (PO) – Es la persona encargada de hacer que su equipo de scrum
aporte valor al negocio, aparte que es la única persona que tiene contacto directamente
con el cliente y sabe las características o los requerimientos que el cliente quiere.
Scrum Máster (SM) Es el encargo de liderar el equipo, el scrum master dirige a su equipo
para que pueda cumplir con el objetivo en el tiempo estimado, así mismo si hay un
problema con el proyecto ayudando a resolver para que se pueda continuar con el
proyecto.
Development Team (DT) Es la base principal ya que los desarrolladores diseño y ejecuta
la aplicación o la página web que se está solicitado teniendo en cuenta todos los
requerimientos, cabe resaltar que cada desarrollador tiene tareas y actividades diferente
que se debe cumplir y rendir cuentas frente a la organización.
Stakeholder: Rector “Colegio Formación del Mañana”: son agentes implicados, de
una u otra forma -tanto positiva como negativa- en las acciones que se llevan a cabo en
una entidad
CICLO DE VIDA DEL PROYECTO
En este espacio se evidenciarán el marco de trabajo scrum donde se aplicarán los
roles y artefactos del sprint.
1 Inicio del proyecto
Visión del producto:
Desarrollo de un Sistema de Información que permita registrar los estudiantes de cinco
cursos técnicos de formación, jornadas diurna y nocturna de dicha institución educativa;
de igual manera que se llevó a cabo una reunión con nuestro (PO), y que de ella se
definieron los siguientes requerimientos:
Creación del producto backlong:
Se realizarán las historias de usuario de acuerdo a los requerimientos que el cliente pidió:
HU01: Permitir la matrícula del estudiante al técnico elegido.
HU04: Mostrar las materias o pénsum académico del técnico elegido.
HU06: Corresponder las materias con los horarios de los técnicos.
HU05: Mostrar los horarios para los técnicos.
HU03: Mostrar el estudiante en el técnico matriculado.
HU07: Permitir certificar el semestre al estudiante cuando cumpla con la
aprobación de las materias
HU08: Permitir certificar al estudiante cuando termine de aprobar todos los
semestres.
HU02: Permitir la cancelación de matrícula del estudiante
2 Planificación del sprint
Al comienzo de cada sprint, el equipo de desarrollo se reunirá con el Product Owner para
revisar y seleccionar las historias de usuario del Product Backlog para el sprint actual. Las
historias de usuario seleccionadas se desglosan en tareas más pequeñas y se estimaron
en términos de esfuerzo necesario.
3 Ejecución del sprint
Luego de realizar la respectiva priorización y detalle de cada uno de los requerimientos
definidos entre el cliente (Rector Colegio Formación del Mañana) y nuestro (PO), se da
inicio a la aplicación de los artefactos del proyecto basado en las historias de usuario,
donde el (PO) se concentrará en presentar de manera inmediata, detallada, clara, corta y
concisa al equipo Scrum, el resultado del Product Backlog (PB)
El equipo de desarrollo se reunirá diariamente en una reunión de sincronización de 15
minutos (Daily Scrum). Durante esta reunión, cada miembro del equipo compartirá su
progreso, lo que hicieron el día anterior, lo que planean hacer hoy y si tienen algún
impedimento. El Scrum Master facilitará esta reunión para mantenerla enfocada y
eficiente.
4 Revisión del sprint
Sprint review
Al final del sprint, se llevará a cabo una reunión de revisión del sprint. El equipo de
desarrollo presentará el incremento del producto completado durante el sprint al Product
Owner y a otras partes interesadas. Se demostrarán las funcionalidades implementadas y
se recopilarán comentarios para futuras iteraciones.
5 Retrospectiva del sprint
Sprint retrospective
Después de la reunión de revisión del sprint, el equipo de desarrollo se reunirá en una
retrospectiva del sprint. Durante esta reunión, el equipo reflexionará sobre el sprint
anterior, identificará lo que funcionó bien y las áreas de mejora. Se discutirán acciones
concretas para mejorar el proceso y la colaboración en futuros sprints.
Artefactos del proyecto y del sprint
Product Backlog
El Product Owner será responsable de mantener el Product Backlog, que contendrá todas
las historias de usuario priorizadas. Las historias de usuario se estimaron en puntos de
historia para ayudar a planificar los sprints.
HU01: Permitir la matrícula del estudiante al técnico elegido.
HU04: Mostrar las materias o pénsum académico del técnico elegido.
HU06: Corresponder las materias con los horarios de los técnicos.
HU05: Mostrar los horarios para los técnicos.
HU03: Mostrar el estudiante en el técnico matriculado.
HU07: Permitir certificar el semestre al estudiante cuando cumpla con la
aprobación de las materias.
HU08: Permitir certificar al estudiante cuando termine de aprobar todos los
semestres.
HU02: Permitir la cancelación de matrícula del estudiante
3
Sprint Backlog
Al comienzo de cada sprint, el equipo de desarrollo seleccionará una cantidad adecuada
de historias de usuario del Product Backlog y las colocará en el Sprint Backlog. El Sprint
Backlog contendrá las historias de usuario que se abordarán en el sprint actual y se
dividirá en tareas más pequeñas si es necesario.
Sprint 1:
HU01: Permitir la matrícula del estudiante al técnico elegido
Desarrollar la interfaz de matrícula.
Implementar lógica de validación y almacenamiento de matrícula.
HU04: Mostrar las materias o pénsum académico del técnico elegido
Diseñar y desarrollar pantalla de visualización del pénsum académico.
Conectar con la base de datos para obtener la información del pensum.
HU06: Corresponder las materias con los horarios de los técnicos
Desarrollar algoritmos para asignar horarios a las materias.
Implementar lógica de vinculación de horarios con las materias.
Sprint 2:
HU05: Mostrar los horarios para los técnicos
Diseñar y desarrollar pantalla de visualización de horarios.
Obtener información de los horarios desde la base de datos.
HU03: Mostrar el estudiante en el técnico matriculado
Implementar funcionalidad para listar estudiantes matriculados en un técnico. Desarrollar
búsqueda y filtrado de estudiantes por técnico.
HU07: Permitir certificar el semestre al estudiante cuando cumpla con la aprobación
de las materias
Implementar lógica de seguimiento de aprobación de materias por estudiante.
Sprint 3:
HU08: Permitir certificar al estudiante cuando termine de aprobar todos los
semestres
Implementar lógica para verificar la aprobación de todos los semestres.
Desarrollar el proceso de certificación final para los estudiantes que cumplan con los
requisitos.
HU02: Permitir la cancelación de matrícula del estudiante
Diseñar y desarrollar interfaz para cancelar la matrícula de un estudiante. Implementar
lógica de cancelación y actualización de la base de datos.
Incremento: Al final de cada sprint, el equipo de desarrollo entregará un incremento del
producto. Este incremento debe ser potencialmente entregable y debe incluir la
funcionalidad completa y probada de las historias de usuario seleccionadas para ese
sprint.
