Your SlideShare is downloading. ×
Gestion proyectos, metodología ágiles y SCRUM
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Gestion proyectos, metodología ágiles y SCRUM

2,353
views

Published on

Diapositivas del seminario de metodología ágiles en la gestión de proyectos SCRUM …

Diapositivas del seminario de metodología ágiles en la gestión de proyectos SCRUM

https://alexismarin.wordpress.com/

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,353
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
126
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Metodología ágiles y SCRUM Gestión de proyectosNoviembre 2012Este documento ha sido creado con el fin de servir comointroducción a los técnicos y personas que están interesadasen la gestión de proyectos.
  • 2. Manifiesto ágil: • “Individuals and interactions over processes and tools” • “Working software over comprehensive documentation” • “Customer collaboration over contract negotiation” • “Responding to change over following a plan”
  • 3. Jeff Sutherland (a guru) states: • “Scrum assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression.” • “Scrum is an enhancement of the commonly used iterative/incremental object-oriented development cycle”
  • 4. Principios y valores ágiles  La prioridad mayor es la satisfacción del cliente haciendo entregas continuas de software valioso para él  Los cambios son bienvenidos siempre  La medida principal de progreso es el software funcionando  El gestor es un facilitador no un controlador  Equipos auto-organizados y multidisciplinares  Inspeccionar y adaptar  Mejora continua  Respeto, claridad y comunicación  Ritmo sostenible  La arquitectura y diseño emergen Page 4
  • 5. Declaración de valores Fuente: www.agilemanifesto.org Page 5
  • 6. Declaración de valores Fuente: www.agilemanifesto.org Page 6
  • 7. Nivel de ruido Fuente: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Page 7
  • 8. Ágil no es hacer lo que quiera Page 8
  • 9. Estimación y planificación ágil Page 9
  • 10. ¿Qué es SCRUM? No es un acrónimo… Page 10
  • 11. ¿Qué es SCRUM? Es el arte de lo posible Page 11
  • 12. ¿Qué significa SCRUM? Scrum significa melé Melé es un tipo de jugada del deporte Rugby, donde todos los jugadores de ambos equipo se agrupan en una formació, actuando como una unidad y en la cual lucharán por obtener el balón. Page 12
  • 13. ¿Qué significa SCRUM?La complejidad de una melé hace que: Si un miembro del equipo se viene abajo, se cae toda le melé.En consecuencia, los jugadores deben estar bien coordinados, apoyarse ensus compañeros para empujar al mismo tiempo y con ello, avanzar a lamisma velocidad. Page 13
  • 14. ¿Cómo lo definimos? La Wikipedia define SCRUM una metodología para la gestión y desarrollo de SW basada en un proceso iterativo incremental utilizando comunmente en entornos basados en el desarrollo ágil de SW. Page 14
  • 15. Scrum en 100 palabras• Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo.• Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes).• El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad.• Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorándolo en otro sprint. Page 15
  • 16. Contexto SCRUM Delega completamente en Sólo abarca Sus raíces teóricas el equipo la prácticas de están en las teorías responsabilidad de decidir gestión sin entrar de la la mejor manera deen las prácticas de auto organización. trabajar para ser lo más desarrollo como productivos posibles y, le puede hacer XP. da gran protagonismo a las reuniones que realicen a lo largo del proyecto. Page 16
  • 17. Modelo de referencia Roles Artefactos Ceremonias Development Product The Daily Team Backlog Scrum Scrum Sprint The Planning Master Backlog meeting Product Burndown The Sprint Owner Chart Review The Retrospective Page 17
  • 18. Ken Schwaber: “En Scrum, un grupo en el que selleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... producirán incrementos periódicos... de basura. ” Page 18
  • 19. RolesCada persona que interviene en el proceso de creación de un producto tiene un rolespecífico en Scrum. • Rol ≠ puesto en la n • Distinguir entre gallinas y cerdos Page 19
  • 20. Roles Chickens No son parte formal de los procesos, pero deben ser tenidos en cuenta. Marcan el rumbo del proyecto. Page 20
  • 21. Chickens • Usuarios • Stakeholders • Managers Page 21
  • 22. Roles Pigs Están comprometidos con el proyecto y con el proceso de Scrum. Hacen que las cosas sean posibles. Page 22
  • 23. Pigs • Recopila especificaciones • Gestiona la n Dueño de Producto • Prioriza y gestiona la pila de producto (Backlog) • Acepta las entregas • Gestiona el roadmap • Responsable mico • Interfaz de la n con Scrum Cliente • “Cerdo con plumas” Page 23
  • 24. Pigs - Es un facilitador - Asegura que el proceso se cumple de forma correcta - Debe ayudar a desbloquear las tareas del equipo - Mantiene el proceso en marcha Scrum Master - Estiman el esfuerzo necesario - Comprometidos con la entrega del producto terminado - 5 a 9 personas - Cubren los roles necesarios para el desarrollo del Equipo proyecto - Multifuncionales, autónomos y autogestioados pero responsables ante el dueño del producto Page 24
  • 25. Ciclo de vida Retrospective Page 25
  • 26. Sprints  En Scrum los proyectos avanzan en una serie de “Sprints”  La duración típica es 2–4 semanas o a lo sumo un mes calendario  La duración constante conduce a un mejor ritmo  El producto es diseñado, codificado y testeado durante el Sprint Page 26
  • 27. Desarrollo secuencial vs superpuesto Requisitos Diseño Código Test En lugar de hacer todo de una cosa a la vez… ...los equipos Scrum hacen un poco de todo todo el tiempo Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Page 27
  • 28. 1. Toma de requisitos al cliente. Para cada requisito principal se crea un bloque de trabajo, llamado historia2. El cliente ordena los bloques de trabajo en una pila de producto según su prioridad de entrega.3. El equipo de trabajo toma un grupo de historias, con el que trabajan durante una iteración o sprint.4. Una vez finalizado un sprint entregan al cliente el resultado del trabajo. Se vuelve al punto 2º hasta terminar la pila de producto. Page 28
  • 29. Ciclo de vida Revisión diariaSprint backlog Nueva Iteración funcionalidad Producto. Back Producto. Backlog seleccionado log priorizado Page 29
  • 30. Planificación Predecir el futuro es fácil. Lo difícil es saber qué es lo que está pasando ahora Page 30
  • 31. Ceremonias Page 31
  • 32. Reuniones Sprint Planning Daily Scrum Sprint ReviewObjetivo: Planificación del Objetivo: Seguimiento del Sprint Objetivo: Revisión del SprintSprintReunión previa al inicio de Reunión diaria y breve, de Esta reunión se realiza alcada sprint donde tomando no más de 15 minutos en final del Sprint, de caráctercomo base las prioridades y las que todos los informal con una duraciónnecesidades del producto integrantes del equipo máxima de cuatro horas; else determina cuáles y cómo dicen las tareas en las que equipo presenta alvan a ser las están trabajando, si se han propietario del producto elfuncionalidades que se encontrado o prevén incremento construido en eldeben cubrir con esa encontrarse con algún Sprint.iteración, en esta se genera impedimento, para poderel Sprint Backlog actualizar sobre el Sprint Backlog las tareas realizadas o los tiempos de trabajo que les restan. Page 32
  • 33. Reuniones Sprint Retrospective Comenzar a hacerReunión que se efectúa alfinalizar el sprint, estaposee una duración entre15 a 30 minutos, en ellaparticipa el ScrumMaster, el Dejar de hacerproduct owner, el equipo ypuede participar los clientes Continuar haciendo Page 33
  • 34. Evaluación Si siempre haces lo que siempre has hecho, Casi siempre conseguirás lo que siempre has conseguido Page 34
  • 35. Planificación Sprint Condiciones para realizar la reunión • El área de Sistemas u organización tienen determinados los recursos posibles para realizar el sprint • El propietario del producto tiene preparado el backlog del mismo • De ser posible el propietario del producto ya trabajó previamente con el equipo • El equipo cuenta con un conocimiento de las tecnologías empleadas y del negocio del producto, suficiente para comprender los conceptos del negocio y poder realizar estimaciones asertivas. Elementos de entrada • El Producto Backlog • El producto desarrollado hasta la fecha de esta reunión a través de los sucesivos incrementos (exceptuando esto si se trata del primer Sprint) • Puntos sobre las condiciones de negocio del cliente • Escenario tecnológico empleado Elementos de salida • Sprint Backlog Page 35
  • 36. Daily Meeting• Se realizan diariamente• La reunión comienza a su hora (9h.)• Solo hablan los cerdos• Cada miembro cuenta: - ¿Qué ha hecho el día anterior? - ¿Qué va a hacer? - ¿Qué problemas o bloqueos se ha encontrado?• 15 minutos
  • 37. Sprint planning meeting• Seleccionar el trabajo a realizar• Identificar todas las tareas del Sprint Backlog• Lo realiza el equipo basándose en Prioridades marcadas por el product owner y en los esfuerzos que estas requieren.• De 2 a 4 horas
  • 38. Sprint review meeting • Revisar el trabajo completado • Demo • Entorno a las 2 horas
  • 39. Sprint retrospective • Impresiones sobre el Sprint • Lo positivo y negativo • El Scrum Master debe facilitar que el proceso mejore en el próximo Sprint.
  • 40. Artefactos Page 40
  • 41. Product Backlog • Los requisitos y funcionalidades son capturados como elementos de una lista para planificar el proyecto. • Divididos en items autocomprobables. • No es una lista completa y definitiva. Es sólo una estimación inicial de los requisitos, importancia y esfuerzo. • El Product Owner prioriza. • Es un documento dinámico que incorpora las constantes necesidades del sistema y se mantiene durante todo el ciclo de vida (hasta la retirada del Sist.). Page 41
  • 42. Sprint Backlog • Se detallan los requisitos del Sprint • Especifica la serie de tareas que se van a desarrollar según los requisitos señalados. • Estas tareas se intentan que no excedan de las 8 horas de trabajo. • Las de mayor duración intentar descomponerlas en Sub-Tareas dentro de ese rango de tiempo. • Al final del sprint se busca un incremento en la funcionalidad. Page 42
  • 43. Burndown Chart Page 43
  • 44. Artefactos Page 44
  • 45. Conclusiones Page 45
  • 46. Conclusiones • Valor para la organización ante todo, representado en software funcional • Es preferible tener el 70% de funcionalidad a tiempo que tratar de lograr el 100% y fallar. • No requiere herramientas especiales. • Requiere disciplina y autogestión. • Transparencia en los procesos. Page 46
  • 47. Conclusiones • Fomenta el aprendizaje. • Fácil y rápido de aprender e implementar. • Facilita la mejora continua. • Incrementa la productividad. • Metodología sencilla pero efectiva. • Visibilidad durante todo el proyecto. • No existe sorpresas. Page 47
  • 48. Scrum no dice como desarrollar, el equipo de desarrollo escoge la metodología. Page 48
  • 49. Compañías que aplican Scrum Page 49
  • 50. Más Información… Page 50
  • 51. En Internet… • www.scrumalliance.org • www.controlchaos.com • www.chileagil.cl • www.proyectosagiles.org Page 51
  • 52. Literatura…  Agile and Iterative Development: A Manager’s Guide by Craig Larman  Agile Estimating and Planning by Mike Cohn  Agile Project Management with Scrum by Ken Schwaber  Agile Retrospectives by Esther Derby and Diana Larsen  Agile Software Development Ecosystems by Jim Highsmith  Agile Software Development with Scrum by Ken Schwaber and Mike Beedle  Scrum and The Enterprise by Ken Schwaber  User Stories Applied for Agile Software Development by Mike Cohn  Artículos semanales en www.scrumalliance.org Page 52
  • 53. Ruegos y Preguntas Page 53
  • 54. En el momento de la definición… La persona razonable se adapta al mundo;la no razonable insiste en cambiar el mundo. Así pues, todo progreso depende de las personas no razonables. Page 54
  • 55. En el momento de la definición…Lo malo de hacer sugerencias inteligentes esque uno corre el riesgo de que se le asigne el proyecto de llevarlas a cabo. Page 55
  • 56. En el momento de la definición… Para la mente innovadora y creativa,siempre es posible encontrar diez problemas para cada solución. Page 56
  • 57. En el momento de la definición… No dejes para mañana lo que dejaste para hoy. Page 57
  • 58. En el momento de la definición… Incorporando nueva gente a un proyecto atrasado… Lo atrasarás aun más. Page 58
  • 59. En el momento de la definición… La gente siempre está dispuesta a haber hecho el trabajo que ya está terminado. Page 59
  • 60. En el momento de la definición… Cuando todo falle, intenta lo que sugirió el jefe del proyecto. Page 60
  • 61. En el momento de la planificación…Si te comprometes a algo que es imposible, sigue siendo imposible aún después de tu compromiso. Page 61
  • 62. En el momento de la planificación… Una estimación exacta es un contrasentido en los términos. Page 62
  • 63. En el momento de la planificación… Lo agradable de NO PLANIFICAR es que los fracasos llegan por sorpresa, y no están precedidos por semanas de angustia y depresión. Page 63
  • 64. alex.marin@physio.esalexismarin.wordpress.com Page 64