Título

Nombres

Corporación universitaria Remington

Ingeniería de software

10/02/2023
 índice

Capítulo 1. Introduccíon ………………………………………………………………….3

Capítulo 2. Objetivos………………………………………………………………………. 4

Capítulo 3. Marco teórico ………………………………………………………………..4

3.1 SEMAT ………………………………………………………………………………………………………………5

3.1 SCRUM ……………………………………………………………………………………………………………...5

3.1.1 Bases del trabajo en SCRUM ………………………………………………………… 5

3.1.1 Roles ……………………………………………………………………………………………. 5

3.1.1 Los eventos del equipo Scrum ……………………………………………………… 6

3.1.1 Sprint Planning ……………………………………………………………………………. 7

3.1.1 Daily Meeting ……………………………………………………………………………… 7

3.1.1 Sprint Review ……………………………………………………………………………… 8

3.1.1 Sprint Restrospective…………………………………………………………………… 8

3.1.1 Grooming ……………………………………………………………………………………. 8

3.1.1 Los artefactos SCRUM…………………………………………………………………. 8

Capítulo 3. Modelamiento ……………………………………………………………… 11

Capítulo 3. Conclusiones ..……………………………………………………………… 13

Capítulo 3. Referencias …..……………………………………………………………….13

 Introducción
Mediante el siguiente proyecto, dejaremos claro el proceso llevado acabo para desarrollar
software a través de la metodología SCRUM, siendo claros con sus etapas, manera de usar
y ventajas de dicho método, teniendo en cuenta la necesidad de la industria del software
por gestionar de manera óptima requerimientos y, de la misma manera, suplirlos.
Empecemos por una pequeña definición y contextualización histórica de SCRUM.
SCRUM es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente en equipo y obtener el mejor resultado posible
de un proyecto. El concepto de SCRUM tiene su origen en un estudio de 1986 sobre los
nuevos procesos de desarrollo utilizados en productos exitosos en Japón y los Estados
Unidos; en el año de 1993 se realizó el primer SCRUM para desarrollo de un producto de
software, 2 años más tarde esta metodología ya estaba normalizada.
En 2001 un grupo de personas muy importantes, en lo que empezaba a ser el desarrollo
ágil, escribieron los valores fundamentales de los procesos ágiles, aquí algunos ejemplos y
sectores de quienes usan SCRUM
 Objetivos:
1. Conocer la metodología ágil SCRUM, como funciona y su implementación en
proyectos reales
2. Entender el uso de SCRUM en la industria del desarrollo de software a en equipos
tanto grandes como pequeños
3. Modelar la metodología y dar ejemplos de quienes la implementan en grandes escalas, así
como también sus ventajas y desventajas

Marco teórico
SEMAT: Es una iniciativa tomada por Ivar Jacobson, Pan-Wei Ng, Paul E.McMahon, Ian
Spence y Svante Lidman que busca redefinir la ingeniería de software por medio de que
los autores consideran como ”la esencia de la ingeniería de software: El núcleo de SEMAT”
Busca dicha redefinición basándose en una teoría sólida, principios probados y las mejores
prácticas aplicables a los proyectos de software, de manera que:

• Se incluya un núcleo (Kernel) de elementos ampliamente aceptados y que se

pueden extender a usos específicos
• Traten asuntos tecnológicos y humanos
• Los apoyen la industria, la academia, los investigadores y los usuarios
• Apoyen la extensión ante los requisitos cambiantes y la tecnología
SEMAT se base y enfoca principalmente en 2 objetivos independientes entre si:
1. Encontrar un Kernel de elementos ampliamente aceptados
2. Definición de una base teórica sólida
SCRUM
Los 12 principios del manifiesto ágil:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y
continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses,

con preferencia al periodo de tiempo más corto posible.
 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el

entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de

desarrollo y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante
de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos

autoorganizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.

Bases del trabajo en SCRUM: Al estar enmarcada dentro de las metodologías agiles,
Scrum se basa en aspectos como:
• La flexibilidad en la adopción de cambios y nuevos requisitos durante un
proyecto complejo.

• El factor humano.

• La colaboración e interacción con el cliente.

• El desarrollo iterativo como forma de asegurar buenos resultados.

Roles: el equipo tiene como foco entregar valor y ofrecer resultados de calidad que
permitan cumplir los objetivos de negocio del cliente.

Para ello, los equipos de Scrum son autoorganizados y multifuncionales. Es decir, cada uno
es responsable de unas tareas determinadas y de terminarlas en los tiempos acordados.
Esto garantiza la entrega de valor del equipo completo, sin necesidad de ayuda o la
supervisión minuciosa de otros miembros de la organización.

A continuación, desglosamos los 3 roles más importantes en un equipo de trabajo Scrum.

