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

Transcripción

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

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

3 ÍNDICE Metodologías ágiles Metodologías ágiles vs tradicionales Scrum Kanban extreme Programming

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

9 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

10 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

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 Mucha documentación inservible No se entrega valor hasta el final

13 Cascada vs Agile

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 de funcionalidad Cambios en el alcance 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 Participar y En todas las definir el direcciones. Tanto con producto de el cliente como con el equipo manera Comunicación Optimizar Equipo Colaborar Flexibilidad Entregas rápidas Respuesta ante los cambios conjunta Calidad Aportar Valor Tener algo funcionando desde el principio

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

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

23 Construcción Iterativa

24 Quién las usa?

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 Casos de uso vs Historias de usuario Casos de uso 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

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

34 Roles en Scrum Product Owner Scrum Master Development Team 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. 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. Equipo multidisciplinar autoorganizado (desarrolladores, QA, diseño, UX, arquitectos ) Encargado del desarrollo del producto.

35 Ceremonias de Scrum Daily Scrum 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.

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 Principios básicos de Kanban Visualizar el flujo de trabajo Limitar el Trabajo en curso Gestionar el flujo Tener reglas claras 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 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.

46 Thanks!! Alguna pregunta?