Analisis De Sistemas de Informacion

14
SCRUM Ciclo de vida Scrum no es una metodología prescriptiva sino un marco metodológico que debe ser continuamente adaptado a cada proyecto, equipo o empresa.

description

 

Transcript of Analisis De Sistemas de Informacion

Page 1: Analisis De Sistemas de Informacion

SCRUM Ciclo de vida

Scrum no es una metodología prescriptiva sino un marco metodológico que debe ser continuamente adaptado a cada proyecto, equipo o empresa.

Page 2: Analisis De Sistemas de Informacion

SCRUM Ciclo de vida

Todo el trabajo es realizado en Sprint (30 días) Durante el Sprint se realizan reuniones que constituyen la

inspección empírica y las practicas de adaptación de Scrum.

Sprint Reunión de planeamiento del Sprint (< 8hs)

Primeras 4hsRequerimientos a realizarse en el sprint

Segundas 4hsPlan de trabajo del sprint

Page 3: Analisis De Sistemas de Informacion

SCRUM Ciclo de vida Daily sprint (< 15min)

¿ Qué has hecho en este proyecto desde el ultimo Daily sprint (sprint diario)?

¿ Qué planeas hacer en el proyecto entre hoy y la próxima reunión Daily Scrum?

¿ Qué impedimentos se te han presentado para lograr lo prometido en el Sprint y proyecto?

Sprint Review (< 4hs)Presentación de lo desarrollado durante el sprint

Sprint Retrospective (< 3hs)Revisión y análisis del proceso de desarrollo

Page 4: Analisis De Sistemas de Informacion

SCRUM Ciclo de vidaScrum basa todas sus practicas en un esqueleto de proceso iterativo e incremental.

El circulo de abajo representa una iteración de las actividades de desarrollo que ocurren uno luego de otra.

El resultado de cada iteración es un incremento del producto. El otro circulo representa la inspección diaria que ocurre durante la iteración, en la cual los miembros del equipo se reúnen, inspeccionando las actividades realizadas por otro miembro del equipo y hacer los ajustes apropiados. El ciclo se repite hasta que el proyecto se termina.

Page 5: Analisis De Sistemas de Informacion

SCRUM Ciclo de vida

El esqueleto opera de la siguiente manera: En el comienzo de una iteración, el equipo revisa que se debe hacer. Luego selecciona lo que cree que se puede agrupar en un incremento de una potencial envío de funcionalidad para el fin de la iteración. El equipo es luego dejado solo para que realice su mejor esfuerzo por el resto de la iteración. Al final de la iteración, el equipo presenta el incremento de funcionalidad que construyo para que los stakeholders puedan inspeccionar que funcionalidad y adaptaciones de tiempo se pueden hacer al proyecto.

Page 6: Analisis De Sistemas de Informacion

SCRUM Ciclo de vida

Page 7: Analisis De Sistemas de Informacion

SCRUM Ciclo de vida

El corazón de scrum se basa en la iteración. El equipo mira los requerimientos considera la tecnología disponible evalúa su complejidad dificultades sorpresas.

El equipo analiza que se necesita hacer y selecciona la mejor forma de hacerlo. Este proceso creativo es el corazón de scrum.

 

Page 8: Analisis De Sistemas de Informacion

El Sprint Planning Meeting: es una reunión que tiene una duración fija de no más de 8 horas, divididas en dos partes iguales de 4 horas.

La primera parte sirve para seleccionar el Product Backlog la segunda para preparar el Sprint Backlog. El objetivo de la primera parte es que el Equipo seleccione aquellos elementos del

Product Backlog que cree que puede comprometerse a transformar en un incremento de funcionalidad potencialmente entregable.

El Equipo demostrará esta funcionalidad al Product Owner y a los stakeholders en el Sprint review meeting al final del Sprint.

El Equipo puede hacer sugerencias, pero la decisión de que elementos del Product Backlog pueden formar parte del Sprint es responsabilidad del Producto Owner.

El Equipo es responsable de determinar que parte del Product Backlog, seleccionado por el Product Owner para ese Sprint, va a tratar de implementar durante ese Sprint.

SCRUM REGLAS

Page 9: Analisis De Sistemas de Informacion