Product owner:
Es el responsable de maximizar el valor del trabajo, que viene de la mano de una buena
gestión del Product Backlog, el cual explicaremos más adelante.

El Product Owner es el único perfil que habla constantemente con el cliente, lo que le
obliga a tener muchos conocimientos sobre el negocio.

Para finalizar, un equipo Scrum debe tener solo un Product Owner y este puede ser parte
del equipo de desarrollo.

Scrum Master
Es el responsable de que las técnicas Scrum sean comprendidas y aplicadas en la
organización. Es el manager de Scrum, un líder que se encarga de eliminar impedimentos
o inconvenientes que tenga el equipo dentro de un sprint (que ya revisaremos en detalle
más adelante), aplicando las mejores técnicas para fortalecer el equipo de marketing
digital.

Dentro de la organización, el Scrum Master tiene la labor de ayudar en la adopción del

framework en todos los equipos.

Equipo de desarrollo
Son los encargados de realizar las tareas priorizadas por el Product Owner. Es un equipo
multifuncional y autoorganizado. Son los únicos que estiman las tareas del product
backlog, sin dejarse influenciar por nadie.

Los equipos de desarrollo no tienen sub-equipos o especialistas. La finalidad de esto es

transmitir la responsabilidad compartida si no se llegan a realizar todas las tareas de un
sprint.

Los eventos del equipo Scrum

En la tabla anterior reflejamos las diferentes ceremonias Scrum y su peso en horas según
se avanza en semanas de trabajo. El desarrollo iterativo se realiza en un sprint que
contiene los siguientes eventos Scrum: Sprint Planning, Daily Meeting, Sprint Review,
Sprint Retrospective y Grooming.

Antes de profundizar en los diferentes eventos, es importante definir qué es un sprint en

Scrum. El sprint es el corazón de este marco de trabajo, el contenedor de los demás hitos
del proceso. Todo lo que ocurre en una iteración para entregar valor está dentro de un
sprint. La duración máxima es de un mes, el tiempo se determina en base al nivel de
comunicación que el cliente quiere tener con el equipo. Los sprints largos pueden hacer
que se pierda feedback valioso del cliente y poner en peligro el proyecto.

Sprint Planning

En esta reunión todo el equipo Scrum define qué tareas se van a abordar y cuál será el
objetivo del sprint. La primera reunión que se hace en el sprint puede llegar a tener una
duración de 8 horas para sprints de un mes.

El equipo se hace las siguientes preguntas:

• ¿Qué se va a hacer en el sprint? En base a ello, se eligen tareas del Product

Backlog.

• ¿Cómo lo vamos a hacer? El equipo de desarrollo define las tareas

necesarias para completar cada ítem elegido del Product Backlog.

La definición de qué se va a hacer implica que el equipo tenga un objetivo y se encuentre

comprometido con la entrega de valor que se hará al cliente al final del sprint. A esto se le
llama Sprint Goal.

El resultado de esta reunión es el Sprint Goal y un Sprint Backlog (que revisaremos más
adelante).

Daily Meeting

Es una reunión diaria dentro del sprint que tiene como máximo 15 minutos de duración.
En ella deben participar, sí o sí, el equipo de desarrollo y el Scrum Master. El Product
Owner no tiene la necesidad de estar presente.

En esta reunión diaria el equipo de desarrollo hace las siguientes 3 preguntas:

• ¿Qué hice ayer?

• ¿Qué voy a hacer hoy?

• ¿Tengo algún impedimento que necesito que me solucionen?

Una Daily Scrum es el lugar más oportuno para poder inspeccionar el trabajo y poder
adaptarse en caso de que haya cambio de tareas dentro de un sprint.

Sprint Review

La review del valor que vamos a entregar al cliente se hace en esta reunión, al final de
cada sprint. Su duración es de 4 horas para sprints de un mes y es la única reunión de
Scrum a la que puede asistir el cliente.

En esta reunión el Product Owner presenta lo desarrollado al cliente y el equipo de

desarrollo muestra su funcionamiento. El cliente valida los cambios realizados y además
brinda feedback sobre nuevas tareas que el Product Owner tendrá que agregar al Product
Backlog.

Sprint Restrospective

La retrospectiva es el último evento de Scrum, tiene una duración de 3 horas para sprints
de un mes, y es la reunión del equipo en la que se hace una evaluación de cómo se ha
implementado el framework Scrum en el último sprint.

Es una gran oportunidad para el equipo Scrum de inspeccionarse a sí mismo, proponiendo

mejoras para el siguiente sprint. El resultado es una lista de mejoras que debe aplicar el
siguiente día, ya que al finalizar la retrospectiva, inmediatamente comienza un nuevo
sprint, que incluye los mismos eventos mencionados anteriormente.

Grooming

