Breve introducción-presentación sobre metodologías ágiles y framework SCRUM. Se muestra en formato infográfico y breve. Agile: principios, valores, historia. SCRUM: introducción, artefactos, eventos, roles.

1. Agile Takers
Introducción a las metodologías ágiles
Digital Takers - Open Knowledge Database
http://www.dtakers.com 1

2. 2
Metodologías ágiles SCRUM
KANBAN
XP
LEAN
CRYSTAL
Cifras de los años 2015 y 2016.
▫ El 80% de las empresas de software usan metodologías
ágiles [1].
▫ El 50% de los equipos ágiles dicen combinar prácticas ágiles
y tradicionales [1].
▫ De las empresas “ágiles” el 58% elige SCRUM [2].
▫ El 84% de las empresas reportó un incremento de la
productividad con la adopción de metodologías ágiles [3].
ASD
FDD
DSDM

3. 3
Muchos conceptos de las metodologías ágiles datan de los años 80 y 90. Por ejemplo SCRUM se
aplicó por primera vez al software en 1993.
A finales de los años 90 se conocían como metodologías “lightweight” y sus detractores las
tachaban de “anti-metodologías”.
En el año 2001 el término “ágil” irrumpe en el mundo del desarrollo de software.
Un grupo de 17 expertos se reúne en Utah (E.E.U.U) . Fundan “The agile alliance” y redactan el
manifiesto ágil.
Basados en su experiencia y con el objetivo de conseguir equipos de alto rendimiento establecen 4
valores fundamentales que inspiran 12 principios.
Historia del agilismo

4. 4
Manifiesto ágil
Valores [4]
➔ Individuos e interacción
por encima de herramientas y procesos.
➔ Software que funciona
por encima de documentación.
➔ Colaboración con el cliente
más que negociación de contratos.
➔ Adaptarse a cambios
más que plan estricto.
Principios [4]
1. Satisfacer al cliente entregando software que aporte valor.
2. Dar la bienvenida a los cambios.
3. Entrega frecuente de software que funciona.
4. Negocio y desarrollo trabajan juntos.
5. Confiar en individuos motivados y bien equipados.
6. Comunicación efectiva (cara a cara).
7. La medida de progreso es el software que funciona.
8. Desarrollo sostenible.
9. Atención continua a calidad y diseño.
10. Simplicidad.
11. Auto organización.
12. Reflexión frecuente (feedback).

5. Gráfico comparativo de las distintas metodologías ágiles utilizadas en
el año 2016 [2]. 5
SCRUM
56 %
Híbridos
24%
¿Qué eligen las empresas?

6. 6
Introducción a SCRUM
Se inventa en 1986 y se aplica al mercado del desarrollo de software por primera vez en 1993.
Scrum es un framework ágil compuesto por un conjunto de buenas prácticas (realmente no es una
metodología en sí). Cada equipo puede adaptarlo a sus necesidades o utilizar las prácticas que
crean convenientes.
Los pilares de la teoría SCRUM: transparencia, inspección y adaptación.
Principales características: progresión iterativa, compromiso por parte de todos los implicados,
entrega continua de software y una serie de roles, artefactos y eventos (reuniones). Aumenta la
predictibilidad y el control de riesgos.
Está recomendado para proyectos susceptibles de cambios frecuentes o con un factor medio-alto
de incertidumbre.

7. 7
SCRUM framework
Artefactos
● Lista de tareas → Product Backlog
● Tareas por realizar → Sprint Backlog
● Reporte de progreso → Burndown chart
Product owner
Scrum Master
Desarrolladores
Colaboran, refinan, planifican.
Facilita y asesora Facilita, guía, ayuda
Reuniones
● Sprint planning meeting.
● Daily SCrum meeting.
● Sprint review.
● Sprint retrospective.
● Refinement meeting [5] (grooming).
Product backlog Sprint backlog
Limitaciones
❏ Equipo máximo de 7 miembros.
❏ Duración de sprint entre 1 y 4 semanas.
❏ Las tareas del sprint backlog no deben alterarse durante el sprint.
SCRUM fomenta:
❏ Que los individuos hagan todo tipo de tareas.
❏ Feedback y mejora continua.
❏ Que fluya la comunicación de forma efectiva.
Sprints
Días
Sprint Burndown
Feedback
Retrospectiva
Feedback
Conceptos
● Story points.
● Estimations.
● User Story.
● Épica.
● DoD
Roles e interacción

