Universidad Nacional Autónoma de

Honduras

Ingeniería en Sistemas
Ing. Néstor López Luque

Metodologías Ágiles

SCRUM
Problemas tradicionales en
los proyectos de software
Problemas tradicionales en
los proyectos de software
Probemos algo!!
Opciones
Que gestionamos?
Historia Scrum
¿Qué es Scrum?
En que proyectos
aplicarlo?
 Si trabajas en un sector en el que el nivel de
incertidumbre es alto.
 Los requerimientos son cambiantes.
 Existe buen grado de confianza con el cliente.
En que tipo de proyectos
¿Que hay en el
mercado?
¿Para qué lo están
usando?
Vista General de Scrum
Framework
Principios
Roles
 Es quien toma las decisiones del cliente. Su
responsabilidad es el valor del producto. Para simplificar
la comunicación y toma de decisiones es necesario que
este rol recaiga en una única persona.

 Determinar la visión del producto, hacia dónde va el

equipo de desarrollo.
Gestionar las expectativas de los stakeholders

Product


 Recolectar los requerimientos

Determinar y conocer en detalle las características

Owner

funcionales de alto y de bajo nivel
 Maximizar la rentabilidad del producto
 Determinar las prioridades de cada una de las
características por sobre el resto
 Aceptar/rechazar el producto construido durante el
Sprint y proveer feedback valioso para su evolución
 Participar de la revisión del Sprint junto a los
miembros del Equipo de Desarrollo para obtener
feedback de los stakeholders.

Universidad Nacional Autónoma de Honduras Ing Néstor

López Luque
 Es el responsable del cumplimiento de las reglas de
un marco de scrum técnico, asegurando que se
entienden en la organización, y se trabaja conforme
a ellas. Proporciona la asesoría y formación
necesaria al propietario del producto y al equipo.
 Velar por el correcto empleo y evolución de
Scrum
 Facilitar el uso de Scrum a medida que avanza el

Scrum tiempo. Esto incluye la responsabilidad de que

todos asistan a tiempo a las daily meetings,
reviews y retrospectivas

Master  Asegurar que el equipo de desarrollo sea

multifuncional y eficiente
 Proteger al equipo de desarrollo de distracciones
y trabas externas al proyecto
 Detectar, monitorear y facilitar la remoción de
los impedimentos que puedan surgir con
respecto al proyecto y a la metodología
 Asegurar la cooperación y comunicación dentro
del equipo

Universidad Nacional Autónoma de Honduras Ing Néstor

López Luque
 Lo forman el grupo de profesionales que realizan el
Equipo incremento de cada sprint. Se recomienda que un
equipo scrum tenga entre 3 y 8 personas. Más allá
de 8 resulta más difícil mantener la comunicación
de directa, y se manifiestan con más intensidad los
roces habituales de la dinámica de grupos.

Desarrollo  Todos conocen y comprenden la visión del

propietario del producto.
 Aportan y colaboran con el propietario del
producto en el desarrollo de la PB
 Todos los miembros participan en las decisiones.
 Se respetan las opiniones y aportes de todos.
Todos conocen el modelo de trabajo con
scrum.
Artefactos
  Entendimiento general
 Comprobación del producto con
el equipo
 Cierre de expectativas y alcance
general
Visión de
Producto PARA (cliente) QUIEN (necesidad) EL
(nombre del producto) ES UN (tipo
de producto) QUE (brinda esta razón
para comprarlo). A DIFERENCIA DE
(productos de la competencia),
NUESTRO PRODUCTO (factores
distintivos)

Universidad Nacional Autónoma de Honduras Ing Néstor

López Luque
Gestión
Product
Backlog
Product Backlog
Product Backlog
Product Backlog
Product
Backlog Item

Pueden ser construidos

de muchas formas
generalizadas, se
concentran en el
alcance y
fundamentalmente en
los criterios de
aceptación.
Product Backlog Item
Product
Backlog
Item
 Lista de tareas que va a realizar el
equipo en una iteración, para

Sprint construir un incremento:

•Descripción breve.

Backlog •Persona que la tiene asignada.

•Esfuerzo pendiente para
terminarla.

Universidad Nacional Autónoma de Honduras Ing Néstor

López Luque
 Condiciones
Sprint


 Realizada de forma conjunta por todos

los miembros del equipo.

Backlog  Cubre todas las tareas identificadas por

el equipo para conseguir el objetivo del
sprint.
 Sólo el equipo la puede modificar
durante el sprint.
 Las tareas demasiado grandes deben
descomponerse en otras más péquelas.
Se deben considerar “grandes” .las
tareas que necesitan más de un día
para realizarse.
 Es visible para todo el equipo.
