Metodologias Agiles

Gestión Ágil de Proyectos:
Scrum, Kanban y XP
ÍNDICE
➜ Metodologías ágiles
➜ Metodologías ágiles vs tradicionales
➜ Scrum
➜ Kanban
➜ eXtreme Programming
1.
Metodologías Ágiles
Qué son. Por qué surgen. El Origen.
#AGIL
Las metodologías ágiles son un conjunto de técnicas para gestionar y
E
desarrollar proyectos en contraposición a las técnicas clásicas.
Metodologías
Ágiles
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.

Un poco de
Historia
1986 1993 - 1995 2001

En EEUU y Japón surge el Se documenta y formaliza Las personas más
concepto debido a la el primer documento de relevantes del desarrollo
necesidad de salir al Scrum para desarrollo ágil ágil escriben el Manifiesto
mercado muy rápido con de software. Ágil donde se recogen sus 4
requisitos muy novedosos. principios.
… Antes de todo esto

A finales del S. XIX ~ principios del S. XX surge el concepto Lean Manufacturing de la mano
de Toyota.
TOYOTA - Lean Manufacturing
The Seven Wastes Principios de Lean

- Sobreproducción - Calidad. Detección de problemas
- Tiempo de espera al principio
- Transporte - Eliminar lo que no aporte valor
- Exceso de procesado - Mejora continua
- Inventario - Producir lo necesario
- Movimiento - Flexibilidad
- Defectos - Compartir información
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

2.
Metodologías ágiles vs tradicionales
Qué aporta el agilismo, beneficios, cambios...
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

Cascada vs
Agile
www.crmsearch.com
Plan inicial vs
Realidad
A.J. Juliani
Importancia del
Feedback
“ Se dedica mucho esfuerzo a
alcanzar objetivos que aportan
muy poco valor.
Dinero perdido + tiempo perdido = Cliente

insatisfecho
El gran enemigo
Los cambios
Cambios de Cambios en el Cambios de

funcionalidad alcance tecnología
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
¿Existe
alguna
alternativa?
Gestión
Ágil
Participar y
Principios En todas las

direcciones. Tanto con
definir el
producto de
el cliente como con el
manera
equipo
conjunta
Comunicación
Optimizar Equipo
Flexibilidad Colaborar
Entregas Calidad
rápidas
Respuesta Aportar
ante los Valor
cambios Tener algo
funcionando
desde el
principio
Beneficios
Calidad Resultados Flexibilidad

Realizando pruebas desde el Entregando algo tangible y Permitiendo cambios de
principio e iterando sobre el que aporte valor desde la alcance, estimando y
producto tras recibir el primera iteración. planificando de manera ágil.
feedback.
Mantenibilidad Eliminación de riesgos Motivación

Creando un software de Validando cada entrega en Trabajando de manera
calidad, con casos de prueba sprints cortos y asegurando conjunta con el cliente,
y una documentación la calidad con casos de viendo crecer el producto
asumible. pruebas. final tras cada iteración.
Definición del
Producto
¿Cómo funciona? ¿Qué necesidades cubre?
¿Qué es? ¿Por qué es útil? ¿A quién va dirigido?

Construcción
Iterativa
¿Quién las usa?
Casos de uso vs
Historias de usuario
Casos de uso Historias de usuario

Casos de uso vs
Historias de usuario
Casos de uso Historias de usuario

Descripción de todos los pasos Definición corta de una
que se deben llevar a cabo para funcionalidad, que debe poder
realizar una acción. escribirse en una nota adhesiva.
Especificación de interacciones Lenguaje sencillo de entender

entre los actores y el sistema. por el equipo y el cliente.
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
3.
Scrum
¿Qué es? Roles, prácticas...
¿Qué es?
SCRUM
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
Glosario
Scrum
Product Backlog Sprint Backlog Gráfico Burndown

