Mitos y leyendas de la gestión ágil y scrum

1,005 views

Published on

Ing. Mariel Feder Szafir, MC, PMP
IEEE - ORT presentación 4-julio-2013

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,005
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Mitos y leyendas de la gestión ágil y scrum

  1. 1. Mitos y Leyendas de la Gestión Ágil deGestión Ágil de Proyectos Ing. Mariel Feder Szafir, MC, PMP
  2. 2. El contexto • Proyectos de TI, la constante es el cambio. • Introducción de nuevas tecnologías • Reglas de negocios que cambian rápidamente. • Liberaciones parciales que modifican las expectativas Los requerimientos están apareciendo en mi mente en este momento Ahora están cambiando… Cambiando… cambiando… Cambiando… Ok. No, espere… cambiando… Cambiando… fin. Por supuesto, no compartiré estas ideas con el departamento de Ingeniería. Ok, Ya presupuesté matones para obtenerlas
  3. 3. Manifiesto Ágil • Priorizar: • Individuos e interacciones sobre procesos y herramientas • Software funcionando sobre documentación completa • Colaboración con el cliente sobre negociación contractual • Respuesta ante el cambio sobre seguir un plan• Respuesta ante el cambio sobre seguir un plan • Esto es, aunque se valora los elementos de la derecha, se prioriza los primeros.
  4. 4. 12 principios • 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.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.
  5. 5. 12 principios • 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.
  6. 6. Concepto Ágil • La agilidad es un marco común, las metodologías implementaciones
  7. 7. “Metodologías”Ágiles más populares • SCRUM • Lean • XP = Exterme Programming • TDD = Test Design Driven • Dynamic Systems Development Method (DSDM) (FDD) • Lean Software Development (LSD) • Kanban • Open Unified Process (OpenUP) • Programación Extrema (XP)Method (DSDM) • 1643551(ASD) • Agile Unified Process (AUP) • Crystal Clear • Agile Modeling • Essential Unified Process (EssUP) • Feature Driven Development • Programación Extrema (XP) • Método de desarrollo de sistemas dinámicos (DSDM) • G300 (o también llamada del 300%).
  8. 8. Conceptos en Común • Desarrollo incremental con ciclos cortos • Cooperación entre cliente y desarrollador y mucha comunicación personal • Capacidad de adaptación, incorporación de cambios (vs PLAN- DRIVEN )DRIVEN )
  9. 9. Comparación Área Ágiles Tradicionales/Predictivas Desarrolladores Ágiles, con mucho conocimiento, comprometidos, colaboración Orientados al plan, habilidades adecuadas, acceso a conocimiento externo Clientes Dedicado, relación de confianza, colaborador, representativo, empowered Acceso al conocimiento, colaborador, representativo, empowered Requerimientos Emergentes, cambian rápidamente Definidos al comienzo, mayormenteRequerimientos Emergentes, cambian rápidamente Definidos al comienzo, mayormente estables Arquitectura Diseño para los requerimientos en curso Diseño para requerimientos actuales y previstos Cambios No es tan caro Caro Tamaño Productos y equipos chicos y medianos Grandes equipos y productos Objetivo principalGenerar valor rápidamente Generar seguridad
  10. 10. SCRUM
  11. 11. SCRUM • Es un proceso de gestión. No hace referencia al proceso de ingeniería. • Aplicado a programas se conoce como Scrum de Scrums
  12. 12. Principio básico • Durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva yenfrentados de una forma predictiva y planificada. • Como el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes
  13. 13. Elementos de la metodología • Roles • Reglas • Artefactos
  14. 14. SCRUM - Roles • Product Owner: La voz del cliente • Scrum Master: Facilitador • Equipo de desarrollo • Roles auxiliares:• Roles auxiliares: • Stakeholders (interesados) • Managers (administradores)
  15. 15. Product Owner • Define los requerimientos que conforman el producto. • Decide la fecha de entrega y el contenido de cada una. • Responsable del Retorno de la Inversión con el cliente. • Prioriza cada requerimiento en base al valor del mercado. • Único responsable del listado global de requerimientos.• Único responsable del listado global de requerimientos. • Aprueba o rechaza versiones entregables y funcionales post iteración. • Es la voz del cliente para con el equipo.
  16. 16. Scrum Master • Representa y administra el proyecto. • Responsable de la correcta aplicación de la metodología. • Promueve la eficiencia del equipo. • Optimiza la sinergia entre el equipo, los interesados y el cliente.cliente. • Es la barrera entre el equipo y los interesados.
  17. 17. Equipo de Desarrollo • Multidisciplinario: Analistas, Programadores, Diseñadores, Testers, QA,DBA, etc. • De tiempo completo. Casi excluyente. • Auto‐organizado: No necesitan un líder para• Auto‐organizado: No necesitan un líder para funcionar. La asignación de tareas es dinámica. • Modificable únicamente entre sprints. • Comprometidos con el objetivo de cada sprint y los objetivos globales de negocio.
  18. 18. Artefactos • Product Backlog • Sprint Backlog • Product • Sprint Goal
  19. 19. Product Backlog • A cargo del Product Owner. • Es una lista de funcionalidades priorizadas por el cliente y estimadas según el esfuerzo a realizar para desarrollarlas. • Deben ser simples para no generar complejidades y re-trabajo.re-trabajo.
  20. 20. Sprint Backlog • No se modifica durante la iteración. • Son las funcionalidades, en orden de prioridad, a realizar durante la siguiente iteración. • Es el Team el encargado de auto-organizarse para realizar el trabajo planificado.trabajo planificado.
  21. 21. Sprint Goal • Objetivo del Sprint. • El Team debe tener siempre en claro el mismo, para estar enfocado en su cumplimiento. • Este objetivo es informado en la Sprint Planning Meeting.
  22. 22. Producto • Entregable producto de la iteración • No es un prototipo, es un entregable funcional sobre lo pactado en el Sprint. • No se puede generar un entregable parcial, debe ser tal como se comprometió que se realizaría.se comprometió que se realizaría.
  23. 23. Reglas • Sprint • Sprint Planning Meeting • Daily Scrum Meeting Sprint • Sprint Review Meeting • Sprint Retrospective Meeting• Sprint Retrospective Meeting
  24. 24. Sprint • Duración de 2 a 4 semanas. • El trabajo se realiza de manera dinámica pero se debe documentar lo realizado (sin que la misma atrase el trabajo realizado). • El sprint backlog es fijo sin poder modificarlo hasta el final• El sprint backlog es fijo sin poder modificarlo hasta el final de la iteración. • En caso de que se considere, el Scrum Master con la aprobación del cliente puede cortar la iteración y re‐planificar las siguientes.
  25. 25. Sprint • Si se termina antes de lo planeado, se puede hablar con el Product Owner para analizar si es conveniente incluir nuevas funcionalidades a la misma.misma. • En caso de que se considere, el Scrum Master con la aprobación del cliente puede subdividir las funcionalidades en unidades más pequeñas e incluirlas en la iteración corriente y dejar las otras pendientes para ser replanificadas
  26. 26. Sprint planning Meeting • 2 segmentos de 4 horas cada una. • En la 1er sección se genera el product backlog. • En la 2da sección se genera el sprint backlog. • No debe estar presente ningún interesado• No debe estar presente ningún interesado • Luego de trabajado el product backlog se trabaja sobre los supuestos del mismo para producir el Sprint Backlog.
  27. 27. Daily Scrum Meeting • Reunión de 15 minutos. • Se responde a 3 preguntas. • ¿Qué se ha hecho desde la última reunión? • ¿Qué se hará hasta la próxima reunión?• ¿Qué se hará hasta la próxima reunión? • ¿Qué inconvenientes se presentaron para impedir que el trabajo se realizara como estaba planeado? • Si se genera algún tipo de debate, se deja debidamente registrado y se trata en otra reunión.
  28. 28. Sprint Review Meeting • Duración 4 horas. • Se invierte 1 hora máximo en la preparación de la misma. • La presenta el Team al Product Owner e interesados. • No se informa funcionalidad incompleta.
  29. 29. Sprint Review Meeting • Se debe realizar sobre el ambiente de prueba correspondiente. • Se comienza informando el objetivo de la iteración para luego mostrar las funcionalidades que permiten alcanzarlo.que permiten alcanzarlo. • Se obtiene información sobre lo realizado para usarlo como lección aprendida. • Al final se planifica la fecha y el lugar para la próxima reunión.
  30. 30. Sprint Retrospective Meeting • Duración 3 horas. • Están presentes el Team, el Scrum Master y opcionalmente el Product Owner. • Se realizan 2 preguntas:• Se realizan 2 preguntas: • ¿Qué se hizo bien en la iteración pasada? • ¿Qué se puede mejorar para la próxima iteración? • Se registran las respuestas de los participantes para plasmarlas como lecciones aprendidas para futuras iteraciones.
  31. 31. Conceptos adicionales • Ciclo de trabajo cortos • Replanificaciones controladas • Team Velocity
  32. 32. Estimación • Story Points • Dias Ideales • Se prioriza y analiza por funcionalidad y no por actividad. • Se separa la estimación de la duración.• Se separa la estimación de la duración. • En base a las funcionalidades, la estimación y la duración deducida se genera el calendario.
  33. 33. Supuestos para la estimación • Sólo trabajaré en la User Story que estoy estimando. • Todo lo que necesite para desarrollar la User Story estará disponible cuando lo necesite. • No habrá interrupciones durante el transcurso del desarrollo de la User Story.de la User Story.
  34. 34. Reestimaciones • La cantidad de Story points de una User Story no varía salvo que se modifique el alcance. • La duración en el tiempo va cambiando al final de cada iteración en función de la velocidad obtenida.
  35. 35. Planificación – Release Plan 1- Determinar las condiciones a satisfacer 2-Estimar las user stories 3- Determinar la duración de la iteración 4-Estimar la velocidad del equipo 5-Priorizar las user stories 6-Seleccionar las user stories y la fecha del release
  36. 36. Planificación
  37. 37. Sprint Planning Meeting – “Velocity Driven” 1 -Ajustar prioridades 2-Determinar la velocidad del equipo 3-Identificar el objetivo de la iteraciónequipo iteración 4-Seleccionar las user stories 5-Dividir las user stories en actividades 6-Estimar las actividades
  38. 38. Sprint Backlog - Ejemplo
  39. 39. Kanban
  40. 40. Dimes y Diretes
  41. 41. Mito nro 1 • Ser ágil implica informalidad • dinámico no es lo mismo que informal
  42. 42. Mito nro 2 • En un proyecto Ágil no es necesario estimar ni planificar • estimación continua • planificación iterativa
  43. 43. Mito nro 3 • Se puede aplicar gestión ágil en todos los proyectos de software y con todos los clientes.
  44. 44. Factores a considerar • tamaño • complejidad • criticidad • competencias del personal • cultura, riesgo, limitaciones• cultura, riesgo, limitaciones • dependencias entre funcionalidades • estimación de costo y esfuerzo • alineación con la estrategia, planes de TI y otros • intereses de los stakeholders.
  45. 45. Factores a considerar
  46. 46. Criterios a considerar • Personas • Tecnología • Procesos
  47. 47. Mito nro 4 • No es necesario definir el alcance del proyecto. No se requiere gestión del alcance.
  48. 48. Mito nro 5 • No es necesario un Project Manager. El equipo se autogestiona. • El rol de Scrum Master sustituye al Project Manager completamente
  49. 49. Mito nro 6 • Se pueden introducir cambios en cualquier momento del proyecto, en el momento en que se hacen necesarios. No es necesario realizar gestión del cambio. • Distinguir entre corrección y nuevo requerimiento • Incorporación del cambio en el proyecto • La clave está en la gestión del cambio• La clave está en la gestión del cambio
  50. 50. Mito nro 7 • No es necesario realizar gestión de riesgos.
  51. 51. Mito nro 8 • Como no hay un “plan”, no es necesario realizar tareas de monitoreo. Tampoco hay indicadores o gráficos que puedan utilizarse.
  52. 52. Ejemplos de monitoreo • Team Velocity = velocidad del equipo
  53. 53. Ejemplos de monitoreo • Release Burndown chart
  54. 54. Ejemplos de monitoreo • Release Burndown BAR chart
  55. 55. Ejemplos de monitoreo • Parking lot
  56. 56. Ejemplos de monitoreo • Iteration Burn down chart
  57. 57. Ejemplos de monitoreo • Diagrama de Gantt / Release Plan
  58. 58. Mito nro 8 • Todas las estrategias Ágiles son Metodologías Ágiles . • Todas las Metodologías Ágiles son o incluyen metodologías de Gestión. • Scrum y las metodologías ágiles en general cubren las 9 áreas del conocimiento.del conocimiento.
  59. 59. Cobertura
  60. 60. Mito Nro 9 • El product backlog es suficiente para todas las actividades.
  61. 61. Mito nro 10 • Es simple realizar contratos asociados a proyectos gestionados en base a metodologías ágiles. • Contratos de alcance variable
  62. 62. Conclusiones ….
  63. 63. Reflexiones Vamos a intentar algo que se llama Programación Ágil Eso significa no más planificación y no más documentación. Solo escribir código y quejarse Que bueno que lo que hacemos ahora tiene un nombre
  64. 64. Bibliografía • Manifiesto Ágil: www.agilmanifesto.org • Project Management the Agile Way John C. Goodpasture Describe varios métodos agiles. Es una guía de como evaluar y seleccionar la mejor para un caso particular y cuando las metodologías agiles no son la mejor opción.agiles no son la mejor opción. • Making sense o Agile Project management: Balancing Control And Agility Charles G. Cobb (2011) Como los proyectos agiles encajan en el modelo general de gestión para lograr estrategias mas efectivas. Trae casos resales mostrando buenas y malas aplicaciones de ágil, discutiendo las metodologías agiles y no agiles.
  65. 65. Biblografía • Scrum Project Management Kim H. Pries y Jon M. Quigley (2010) Introduce los conceptos básicos de scrum y aplica como adaptarlos para gestionar efectivamente un amplio ramo de programas y proyectos complejos. Provee métodos de planificación para controlar el alcance y asegurar que el proyecto cumple el cronograma, incluyendo métodos scrum de seguimiento para ayudar al equipo a mejorar su resultados y comunicación. El autor demuestra como combinar elementos de gestión de proyectos tradicional con scrum y discute la improvisación, solucionesde gestión de proyectos tradicional con scrum y discute la improvisación, soluciones creativas a problemas y fenómenos emergentes. • Agile Estimating and Planning Mike Cohn; Prentice Hall Professional Technical Reference, 2006 Traditional, deterministic approaches to planning and estimating simply don't cut it on the slippery slopes of today's dynamic, change-driven projects. Mike Cohn's breakthrough book gives us not only the philosophy, but also the guidelines and a proven set of tools that we need to succeed in planning, estimating, and scheduling projects with a high uncertainty factor. At the same time, the author never loses sight of the need to deliver business value to the customer each step of the way.
  66. 66. Bibliografía • Balancing Agility and Discipline: A Guide for the Perplexed Barry Boehm, Richard Turner; Addison‐Wesley, 2002 Nowadays, there are many methodologies you can introduce your to students. On the one hand, there are the more agile methods that focus on individual projects, and how to get them done fast--the camp represented by Beck and Cockburn. On the other hand, there are the more disciplined methods, focused on setting up organizational processes for getting projects done with predictable high quality--the camp best represented by the SEI, the CMMI, and Humphrey. Although these methods are often presented as mutually exclusive, they actually lie on a continuum. The authors of Balancing Agility and Discipline have worked out clear guidelines for determining where on that continuum a particular software development project is located--and therefore, how agile or disciplined a chosen methodology can or has to be. guidelines for determining where on that continuum a particular software development project is located--and therefore, how agile or disciplined a chosen methodology can or has to be. • Succeeding with Agile: Software Development Using Scrum Mike Cohn; Addison‐Wesley, 2003 This is a guide to starting fast with Scrum and agile–and then succeeding over the long haul. Leading agile consultant and practitioner Mike Cohn presents detailed recommendations, powerful tips, and real-world case studies drawn from his experience helping many software organizations make Scrum and agile work
  67. 67. Bibliografía • Agile Project Management with Scrum (Microsoft Professional) Ken Schwaber; Microsoft Press, 2003 The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But Scrum’s simplicity itself—its lack of prescription—can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co- creator and evangelist Ken Schwaber identifies the real-world lessons—the successes and failures—culled from his years of experience coaching companies in agile project management. Through them, you’ll understand how to use Scrum to solve complex problems and drive better results—delivering more valuable software faster. • Scrum and XP from the Trenches (Enterprise Software Development) Henrik Kniberg; C4 Media, 2007 Analiza casos reales de proyectos gestionados utilizando estas metodologías
  68. 68. Bibliografía • J. Highsmith and A. Cockburn, “Agile Software Development: The Business of Innovation,” Computer, Sept. 2001 • L. Copeland, “Developers Approach Extreme Programming with Caution,” Computerworld, 22 Oct.2001 • Extreme Programming Explained, G. Succi and M. Marchesi, eds.,Addison Wesley Longman, Reading, Mass., 2001 • M. Fowler, “Is Design Dead?” Extreme Programming Explained, G. Succi and M. Marchesi, eds., Addison Wesley Longman, Reading, Mass., 2001 • Fowler Martin, “Fixed Scope Mirage”, September 30th on http://www.martinfowler.com• Fowler Martin, “Fixed Scope Mirage”, September 30th on http://www.martinfowler.com • Beck, Kent and Fowler, Planning Extreme Programming, Addison Wesley, New Jersey 2001. • Beck, Extreme Programming Explained, Addison Wesley, Boston 2004 • Robert Martin, Extreme Programming Development Through Dialog, IEEE software, July August 2000 • Kent Beck, Embracing change with Extreme Programming, IEEE Computer, Octobre 1999. • Peter Stevens, http://www.dosideas.com, Mayo 2009, visited June 2009
  69. 69. Bibliografía • Utilizing Agile principles alongside A Guide to the Project Management Body of Knowledge(PMBOK® Guide) for better project execution and control in software development projects. Mike Griffiths. Originally published as part of 2004 PMI Global Congress Proceedings – Anaheim, California • Enriching PMBOK Guide by practices and techiques of agile• Enriching PMBOK Guide by practices and techiques of agile project management of software development. Alexander S. Lesnevsky. Originally published as part of 2007 PMI Global Congress Proceedings, Budapest. • Agile Project Management and the PMBOK Guide. Michele Sliger. Originally published as part or 2008 PMI Global Congress Proceedings, Denver, Colorado, USA.
  70. 70. Preguntas?Preguntas?
  71. 71. Porquéel Pollocruzóla carretera ágilmente? • EL ANALISTA DE NEGOCIO: Hoy tuve 12 reuniones y no tengo tiempo para entrar en toda la Historia de Usuario. Pero te puedo adelantar que involucra un gallo en un equipo distribuido. • El PROJECT MANAGER AGIL: El pollo no va a poder cruzar la carretera este mes. Los requerimientos estaban previstos para el viernes pasado. Va a tener que esperar su turno en el backlog. A lo mejor puede cruzarla en la iteración 9.mejor puede cruzarla en la iteración 9. • EL DESARROLLADOR: Porque así estaba indicado en los requerimientos. La catapulta resultó el método más eficiente. Cómo? Que tenía que llegar vivo al otro lado? Figuraba esto en los requerimientos? • EL SCRUM MANAGER: Iteremos compañeros. Llevemos al pollo al centro de la ruta hoy, y conversaremos sobre el resto del camino mañana.
  72. 72. Muchas gracias Ing. Mariel Feder Szafir, MC, PMP mfeder@netgate.com.uy

×