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

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

➜ Metodologías ágiles➜ Metodologías ágiles vs tradicionales➜ Scrum➜ Kanban➜ eXtreme Programming

ÍNDICE

1.Metodologías ÁgilesQué son. Por qué surgen. El Origen.

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

Metodologías Ágiles

Problemas clásicos en elDesarrollo

▪ 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 deHistoria

1986En EEUU y Japón surge el concepto debido a la necesidad de salir al mercado muy rápido con requisitos muy novedosos.

1993 - 1995Se documenta y formaliza el primer documento de Scrum para desarrollo ágil de software.

2001Las personas más relevantes del desarrollo ágil escriben el Manifiesto Ágil donde se recogen sus 4 principios.

… Antes de todo estoA finales del S. XIX ~ principios del S. XX surge el concepto Lean Manufacturing de la mano de Toyota.

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

“ 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

2.Metodologías ágiles vs tradicionalesQué 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

▪ No se entrega valor hasta el final

▪ Mucha documentación inservible

Cascada vsAgile

www.crmsearch.com

Plan inicial vsRealidad

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 en el alcance

Cambios de funcionalidad

Cambios de tecnología

Otros erroresTí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

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

BeneficiosMetodologías Ágiles

CalidadRealizando pruebas desde el principio e iterando sobre el producto tras recibir el feedback.

ResultadosEntregando algo tangible y que aporte valor desde la primera iteración.

FlexibilidadPermitiendo cambios de alcance, estimando y planificando de manera ágil.

MantenibilidadCreando un software de calidad, con casos de prueba y una documentación asumible.

Eliminación de riesgosValidando cada entrega en sprints cortos y asegurando la calidad con casos de pruebas.

MotivaciónTrabajando de manera conjunta con el cliente, viendo crecer el producto final tras cada iteración.

Definición delProducto

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

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

ConstrucciónIterativa

¿Quién las usa?

Casos de usoDescripció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 usuarioDefinición corta de una funcionalidad, que debe poder escribirse en una nota adhesiva.

Lenguaje sencillo de entender por el equipo y el cliente.

Casos de uso

Casos de uso vs Historias de usuario

Historias de usuario

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

Jefe vsLí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

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

¿Qué es?

SCRUM

Qué esScrum

▪ 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

El proceso deScrum

GlosarioScrum

Product BacklogListado 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 BacklogListado de requisitos que se van a abordar en el sprint. Cada historia de usuario se desgrana en tareas asumibles y se estiman.

Gráfico BurndownGráfico que muestra la cantidad de requisitos pendientes al comienzo del sprint junto a los requisitos completados. Da una visión global del estado.

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

Roles enScrum

Product OwnerParticipa 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 MasterEncargado 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 TeamEquipo multidisciplinar autoorganizado (desarrolladores, QA, diseño, UX, arquitectos…) Encargado del desarrollo del producto.

Ceremonias deScrum

Daily ScrumReunió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 ReviewAl 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 PlanningAl inicio de cada sprint. Se selecciona el trabajo que se va a hacer en este sprint y se estima.

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

La importancia dePriorizar

▪ 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 deEstimar

▪ 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.kanbanVeamos algún ejemplo

Qué esKanban

▪ 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

Tener reglasclaras

Principios básicos de Kanban

Limitar elTrabajo en

curso

Visualizar elflujo de trabajo

Gestionar elflujo

Mejorar enequipo

TableroKanban

▪ 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 DoneAntes de empezar es necesario definir qué significa que una tarea está terminada.

Kanbanboard

Ejemplo

4.eXtreme ProgrammingQué es XP. Técnicas más comunes.

Qué esXP

▪ 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ísticasXP

TDDDesarrollo guiado por pruebas. Antes de programar se deben escribir las pruebas que validen cada funcionalidad.

Pair ProgrammingTécnica en la que dos programadores comparten el mismo ordenador para desarrollar a la vez.

Integración con clienteSe recomienda que al menos una persona del cliente trabaje de manera conjunta al equipo de desarrollo.

RefactorizaciónSobreescribir ciertas partes del código para mejorar su legibilidad y mantenibilidad sin modificar su funcionamiento.

Propiedad compartidaSe promueve que todos los miembros del equipo puedan tocar cualquier parte del código.

SimplicidadCuanto más simple sea el sistema que se construya más fácil será comprenderlo y añadir nuevas funcionalidades.

Thanks!!¿Alguna pregunta?