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