• Save
SCRUM - Osiris López
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
952
On Slideshare
952
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

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. TEMA DE REVISION OSIRIS LOPEZ MARTINEZ INFORMATICA III
  • 2.
      • Re-Ingeniería - Goldratt, Takeuchi y Nonaka en la década de 1980.
      • Desarrollo de software - Jeff Sutherland en 1993.
      • Formalizada con la colaboración de Ken Schwaber en una presentación en OOSPLA 96.
      • ¿El por qué de SCRUM? (Metodologías Ágiles)
  • 3.
      • Febrero de 2001, Reunión celebrada en Utah-EEUU – 17 expertos del desarrollo de software
      • Manifiesto ágil. Se valora:
        • Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
        • Desarrollar software que funciona más que conseguir una buena documentación.
        • La colaboración con el cliente más que la negociación de un contrato.
        • Responder a los cambios más que seguir estrictamente un plan.
  • 4.
      • Definición
      • Historias (ID, NOMBRE, IMPORTANCIA, ESTIMACIÓN INICIAL, COMO PROBARLO, NOTAS )
      • Excel buena herramienta
      • Campos adicionales ( CATEGORÍA, COMPONENTES, SOLICITANTE, BUG TRACKING ID )
      • Ejemplo
  • 5.
      • Ejemplo
  • 6.
      • PREPARACIÓN
        • Pila de producto
        • Dueño de producto
        • Elementos importantes deben tener ratios de importancia asignados
        • El dueño de producto debe comprender cada historia
        • Niveles de importancia y estimaciones.
  • 7.
      • COMO SE HACE
        • Propósito
        • Produce
          • Una meta de Sprint
          • Una lista de miembros (y su nivel de dedicación, si no es del 100%)
          • Una Pila de Sprint (lista de historias incluidas en el Sprint)
          • Una fecha concreta para la Demo del Sprint
          • Un lugar y momento definidos para el Scrum Diario.
  • 8.
      • DUEÑO DEL PRODUCTO (asistencia)
      • Calidad interna y externa (no es negociable)
  • 9.
      • TIME - BOXED
        • Todo en Scrum tiene una duración determinada
        • ¿ Qué pasa si la reunión ha terminado su tiempo de duración y no se ha cumplido lo esperado?
        • Agenda
  • 10.
      • Ejemplo AGENDA
    • Reunión de planificación de Sprint: 13:00 – 17:00 (10 minutos de descanso cada hora)
    • • 13:00 – 13:30. El Dueño de Producto comenta la meta del Sprint y resume la Pila de Producto. Se establece un lugar, fecha y hora para la Demo.
    • • 13:30 – 15:00. El equipo da estimaciones de tiempo, y divide los elementos tanto como sea necesario. El Dueño de Producto actualiza los ratios de importancia. Se clarifican los elementos. Para todos los elementos de alta importancia se establece el “Como probarlo”.
    • • 15:00 – 16:00. El equipo selecciona las historias que se incluirán en el Sprint. Se realizan cálculos de velocidad para chequear si es factible.
    • • 16:00 – 17:00. Se selecciona un lugar y hora para el Scrum Diario (si es que cambio respecto al último Sprint). Se continúa dividiendo las historias en tareas.
  • 11.
      • DURACIÓN DEL SPRINT
      • METAS DEL SPRINT
      • HISTORIAS EN EL SPRINT
      • (exclusivamente Equipo)
  • 12.
      • DUEÑO DEL PRODUCTO EN EL SPRINT (HISTORIAS)
  • 13.
      • EQUIPO EN EL SPRINT (HISTORIAS)
        • Estimando a ojo de buen cubero (equipos pequeños – sprint cortos)
        • Estimando usando cálculos de velocidad
    • (días-hombre disponibles) x (factor de dedicación) = velocidad estimada
  • 14.
      • USO DE TARJETAS
  • 15.
      • EN ESENCIA
      • Prioridad 1: Una meta de Sprint y una fecha para la demo.
      • Prioridad 2: Lista de qué historias ha aceptado terminar el equipo en este Sprint.
      • Prioridad 3: Una estimación para cada historia del Sprint.
      • Prioridad 4: “Como probarlo”, relleno para cada historia del Sprint.
      • Prioridad 5: Cálculos de velocidad y recursos, como chequeo de la planificación del Sprint. Incluyendo una lista de los miembros del equipo y sus compromisos.
  • 16.
      • COMUNICADOS E INFORMACIÓN VISIBLE
      • PILAS DE SPRINT
  • 17.
      • BURNDOWN
  • 18.
      • ALARMAS - BURNDOWN
  • 19.
      • EQUIPO JUNTO
        • Audibilidad
        • Visibilidad
        • Aislamiento
  • 20.
      • Duración 15 minutos
      • Actualización pila de SPRINT
      • Puntualidad
      • Scrum Master indispensable
  • 21.
      • IMPORTANCIA
        • Reconocimiento
        • Se interactúa con otros del equipo
        • El equipo sabe que tendrán que hacer una demo pase lo que pase, lo que incrementa significativamente las posibilidades de que haya algo útil que demostrar
        • Otras personas se enteran de lo que está haciendo el equipo
        • Hacer una demo fuerza al equipo a acabar realmente las cosas y entregarlas (incluso aunque sea sólo en entorno de pruebas)
  • 22.
      • Es el segundo evento más importante de Scrum (siendo el primero la reunión de planificación de Sprint) ya que ¡es tu mejor oportunidad para mejorar!
    • • Bien: si hiciéramos el Sprint otra vez, volveríamos a
    • hacer estas cosas igual.
    • • Mejorable: si hiciéramos otra vez el Sprint, haríamos
    • estas cosas de forma diferente.
    • • Mejoras: ideas concretas sobre cómo podemos mejorar
    • en el futuro.
    PILA DE SPRINT
  • 23.
      • “ Deberíamos haber pasado más tiempo dividiendo historias en sub-historias y tareas”
      • “ Demasiadas distracciones”
      • “ Nos sobre-comprometimos y sólo hicimos la mitad”
      • “ Nuestro entorno de oficina es demasiado ruidoso y desordenado”
  • 24.
      • Encargados de pruebas: acceden al sistema en la forma exacta en la que los usuarios finales lo harán, lo que significa que debe hacerse manualmente (asumiendo que tu sistema sea para usuarios humanos).
      • Encargados de pruebas detectan errores – Equipo SCRUM los soluciona
  • 25.
      • Tras la reunión de planificación de Sprint, crea una página de información. Añade un enlace a la página desde la página principal del Wiki. Imprime la página y ponla en la pared por la que pase la gente cerca de tu equipo.
      • Manda un correo a todo el mundo anunciando que ha comenzado un nuevo Sprint. Incluye el objetivo del Sprint y un enlace a la página de información del Sprint.
      • Actualiza el documento de estadísticas de Sprint. Añade tu velocidad estimada, tamaño del equipo, longitud del Sprint, etc.
      • Asegúrate de que el Scrum diario comienza y termina a su hora.
      • Asegúrate de que todas las historias son añadidas o eliminadas de la Pila de Sprint cuando sea necesario para mantener el Sprint en fecha.
      • Asegúrate de que se notifica al Dueño de Producto sobre estos cambios
  • 26.
      • Asegúrate de que el equipo mantiene actualizados la Pila de Producto y el burn – down.
      • Asegúrate de que los problemas o impedimentos son solucionados o reportados al Dueño de Producto y/o el Jefe de Desarrollo.
      • Haz una demo de Sprint abierta.
      • Todo el mundo debería ser notificado acerca de la demo uno o dos días antes.
      • Haz una retrospectiva de Sprint con todo el equipo y el Dueño de Producto. Invita al Jefe de Desarrollo también, de forma que pueda ayudar a difundir las lecciones aprendidas.
      • Actualiza el documento de estadísticas de Sprint. Añade la velocidad real y los puntos clave de la retrospectiva.