Durante el Sprint: es limitado en el tiempo a 30 días consecutivos en el calendario.

Sin considerar otros factores, esta es la cantidad de tiempo necesaria para que un Equipo pueda construir algo de interés significativo para el Product Owner y los stakeholders y llevarlo a un estado en que sea potencialmente entregable.

Este es también el máximo tiempo que puede ser asignado sin que el Equipo tenga que hacer tanto trabajo que requiera artefactos y documentación para soportar su proceso de razonamiento.

Es también el máximo tiempo que la mayoría de los stakeholders esperarán sin perder interés en el progreso del equipo y sin perder su convencimiento de que el Equipo está haciendo algo significativo por ellos.

– El equipo puede buscar consejo, ayuda, información y soporte fuera de él mismo durante el Sprint.

– Nadie puede proporcionar consejo, instrucciones, comentarios o dirección al Equipo durante el Sprint. El Equipo es completamente autogestionado.

– El Equipo se compromete con el Product Backlog durante el Sprint planning meeting. No se permite a nadie cambia el Producto Backlog durante el Sprint. El Producto Backlog esta congelado hasta el final del Sprint.

SCRUM REGLAS

Page 10: Analisis De Sistemas de Informacion

– Si el equipo se siente incapaz de completar todo el Product Backlog comprometido durante el Sprint, puede consultar con el Product Owner que elementos quitar del Sprint actual.

– Si se eliminan tantos elementos que el Sprint pierde su valor y significado, el ScrumMaster puede terminar anormalmente el Sprint.

SCRUM REGLAS

Page 11: Analisis De Sistemas de Informacion

El Sprint Review Meeting: proporciona un punto de inspección para el progreso del proyecto al final de cada Sprint. Basándose en esta inspección, se pueden hacer adaptaciones al proyecto.

El Sprint review meeting está limitado a 4 horas.

El propósito del Sprint review es que el Equipo presente al Product Owner y los stakeholders la funcionalidad que está completada.

La funcionalidad que no esta "completada" no puede ser presentada.

Artefactos que no son funcionalidad no pueden ser presentados excepto cuando se usan para mejorar el entendimiento de la funcionalidad demostrada.

Los artefactos no pueden ser mostrados como productos de trabajo, y su uso debe ser minimizado para evitar confundir a los stakeholders o exigir que estos entiendan como funciona el desarrollo del sistema.

SCRUM REGLAS

Page 12: Analisis De Sistemas de Informacion

• La funcionalidad deberá ser presentada en los equipos de trabajo de los miembros del Equipo y ejecutada desde un servidor lo más parecido posible a uno de producción, usualmente un servidor del entorno de aseguramiento de la calidad.

• El Sprint review comienza con un miembro del Equipo presentando las metas del Sprint, el Product Backlog comprometido y el Product Backlog completado. Diferentes miembros del equipo pueden comentar que fue bien y que no fue bien en el Sprint.

• La mayoría del Sprint review se consume con los miembros del Equipo presentando funcionalidad, respondiendo preguntas de los stakeholders sobre la presentación y descubriendo que cambios desean estos.

• Al final de la presentación, los stakeholders son encuestados, uno a uno, para recoger sus impresiones, que cambios desean, y la prioridad de esos cambios.

• El Product Owner discute con los stakeholders y el Equipo el potencial cambio del Product Backlog basándose en su feedback.

SCRUM REGLAS

Page 13: Analisis De Sistemas de Informacion

• El Sprint Retrospective Meeting: es una reunión promovida por el ScrumMaster en la cual el Equipo discute el Sprint más recientemente finalizado y determina que puede ser cambiado para hacer el próximo Sprint más divertido y productivo.

• El Sprint Review se centra en 'que' está construyendo el Equipo, la Sprint Retrospective se centra en el 'como'. La motivación para realizar esta reunión es lograr la mejora continua del proceso de desarrollo.

– El Sprint restropective meeting está limitado a 3 horas de duración.

– Solo asisten el Equipo, el ScrumMaster y el Product Owner, este último es opcional.

– La reuniñon comienza con todos los miembros del equipo contestando dos preguntas como son:

SCRUM REGLAS

Page 14: Analisis De Sistemas de Informacion

GRACIAS POR SU ATENCIÓN