El documento introduce Scrum, un proceso ágil para el desarrollo de software. Scrum permite entregas frecuentes de valor a través de iteraciones cortas llamadas "sprints". Los equipos Scrum son multifuncionales y auto-organizados, trabajando en conjunto para completar los objetivos de cada sprint. Scrum utiliza artefactos como el product backlog, sprint backlog y burndown chart para planificar y monitorear el progreso.

1. Introducción a SCRUM David Doctor Project Manager 11 Julio 2008

2. Perdiendo la carrera de relevos Adaptado de: Hirotaka Takeuchi and Ikujiro Nonaka, “The New Product Development Game”, Harvard Business Review , Enero 1986 . “ El estilo de ‘carrera de relevos’ aplicado al desarrollo de productos puede presentar conflictos con los objetivos de velocidad máxima y flexibilidad. Por el contrario un estilo holístico donde el equipo busca, como en un juego de fútbol, de forma integrada, meter un gol, pasando el balón, puede servir mejor a las actuales necesidades competitivas”

3. Scrum es un proceso ágil que nos permite centrarnos en la entrega de un mayor valor de negocio en el menor tiempo posible. Permite la rápida y continua inspección del software en producción (en intervalos de dos a cuatro semanas) La parte de negocio establece las prioridades. El equipo se auto-organiza para encontrar la forma de entregar las funcionalidades de mayor prioridad. Cada dos o cuatro semanas cualquiera puede ver el trabajo real realizado, decidiendo así mismo si se puede liberar o se debe continuar para mejorarlo mediante otro “sprint” Scrum en 100 palabras

4. Orígenes de Scrum Jeff Sutherland Uso inicial de Scrum en Easel Corp en 1993 IDX y más de 500 personas usando Scrum Ken Schwaber ADM Presentación de Scrum en OOPSLA 96 con Sutherland Autor de tres libros sobre Scrum Mike Beedle Patrones para Scrum en PLOPD4 Ken Schwaber y Mike Cohn Co-fundadores de la Scrum Alliance en 2002, inicialmente dentro de la Agile Alliance

5. Quién usa Scrum: Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

6. Scrum ha sido usado para: Software comercial Desarrollo interno Desarrollo contratado (por terceros) Proyectos de precio fijado Aplicaciones financieras Aplicaciones certificadas ISO-9001 Sistemas embebidos Sistemas 24x7 Joint Strike Fighter Desarrollo de videojuegos Sistemas para control de satélites Sitios web Teléfonos móviles Aplicaciones para redes Aplicaciones ISV (Independent Software Vendors) Algunas de las mayores aplicaciones en producción

7. Características Equipos auto-organizados El producto progresa en una serie de “sprints” mensuales Los requisitos son listados en un “product backlog” No hay prácticas de ingeniería prescritas (Scrum se adecua a todas) Es una de las “metodologías ágiles”

8. Manifiesto ágil - Valores www.agilemanifesto.org Procesos y herramientas Individuos e interacciones En lugar Seguir un plan Responder a cambios En lugar Documentación comprensible Software que funciona En lugar Negociación de contrato Colaboración del cliente En lugar

9. Scrum Product backlog Warrants Portfolio Mercados Sprint 2-4 semanas Mercados Objetivo del Sprint Sprint backlog Producto para entrega (o incremento ) C/V Valores Portfolio C/V Valores Warrants 24 horas

10. En resumen Imagen disponible en: www.mountaingoatsoftware.com/scrum

11. Sprints Los proyectos Scrum progresan en una serie de “Sprints” Análogo a iteraciones en XP La duración típica es de 2-4 semanas Una duración constante lleva a un mejor ritmo El producto es diseñado, codificado y probado durante el sprint

12. Desarrollo secuencial vs. paralelo Fuente: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. En lugar de completar una cosa cada vez… ...los equipos Scrum hacen un poco de cada cosa al mismo tiempo Requisitos Diseño Codificación Pruebas

