SCRUM - Osiris López
0 recomendaciones1,230 vistas
Este documento describe la historia y los principios de Scrum, una metodología ágil para el desarrollo de software. Se menciona que Scrum se desarrolló en la década de 1990 y se formalizó en 1996, basándose en principios establecidos en el Manifiesto Ágil de 2001. Scrum utiliza historias de usuario, reuniones diarias, sprints de tiempo limitado y retrospectivas para entregar software de manera iterativa e incremental.
SCRUM - Osiris López
- 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
- 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.