Scrum

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

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”

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

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

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

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

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”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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.

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

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

Burndown chart Horas

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

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

Tasks boards (II)

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)

Task boards (IV)

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

Scrum de Scrums

Scrum de scrums de scrums

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

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

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/

http://agilemanontroppo.blogspot.com	45
http://www.slideshare.net	16
http://agilemanontroppo.blogspot.com.es	2
http://www.blogger.com	1

Scrum

by David Doctor on Jul 30, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 64

Statistics

Scrum — Presentation Transcript