13. No se admiten cambios durante un Sprint Planea las duraciones del Sprint de acuerdo al máximo tiempo que puedes comprometerte a dejar modificaciones fuera del sprint (un mes más o menos ) Cambio

14. Scrum framework Product owner ScrumMaster Team Roles Planificación Revisión Retrospectiva Reunión diaria Ceremonias Product backlog Sprint backlog Burndown charts Artefactos

15. Scrum framework Product backlog Sprint backlog Burndown charts Artefactos Planificación Revisión Retrospectiva Reunión diaria Ceremonias Product owner ScrumMaster Team Roles

16. Product owner Define las funcionalidades del producto Decide las fechas de lanzamiento y contenido Es responsable de la rentabilidad del producto (ROI) Prioriza las funcionalidades de acuerdo a un valor del mercado Ajusta las funcionalidades y prioridades en cada iteración, cuando sea necesario Acepta o no el trabajo realizado

17. Scrum Master Representa la gerencia para un proyecto Responsible de la aplicación de valores y prácticas de Scrum Elimina impedimentos Asegura que el equipo es completamente funcional y productivo Garantiza la cooperación de los diferentes roles y funciones Escudo de interferencias externas

18. El equipo Entre 5-9 personas Multi-funcional: Programadores, testeadores, diseñadores,etc . Los miembros deben emplear su tiempo íntegro Puede haber excepciones (e.j., administrador de base de datos) Los equipos se auto-organizan Idealmente, sin títulos, aunque es posible Los miembros solo pueden ser intercambiados solo entre los Sprints

19. Scrum framework Product backlog Sprint backlog Burndown charts Artefactos Product owner ScrumMaster Team Roles Planificación Revisión Retrospectiva Reunión diaria Ceremonias

20. Planificación del Sprint Condiciones del Negocio Capacidades del equipo Product backlog Tecnología Producto actual Priorización Analizar y evaluar el product backlog Seleccionar el objetivo del Sprint Planificación Decidir como conseguir el objetivo del sprint (diseño) Crear el sprint backlog (tareas) de los elementos del product backlog (user stories / funcionalidades) Estimar el sprint backlog en horas Objetivo del Sprint Sprint backlog

21. Planificación del Sprint Los equipos seleccionan los elementos del product backlog con el compromiso de terminarlos Se crea el Sprint backlog Se definen las tareas y son estimadas (1-16 horas) Colaborativo, no solo realizado por el ScrumMaster Diseño de alto nivel es considerado

22. Planificación del Sprint (II) Quiero que los usuarios del portal puedan comprar-vender acciones Modelado (8 horas) Codificar IGU (4) Escribir test (4) Codificar webservices (6) Actualizar los test de rendimiento (4)

23. Reunión diaria Parámetros Diaria 15 minutos Todos en pie! No es para resolver problemas Todo el mundo es invitado Solo los miembros del equipo, el Scrum Master, el Product owner pueden hablar Ayuda a evitar otras reuniones innecesarias

24. Tres cuestiones, para todos Las respuestas no son un reporte al scrum master Son compromisos delante del resto ¿Qué hiciste ayer? 1 ¿Qué harás hoy? 2 ¿Hay algún obstáculo? 3

25. Revisión del Sprint El equipo presenta lo que ha conseguido durante el Sprint Tipicamente son demos de nuevas funcionalidades de la arquitectura Informal 2 horas de preparación Sin presentación Todo el equipo participa Se invita a todo el mundo

26. Retrospectiva del Sprint Periodicamente se observa lo que funciona y lo que no Entre 15 – 20 minutos Realizado después de cada Sprint Todo el equipo participa Scrum Master Product owner Equipo Clientes y otros

27. Iniciar / Parar / Continuar El equipo discute lo que le gustaría: Comenzar a hacer Dejar de hacer Continuar haciendo Esta es solo una de las muchas formas de hacer una retrospectiva

28. Scrum framework Product owner ScrumMaster Team Roles Planificación Revisión Retrospectiva Reunión diaria Ceremonias Product backlog Sprint backlog Burndown charts Artefactos

