September 23, 2024 | Author: Anonymous | Category: N/A
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
E
Las 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 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 concepto debido a la necesidad de salir al mercado muy rápido con requisitos muy novedosos.
Se documenta y formaliza el primer documento de Scrum para desarrollo ágil de software.
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.
TOYOTA - Lean Manufacturing
The Seven Wastes - Sobreproducción - Tiempo de espera - Transporte - Exceso de procesado - Inventario - Movimiento - Defectos
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
“
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 funcionalidad
Cambios en el alcance
Cambios de 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
Principios Metodologías Ágiles
Participar y
En todas las
definir el
direcciones. Tanto con
producto de
el cliente como con el equipo
manera
Comunicación
Optimizar
Equipo
Flexibilidad
Colaborar Entregas rápidas
Respuesta ante los cambios
conjunta
Calidad
Aportar Valor Tener algo funcionando desde el principio
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.
Definición del Producto ¿Cómo funciona? ¿Qué es?
¿Qué necesidades cubre? ¿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 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.
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 actualizado con todos los requisitos del producto. Debe estar priorizado. Es de alto nivel, no entra en detalles de implementación.
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 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.
El proceso de Scrum
El proceso de Scrum
Ceremonias de Scrum Daily Meeting
Sprint Review
Reunión diaria donde sólo los involucrados pueden hablar. Se responden 3 preguntas:
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.
-
¿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.
Roles en Scrum Product Owner
Scrum Master
Participa en la Encargado de que se definición del cumplan las reglas de producto. Representa Scrum. Resuelve al negocio y prioriza posibles conflictos. historias de usuario. Motiva y protege al Nexo de unión entre equipo. Su tarea es los implicados. Debe facilitar el trabajo al maximizar el valor del equipo. producto.
Development Team Equipo multidisciplinar autoorganizado (desarrolladores, QA, diseño, UX, arquitectos…) Encargado del desarrollo del 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 flujo de trabajo
Limitar el Trabajo en curso
Gestionar el flujo
Tener reglas claras
Mejorar en equipo
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 pruebas. Antes de programar se deben escribir las pruebas que validen cada funcionalidad.
Técnica en la que dos programadores comparten el mismo ordenador para desarrollar a la vez.
Se recomienda que al menos una persona del cliente 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 funcionamiento.
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.
I am Jose A. Dorado Cerón Product Owner & Software Architect en Emergya @jadoradoce /
[email protected]