lOMoARcPSD|15300075

AA2EV01 Asignando roles y ciclos de vida

programacion uml (Universidad Nacional Abierta y a Distancia)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Hotel Lima (limahotel951@gmail.com)
 lOMoARcPSD|15300075

APLICACIÓN DEL MARCO DE TRABAJO SCRUM PARA PROYECTOS DE

DESARROLLO DE SOFTWARE

Estudio de caso, asignando roles y ciclo de vida

PRESENTADO POR:

JONATHAN JAVIER PRIETO TORRES – 1052395240

CARLOS ALBERTO HERNANDEZ ARCILA

TUTOR

SERVICIO NACIONAL DE APRENDIZAJE - SENA

APLICACIÓN DEL MARCO DE TRABAJO SCRUM PARA PROYECTOS DE DESARROLLO

DE SOFTWARE

2022

Downloaded by Hotel Lima (limahotel951@gmail.com)

 lOMoARcPSD|15300075

3.2.2. Actividad de aprendizaje AA2. Relacionar roles de usuarios, de acuerdo al ciclo de vida.

Evidencia AA2-EV01. Estudio de caso, asignación de roles y ciclos 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

En base a lo repasado y aprendido a lo largo del curso, además de los apoyos académicos presentes

para esta etapa del proceso formativo, 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:

Roles

• (01) Product Owner (PO) o dueño del proyecto.

• (02) Scrum Master (SM) o mentores, cada (SM) motivará y tendrá en constante evaluación el
desarrollo presentado por tres integrantes del (DT).
• (01) Development Team (DT), integrado por seis funcionarios que darán cumplimiento al
desarrollo del proyecto.
• Stakeholder: Rector <Colegio Formación del Mañana=

Downloaded by Hotel Lima (limahotel951@gmail.com)

 lOMoARcPSD|15300075

Ciclo de vida SCRUM

Una vez asignado a cada uno de los integrantes del equipo Scrum el rol a ejercer y de realizar la

respectiva priorización de las historias de usuario del Product Backlog como se identificó en la

actividad anterior, se procede a dar inicio con el ciclo de vida Scrum del proyecto tomando como eje

el enfoque de importancia ya establecido, a fin de poder ir desarrollando uno a uno los requerimientos

y seguir a los siguientes hasta obtener la satisfacción del cliente, siguiendo los pasos que presentare

a continuación:

1. Tomando como referencia la actividad anterior, sabemos que existe ya una necesidad por parte

del cliente o stakeholder (Rector <Colegio Formación del Mañana=) que corresponde al

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:

• R1: Permitir la matrícula del estudiante al técnico elegido.

• R2: Permitir la cancelación de matrícula del estudiante.
• R3: Mostrar el estudiante en el técnico matriculado.
• R4: Mostrar las materias o pénsum académico del técnico elegido.
• R5: Mostrar los horarios para los técnicos.
• R6: Corresponder las materias con los horarios de los técnicos.
• R7: Permitir certificar el semestre al estudiante cuando cumpla con la aprobación de las
materias.
• R8: Permitir certificar al estudiante cuando termine de aprobar todos los semestres.

2. Con dicha información del paso anterior, se procede a realizar, ordenar, priorizar y

documentar los requerimientos por parte de nuestro (PO) y en apoyo del equipo Scrum, a fin de

lograr realizar las historias de usuario y ser presentado el respectivo (PB).

Downloaded by Hotel Lima (limahotel951@gmail.com)

 lOMoARcPSD|15300075

3. 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).

4. Al presentarse el (PB) se hace una reunión con el equipo Scrum y se determina si todos están de

acuerdo con lo que allí se menciona, si tienen sugerencias de cambio. En caso de ser necesario se

documentan las sugerencias a modificar y el (PO) nuevamente se entrevista con el Stakeholder

para darle a conocer dichas peticiones, una vez hay acuerdo se realiza la respectiva configuración

del Product Backlog y nuevamente se presenta para revisión.

5. Apenas es presentado y aceptado el Product Backlog (PB) al equipo Scrum por parte de nuestro

Product Owner (PO), se da inicio a sesión de reuniones diarias o Daily Meetings. En esta primera

reunión, se da aplicación al artefacto del proyecto denominado Sprint Backlog (SB), en la cual

el (PO) distribuye el personal en dos grupos de trabajo (G1 – G2), cada uno de ellos conformados

por un Scrum Master (SM) y tres integrantes del Development Team (DT), que trabajaran

mediante uso de sistemas de control de versiones Git para trabajar por separado y así conservar

la integridad del código fuente.

• El (G1) se encargará de desarrollar el (R1) definido en el (PB).

• El (G2) se encargará de desarrollar el (R2) definido en el (PB).

En la segunda reunión, se exige por parte del (PO) la presentación de un plan de trabajo del (DT)

a fin de establecer metas y responsabilidades de entrega del producto como estrategia del (SB), y

a partir de ello se continuará realizando diariamente las respectivas reuniones para evidenciar los

Downloaded by Hotel Lima (limahotel951@gmail.com)

 lOMoARcPSD|15300075

avances y el cumplimiento de este plan por parte del (DT), lo anterior se ejecutará hasta lograr el

desarrollo satisfactorio de los requerimientos del (PB).

