Scrum

Historia

Scrum = Formación para reiniciar el juego

Historia

Fuente: https://hbr.org/1986/01/the-new-new-product-development-game

Principios de Hirotaka Takeuchi

  • Inestabilidad incorporada
  • Equipos de desarrollo auto-organizados
  • Fases de desarrollo traslapadas
  • Multi-aprendizaje
  • Control sutil
  • Transferencia de aprendizaje organizacional

Aparición del Marco de Trabajo

  • Jeff Sutherland (1993) y Ken Schwaber (1995).
  • Miembros de Easel Corporation en 1993
  • Presentaron Worshop con la metodología en 1995 (link)
  • Aplican los conceptos de Takeuchi al desarrollo de software

Fuente: wikipedia

Problemas de las Metodologías Tradicionales

  • Creatividad inhibida
  • Limitaciones al escribir documentación (documentos extensos, malos entendidos)
  • Mala predicción de tiempos
  • Imposibilidad de predecir dificultades futuras
  • Mucho trabajo y poca diversión
  • Resultado poco optimizados 

Valores del Manifiesto Ágil

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Valores de Scrum

Foco

Coraje

Apertura 

Compromiso

Respeto

¿Cuando aplicar Scrum?

Fuente: The Cynefin framework (Snowden and Boone 2007)

Roles

Product Owner

Toma los requisitos del sistema y los transfiere al Product Backlog.

Prioriza más valor agregado a menor costo. 

The Team

Desarrollan el producto basado en los visionado por el Product Owner.

(7±2 Personas)

Scrum Master

Encargado de que nada interrumpa el trabajo del equipo mediante eliminación de obstáculos o programación de reuniones. Es el experto en Scrum.

Ciclo de Desarrollo

Artefactos y Reuniones

Product Backlog

  • No solo incluye requerimientos de los usuarios, sino requerimientos internos del equipo de trabajo
  • Para los requerimientos de los usuarios usualmente se usan historias de usuario.

 

Planeación del Sprint Parte Uno

  • Estudiar los elementos de mayor prioridad del Product Backlog (objetivos, contexto)
  • Definir como debe entregarse cada elemento para considerarlo terminado
  • Duración: 4 horas para sprint de 4 semanas 

                        2 horas para sprint de 2 semanas

Planeación del Sprint Parte Dos

  • Determinar los elementos a desarrollar durante el Sprint
  • Detallar las tareas que se requieren para lograr cada uno de los items del Product Backlog
  • Debe asistir el Product Owner
  • Duración: 4 horas para sprint de 4 semanas                                       2 horas para sprint de 2 semanas

Sprint Backlog

Scrum Diario

  • Reporte de:
    • ¿Qué he progresado?
    • ¿Qué pienso hacer hoy?
    • ¿Qué obstáculos se me han presentado?
  • Solo asiste el equipo
  • Duración: 15 minutos

Actualización al Sprint Backlog

Spring Burndown

Reunión Semanal con el Product Owner

  • Esta reunión se plantea para actualizar el Product Backlog acorde al progreso del Sprint
  • Se pueden plantear mejoras como:
    • Detallar mejor los requerimientos
    • Separar elementos
    • Estimar nuevos elementos
    • Desestimar elementos anteriores
  • Las mejoras son planteadas para Sprint futuros

Sprint Review

  • Asiste el Product Owner y pueden ser invitadas todas las partes interesadas en el desarrollo
  • No se usan diapositivas
  • En la reunión se realiza
    • Retroalimentación de lo realizado
    • Demo del desarrollo
  • Duración:  max. 4 horas

Retrospectiva del Sprint

  • Se responden las siguientes preguntas:
    • ¿Qué estuvo bien?
    • ¿Qué pudo ser mejor?
    • ¿Cosas para intentar?
    • ¿Asuntos para escalar?
  • Duración:  max. 3 horas

Herramientas

scrum

By Gustavo Andrés Uribe Gómez