El Grooming en Scrum es el tiempo de revisión que se dedica dentro de los equipos

durante los sprints para refinar los requerimientos. Es una reunión que no debe ocupar
más del 10% del tiempo disponible del sprint. Las tareas de usuario se revisan con un par
de sprints de ventaja para que cuando llegue el equipo ya esté todo listo para el desarrollo
de la tarea.

Los artefactos SCRUM: Los eventos y artefactos de Scrum están definidos para maximizar
la transparencia dentro del equipo; es decir, que todos tengan una misma visión de lo que
está ocurriendo en el proyecto.

Si te preguntas qué son los artefactos Scrum, a continuación, explicamos los 3 clave:
Product Backlog, Sprint Backlog e Incremento.

1. Product Backlog: Básicamente Product Backlog es el listado de tareas que engloba

todo un proyecto. Cualquier cosa que debamos hacer debe estar en el Product
Backlog y con un tiempo estimado por el equipo de desarrollo.
La responsabilidad exclusiva de ordenar el Product Backlog es del Product Owner,
que se encuentra en constante comunicación con el cliente para asegurarse de que
las prioridades están bien establecidas.
 La ordenación también es 100% responsabilidad del Product Owner, por lo que las
tareas que están más arriba deben de ser las de mayor prioridad. El equipo de
desarrollo elige tareas del Product Backlog en el Sprint Planning para generar tanto
el Sprint Backlog como el Sprint Goal.

2. Sprint Backlog: Es el grupo de tareas del Product Backlog que el equipo de

desarrollo elige en el Sprint Planning junto con el plan para poder desarrollarlas.
Debe ser conocido por todo el equipo, para asegurarse de que el foco debe estar
en este grupo de tareas.
El Sprint Planning no cambia durante el sprint, solo se permite cambiar el plan para
poder desarrollarlas.

3. Incremento: El Product Increment o incremento de Scrum es el resultado de sumar

todos los elementos del Product Backlog completados durante el sprint actual,
añadiendo también el valor de todos los sprints anteriores.
La suma de los incrementos se presenta en cada Sprint Review, y se pueden crear
varios incrementos de Scrum dentro de un mismo sprint
Ventajas y desventajas:

Ventajas:

• Scrum es muy fácil de aprender: los roles, hitos y artefactos son claros y tienen un
objetivo, por lo que es un método muy relacionado con nuestra manera diaria de
trabajar.

• El cliente puede comenzar a usar el producto rápidamente.

• Se agiliza el proceso, ya que la entrega de valor es muy frecuente.

• Menor probabilidad de sorpresas o imprevistos, porque el cliente está viendo

frecuentemente el proyecto.

Desventajas:

• Aunque Scrum sea fácil de aprender, es muy difícil implementarlo. Esto supone
una predisposición y un cambio de cultura de la organización que debe ir desde los
altos mandos hasta los clientes.

• La necesidad de tener equipos multidisciplinares puede ser un problema, ya que es

difícil encontrar personas que sean capaces de hacer todo el trabajo de un equipo.
 • El equipo puede tender a realizar el camino más corto para conseguir el objetivo
de un sprint, el cual no siempre ofrece resultados de calidad.

Modelamiento

Aplicaremos SEMAT para el uso de la metodología ágil de SCRUM, así:

Requisito Identifica
Cliente

Cliente

Emplea y adapta
Se enfoca en
Creado para tratar

Apoya a
Solución

Historia Usuario satisface Aplicación

Produce
delimitan

Proyecto Ejecuta y planea

Equipo
Esfuerzo

Iteraciones
Tarjetas para los requerimientos completados:
 Conclusiones

• Por medio del trabajo expuesto anteriormente entendimos y conocimos de

manera óptima la metodología SCRUM, así como también el funcionamiento de
esta y SEMAT.
• La metodología ágil SCRUM es eficiente y es de provecho para equipos de
desarrollo complejos y también pequeños, dando herramientas y permitiéndonos
avanzar como conjunto en un proyecto específico

Referencias

Sundararajan, M. (2012). Traditional SDLC Vs Scrum Methodology - A Comparative

Study. University, Avadi , India.

https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=774082

9e70c028a75780d3b7bd034345beb940c4

Vanegas, C. E. D., & Jaramillo, C. (2015). Una representación basada en Semat y RUP

para el Método de Desarrollo SIG del Instituto Geográfico Agustín Codazzi.

Ingenierías USBMed, 6(1), 24-37. https://doi.org/10.21500/20275846.1721

Camacho Vitt, W. A. (2014). Incorporando SEMAT en un una metodología Ágil, para

equipos distribuidos. Universidad Nacional de Colombia.

https://www.researchgate.net/publication/299483164_Incorporando_SEMAT_en_u

n_una_metodologia_Agil_para_equipos_distribuidos