UNIVERSIDAD DE COSTA RICA

Sede del Sur

Informática Empresarial – ingeniería del Software (IF-7100)
Josep Fernández Ortega (B82923)
MSc José Pablo Noguera Espinoza

Agile Scrum Deep Dive

Esta metodología fue desarrollada por Ken Schwaber y Jeff Sutherland. La piedra angular
de Scrum se describe en la Guía oficial de Scrum.

El enfoque de Scrum es dividir el proyecto en fragmentos lógicos más pequeños (mini

proyectos) y ejecutarlos en iteraciones cortas de idealmente una a tres semanas. Esas
iteraciones se llaman Sprints

Entonces, en lugar de correr un maratón largo hacia un destino imaginario como se hace en
Waterfall, se divide la distancia en Sprints cortos con una línea de meta visible. Cuanto más
corta sea la duración del Sprint, más visible será el final y más fácil será planificar y
predecir el resultado y decidir a dónde continuar.

Es más fácil detectar "errores" cuando el equipo está codificando el material incorrecto,
asumiendo que se tiene comentarios regulares del cliente (o su PO proxy) para decir qué
entregó mal el equipo, por ejemplo, debido a requisitos de software incompletos.

Al hacerlo, logramos muchas ventajas frente al modelo Waterfall.

A - Mejora continua
B - Transparencia
C - Adopción anticipada
D - Adopción del cambio
El equipo Scrum

La metodología Agile Scrum implica un equipo autónomo y autogestionado. Por lo general,

hablamos de equipos de diez que incluirán los siguientes roles.

▪ Desarrolladores.
▪ Scrum Master.
▪ Product Owner.
▪ Arquitecto.
▪ Ingeniero de Calidad.
▪ Escritor Técnico (en algunos casos).

La composición del equipo se basa en la naturaleza del trabajo y la situación actual de su

organización. Sin embargo, la parte más importante es que el equipo será autónomo. Para
obtener los mejores resultados, debe adoptar el enfoque de dividir su empresa en sub-
empresas más pequeñas.

Cómo se divide el alcance

La convención de nomenclatura común en la metodología Scrum es: Épica ➤ Historia de

usuario ➤ Tarea

➢ Épico: algo que no tiene por qué encajar en un Sprint

➢ Historia: algo accionable y lo suficientemente pequeño como para caber en un
Sprint.
➢ Tareas: partes de una historia que puede completar un solo miembro del equipo.
Ciclo de Sprint y reuniones

Cada Sprint debe estar dedicado a la ejecución de ciertas historias de usuario.

Hay ciertas reuniones que generalmente se realizan durante una iteración de Sprint; por
supuesto, una reunión de Scrum que se ejecuta a diario y reuniones centrales a nivel de
Sprint: planificación, revisión, retrospectiva y preparación del backlog.

El equipo se compromete a completar esas historias de usuario de acuerdo con los criterios
de Terminado.
Definición de Terminado

Antes de que el equipo comience a implementar algo, tiene que llegar a un cierto acuerdo
sobre qué pasos deben ejecutarse para considerar el trabajo terminado. Por supuesto, es un
documento vivo y puede ser ajustado y modificado si así lo acuerdan las partes interesadas.
Es importante no inflar demasiado este documento porque, si hay demasiadas condiciones o
el documento es demasiado complejo, no funcionará. Cuanto menos, mejor.

Velocidad

Velocidad es la palabra mágica que es fundamental para cualquier gerente de proyecto. Hay
diferentes formas de ver la velocidad, pero ninguna es perfecta. Las siguientes son varias
posibilidades y posibles desafíos para cada uno de ellos.

▪ Puntos de la historia para medir la velocidad

▪ Velocidad en horas a nivel de tarea
▪ Velocidad de alto nivel por experto

Herramientas

Existen diferentes herramientas en el mercado para la gestión de proyectos además de la

pizarra con pegatinas. Por ejemplo: Jira, Trello, proyecto de Microsoft o incluso Excel.

Utilice las herramientas solo cuando simplifiquen el proceso y no lo hagan más complejo.

Para usar algo digital, una simple página wiki con estados y una pizarra con post-its puede
ser suficiente. Las herramientas sofisticadas no son algo que impulse el proceso; ¡Es
importante no convertirse en un sirviente de la herramienta!