29. Product backlog Son los requisitos Una lista de todo el trabajo deseado en el proyecto Idealmente cada elemento se expresa con un peso que expresa el valor para el usuario o clientes del producto Priorizado por el Product Owner Repriorizado al inicio de cada Sprint Este es el product Backlog

30. Ejemplo de Product Backlog Backlog item Estimado Permitir al usuario comprar acciones 3 Permitir que un usuario busque eventos de mercado 5 Permitir a un usuario obtener información sobre una compañía 3 Permitir a un empleado del banco obtener un informe de alertas 8 Mejorar el tratamiento de excepciones 8 ... 30 ... 50

31. Objetivo del Sprint Frase corta que ilustre el foco de trabajo durante el sprint Aplic. De BBDD Servicios financieros Ciencias Funcionalidades para realizar estudios genéticos de la población Proveer más indicadores técnicos que la compañía ABC en tiempo real, con datos streaming. Hacer que la aplicación funcione con SQL Server además de Oracle.

32. Gestión del Sprint Backlog Cada persona escoge el trabajo que hará El trabajo nunca es asignado La estimación del trabajo restante es actualizada diariamente Cualquier miembro del equipo puede cambiar, eliminar o modificar tareas Si una tarea no está clara, defínala como un elemento del backlog con mayor cantidad de tiempo y descompóngala después Actualice las cosas a ser realizadas tan pronto tenga más información

33. Un Sprint Backlog Tareas Codificar el IGU Codificar la capa de negocio Testear Escribir la ayuda on-line Escribir la clase foo Lun Mar Mie Jue Vie 8 16 8 12 8 4 12 16 8 4 11 8 4 8 8 Añadir logging de errores 8 10 16 8 8

34. Burndown chart Horas

35. Horas 40 30 20 10 0 Lun Mar Mie Jue Vie Tareas Codificar el IGU Capa de negocio Testear Escribir ayuda online Lun 8 16 8 12 Mar Mie Jue Vie 50 4 12 16 7 11 8 10 16 8

36. Tasks boards La pizarra de tareas muestra todo el trabajo que se está realizando durante un Sprint Se actualiza continuamente durante todo el sprint (si alguien piensa en una nueva tarea escribe una nueva tarjeta y la pone) Durante o antes del daily scrum, las estimaciones son cambiadas y las tarjetas se mueven

37. Tasks boards (II)

38. Tasks boards (III) Story – Descripción del “user story" To Do – Todas las tarjetas de tareas que tienen que ser realizadas en el sprint Work In Process – Cualquier tarjeta sobre lo que se esté trabajando va aquí. El programador que elija que va a trabajar en esa tarea lo mueve cuando esté preparado/a para comenzar la tarea. Normalemnte se hace durante el daily Scrum cuando alguien dice “Voy a trabajar sobre esto hoy” To Verify – Tareas relacionadas con testing Done – Pila de tarjetas que ya han sido realizadas. Al final del sprint son eliminadas (a veces se eliminan durante el sprint si hay muchas tarjetas)

39. Task boards (IV)

40. Escalabilidad Equipos de 7 ± 2 personas La escalabilidad a través de los equipos de equipos Factores de escalabilidad Tipo de aplicación Tamaño del equipo Dispersión del equipo Duración del proyecto Scrum ha sido utilizado en varios proyectos con equipos de +500 personas

41. Scrum de Scrums

42. Scrum de scrums de scrums

43. Para saber más www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com [email_address]

44. Lecturas recomendadas Agile and Iterative Development: A Manager’s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber User Stories Applied for Agile Software Development by Mike Cohn Artículos semanales en www.scrumalliance.org

45. Copyright You are free: to Share―to copy, distribute and and transmit the work to Remix―to adapt the work Under the following conditions Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Nothing in this license impairs or restricts the author’s moral rights. For more information see http://creativecommons.org/licenses/by/3.0/