Listado dinámico, público y Listado de requisitos que se Gráfico que muestra la
actualizado con todos los van a abordar en el sprint. cantidad de requisitos
requisitos del producto. Cada historia de usuario se pendientes al comienzo del
Debe estar priorizado. Es de desgrana en tareas sprint junto a los requisitos
alto nivel, no entra en asumibles y se estiman. completados. Da una visión
detalles de implementació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.
El proceso de
Scrum
El proceso de
Scrum
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
pueden hablar. Se responden 3 preguntas: completado y el que no se ha terminado. Se
- ¿Qué hiciste ayer? hace una demostración y se obtiene feedback.
- ¿Qué vas a hacer hoy?
- ¿Tienes algún bloqueo?
Sprint Planning Sprint Retrospective

Al inicio de cada sprint. Se selecciona el Al final del sprint. Se reunen todos los implicados
trabajo que se va a hacer en este sprint y para analizar qué se ha hecho bien y se debe
se estima. seguir haciendo y qué se ha hecho mal y se debe
cambiar.
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
al negocio y prioriza posibles conflictos. (desarrolladores, QA,
historias de usuario. Motiva y protege al diseño, UX,
Nexo de unión entre equipo. Su tarea es arquitectos…)
los implicados. Debe facilitar el trabajo al Encargado del
maximizar el valor del equipo. desarrollo del
producto. producto.
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)
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
4.
kanban
Veamos algún ejemplo
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
Principios básicos de
Kanban
Visualizar el Limitar el Gestionar el Tener reglas Mejorar en

flujo de Trabajo en flujo claras equipo
trabajo curso
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.
Kanban
board
Ejemplo
4.
eXtreme Programming
Qué es XP. Técnicas más comunes.
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
Técnicas y características
XP
TDD Pair Programming Integración con cliente

Desarrollo guiado por Técnica en la que dos Se recomienda que al menos
pruebas. Antes de programadores comparten una persona del cliente
programar se deben escribir el mismo ordenador para trabaje de manera conjunta al
las pruebas que validen cada desarrollar a la vez. equipo de desarrollo.
funcionalidad.
Refactorización Propiedad compartida Simplicidad

Sobreescribir ciertas partes Se promueve que todos los Cuanto más simple sea el
del código para mejorar su miembros del equipo sistema que se construya más
legibilidad y mantenibilidad puedan tocar cualquier parte fácil será comprenderlo y añadir
sin modificar su del código. nuevas funcionalidades.
funcionamiento.
I am Jose A. Dorado Cerón
Product Owner & Software Architect en Emergya
@jadoradoce / jose.doradoce@gmail.com

Metodologias Agiles

Cargado por

Copyright:

Formatos disponibles

Metodologias Agiles

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologias Agiles

Cargado por

Copyright:

Formatos disponibles

Gestión Ágil de Proyectos:

Resultado: Equipo y cliente insatisfechos. Tiempo y dinero perdido.

1986 1993 - 1995 2001

… Antes de todo esto

The Seven Wastes Principios de Lean

Software funcionando sobre documentación excesiva

Colaboración con el cliente sobre negociación

Respuesta ante el cambio sobre seguir un plan

▪ 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

Dinero perdido + tiempo perdido = Cliente

Cambios de Cambios en el Cambios de

Principios En todas las

Calidad Resultados Flexibilidad

Mantenibilidad Eliminación de riesgos Motivación

¿Cómo funciona? ¿Qué necesidades cubre?

¿Qué es? ¿Por qué es útil? ¿A quién va dirigido?

Casos de uso Historias de usuario

Casos de uso Historias de usuario

Especificación de interacciones Lenguaje sencillo de entender

Product Backlog Sprint Backlog Gráfico Burndown

Daily Meeting Sprint Review

Sprint Planning Sprint Retrospective

Product Owner Scrum Master Development Team

Visualizar el Limitar el Gestionar el Tener reglas Mejorar en

DoD: Definition of Done

TDD Pair Programming Integración con cliente

Refactorización Propiedad compartida Simplicidad

También podría gustarte