1.
Gestión Ágil de Proyectos:
Scrum, Kanban y XP

2.
ÍNDICE
➜ Metodologías ágiles
➜ Metodologías ágiles vs tradicionales
➜ Scrum
➜ Kanban
➜ eXtreme Programming

3.
1.
Metodologías Ágiles
Qué son. Por qué surgen. El Origen.

4.
#AGILE
Las metodologías ágiles son un conjunto de técnicas para gestionar y
desarrollar proyectos en contraposición a las técnicas clásicas.

5.
Metodologías
Ágiles

6.
Problemas clásicos en el
Desarrollo
▪ Cambios de contexto y de alcance
▪ Aparecen retrasos => No hay tiempo para pruebas
▪ Planificaciones poco realistas
▪ Cliente poco involucrado
▪ Falta de comunicación
▪ Equipo poco motivado
▪ No hay flexibilidad
▪ El resultado no es lo esperado por el cliente
Resultado: Equipo y cliente insatisfechos. Tiempo y dinero perdido.

7.
Un poco de
Historia
1986 1993 - 1995 2001
En EEUU y Japón surge el Se documenta y formaliza
el primer documento de
Scrum para desarrollo ágil
de software.
Las personas más
concepto debido a la relevantes del desarrollo
ágil escriben el Manifiesto
Ágil donde se recogen sus 4
principios.
necesidad de salir al
mercado muy rápido con
requisitos muy novedosos.
… Antes de todo esto
A finales del S. XIX ~ principios del S. XX surge el concepto Lean Manufacturing de la mano
de Toyota.

8.
TOYOTA - Lean Manufacturing
The Seven Wastes
- Sobreproducción
- Tiempo de espera
- Transporte
Principios de Lean
- Calidad. Detección de problemas
al principio
- Eliminar lo que no aporte valor
- Mejora continua
- Exceso de procesado
- Inventario - Producir lo necesario
- Flexibilidad
- Movimiento
- Defectos - Compartir información

9.
Manifiesto Ágil
“ Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación excesiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

10.
2.
Metodologías ágiles vs tradicionales
Qué aporta el agilismo, beneficios, cambios...

11.
Desarrollo en Cascada
▪ Poco flexible. No se puede ir atrás
▪ Muy estricto. No permite cambios de alcance
▪ Pequeños errores causan grandes problemas
▪ Mucha documentación inservible
▪ No se entrega valor hasta el final

12.
Cascada vs
Agile
www.crmsearch.com

13.
Plan inicial vs
Realidad
A.J. Juliani

14.
Importancia del
Feedback

15.
“ Se dedica mucho esfuerzo a
alcanzar objetivos que aportan
muy poco valor.
Dinero perdido + tiempo perdido = Cliente insatisfecho

16.
El gran enemigo
Los cambios
Cambios de Cambios en el
alcance
Cambios de
tecnología
funcionalidad

17.
Otros errores
Típicos
▪ No medir el avance o medirlo mal
▪ Añadir más personas creyendo que se irá más rápido
▪ No hacer pruebas desde el principio
▪ Creer que estamos construyendo una casa en vez de software
▪ No tener una visión global del estado actual
▪ Poca implicación del cliente
▪ Estimaciones sin técnicos
▪ Pérdida del foco
▪ No decir no
▪ No obtener feedback
▪ Herramientas inadecuadas para planificar

18.
¿Existe
alguna
alternativa?
Gestión
Ágil

19.
Principios
Participar y
definir el
En todas las
direcciones. Tanto con
el cliente como con el
equipo
Metodologías Ágiles
producto de
manera
Comunicación conjunta
Optimizar Equipo
Calidad
Flexibilidad Colaborar
Entregas
rápidas
Aportar
Valor
Respuesta
ante los
cambios Tener algo
funcionando
desde el
principio

20.
Beneficios
Metodologías Ágiles
Calidad Resultados Flexibilidad
Realizando pruebas desde el
principio e iterando sobre el
producto tras recibir el
feedback.
Entregando algo tangible y
que aporte valor desde la
primera iteración.
Permitiendo cambios de
alcance, estimando y
planificando de manera ágil.
Mantenibilidad Eliminación de riesgos Motivación
Creando un software de
calidad, con casos de prueba
y una documentación
asumible.
Validando cada entrega en
sprints cortos y asegurando
la calidad con casos de
pruebas.
Trabajando de manera
conjunta con el cliente,
viendo crecer el producto
final tras cada iteración.

21.
Definición del
Producto
¿Cómo funciona?
¿Por qué es útil?
¿Qué necesidades cubre?
¿Qué es? ¿A quién va dirigido?

22.
Construcción
Iterativa

23.
¿Quién las usa?

24.
Casos de uso vs
Historias de usuario
Casos de uso Historias de usuario

25.
Casos de uso vs
Historias de usuario
Casos de uso Historias de usuario
Descripción de todos los pasos
que se deben llevar a cabo para
realizar una acción.
Definición corta de una
funcionalidad, que debe poder
escribirse en una nota adhesiva.
Especificación de interacciones
entre los actores y el sistema.
Lenguaje sencillo de entender
por el equipo y el cliente.

26.
Historias de
Usuario
▪ Siguen el patrón: “Cómo - Quiero - Para”
▪ Sirven para especificar requisitos
▪ Son independientes unas de otras
▪ Son pequeñas
▪ Se pueden estimar
▪ Se pueden verificar una vez implementadas
▪ Son flexibles
▪ Son entendibles y fomentan la comunicación

27.
3.
Scrum
¿Qué es? Roles, prácticas...

28.
¿Qué es?
SCRUM

