El documento analiza las metodologías ágiles de gestión de proyectos, centrándose en Scrum, Kanban y Extreme Programming (XP). Se destacan las diferencias entre enfoques ágiles y tradicionales, así como los beneficios del agilismo como flexibilidad, colaboración y entrega continua de valor. También se describen los roles y prácticas clave en Scrum y Kanban, así como las técnicas de programación asociadas a XP.

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

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

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

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

5. #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.

6. Metodologías
Ágiles

7. 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.

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

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

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

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

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

13. Cascada vs
Agile
www.crmsearch.com

14. Plan inicial vs
Realidad
A.J. Juliani

15. Importancia del
Feedback

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

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

18. 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

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

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

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

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

23. Construcción
Iterativa

24. ¿Quién las usa?

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

26. Casos de uso
Casos de uso vs
Historias de usuario
Historias de usuario

27. 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

28. Jefe vs
Líder
▪ Desaparece el jefe autoritario por el
líder con conocimientos que guía al
equipo.
▪ Soluciones vs problemas
▪ Confianza vs miedo
▪ Convencer vs imponer
www.upadpsicologiacoaching.com

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

30. ¿Qué es?
SCRUM

31. 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

32. El proceso de
Scrum

33. Glosario
Scrum
Product Backlog
Listado dinámico, público y
actualizado con todos los
requisitos del producto.
Debe estar priorizado. Es de
alto nivel, no entra en
detalles de implementación.
Sprint Backlog
Listado de requisitos que se
van a abordar en el sprint.
Cada historia de usuario se
desgrana en tareas
asumibles y se estiman.
Gráfico Burndown
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.
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.

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

35. Ceremonias de
Scrum
Daily Scrum
Reunión diaria donde sólo los involucrados
pueden hablar. Se responden 3 preguntas:
- ¿Qué hiciste ayer?
- ¿Qué vas a hacer hoy?
- ¿Tienes algún bloqueo?
Sprint Review
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.
Sprint Planning
Al inicio de cada sprint. Se selecciona el
trabajo que se va a hacer en este sprint y
se estima.
Sprint Retrospective
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.

36. 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)

37. 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

38. 4.
kanban
Veamos algún ejemplo

39. 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

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

41. 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.

42. Kanban
board
Ejemplo

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

44. 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

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

46. Thanks!!
¿Alguna pregunta?