Your SlideShare is downloading. ×
0
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile scrum
Metodología agile 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

Metodología agile scrum

10,143

Published on

1 Comment
10 Likes
Statistics
Notes
  • seria piola si se podria descargar
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
10,143
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
342
Comments
1
Likes
10
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 ágil de desarrollo de Proyectos.  Proyectos que requieren rapidez y flexibilidad.  Equipos pequeños (7±2), multidisciplinares y localizados en un mismo sitio.  Métodos adaptativos (rápida adopción de cambios según necesidades).  Métodos de desarrollo iterativo e incremental.  Mínima producción de documentación.  Colaboración constante cliente–equipo desarrollo.
  • 2.  SCRUM:  Scrum significa melé, es que todos los jugadores de ambos equipos se agrupan en una formación en la cual lucharán por obtener el balón.  Si un miembro se viene abajo, falla toda la melé.  Los jugadores están bien coordinados para empujar al mismo tiempo y avanzar a la misma velocidad.  SCRUM en Ingeniería del Software:  Es una metodología ágil para desarrollo y mantenimiento de Software.  Basado en un desarrollo iterativo e incremental.  Grupos auto-organizados y multidisciplinares.  Rápida adaptación a cambios, minimizando costes, tiempos y equipos de trabajo.  Adaptación continua a las circunstancias de evaluación del proyecto.
  • 3.  Colaboración estrecha con el cliente. Predisposición y respuesta al cambio. Prefiere el conocimiento tácito de las personas al explícito de los procesos. Desarrollo incremental con entregas funcionales frecuentes. Comunicación verbal directa entre los implicados en el proyecto. Motivación y responsabilidad de los equipos por la autogestión, auto-organización y compromiso. Simplicidad. Supresión de artefactos innecesarios en la gestión del proyecto.
  • 4. Esquema SCRUM
  • 5.  El proceso parte de la lista de tareas (Product backlog). De esta lista el cliente prioriza los requisitos basándose en objetivos, balanceando el valor que le aportan a su coste y quedando repartidos en iteraciones y entregas (Sprint backlog), De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla mediante la re planificación de objetivos que se puede realizar al inicio de cada iteración Cada día de una iteración debe realizarse una reunión con los integrantes del equipo con el objetivo de obtener de primera mano los avances de las tareas y los obstáculos que se van presentando a lo largo del desarrollo de la iteración Una vez finalizado un Sprint backlog, se revisan con el usuario o cliente los productos obtenidos (Sprint review) y si cumplen con las necesidades plasmadas por el usuario al inicio de la iteración. Cada fin de un Sprint Backlog, se debe revisar los aspectos positivos y negativos del mismo (Sprint retrospective) con el objetivo de poder utilizar estos para una mejor planificación de la siguiente iteración a realizar.
  • 6.  SPRINTS:  Los sprints son cada una de las partes del ciclo de vida del método Scrum.  Son la base del desarrollo.  Distintas partes en las que se divide el producto a realizar  Cada Sprint dura de 2 a 4 semanas
  • 7.  Componentes o Roles.  Propietario del producto (Product Owner)  Scrum Manager (o Scrum Master).  Equipo de desarrollo (Scrum Team).  Usuarios o Clientes y Stackholders. Elementos o artefactos  Pila de Producto (Product Backlog)  Pila de Sprint (Sprint Backlog)  Burndown Chart.  Incremento. Reuniones o meetings  Sprint Planning meeting.  Sprint Review.  Sprint Retrospective  Daily Scrum Meeting.
  • 8.  Product Owner.  El responsable de obtener el mayor valor de producto  Representa al cliente  Es el que puede definir o cambiar el producto y acepta o rechaza el resultado de cada Sprint.  Es el que exige y prioriza los requerimientos del producto.  Scrum Master o Scrum Manager.  Gestor de los equipos  Responsable del funcionamiento y productividad del equipo de desarrollo.  Asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer.  Trabaja junto al equipo
  • 9.  Scrum Team. Equipo de desarrollo.  Grupo de trabajo que desarrollan el producto Sprint a Sprint.  Responsables de implementar las funcionalidades del Product Owner.  5 a 9 personas, multidisciplinares y multifuncionales.  Comprometidos y auto-organizados. Stackholders (clientes, usuarios…)  Hacen posible el proyecto.  Sólo participan directamente durante las revisiones del sprint.  Beneficiarios finales del producto.  Viendo los progresos, pueden aportar ideas, sugerencias o necesidades.
  • 10.  Product Backlog o Pila de Prducto:  Todas las tareas, funcionalidades o requerimientos a realizar  Marcadas y priorizadas por el Product owner.  Lista de requisitos de usuario que se origina con la visión inicial del producto  Va creciendo y evolucionando durante el desarrollo por lo que nunca llega a ser una lista definitiva.  Sprint Backlog o Pila de Sprint:  Una tarea que proviene de la lista de tareas (Product backlog),  Deben acometerse entre 2 y 4 semanas.  Un Sprint backlog no puede ser alterado o modificado. Hay que esperar a que concluya para hacerlo.  En definitiva, es la lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto.
  • 11.  Burndown Chart:  Es el gráfico que controla el progreso del sprint y la cantidad restante de trabajo por hacer.  Re-estima las tareas o se añaden nuevas tareas.  Es muy importante para que los Stackholders evalúen el proceso de cada sprint. Incremento:  Es el resultado entregable final de cada Sprint
  • 12. Sprint Planningmeeting.Sprint Review.SprintRetrospectiveDaily ScrumMeeting
  • 13.  Sprint Planning Meeting:  Sprint Review Meeting:  Reunión de planificación del sprint Backlog  Reunión de revisión del Sprint.  Se priorizan los requerimientos  Se realiza una vez terminado un Sprint.  Participantes: Scrum master, Scrum team y el  Revisión entre 2 y 4 horas Product owner.  El Scrum Team Muestra los avances “live” al  Jornada previa al inicio de un Sprint Product Owner  Determina el trabajo y los objetivos que se deben  Se presentan nuevas funcionalidades y se genera cumplir en esa iteración un feedback del producto.  La duración depende del Sprint, pero como máximo  la revisión del sprint es el análisis y revisión del será de 8 horas. incremento generado.  Reunión diaria (Daily scrum meeting).  Tarea iterativa todos los días de cada Sprint  Sprint Retrospective:  Primera actividad del día  Retrospectiva del Sprint.  Duración entorno a 15 minutos.  El Product owner revisará con el equipo los objetivos  Será moderado por el Scrum Master, 3 preguntas a cada marcados inicialmente en el Sprint backlog concluido, miembro del Scrum Team .  se aplican cambios y ajustes necesarios,  ¿Qué hice ayer?,  ¿Qué tengo previsto hacer hoy?  Se marcan aspectos positivos (para repetirlos) y los aspectos  ¿Qué dificultades tengo?) negativos (para evitar que se repitan) del Sprint.  Se verifica el avance de las tareas y la planificaciones de  Se realiza al finalizar un Sprint, y durará entorno a una hora. las mimas.
  • 14.  Ventajas.  Obtención de Software con requerimientos exigidos de forma rápida.  Trabajo con iteraciones rápidas  Gran adaptación al cambio. Ventaja competitiva.  Creatividad y efectividad del equipo auto administrado y entorno libre de interrupciones.  Reuniones dedicadas a problemas recientes. Evita estancamiento. Inconvenientes.  Delegación de responsabilidades y posibilidad de fallo.  Dificultad de aplicación para grandes proyectos  Se requiere de un agile champion para monitorizar el desarrollo  Problemas si el precio y fecha de entrega son cerrados  Presuposiciones de: equipos formados y motivados, clientes involucrados en el desarrollo y su participación, y que la documentación no es necesaria.
  • 15.  Conclusiones.  No es válido para cualquier proyecto o equipo de trabajo.  Óptimo para un equipo de 8 personas.  No existe una metodología válida 100% para todas las personas o empresas, pero Scrum está empujando fuerte por su facilidad de implantación y agilidad en cuanto a cambios.  Scrum evita la burocracia y generación de documentos.  La idea Principal es ponerse a trabajar cuanto antes y que el cliente vaya viendo avances.  Idea metodología ágil: que se pueda reconducir fácilmente el proyecto y que afecte lo menos posible a costes, tiempos y equipos de trabajo.  Algunas empresas que han desarrollado una metodología Scrum con éxito son: Adobe Google HP Microsoft Motorola Philips SAP Nokia Xerox….

×