Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Un poco más de Agile y Scrum à la Pablo

La presentación cubre:

-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.

  • Soyez le premier à commenter

Un poco más de Agile y Scrum à la Pablo

  1. 1. Waterfall Agile y Lean Startup Scrum - Contexto Scrum - Roles Scrum - Eventos Scrum - Herramientas De qué vamos a hablar
  2. 2. (2003 – 2008) Ing. Informático UPV (2008-2011) Program Manager Microsoft (2011-2014) Product Manager / Product Owner Softonic (2015-2015) Product Manager / Agile Coach Packlink (2015-2015) Product Manager / Agile Coach EsLife (2015 – 2016) Agile Coach Pocketworks (2016-Ahora) Product Manager Schibsted (Milanuncios) Certified Professional Scrum Master Scrum.org Y tú, ¿quién eres?
  3. 3. De dónde venimos
  4. 4. Requisitos Análisis Diseño Desarrollo Validación Mantenimiento Waterfall
  5. 5. Cuando la cascada se queda seca…
  6. 6. Hay que saber exactamente qué se quiere desde el principio – Se confía en que los requisitos se han tomado bien – No se esperan cambios a mitad del proyecto
  7. 7. Si hay que hacer cambios, hay que volver a empezar desde la fase 1.
  8. 8. Documentación obsoleta prácticamente en cuanto se escribe. Es una inversión poco óptima de tiempo y esfuerzo.
  9. 9. Agile Utah. Febrero de 2001
  10. 10. Procesos y herramientas Documentación extensiva Negociación contractual Seguir un plan Individuos e interacciones Software funcionando Colaboración con el cliente Adaptación al cambio http://agilemanifesto.org Agile Manifesto
  11. 11. • Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. • Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. • Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. • Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. • 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. • 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. • El software funcionando es la medida principal de progreso. • Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. • La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. • La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. • Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados. • A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia 12 Principios de Agile http://agilemanifesto.org
  12. 12. • Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. • Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. • Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. • Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. • 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. • 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. • El software funcionando es la medida principal de progreso. • Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. • La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. • La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. • Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados. • A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia 12 Principios de Agile http://agilemanifesto.org
  13. 13. Proceso Iterativo e incremental Agile en pocas palabras Foco Datos y cliente Equipo Autogestionado y multidisciplinar
  14. 14. Requisitos Análisis Diseño Desarrollo Validación Mantenimiento Comparativa entre metodologías Iteración 1 Iteración 2 Iteración 3 … Iteración N Waterfall Agile
  15. 15. Waterfall Agile Entorno Predictivo Cambiante Proceso Secuencial Iterativo Investigación y definición Al principio En cada iteración Planificación Largo plazo Corto plazo Interacción con el cliente Principio y final En cada iteración Desarrollo Linear Iterativo Flexibilidad ante cambios Baja Alta Tiempo de reacción ante errores Alto Bajo Entrega Al final Incremental Responsable Project Manager Equipo Equipo Por disciplinas Multifuncionales Documentación Extensa Sólo la imprescindible Comparativa entre metodologías
  16. 16. Con dibujos  http://www.projectcartoon.com Iteración 1 Iteración 2 Entrega final Entrega final
  17. 17. Con dibujos  http://effectivesoftwaredesign.com/
  18. 18. Lean Startup
  19. 19. Lean Startup
  20. 20. Agile en el Mundo Real
  21. 21. Quién está usando Agile
  22. 22. Cómo lo están aplicando + Prescriptivo + AdaptableDSDM XP SCRUM KANBAN POR LIBRE VersionOne 10th Annual State of Agile Report
  23. 23. 1. Acelerar la entrega de producto 2. Mejorar la gestión de cambios de prioridades 3. Mejorar la productividad Por qué lo están usando VersionOne 10th Annual State of Agile Report
  24. 24. 1. Mejorar la gestión de cambios de prioridades 2. Mejorar la productividad 3. Mejorar la visibilidad del proyecto Qué están obteniendo VersionOne 10th Annual State of Agile Report
  25. 25. 1. Cultura de empresa no alineada con metodologías ágiles 2. Falta de experiencia con metodologías ágiles 3. Falta de soporte por parte de dirección Por qué no les está funcionado VersionOne 10th Annual State of Agile Report
  26. 26. SCRUM
  27. 27. Transparencia Definiciones y resultados disponibles para todos Los pilares de SCRUM Inspección Revisión crítica y frecuente de procesos y progreso Adaptación Ajustar procesos y herramientas si se detectan desvío
  28. 28. Organización dividida en equipos pequeños, multidisciplinares y auto-organizados. Organización
  29. 29. Trabajo dividido en una lista priorizada y estimada de pequeñas tareas que aporten valor. Trabajo
  30. 30. Tiempo Iteraciones cortas con código potencialmente entregable y demostrable al final de cada iteración.
  31. 31. Prioridades Prioridades actualizadas después de cada iteración en base a datos y feedback del cliente
  32. 32. Procesos Procesos optimizados haciendo una retrospectiva después de cada iteración, en base a la nueva experiencia adquirida.
  33. 33. Scrum Kanban Iteraciones Tiempo fijo (1-4 semanas) Sin tiempo fijo Compromiso Compromiso de entrega por sprint Sin compromiso Equipo Equipos multidisciplinares Opcional Planificación Planificación por sprint Sin planificación Tamaño de tareas Tienen que caber en 1 sprint Sin tamaño definido Estimaciones Obligatorias Sin estimaciones WiP Limitado por la capacidad del sprint Limitado por dev Roles PO, SM, Dev Team Sin roles Reuniones Planning, Daily, Retro, Demo Sin reuniones Board Se empieza en cada sprint Siempre el mismo SCRUM vs. KANBAN
  34. 34. Los intocables
  35. 35. Elementos intocables (aunque ampliables) Roles • Product Owner • Scrum Master • Development Team Ceremonias • Sprint planning • Daily Scrum • Demo • Retro Artefactos • Product backlog • Sprint backlog • Incremento
  36. 36. Roles Product Owner • Gestionar el Product Backlog • Resolver dudas de negocio Scrum Master • Guía espiritual de Scrum • Facilitar y ayudar con impedimentos Development Team • Gestionar tareas sprint • Decidir cómo implementar la solución
  37. 37. Product Owners • Los responsables de maximizar el valor aportado por el trabajo del Dev. Team. • Responsables de definir, gestionar y priorizar el backlog. • Resuelven las dudas de negocio al Dev. Team. • Definen qué se hace, pero no cómo. Validan la entrega final. • Son los únicos que pueden decir al Dev Team en qué trabajar.
  38. 38. Product Owner/Manager vs. Project Manager POs/PMs centrados en el producto: • Medio-largo plazo: – Visión y estrategia del producto – Inputs: Clientes, mercado, competidores, etc. • Corto plazo: – Trabajan codo con codo con el equipo de desarrollo – Aterrizan esa visión en historias de usuario
  39. 39. Product Owner/Manager vs. Project Manager Project Managers centrados en el proceso: • Tiempos • Presupuesto • Gestión con clientes/partners
  40. 40. Scrum Master • Gurú de Scrum. Guía espiritual en esta metodología. • Responsable de que se entienda y se cumpla la metodología. • Asistente del Dev Team, PO y Stakeholders para resolver dudas, quitar impedimentos, facilitar ceremonias, promover mejoras.
  41. 41. Qué NO es el Scrum Master • No es el jefe del proyecto. • No es el representante del equipo de desarrollo. • No es la máxima autoridad técnica en ninguna tecnología. • No establece prioridades. • No define cómo implementar la solución. • No es responsable de la entrega a final de sprint.
  42. 42. Development Team • Definen e implementan el “cómo” frente al “qué” de los POs. Sólo trabajan en tareas añadidas por los POs. • Equipo multidisciplinar y autogestionado. • Comprometidos a aportar valor al final de cada sprint. • No hay individuos ni roles, sólo miembros de un equipo. • El éxito o fracaso son grupales.
  43. 43. Development Lead • Otro miembro del equipo de desarrollo. • Punto de referencia técnico en su disciplina. • Guía para el resto de desarrolladores a nivel de arquitectura y diseño. • Primer punto de contacto del PO con el Dev Team. • NO es el único responsable técnico. • NO toma las decisiones técnicas en solitario. No se impone, sino que promueve el trabajo en equipo. • No tiene por qué ser el más avanzado en todas las tecnologías.
  44. 44. Dev Team & Gremios • Los equipos mutidisciplinares siguen teniendo especialistas en distintas tecnologías. • Los especialistas de cada equipo pueden juntarse en gremios/comunidades de práctica para compartir experiencias.
  45. 45. Stakeholders y Clientes • Expresan necesidades y sugieren nuevas funcionalidades a los POs. • NO hablan directamente con el equipo de desarrollo, sólo con POs. • Pueden asistir a las Demos. • Pueden validar el desarrollo de funcionalidades. • Como clientes, o sus representantes, tienen el foco de atención del resto de roles (gestionados por los POs).
  46. 46. Ceremonias Sprint Planning Daily Scrum Grooming Demo Retro
  47. 47. Antes de empezar con las reuniones… Puntualidad Hay que prepararlo todo antes de empezar. Sin cacharros No se llevan ni portátiles, ni móviles. Papel y boli. Contexto Recordad por qué se tiene la reunión, los temas a tratar y el objetivo. Control del tiempo Cada tema se trata en su slot. Si salen temas nuevos, se dejan para el final. Notas Alguien debe tomar notas de lo que se trata en la reunión, par enviarlo al finalizar. Responsables Para cada acción pendiente, se acuerda un responsable y una fecha de entrega.
  48. 48. Sprint Planning ¿Quién? • Dev Team • Product Owner • Scrum Master ¿Cuándo? • Inicio de sprint • 4h máximo (sprint 2 sem.) ¿Qué? • Dev. Team analiza, divide en tareas y estima las historias de la cima del backlog. • Se cierra el compromiso sobre qué se entregará al final del sprint.
  49. 49. Informe de inicio de Sprint • Título del sprint: – Número de Sprint. Ej. Sprint 1. – Semanas cubiertas por el sprint. Ej. Sprint 15-16. – Otros nombres: Ej. Planetas de Star Wars, Personajes de los Simpson, etc. • Objetivo del sprint: Acordado durante el sprint planning. • Capacidad del sprint: Suma de la capacidad de cada Dev. • Sprint backlog: Listado de las historias/tareas a realizar durante el sprint. – Total planificado: Total de puntos de historia planificados . – Capacidad del sprint: Total de puntos de historia disponibles durante el sprint. – Buffer disponible: Puntos no planificados de la capacidad.
  50. 50. Informe de inicio de Sprint
  51. 51. Daily Scrum ¿Quién? • Dev Team • POs y SM (opcionales) ¿Cuándo? • Diariamente • Mismo sitio, misma hora. • Máximo 15min. ¿Qué? • Ayer • Hoy • Impedimentos • (Todos en pie)
  52. 52. Burn-up / Burn-down
  53. 53. Grooming / Refinamiento ¿Quién? • Product Owner • Algunos Devs (como Leads). ¿Cuándo? • 2-3 días antes de la planning • 1 hora máximo (sprint 2 sem.) ¿Qué? • Revisar las historias para el siguiente sprint • Preguntar dudas • Dejar el backlog listo para planning
  54. 54. Demo ¿Quién? • PO • SM • Dev Team • Stakeholders ¿Cuándo? • Al final del sprint • 1,5 hora máximo (sprint de 2 sem.) ¿Qué? • Revisar las historias 100% hechas (según DoD) • Punto de partida para el siguiente sprint.
  55. 55. Informe de cierre de Sprint • Tareas planificadas y terminadas: Tareas inicialmente planificadas para el sprint que se consideran Done (según la DoD). • Tareas planificadas y no terminadas: Tareas inicialmente planificadas para el sprint que no se consideran Done. • Tareas no planificadas y terminadas: Tareas que no se incluyeron en la planificación inicial pero que se han terminado en el sprint. • Resumen: Resumen de la capacidad, los puntos de historia planificados, los terminados y los no planificados.
  56. 56. Informe de cierre de Sprint
  57. 57. Retrospectiva ¿Quién? • PO • SM • Dev Team ¿Cuándo? • Al final del sprint • 2 hora máx. (sprint 2 sem.) ¿Qué? • Analizar cómo ha ido el sprint • Proponer mejoras y potenciar lo que funciona • Revisar compromisos de la retro anterior
  58. 58. Informe de Action Items
  59. 59. Herramientas Product Backlog Épicas, Historias, Tareas Historias de usuario Bugs Versiones Estimaciones Nivel de cariño Definition of Done (DoD) Sprint Backlog Sprint Dashboard
  60. 60. Product Backlog • Sólo lo actualiza el Product Owner. – Aunque las estimaciones únicamente las proporciona el Dev Team. • Contiene todo en lo que se va a trabajar en futuros sprints. • Sólo hay 1 backlog por producto, aunque haya varios equipos. • Es un listado priorizado, con un nivel de detalle decreciente. • Visibile para stakeholders y el resto de la organización.
  61. 61. Product Backlog - Detalle - Prioridad + Detalle + Prioridad Siguiente sprint Siguiente par de sprints Futuro
  62. 62. Épicas, Historias, Subtareas, Tareas y Bugs Épica Historia Usuario 1 HU 2 Historia Usuario N Subtarea 1 ST 2 ST N Tarea… … Bug
  63. 63. Historias de usuario • Título: Título descriptivo- • Descripción: Siguiendo el formato Como… Quiero…Para… – El Como… es desde el punto de vista del usuario final, no del reporter. • Due date (opcional): Para cuándo tiene que estar listo (si aplica). • Criterios de aceptación: Aquello que se va a comprobar para decidir si está lista para subir. • Nivel de cariño: Indica qué nivel de detalle hay que incluir dependiendo de si es algo que se va a quedar, si es un test o un parche temporal. • Épica: Grupo de funcionalidades a la que pertenece la historia. • Reporter: Quién lo ha solicitado, por si hay dudas en el futuro. • Estimación inicial: Estimación de alto nivel del Dev Team.
  64. 64. Bug template • Título: Título descriptivo • Descripción: Descripción del error • Pasos para reproducir el error: – 1) – 2) – 3) • Comportamiento actual: Qué pasa cuando se siguen los pasos anteriores • Comportamiento esperado: Qué debería pasar al seguir los pasos anteriores • Versión: En qué versión del product pasa el error • Plataforma: En qué plataforma pasa el error • Información adicional: Más información que no se haya cubierto en los campos anteriores
  65. 65. Versiones Épica Historia Usuario 1 HU 2 Historia Usuario N Subtarea 1 ST 2 ST N Tarea … … Bug Épica Historia Usuario 1 HU 2 Historia Usuario N Subtarea 1 ST 2 ST N Tarea … … Bug Épica Historia Usuario 1 HU 2 Historia Usuario N Subtarea 1 ST 2 ST N Tarea … … Bug
  66. 66. Estimaciones • Aproximación del esfuerzo necesario para realizar cada tarea. • NO se usan ni días ni horas, sino puntos de historia. Sólo son válidas cifras de la secuencia de Fibonacci – 0,1,1,2,3,5,8,13,21,34… • Se toma como punto de partida una tarea muy sencilla. Ejemplo: Añadir una imagen • Hay que ser realistas, pero es mejor no quedarse corto.
  67. 67. Planning Poker • Técnica de estimación consensuada durante la sesión de planning. • Después de analizar una historia de usuario, todos los desarrolladores seleccionan una de las cartas de estimación. • Si hay consenso, se anota la estimación. Si no, se ponen en común los distintos puntos de vista hasta llegar a un acuerdo.
  68. 68. Puntos vs. Valor • Puntos Estimados: Estimación inicial del esfuerzo para realizar la tarea. • Esfuerzo real: Una vez terminada la tarea, el esfuerzo real invertido en realizarla. • Valor: Valor aportado al cliente cuando la tarea está en producción.
  69. 69. Delivery
  70. 70. Delivery
  71. 71. Análisis de estimaciones • Junto al listado de tareas planificadas y sus estimaciones iniciales. • Cuando una tarea se pasa a Done, se añade el esfuerzo real invertido. • Para identificar desviaciones y aprender de cara a futuras estimaciones.
  72. 72. Análisis de estimaciones
  73. 73. Nivel de cariño Nivel de cariño Calidad de código Explicación Ejemplo (Amazon) Rollete de una noche Baja Bajo riesgo, tráfico medio, conocimiento sin validar, con posibilidades de que cambie Experimento en una landing informativa Rollo de verano Media Riesgo medio-alto, tráfico bajo, conocimiento sin validar, con posibilidades de que cambie Experimento en el funnel de compra Novieta Alta Riesgo bajo, tráfico bajo-medio, conocimiento validado, poco probable que cambie Cambios en el perfil del usuario Novia formal Muy alta Crítico, tráfico medio-alto, alto impacto en usuarios, validado, poco probable que cambie Integración de una nueva plataforma de pago Boda Extrema Crítico para el funcionamiento del producto, validado y poco probable que cambie Tramitación de compra y envío
  74. 74. Definition of Done (DoD) • Definición de qué significa que algo está 100% hecho. • Una historia no está terminada si no se satisfacen todas las condiciones de la DoD. • Lo definen Dev Team + PO.
  75. 75. Sprint Backlog • Items del Product Backlog que se harán en el sprint. • Se cierra al final del sprint planning. • Todas las historias están estimadas y divididas en tareas más pequeñas (también estimadas). • Sólo se pueden añadir tareas “haciendo hueco” (quitando otras). • El Dev Team se compromete a terminar todo lo que deciden que entra.
  76. 76. Sprint Dashboard • Refleja el estado de todas las historias/tareas/bugs del sprint. • Permite ver si hay algún “problema” en función de la distribución de las tareas. • Idealmente, se trabaja con versión online y física. – El online se actualiza al momento, en cuanto hay cambios en la tarea. – El físico se puede actualizar durante el Daily Scrum. • Los encargados de mantenerlo son el Dev Team. • Se pueden usar post-it de varios colores para identificar distintos tipos de ítems (Historias, Tareas, Bugs, Tickets, etc.) • Se puede usar una sección para imprevistos con | Fuegos | Must | ASAP|
  77. 77. Sprint Dashboard ToDo InProgress Buffer Peer Review Testing Pre To upload Testing Prod Done Blocked Fuego Must ASAP SPRINT BOARD FIREFIGHTER BOARD
  78. 78. Cómo se puede aplicar Shu Sigue las normas para aprender la base Ri Encuentra tu propio camino aprendiendo de tus experiencias Ha Rompe con la tradición, sé creativo e investiga por tu cuenta
  79. 79. Pabgarm (at) Gmail (dot) com @pabgarm https://es.linkedin.com/in/pabgarm ¡Gracias! Para dudas, comentarios, preguntas y/o feedback:
  80. 80. Referencias Guía oficial de Scrum • Ken Schwaber & Jeff Sutherland. Creadores de Scrum • Link: http://www.scrumguides.org/ The Scrum Master Training Manual • Nader K. Rad, Frank Turley. Management Plaza • Link: http://mplaza.pm/product/scrum-master-training-manual/ Otros • https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf • http://agilemanifesto.org/ • http://www.scrumguides.org/ • Kanban and Scrum - Making the Most of Both by Henrik Kniberg and Mattias Skarin • The Scrum Master training manual, By Nader K. Rad, Frank Turley • https://en.wikipedia.org/wiki/Shuhari

    Soyez le premier à commenter

    Identifiez-vous pour voir les commentaires

  • FernandoDiazdelaSern

    Jan. 30, 2017
  • ClaudiaGonzalez17

    Apr. 3, 2017
  • sebastiancari

    Aug. 8, 2020
  • JosRoldnOrozco

    Mar. 1, 2021

La presentación cubre: -Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall Agile y Lean Startup - Los pilares de Scrum; ---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo. ---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva. ---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad. ---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.

Vues

Nombre de vues

941

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

3

Actions

Téléchargements

117

Partages

0

Commentaires

0

Mentions J'aime

4

×