Idealmente en un tablero o pared en el
mismo espacio físico donde trabaja el
equipo.
Sprint Backlog
Lista de
impedimentos
Incremento
 El gráfico de avance o “burndown” es el gráfico que
actualiza el equipo en las reuniones de seguimiento
del sprint, para monitorizar el ritmo de avance, y
detectar de forma temprana posibles desviaciones
sobre la previsión que pudieran comprometer la
entrega al final de sprint.

La estrategia ágil para el seguimiento de los

Burndown proyectos se basa en:

 Medir el esfuerzo que falta, no el realizado.

Chart  Realizar un seguimiento muy cercano (diario

de ser posible).

Este gráfico debe ser actualizado diariamente, y se

registra:
 En el eje Y se registra el trabajo que aún
falta por realizar.
 En el eje X se registran los días del sprint.

Universidad Nacional Autónoma de Honduras Ing Néstor

López Luque
Burndown
Chart
Burndown Chart
Burndown Chart
Burndown Chart
kanban
BurnUp

 El gráfico de
producto o gráfico
“burn up” es una
herramienta de
planificación propia
del product owner,
que presenta
visualmente la
evolución previsible
del producto.
BurnUp
ANÁLISIS DE BURNUP PARA TOMA DE DECISIONES SOBRE UN PROYECTO ÁGIL
Eventos
Sprint
Reunión de planificación de Sprint
Scrum
diario
Revisión del Sprint
Reunión realizada al final del sprint
para comprobar el incremento. No
debe durar más de 4 horas, en el
caso de revisar sprints largos.
Precondiciones
Se ha concluido el sprint.
Asiste todo el equipo de desarrollo, el propietario del producto, el
Scrum Master y todas las personas implicadas en el proyecto que lo
deseen.
Entradas
Incremento terminado.
Resultados
Feedback para el propietario del producto: hito de seguimiento de
la construcción del sistema, e información para mejorar el valor de
la visión del producto.
Convocatoria de la reunión del siguiente sprint.
 Nombre de la reunión en la que el
equipo analiza la forma de trabajo
para su mejora continua. Las reuniones
retrospectivas son por tanto un una
“meta-práctica” ágil.

Aunque es frecuente realizarlas al final

Retrospectiva de cada sprint, no deben confundirse
con las reuniones de revisión del sprint.
del Sprint
El objetivo de la revisión del sprint es
analizar “QUÉ” se está construyendo,
mientras que una reunión retrospectiva
se centra en “CÓMO” lo estamos
construyendo: “CÓMO” estamos
trabajando, con el objetivo de analizar
problemas y aspectos mejorables.

Universidad Nacional Autónoma de Honduras Ing Néstor

López Luque
Estrella de Mar
Barco
Sombreros
Estimaciones

Es una práctica ágil,

para conducir las
reuniones en las que se
estima el esfuerzo y la
duración de tareas.
James Grenning ideó
este juego de
planificación para
evitar discusiones
dilatadas que no
terminan de dar
conclusiones
concretas.
  Scrum puede minimizar los riesgos
y maximizar el éxito de un
proyecto cuando se existe
confianza con el cliente.
Conclusión  En los casos que se conoce muy
bien los requisitos Scrum no aporta
mucho al igual en los proyectos
con mucho caos

Universidad Nacional Autónoma de Honduras Ing Néstor

López Luque
¿Los sistemas que se desarrollan usando un enfoque
ágil se mantienen, a pesar del énfasis en el proceso de
desarrollo de minimizar la documentación formal?

Se estima que la documentación formal describe el sistema y, por lo

tanto, facilita la comprensión a quienes cambian el sistema. Sin
embargo, en la práctica, con frecuencia la documentación formal no se
conserva actualizada y, por ende, no refleja con precisión el código del
programa. Por esta razón, los apasionados de los métodos ágiles
argumentan que escribir esta documentación es una pérdida de tiempo
y que la clave para implementar software mantenible es producir un
código legible de alta calidad. De esta manera, las prácticas ágiles
enfatizan la importancia de escribir un código bien estructurado y
destinar el esfuerzo en mejorar el código. En consecuencia, la falta de
documentación no debe representar un problema para mantener los
sistemas desarrollados con el uso de un enfoque ágil
Según Ian Sommerville:
según su experiencia con el mantenimiento de sistemas, éste
sugiere que el documento clave es el documento de
requerimientos del sistema, el cual indica al ingeniero de
software lo que se supone que debe hacer el sistema. Sin tal
conocimiento, es difícil valorar el efecto de los cambios
propuestos al sistema. Varios métodos ágiles recopilan los
requerimientos de manera informal e incremental, aunque sin
crear un documento coherente de requerimientos. A este
respecto, es probable que el uso de métodos ágiles haga más
difícil y costoso el mantenimiento posterior del sistema.
Universidad Nacional Autónoma de Honduras Ing Néstor
López Luque