8. Se pueden utilizar diversas técnicas de
estimado en SCRUM.
Una de las más populares son las tarjetas de
estimación en progresión fibonacci ( 0, 0.5, 1,
2, 3, 5, 8, 13, 20, 40, 100 ).
El equipo debe estimar por consenso y es el
responsable de cumplir el compromiso
adquirido.
Estimation cards Story points Sprint burndown
Se puede utilizar cualquier magnitud a la hora
de estimar (tiempo, story points, talla, etc…).
Los story points son una buena abstracción
que permite trabajar de una forma ágil y
aumentar la precisión conforme el equipo va
ganando madurez.
Gráfico sencillo que refleja el progreso del
sprint facilitando transparencia y
predictibilidad.
Todos los miembros del equipo pueden usarlo
de referencia y tomar las acciones necesarias
para resolver atascos o garantizar el
cumplimiento del compromiso.
Conceptos importantes
Sprint User Stories y épicas Definition of Done (DOD)
Las historias de usuario son requisitos
funcionales descritas por el Product Owner
para ser implementadas por el equipo.
Deben ser claras, concisas y testables e
incluir una definición de "hecho" (DOD).
El equipo puede descomponerlas en
subtareas técnicas.
Una épica es un conjunto de User Stories que
pueden sobrevivir al sprint.
Todo el mundo debe entender qué es
necesario que cumpla una historia de usuario
para que se considere finalizada.
La definición de "hecho" tiene que ser
comprensible y evitar cualquier ambigüedad.
8
Es el nombre que reciben los ciclos de
desarrollo en SCRUM.
Tienen una duración fija de entre una y cuatro
semanas.
Durante el sprint no se debe modificar el
alcance de las historias de usuario.

9. Reuniones de SCRUM
El P.O presenta al equipo las User Stories y
se asegura de que éstos la entienden. El
equipo ayuda al P.O a completar, mejorar o
incrementar la precisión de las U.S.
Se pueden realizar las estimaciones en este
punto.
Refinement meeting (Refinado) [5] Sprint planning meeting Daily Scrum
Sprint ReviewSprint Retrospective
El P.O prioriza las U.S que quiere insertar en
el sprint backlog, el equipo le asesora.
Sólo las U.S bien definidas, con DOD nítida
podrán ser incluídas.
Tras este paso el equipo puede desglosar las
U.S en SubTasks técnicas.
Charla rápida diaria, preferiblemente al
comenzar el día y no más de 15 minutos.
Los miembros del equipo cruzan información
sobre el estado de sus U.S, posibles ayudas
o dependencias.
El equipo muestra al P.O el resultado del sprint utilizando el
software resultante. Una a una se validan todas las U.S
comprometidas.
El P.O puede rechazar alguna si los criterios de aceptación no
se cumplen.
El equipo se junta en privado para analizar los problemas,
soluciones y mejoras aprendidas del sprint que ha acabado.
El resultado serán acciones a realizar y/o comunicaciones a
otros actores implicados.
9

10. 10
[1] Atlassian - Top software development trends in 2016 https://www.atlassian.com/blog/software-
teams/software-development-trends-2016
[2] VersionOne - Annual state of agile report 2016.
http://www.agile247.pl/wp-content/uploads/2016/04/VersionOne-10th-Annual-State-of-Agile-Report.pdf
[3] VersionOne - State of the agile survey year 2015.
https://www.watermarklearning.com/downloads/state-of-agile-development-survey.pdf
[4] The agile manifesto
http://agilemanifesto.org
[5] Product Backlog Refinement es uno de los eventos no especificados por la Scrum Alliance pero es
especialmente útil para incrementar la calidad de las tareas e implicar al equipo mejorando su visión.
https://www.scrumalliance.org/community/articles/2014/october/product-backlog-refinement
Referencias

11. 11
¿Preguntas?
Digital Takers - Open Knowledge Database
http://www.dtakers.com
Manuel Boira
manuel.boira@digitaltakers.com
Alejandro Moros
alejandro.moros@digitaltakers.com