Gestión ágil de proyectos
2 recomendaciones709 vistas
Este documento presenta los conceptos y principios de la gestión ágil de proyectos. Explica brevemente el método tradicional en cascada y contrasta con el enfoque ágil. Luego describe los principios del Manifiesto Ágil y los roles, artefactos y eventos clave de Scrum, una de las metodologías ágiles más populares. Finalmente, menciona otras metodologías ágiles y algunas malas prácticas a evitar.
Gestión ágil de proyectos
- 4. FACTIBILIDAD REQUERIMIENTOS DISEÑO EN CASCADA 4 MÉTODO TRADICIONAL CODIFICACIÓN TEST IMPLEMENTACIÓN MANTENIMIENTO Intervención del usuario Usuario excluido Intervención del usuario Extensa fase de análisis Comienza el mantenimiento
- 5. Just IN TIME
- 6. 6 Estamos descubriendo formas mejores de desarrollar software tanto por nuestra experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas. Software funcionando sobre documentación exhaustiva. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan. Esto es, aunque valoramos los elementos de la derecha, valoramos aún más los de la izquierda.
- 7. PRINCIPIOS Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 7 MANIFIESTO ÁGIL 01
- 8. PRINCIPIOS Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 8 MANIFIESTO ÁGIL 02
- 9. PRINCIPIOS Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. 9 MANIFIESTO ÁGIL 03
- 10. PRINCIPIOS Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 10 MANIFIESTO ÁGIL 04
- 11. PRINCIPIOS Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 11 MANIFIESTO ÁGIL 05
- 12. PRINCIPIOS El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. 12 MANIFIESTO ÁGIL 06
- 13. PRINCIPIOS El software funcionando es la medida principal de progreso. 13 MANIFIESTO ÁGIL 07
- 14. PRINCIPIOS Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 14 MANIFIESTO ÁGIL 08
- 15. PRINCIPIOS La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 15 MANIFIESTO ÁGIL 09
- 16. PRINCIPIOS La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 16 MANIFIESTO ÁGIL 10
- 17. PRINCIPIOS Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados. 17 MANIFIESTO ÁGIL 11
- 18. PRINCIPIOS A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. 18 MANIFIESTO ÁGIL 12
- 19. METODOLOGÍAS ÁGILES § Feature Driven Development (FDD) § Dynamic System Development Methodology § Crystal § Agile Unified Process (AUP) § Scaled Agile Framework (SAFe) § Disciplined Agile Delivery (DAD) § Agile Modeling § Lean § Extreme Programming (XP) § Scrum § Kanban § Large Scale Scrum (LeSS) § Scrumban § 3x (Explore, Expand, Extract) § Essence § Modern Agile 19
- 20. 20
- 22. LIVIANO FÁCIL DE APRENDER DIFÍCIL DE DOMINAR Un marco de trabajo por el cual las personas pueden abordar problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente. SCRUM 22
- 23. 23 CORAJE para asumir desafíos FOCO sobre un acotado número de características COMPROMISO con el éxito del proyecto y del equipo RESPETO por la capacidad y el valor de los demás APERTURA para discutir los desafíos con transparencia
- 26. La razón de que este marco funcione es simple: se estudia cómo la gente trabaja en realidad, no como dice que trabaja.
- 27. En Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración fija llamado Sprint que normalmente son de 1 semana hasta el límite máximo de 4 semanas. SPRINT 27 SCRUM El objetivo de cada ciclo es crear un producto potencialmente usable, es decir, un incremento de producto final que pueda ser utilizado por los clientes.
- 29. ROLES 29 SCRUM Mantener y priorizar el Product Backlog Asegurar que se trabajen los items de mayor valor Entender y priorizar las necesidades de los SH Responder las consultas del equipo de desarrollo Es una única persona RESPONSABILIDADES Y CARACTERÍSTICAS:
- 30. ROLES 30 SCRUM RESPONSABILIDADES Y CARACTERÍSTICAS: Asegurar la correcta implementación de Scrum Eliminar los impedimentos que bloquean al equipo No es una autoridad jerárquica Es una única persona Es el facilitador de los eventos de Scrum
- 31. ROLES 31 SCRUM DEV TEAM DT RESPONSABILIDADES Y CARACTERÍSTICAS: Encargados de construir el producto Autoorganizado y autodirigido Multidisciplinario No tienen títulos No existen sub-equipos
- 32. ROLES 32 SCRUM
- 33. ROLES CERDOS COMPROMETIDOS PRODUCT OWNER Quién maximiza el valor del producto resultante del trabajo del Equipo. SCRUM MASTER Quién asegura la correcta aplicación de Scrum y elimina los impedimientos DEV TEAM Quienes realizan el trabajo de entregar un incremento de producto en cada Sprint. 33 SCRUM GALLINAS INVOLUCRADOS USUARIOS Quienes utilizan el producto CLIENTES Quienes compran el producto MARKETING Y VENTAS Quienes comercializarán el producto DUEÑOS, MANAGERS Y OTROS STAKEHOLDERS Quienes permiten que el proyecto exista
- 34. El Scrum Master y el Dev Team están a cargo de lo rápido que avanzan y la mayor calidad que pueden alcanzar. El Product Manager lo está de traducir esa productividad en valor.
- 35. Las historias de usuario, son pequeñas descripciones de los requerimientos de un cliente. Una historia de usuario suele ser una funcionalidad, algo visible para los usuarios finales. Debe venir acompañada de los criterios de aceptación. La historias de usuario deben cumplir el criterio INVEST 35 HISTORIAS DE USUARIO
- 36. HISTORIAS DE USUARIO 36 I N V E S T INDEPENDENT INDEPENDIENTE NEGOTIABLE NEGOCIABLE VALUABLE VALIOSA ESTIMABLE ESTIMABLE SMALL PEQUEÑA TESTEABLE TESTEABLE
- 37. Una tarea es una unidad de trabajo necesaria para terminar una historia. Puede ser realizada por un solo miembro del equipo, mientras que producir una historia es responsabilidad de todo el equipo. Lo recomendable es que una tarea no dure más de un día de trabajo, o en caso contrario, descomponerla en dos o más tareas. La tareas deben cumplir el criterio SMART 37 TAREAS
- 38. TAREAS 38 S M A R T SPECIFIC ESPECIFICA MEASURABLE ESTIMABLE ACHIEVABLE REALIZABLE RELEVANT RELEVANTE TIME-BOXED LIMITADA
- 39. Una épica es una historia de usuario que no puede ser entregada tal y como se ha definido dentro de una sola iteración, o que es suficientemente grande como para ser partida en historias de usuario más pequeñas. 39 ÉPICAS
- 41. 41 PRODUCT BACKLOG SCRUM ARTEFACTOS Es el conjunto de requisitos o funcionalidades que debe tener un proyecto de forma actualizado y priorizado por los elementos que más valor aportan a nivel de negocio. • Nunca está completo, evoluciona junto con el producto y el entorno. • Es dinámico, cambia constantemente para identificar lo que el producto necesita. • Es responsabilidad del Product Owner
- 42. 42 SPRINT BACKLOG SCRUM ARTEFACTOS Es el conjunto de elementos del Product Backlog seleccionados para el Sprint, más un plan para entregar el Incremento de producto. • Estimada por el Dev Team • Priorizada • Hace visible todo el trabajo que se está realizando • Suficientemente detallada • Compone el Objetivo del Sprint
- 43. 43 INCREMENTO SCRUM ARTEFACTOS Es la suma de todos los elementos del Sprint Backlog completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores. • Inspeccionable • Respalda el empirismo del Sprint • En condiciones de utilizarse aún si en Product Owner no lo libera. • Es un paso hacia la visión o meta final.
- 44. Cuando un elemento del Product Backlog o un Incremento se describe como “Terminado”, todo el mundo debe entender lo que significa “Terminado”. Los miembros del Equipo deben tener un entendimiento compartido de lo que significa que el trabajo esté completado para asegurar la transparencia. El propósito de cada Sprint es entregar Incrementos de funcionalidad que potencialmente se puedan poner en producción y que se ajustan a la Definición de “Terminado” actual del Equipo Scrum. 44 TERMINADO DEFINITION OF DONE
- 45. Un Spike sirve para incluir en un Sprint tareas que no implican desarrollar una historia de usuario y por tanto no aportan directamente un Incremento al producto que se está desarrollando. Se utilizan para: • Investigación y pruebas • Documentación • Formación interna Un Spike no debe durar más que un Sprint 45 SPIKE
- 46. 46 EVENTOS SCRUM
- 47. Es el evento dónde se planifica el trabajo que se va a realizar durante el Sprint. • Intervienen todos los miembros del Equipo Scrum • Se seleccionan y estiman los ítems para el Sprint • Se aclaran dudas sobre los ítems seleccionados • Se define el Objetivo del Sprint • Duración máxima: 2 horas por cada semana de Sprint 47 SPRINT PLANNING SCRUM EVENTOS
- 48. Es una reunión diaria con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo, donde se planea el trabajo para las próximas 24 horas. • Interviene Equipo de Desarrollo y el Scrum Master • El Product Owner puede asistir • No es una reunión de reporte • Duración: 15 minutos Es usual que luego del Daily Scrum los miembros del equipo se vuelvan a reunir para tener discusiones detalladas sobre temas puntuales. 48 DAILY SCRUM SCRUM EVENTOS
- 50. Se lleva a cabo al finalizar el Sprint para inspeccionar el Incremento y adaptar el Product Backlog si fuese necesario. La presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración. • Intervienen todos los miembros del Equipo de Scrum • El Product Owner muestra o explica el avance • Pueden asistir Stakeholders y hacer preguntas • Se revisan tiempos, presupuestos, etc. • Duración máxima: 1 hora por cada semana de Sprint 50 SPRINT REVIEW SCRUM EVENTOS
- 51. Es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint. Debe ser positiva y productiva. Se inspecciona cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas. Duración máxima: 45 min por cada semana de Sprint. 51 RETROSPECTIVA SCRUM EVENTOS
- 52. No es un evento oficial de Scrum, pero el propio creador reconoce su importancia. • Asiste todo el Equipo Scrum • Se revisa cada elemento del Product Backlog y se asegura de que tanto su descripción como los criterios de aceptación del mismo sean precisos y reflejen las necesidades exactas del momento actual del proyecto. • Duración máxima: 2 horas por cada semana de Sprint 52 REFINAMIENTO GROOMING SCRUM EVENTOS
- 53. 53 BURNDOWN CHART Sirve para saber el tiempo que falta para completar las tareas comprometidas en un Sprint. Por debajo de la línea quiere decir que llegamos a tiempo, si vamos por encima de la línea puede querer decir varias cosas: que hemos estimado mal, que ha habido algún problema bloqueante, alguna baja, que el Equipo no funcionando bien, cambios en los requisitos, etc. Al final del Sprint, se tiene una referencia de la velocidad real del Equipo. SCRUM
- 54. Es una técnica para calcular una estimación basada en el consenso, en su mayoría utilizada para estimar el esfuerzo relativo de las tareas • Cada integrante del Equipo tiene un mazo con barajas numeradas • Se propone la tarea a estimar, dando lugar a debate o preguntas • Cada integrante muestra la carta cuyo valor representa el esfuerzo que considera requerirá esa tarea. • Si dos o más integrantes muestran cartas con más de tres grados de diferencia, se piden explicaciones y se vuelve a debatir. • Se repite la operación hasta llegar a un consenso. 54 PLANNING POKER SCRUM
- 55. ¿Cuánto toma ESCRIBIR UN NOMBRE?
- 56. La gente no hace multitarea porque es buena para eso, sino por ser muy distraída. Se le dificulta inhibir el impulso de hacer otra cosa. David Sanbonmatsu - autor de Who multitask and why?
- 59. MALAS Prácticas
- 60. PRIORIZACIÓN POR PROXY Un stakeholder prioriza el Product Backlog basado en requerimientos de su oficina o de un cliente. 60 MALAS PRÁCTICAS PRODUCT OWNER 01
- 61. 100% DE CObertura El Equipo de Scrum crea un Product Backlog cubriendo la totalidad de un proyecto porque entiende que su alcance es limitado. 61 02 MALAS PRÁCTICAS PRODUCT OWNER
- 62. SIN / DEMASIADOS CRITERIOS DE ACEPTACIÓN El Product Backlog contiene historias de usuario que no incluyen los criterios de aceptación o incluyen demasiados. 62 03 MALAS PRÁCTICAS PRODUCT OWNER
- 63. NO HAY ÉPICAS / NO HAY SPIKES El Product Backlog no contiene épicas ni spikes. 63 04 MALAS PRÁCTICAS PRODUCT OWNER
- 64. REPOSITORIO DE IDEAS El Product Owner usa el Product Backlog como un repositorio de ideas y requerimientos. 64 05 MALAS PRÁCTICAS PRODUCT OWNER
- 65. PO PART-TIME / COPYPASTE El Product Owner no trabaja en el Product Backlog diariamente. 65 06 MALAS PRÁCTICAS PRODUCT OWNER
- 66. PO DOMINANTE El Product Owner crea historias de usuario agregando el “cómo” hacerlo. 66 07 MALAS PRÁCTICAS PRODUCT OWNER
- 67. SAbELOTODO El Product Owner no involucra a los stakeholders o expertos para representar su visión. 67 07 MALAS PRÁCTICAS PRODUCT OWNER
- 68. TRABAJO ADICIONAL El Product Owner agrega tareas al Sprint Backlog por considerarlas de suma urgencia. 68 07 MALAS PRÁCTICAS PRODUCT OWNER
- 69. CASI TERMINADO El Product Owner muestra en el Sprint Review historias que no están “Terminadas” como si lo estuvieran. 69 08 MALAS PRÁCTICAS PRODUCT OWNER
- 70. DT SUMISO El Dev Team cumple con las demandas del PO sin discusión. 70 01 MALAS PRÁCTICAS DEV TEAM
- 71. CERO DEUDA tÉCNICA El Dev Team no reclama tiempo o recursos para atacar bugs o mejorar el producto. 71 02 MALAS PRÁCTICAS DEV TEAM
- 72. TIEMPO DE REFINAMIENTO El Dev Team no dedica tiempo suficiente para refinar el Backlog (o le dedica demasiado) 72 03 MALAS PRÁCTICAS DEV TEAM
- 73. DAILY PLANNING El Dev Team utiliza la Daily para discutir requerimientos, refinar historias y hacer una suerte de mini Sprint Planning. 73 04 MALAS PRÁCTICAS DEV TEAM
- 74. MONÓLOGOS No se respeta la regla del Time-Boxed comenzando monólogos. 74 05 MALAS PRÁCTICAS DEV TEAM
- 75. TINO Y GARGAMUZA Faltas de repeto, burlas, comentarios sarcásticos sobre otro miembro del equipo o sus opiniones. 75 06 MALAS PRÁCTICAS DEV TEAM
- 76. FALTA DE PREPARACIÓN No recordar en lo que se estuvo trabajando, o considerarlo poco importante. 76 07 MALAS PRÁCTICAS DEV TEAM
- 77. SIDE PROJECTS El Dev Team trabaja en otras tareas por fuera del Objetivo del Sprint y el Product Owner se entera en el Sprint Review. 77 08 MALAS PRÁCTICAS DEV TEAM
- 78. SIN RUTINA El Daily Scrum no se produce a la misma hora todos los días. 78 01 MALAS PRÁCTICAS SCRUM MASTER
- 79. Asignaciones El Scrum Master asigna las tareas de cada miembro del Dev Team 79 02 MALAS PRÁCTICAS SCRUM MASTER
- 80. TE QUITO UN MINUTO, PUEDER SER? Managers esperan el final de la Daily para hablar con algún miembro del equipo individualmente y solicitarle un reporte más detallado. 80 03 MALAS PRÁCTICAS SCRUM MASTER
- 81. SPRINTS IRREGULARES Los Sprints tienen duraciones irregulares, por ejemplo, cuando no se completan todas las tareas y se extienden a conveniencia. 81 04 MALAS PRÁCTICAS SCRUM MASTER
- 82. MICROMANAGEMENT El Scrum Master impone su forma de organización al Dev Team 82 05 MALAS PRÁCTICAS SCRUM MASTER
- 83. SUPER CODER HERO El Scrum Master permite que regularmente aparezca un “héroe” que resuelve cosas para salvar el Sprint. 83 06 MALAS PRÁCTICAS SCRUM MASTER
- 84. SPRINTS DE MEJORA Se organiza un Sprint de mejoras sin aportar valor real al Incremento. 84 07 MALAS PRÁCTICAS SCRUM MASTER
- 86. EL EQUIPO Comunicar a toda la empresa que se va a trabajar en un nuevo proyecto utilizando Scrum en su totalidad. 86 01 EL CAMINO A SCRUM
- 87. EL EQUIPO Proponer que los interesados se autopostulen para ser parte del Scrum Team #1 87 02 EL CAMINO A SCRUM
- 88. EL EQUIPO Reunir a todos los postulantes en una sala, (opcionalmente) repasar los conceptos principales de Scrum y proponer que entre ellos se elijan los que finalmente van a participar del ST#1 Keywords: valores de Scrum, autoorganizados, multidisciplinario 88 03 EL CAMINO A SCRUM
- 89. EL PROYECTO Seleccionar un proyecto para ser desarrollado en su totalidad por el ST#1. Idealmente debería ser un proyecto nuevo, en el cuál se comunique al cliente la modalidad. En caso que sea imposible, seleccionar el mejor prospects entre los proyectos en marcha. 89 04 EL CAMINO A SCRUM
- 90. EL VIAJE Elegidos el ST#1 y el PS#1, comenzar por el setup de los artefactos y la agenda de eventos. Es importante la transparencia y la comunicación constante al resto de la compañía. 90 05 EL CAMINO A SCRUM
- 91. EL MAPA NO ES EL CAMINO Finalmente, ser pacientes y colaborativos con uno mismo y con el resto del equipo. Eso aplica tanto para los cerdos como para las gallinas. Los resultados no se van a ver en el primer ni en el segundo Sprint, tomará al menos tres o cuatro antes de comenzar a ver mejoras en el proceso. 91 06 EL CAMINO A SCRUM
- 92. Scrum es algo que sólo puedes aprender con la práctica.
- 93. ¿Preguntas?
- 94. MUCHAS GRACIAS MAX KRASZEWSKI / NADINA MAZZITELLI minimalart.co minimalartminimalart