6. A lo largo del desarrollo de las actividades y de las Daily Meetings, para ir mostrando

gráficamente el desarrollo del proyecto corresponde a cada uno de los (SM) dar aplicación de un

artefacto de proyecto denominado Graphs, en el cual permitirá visualizar el trabajo realizado

hasta el momento y el que falta para finalizar por parte de cada grupo de trabajo del (DT), para si

es el caso replantear el método de trabajo y dar cumplimiento a los compromisos adquiridos

dentro del Sprint Backlog.

7. En caso de presentarse dentro de cualquier grupo del (DT) situaciones que dificulten el desarrollo

satisfactorio de los requerimientos, este deberá documentarlo y presentarlo dando aplicación del

artefacto de sprint denominado Incidence Backlog para que el (SM) encargado del grupo

haciendo uso de sus habilidades logre soluciones para cumplir con los compromisos pactados y

entregar el proyecto a tiempo, este dando aplicación al artefacto de proyecto denominado

Impediments Backlogs (IB).

8. Basado en la presentación del artefacto de proyecto denominado Impediments Backlogs (IB) por

parte del (SM), se diseñan estrategias visuales para poder conocer en tiempo real el avance del

proyecto una de ellas es la aplicación del artefacto del sprint denominado Scrum Board, en el

cual puede conocerse la situación actual del equipo Scrum en base al desarrollo del proyecto.

9. Es de anotar que antes de finalizar el presente sprint correspondiente al desarrollo de los

requerimientos del proyecto, no deben quedar tareas pendientes y para ello se da aplicación a un

artefacto del sprint denominado Parking Backlog en el cual se plasmaran los problemas

Downloaded by Hotel Lima (limahotel951@gmail.com)

 lOMoARcPSD|15300075

encontrados durante el desarrollo, dando claridad que al terminar la solución de estos

requerimientos, dicha lista debe quedar vacía.

10. Finalización del sprint: Una vez verificado que los requerimientos cumplen con las necesidades

del stakeholder (Rector <Colegio Formación del Mañana=), además de hacer las respectivas

evaluaciones de funcionalidad por parte del (DT), se programa una reunión e invita al stakeholder

para que revise los resultados de desarrollo y apruebe o no el producto, cualquiera que sea la

opinión del cliente (Aprueba – No aprueba) se da por finalizada la reunión.

11. Tan pronto finaliza la reunión, son tenidas en cuenta dichas recomendaciones y/o correcciones

dadas por el Stakeholder durante la finalización del sprint, y el equipo Scrum inicia un Scrum

Retrospective previo a una reunión con el fin de encontrar soluciones inmediatas a las falencias

presentes en el desarrollo, de la mejor manera y en el menor tiempo posible.

Se da inicio a una nueva reunión entre el equipo Scrum y el Stakeholder, para mostrar las

correcciones y validar el cumplimiento del desarrollo echo en los requerimientos, en caso de no

haber opiniones de cambio se pasa inmediatamente al desarrollo de los siguientes de

requerimientos.

12. Finalizado el primer sprint correspondiente al desarrollo de R1 y R2, se da inicio a un nuevo ciclo

asignando responsabilidad al equipo Scrum, de la siguiente forma:

• El (G1) se encargará de desarrollar el (R3) definido en el (PB).

• El (G2) se encargará de desarrollar el (R4) definido en el (PB).

Downloaded by Hotel Lima (limahotel951@gmail.com)

 lOMoARcPSD|15300075

13. Para el desarrollo de los requerimientos asignados para este segundo sprint, deberán repetirse los
pasos presentados anteriormente en lo numerales (5 al 11) las veces que se necesario, hasta
finalizar la reunión del sprint sin ninguna sugerencia de cambio.

14. Finalizado el segundo sprint correspondiente al desarrollo de R3 y R4, se da inicio a un nuevo

ciclo asignando responsabilidad al equipo Scrum, de la siguiente forma:

• El (G1) se encargará de desarrollar el (R5) definido en el (PB).

• El (G2) se encargará de desarrollar el (R6) definido en el (PB).

15. Para el desarrollo de los requerimientos asignados para este tercer sprint, deberán repetirse los
pasos presentados anteriormente en lo numerales (5 al 11) las veces que se necesario, hasta
finalizar la reunión del sprint sin ninguna sugerencia de cambio.

16. Finalizado el tercer sprint correspondiente al desarrollo de R3 y R4, se da inicio a un nuevo ciclo

asignando responsabilidad al equipo Scrum, de la siguiente forma:

• El (G1) se encargará de desarrollar el (R7) definido en el (PB).

• El (G2) se encargará de desarrollar el (R8) definido en el (PB).

17. Para el desarrollo de los requerimientos asignados para este cuarto sprint, deberán repetirse los
pasos presentados anteriormente en lo numerales (5 al 11) las veces que se necesario, hasta
finalizar la reunión del sprint sin ninguna sugerencia de cambio.

18. Finalmente, se programa una nueva reunión entre el Stakeholder y el equipo Scrum, donde se

muestra el resultado del producto final, desarrollo y utilidad satisfactoria, siendo entregado al

dueño de la necesidad (Rector <Colegio Formación del Mañana=) y poder implementarlo en la

institución educativa.

Downloaded by Hotel Lima (limahotel951@gmail.com)