29.
Qué es
Scrum
▪ Marco de trabajo para desarrollos ágiles
▪ Desarrollo incremental vs planificación y ejecución completa
▪ Equipos auto organizados
▪ Paralelización de las fases de desarrollo vs fases secuenciales
▪ Priorización de los requisitos que más valor aporten
▪ Mejora continua

30.
Glosario
Scrum
Product Backlog Sprint Backlog Gráfico Burndown
Listado dinámico, público y
actualizado con todos los
requisitos del producto.
Debe estar priorizado. Es de
alto nivel, no entra en
Listado de requisitos que se
van a abordar en el sprint.
Cada historia de usuario se
desgrana en tareas
Gráfico que muestra la
cantidad de requisitos
pendientes al comienzo del
sprint junto a los requisitos
completados. Da una visión
global del estado.
asumibles y se estiman.
detalles de implementación.
Sprint
Iteración de entre 1 y 4 semanas (normalmente 2). Al final del sprint se realiza una entrega
al cliente con las nuevas funcionalidades. Entrega continua de valor.

31.
El proceso de
Scrum

32.
El proceso de
Scrum

33.
Ceremonias de
Scrum
Daily Meeting Sprint Review
Reunión diaria donde sólo los involucrados Al final del sprint. Se revisa el trabajo que se ha
completado y el que no se ha terminado. Se
hace una demostración y se obtiene feedback.
pueden hablar. Se responden 3 preguntas:
-
-
-
¿Qué hiciste ayer?
¿Qué vas a hacer hoy?
¿Tienes algún bloqueo?
Sprint Planning Sprint Retrospective
Al inicio de cada sprint. Se selecciona el
trabajo que se va a hacer en este sprint y
se estima.
Al final del sprint. Se reunen todos los implicados
para analizar qué se ha hecho bien y se debe
seguir haciendo y qué se ha hecho mal y se debe
cambiar.

34.
Roles en
Scrum
Product Owner Scrum Master Development Team
Participa en la Encargado de que se Equipo
definición del cumplan las reglas de multidisciplinar
producto. Representa Scrum. Resuelve autoorganizado
(desarrolladores, QA,
diseño, UX,
al negocio y prioriza
historias de usuario.
Nexo de unión entre
los implicados. Debe
posibles conflictos.
Motiva y protege al
equipo. Su tarea es
facilitar el trabajo al
arquitectos…)
Encargado del
desarrollo del
producto.
maximizar el valor del equipo.
producto.

35.
La importancia de
Priorizar
▪ Es una responsabilidad del Product Owner
▪ Se debe priorizar por el valor que aporta cada historia
▪ No se debe priorizar por la complejidad para desarrollarlas
▪ Existen muchas técnicas, como por ejemplo:
▫ Modelo Kano:
▸ Requisitos obligatorios (Básicos)
▸ Requisitos deseados (Esperados)
▸ Requisitos no esperados (Inesperados)
▸ Indiferentes (No aportan valor)
▫ MoSCoW: (Must, Should, Could y Won’t)

36.
La necesidad de
Estimar
▪ Es una responsabilidad de todo el equipo
▪ Todas las tareas deben ser estimadas
▪ Estimación basada en el conocimiento y en la experiencia
▪ Estimar en puntos y conocer la velocidad del equipo
▪ Planning Poker:
▫ Se utiliza la secuencia de Fibonacci
▫ Se explica la historia y se resuelven dudas
▫ Se busca unanimidad y consenso

37.
4.
kanban
Veamos algún ejemplo

38.
Qué es
Kanban
▪ Término japonés: Tarjetas visuales 看板
▪ Proporciona un flujo de trabajo para dividir el proceso en fases
▪ Complementario con Scrum
▪ Los 4 principios básicos de Kanban:
▫ Empieza con lo que haces ahora
▫ Acepta el cambio
▫ Respeta el proceso actual, roles y responsabilidades
▫ Liderazgo en todos los niveles

39.
Principios básicos de
Kanban
Visualizar el
flujo de
Limitar el
Trabajo en
curso
Gestionar el
flujo
Tener reglas
claras
Mejorar en
equipo
trabajo

40.
Tablero
Kanban
▪ Se usa para organizar las tareas del sprint en curso
▪ Se puede adaptar a las necesidades
▪ Se van moviendo las tarjetas por las diferentes columnas
▪ Sirve para tener una visión global del estado actual del sprint
DoD: Definition of Done
Antes de empezar es necesario definir qué
significa que una tarea está terminada.

41.
Kanban
board
Ejemplo

42.
4.
eXtreme Programming
Qué es XP. Técnicas más comunes.

43.
Qué es
XP
▪ Metodología ágil de desarrollo software basada en la flexibilidad
▪ Se considera que los cambios de requisitos son un aspecto natural
▪ Valores de XP:
▫ Simplicidad
▫ Comunicación
▫ Retroalimentación
▫ Valentía
▫ Respeto

44.
Técnicas y características
XP
TDD Pair Programming Integración con cliente
Desarrollo guiado por Técnica en la que dos
programadores comparten
el mismo ordenador para
desarrollar a la vez.
Se recomienda que al menos
pruebas. Antes de una persona del cliente
programar se deben escribir
las pruebas que validen cada
funcionalidad.
trabaje de manera conjunta al
equipo de desarrollo.
Refactorización Propiedad compartida Simplicidad
Sobreescribir ciertas partes
del código para mejorar su
legibilidad y mantenibilidad
sin modificar su
Se promueve que todos los
miembros del equipo
puedan tocar cualquier parte
del código.
Cuanto más simple sea el
sistema que se construya más
fácil será comprenderlo y añadir
nuevas funcionalidades.
funcionamiento.

45.
I am Jose A. Dorado Cerón
Product Owner & Software Architect en Emergya
@jadoradoce / jose.doradoce@gmail.com