You are on page 1of 97

Una Introducción a Scrum

Jorge Hernán Abad Londoño


jorge.abad@gmail.com
Agosto 2009
Agenda
 Metodologías ágiles
 Historias de usuario
 Scrum
 El juego de la estimación
METODOLOGÍAS
ÁGILES
El Manifesto Ágil – una
declaración de valores
Individuos e Procesos y
sobre
interacciones herramientas
Software que Documentación
sobre
funciona exhaustiva
Colaboración Negociación de
sobre
con el cliente contratos
Responder Seguimiento
sobre
ante el cambio de un plan
Fuente: www.agilemanifesto.org
Algunos principios y valores ágiles
 La prioridad mayor es la satisfacción del cliente haciendo
entregas continuas de software valioso para él
 Los cambios son bienvenidos siempre
 La medida principal de progreso es el software funcionando
 El gestor es un facilitador no un controlador
 Equipos auto-organizados y multidisciplinares
 Inspeccionar y adaptar
 Mejora continua
 Respeto, claridad y comunicación
 Ritmo sostenible
 La arquitectura y diseño emergen
Ágil no es hacer lo que se quiera
 … ni tampoco programación heroica
La magia no existe
 Ken Schwaber: “En Scrum, un grupo en el que se
lleven mal entre ellos, no comprendan el negocio del
cliente y trabajen con malas herramientas... también
producirán incrementos periódicos... de basura. ”
 Dan visibilidad y transparencia desde el principio,
aunque no resuelven todos los problemas.
 No ser extremista, usar lo que te funcione
 Se recomienda primero usar todo, luego hacer
modificaciones. Cuidado con “Scrum but…”
HISTORIA DE
USUARIOS

Fuente Wikipedia
Historias de Usuario
 Una historia de usuario es una representación
de un requerimiento de software escrito en una
o dos frases utilizando el lenguaje común del
usuario. Las historias de usuario son utilizadas
en las metodologías de desarrollo ágiles para la
especificación de requerimientos (acompañadas
de las discusiones con los usuarios y las pruebas
de validación). Cada historia de usuario debe ser
limitada, esta debería poderse escribir sobre una
nota adhesiva pequeña. Dentro de la
metodología XP las historias de usuario deben
ser escritas por los clientes.
Historias de Usuario
 Las historias de usuario son una forma
rápida de administrar los requerimientos
de los usuarios sin tener que elaborar
gran cantidad de documentos formales y
sin requerir de mucho tiempo para
administrarlos. Las historias de usuario
permiten responder rápidamente a los
requerimientos cambiantes.
Características
 Independientes unas de otras: De ser necesario, combinar las historias
dependientes o buscar otra forma de dividir las historias de manera que resulten
independientes.
 Negociables: La historia en si misma no lo suficientemente explícita como para
considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su
alcance y éste debe dejarse explícito bajo la forma de pruebas de validación.
 Valoradas por los clientes o usuarios: Los intereses de los clientes y de los
usuarios no siempre coinciden, pero en todo caso, cada historia debe ser
importante para alguno de ellos más que para el desarrollador.
 Estimables: Un resultado de la discusión de una historia de usuario es la
estimación del tiempo que tomará completarla. Esto permite estimar el tiempo
total del proyecto.
 Pequeñas: Las historias muy largas son difíciles de estimar e imponen
restricciones sobre la planificación de un desarrollo iterativo. Generalmente se
recomienda la consolidación de historias muy cortas en una sola historia.
 Verificables: Las historias de usuario cubren requerimientos funcionales, por lo
que generalmente son verificables. Cuando sea posible, la verificación debe
automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.
Características
 Si bien el estilo puede ser libre, la historia
de usuario debe responder a tres
preguntas: ¿Quién se beneficia?, ¿qué se
quiere? y ¿cuál es el beneficio? Por ello,
algunos autores[1] recomiendan redactar
las historias de usuario según el formato:

 Como (rol) quiero (algo) para poder


(beneficio).
Beneficios
 Al ser muy corta esta representa requisitos del
modelo de negocio que pueden implementarse
rápidamente (días o semanas)
 Necesitan poco mantenimiento
 Mantienen una relación cercana con el cliente
 Permite dividir los proyectos en pequeñas
entregas
 Permite estimar fácilmente el esfuerzo de
desarrollo
 Es ideal para proyectos con requerimientos
volátiles o no muy claros
Limitaciones
 Sin pruebas de validación pueden quedar abiertas a distintas
interpretaciones haciendo difícil utilizarlas como base para
un contrato
 Se requiere un contacto permanente con el cliente durante
el proyecto lo cual puede ser difícil o costoso
 Podría resultar difícil escalar a proyectos grandes
 Requiere desarrolladores muy competentes
 Sin pruebas de validación pueden quedar abiertas a distintas
interpretaciones haciendo difícil utilizarlas como base para
un contrato
 Se requiere un contacto permanente con el cliente durante
el proyecto lo cual puede ser difícil o costoso
 Podría resultar difícil escalar a proyectos grandes
 Requiere desarrolladores muy competentes
SCRUM
Estamos perdiendo la carrera de
relevos
“En enfoque de ‘carrera de relevos’ en el
desarrollo de productos ... puede entrar en
conflicto con los objetivos de máxima
velocidad y flexibilidad. En su lugar, un
enfoque holístico o estilo ‘rugby’ - donde un
equipo intenta ir a la distancia como una
unidad, pasando la pelota hacia adelante y
hacia atrás -pueden servir mejor a los
actuales requisitos competitivos".
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product Development
Game”, Harvard Business Review,
January 1986.
Scrum en 100 palabras
• Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el menor
tiempo.
• Nos permite rápidamente y en repetidas ocasiones
inspeccionar software real de trabajo (cada dos semanas
o un mes).
• El negocio fija las prioridades. Los equipos se auto-
organizan a fin de determinar la mejor manera de
entregar las funcionalidades de más alta prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el
software real funcionando y decidir si liberarlo o seguir
mejorandolo en otro sprint.
SCRUM
 Scrum es una metodología para la gestión de proyectos,
expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el
artículo The New New Product Development
Game[Harvard Business Review Ene-Feb 1986] en el
que ponen de manifiesto que:
◦ El mercado competitivo de los productos tecnológicos, además
de los conceptos básicos de calidad, coste y diferenciación, exige
también rapidez y flexibilidad.
◦ Los nuevos productos representan cada vez un porcentaje más
importante en el volumen de negocio de las empresas.
◦ El mercado exige ciclos de desarrollo más cortos.
SCRUM
 El artículo compara al desarrollo tradicional de
ciclo de vida formado por fases separadas y
equipos especializados con las carreras de
relevos, donde un equipo pasa el testigo al
siguiente hasta finalizar el desarrollo del
producto. Siguiendo el símil deportivo, se
compara al nuevo modelo de desarrollo, basado
en el solapamiento de las fases y en un único
equipo multi-disciplinar, con la evolución del
juego del rugby; y de él se toma el término
scrum.
SCRUM
SCRUM
 Nonaka y Takeuchi extraen las bases de scrum de las
prácticas que observan en las empresas con buenos
resultados de rapidez y flexibilidad en la producción:
Xerox, Canon, Honda, NEC, Epson, Brother, 3M o
Hewlett-Packard; y son:
◦ Inestabilidad consustancial al entorno de desarrollo.
◦ Equipos auto-organizados.
◦ Solapamiento de las fases del desarrollo.
◦ Multi-aprendizaje.
◦ Control sutil.
◦ Transferencia de aprendizaje a nivel organizacional.
SCRUM
 Aunque surgió como modelo para el desarrollo de productos tecnológicos,
también se emplea en entornos que trabajan con requisitos inestables y que
requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de
determinados sistemas de software.
 Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel
Corporation (Empresa que en los macro-juegos de compras y fusiones se
integraría en VMARK, luego en Informix y finalmente en Ascential Software
Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal,
también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en
2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de
software scrum está considerado como modelo ágil por la Agile Alliance.

 La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que
son:
◦ Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
◦ Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog),
Incremento.
◦ Reuniones:
 Planificación del sprint, Revisión diaria, Revisión del sprint.
◦ Sprint
Orígenes de Scrum
 Jeff Sutherland
◦ Scrums iniciales en Easel Corp en 1993
◦ IDX 500 personas haciendo Scrum
 Ken Schwaber
◦ ADM
◦ Se presenta Scrum en OOPSLA 96 con Sutherland
◦ Autor de tres libros sobre Scrum
 Mike Beedle
◦ Patrones Scrum en PLOPD4
 Ken Schwaber and Mike Cohn
◦ Fundaron conjuntamente la Scrum Alliance en 2002,
inicialmente dentro de la Agile Alliance
Scrum ha sido utilizado por:
por :
•Microsoft •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts •BMC Software
•High Moon Studios •Ipswitch
•Lockheed Martin •John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •Salesforce.com
•Capital One •Time Warner
•BBC •Turner Broadcasting
•Intuit •Oce
Scrum ha sido utilizado para:
para:
 Software comercial • Desarrollo de video juegos
 Desarrollos internos • Sistemas críticos de soporte
vital, aprobados por laFDA
 Desarrollos bajo Contrato
 Proyectos Fixed-price
• Software de control satelital

 Aplicaciones Financieras
• Sitios Web
 Aplicaciones certificadas ISO
• Software para Handheld
9001 • Teléfonos portátiles
 Sistemas Embebidos • Aplicaciones de Network
switching
 Sistemas con requisitos 7x24
y 99.999% de disponibilidad • Aplicaciones de ISV
 Joint Strike Fighter • Algunas de las más grandes
aplicaciones en uso
Características
 Es una de las metodologías ágiles
 Equipos auto-organizados
 El producto avanza en una serie de “Sprints"
de dos semanas a un mes de duración
 Los requisitos son capturados como
elementos de una lista de “Product Backlog"
 No hay prácticas de ingeniería prescritas
 Utiliza normas generativas para crear un
entorno ágil para la entrega de proyectos
 Uno de los “procesos ágiles”
Nivel de ruido de un proyecto

Lejos de
Acuerdo
Anarquía
Requisitos

Complejo

Fuente: Strategic Management and


Organizational Dynamics by Ralph
Stacey in Agile Software Development
with Scrum by Ken Schwaber and Mike
Cerca de Simple Beedle.

Acuerdo
Cerca de
Certeza

Lejos de
Certeza
Tecnología
Scrum 24 horas

Sprint
2-4 semanas
Objetivo del Sprint

Sprint
Incremento del producto
Return Backlog
potencialmente entregable
Gift wrap
Cancel
Product
Backlog
Poniendo todo junto

Imagen disponible en
www.mountaingoatsoftware.com/scrum
Sprints
 En Scrum los proyectos avanzan en una serie
de “Sprints”
◦ Análogo a las iteraciones en XP
 La duración típica es 2–4 semanas o alo
sumo un mes calendario
 La duración constante conduce a un mejor
ritmo
 El product es diseñado, codificado y testeado
durante el Sprint
Desarrollo secuencial vs.
superpuesto

Requisitos Diseño Código Test

En lugar de hacer todo


de una cosa a la vez ...
...los equipos Scrum
hacen un poco de todo
todo el tiempo

Source: “The New New Product Development Game” by


Takeuchi and Nonaka. Harvard Business Review, January
1986.
No hay cambios en un sprint
Cambios

 Planee la duración del sprint en torno a cuánto tiempo


usted puede comprometerse a mantener los cambios
fuera del sprint
Scrum Framework
Roles
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
Scrum framework
Roles
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
Product Owner

 Define las funcionalidades del producto


 Decide sobre las fechas y contenidos de los releases
 Es responsable por la rentabilidad del producto (ROI)
 Prioriza funcionalidades de acuerdo al valor del
mercado/negocio
 Ajusta funcionalidades y prioridades en cada iteración
si es necesario
 Acepta o rechaza los resultados del trabajo del equipo
El ScrumMaster
 Representa a la gestión del proyecto
 Responsable de promover los valores y prácticas
de Scrum
 Remueve impedimentos
 Se asegura de que el equipo es completamente
funcional y productivo
 Permite la estrecha cooperación en todos los
roles y funciones
 Escudo del equipo de interferencias externas
El Team
 Típicamente de 5 a 9 personas
 Multi-funcional:
◦ Programadores, testers, analistas, diseñadores, etc.
 Los miembros deben ser full-time
◦ Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)
 Los equipos son auto-organizativos
◦ Idealmente, no existen títulos pero a veces se utilizan de acuerdo a
la organización
 Solo puede haber cambio de miembros entre
los sprints
Scrum Framework
Roles
•Product owner
•ScrumMaster
•Team
Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
Capacidad
Sprint Planning meeting
del Equipo
Priorización

Product • Analizar y evaluar el Product Objetivo


Backlog Backlog del Sprint
• Seleccionar el objetivo del Sprint
Condicione
s del Planificación
Negocio
• Decidir como alcanzar el objetivo
del Sprint (diseño)
Producto
• Crear el Sprint Backlog (tareas) Sprint
Actual
en base a los temas del Product Backlog
Backlog (user stories / features)
• Estimar Sprint Backlog en horas
Tecnología
Planificación del Sprint
 El equipo selecciona los temas a partir del Product Backlog
que pueden comprometerse a completar
 Se crea el Sprint Backlog
◦ Se identifican tareas y cada una es estimada (1-16 horas)
◦ Realizado colaborativamente, no solo por el ScrumMaster
 El diseño de Alto Nivel es considerado

COMO planificador Codificar la capa intermedia (8 hs)


de vacaciones, YO Codificar la interfaz de usuario (4)
QUIERO ver fotos Escribir los test fixtures (4)
de los hoteles. Codificar la clase foo (6)
Actualizar test de performance (4)
Daily Scrum
 Parámetros
◦ Diaria
◦ Dura 15 minutos
◦ Parados
 No para la solución de problemas
◦ Todo el mundo está invitado
◦ Sólo los miembros del equipo, ScrumMaster y
Product Owner, pueden hablar
◦ Ayuda a evitar otras reuniones innecesarias
Todos responden 3 preguntas
1
¿Qué hiciste ayer?

2
¿Qué vas a hacer hoy?

3
¿Hay obstáculos en tu camino?
 No es dar un status report al Scrum Master
 Se trata de compromisos delante de pares
Sprint review
 El equipo presenta lo realizado durante el
sprint
 Normalmente adopta la forma de una demo
de las nuevas características o la arquitectura
subyacente
 Informal
◦ Regla de 2 hs preparación
◦ No usar diapositivas
 Todo el equipo participa
 Se invita a todo el mundo
Sprint retrospective
 Periódicamente, se echa un vistazo a lo que
funciona y lo que no
 Normalmente 15 a 30 minutos
 Se realiza luego de cada sprint
 Todo el equipo participa
◦ ScrumMaster
◦ Product owner
◦ Equipo
◦ Posiblemente clientes y otros
Start / Stop / Continue
 Todo el equipo se reúne y discute lo que les
gustaría:
Comenzar a hacer

Dejar de hacer
Esto es sólo una
de las muchas
maneras de Continuar haciendo
hacer una
retrospectiva.
Scrum framework
Roles
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
Product Backlog
 Los requisitos
 Una lista de todos los trabajos
deseados en el proyecto
 Idealmente cada tema tiene
valor para el usuarios o el
cliente
 Priorizada por el Product
Owner
 Repriorizada al comienzo de
cada Sprint
Este es el
product backlog
Ejemplo de Product Backlog
Backlog item Estimación
Permitir que un invitado a hacer una reserva. 3
Como invitado, quiero cancelar una reserva. 5
Como invitado, quiero cambiar las fechas de
3
una reserva.
Como un empleado de hotel, puedo ejecutar
informes de los ingresos por habitación 8
disponible
Mejorar el manejo de excepciones 8
... 30
... 50
Ejemplo de Product Backlog
El objetivo del Sprint
 Una breve declaración de cual será el foco del
trabajo durante el sprint
Ciencias Biológicas
Funciones de apoyo técnico
necesarios para estudios de
Aplicación con B.Datos
genética de poblaciones.
Hacer que la aplicación se
ejecute en SQL Server, además
de Oracle. Servicios Financieros

Soportar más indicadores


técnicos que la empresa ABC en
tiempo real y streaming de datos.
Gestión del Sprint Backlog
 Los individuos eligen las tareas
 El trabajo nunca es asignado
 La estimación del trabajo restante es actualizada
diariamente
 Cualquier miembro del equipo puede añadir, borrar o
cambiar el Sprint Backlog
 El trabajo para el Sprint emerge
 Si el trabajo no está claro, definir un tema del Sprint
Backlog con una mayor cantidad de tiempo y
subdividirla luego.
 Actualizar el trabajo restante a medida de que más se
conoce
Ejemplo de Sprint Backlog
Tareas L M M J V
Codificar UI 8 4 8
Codificar negocio 16 12 10 4
Testear negocio 8 16 16 11 8
Escribir ayuda online 12
Escribir la clase foo 8 8 8 8 8
Agregar error logging 8 4
Ejemplo de Sprint Backlog
Seguimiento
 Es recomendable, que el propietario del producto
emplee una hoja de cálculo, alguna herramienta
similar, o el soporte de una intranet, para guardar en
formato digital la pila del producto.
 Pero no es aconsejable emplearla como base para
trabajar sobre ella en la reunión proyectándola sobre
la pantalla de la sala.
 Es mucho mejor trabajar y manipular elementos
físicos; y usar una pizarra y fichas removibles
(adhesivas, con chinchetas o magnéticas).
Tablero de trabajo
Un área superior donde el Scrum Manager coloca al principio de la
reunión la capacidad real del sprint a 3, 4 y 5 semanas (A); y al final (D),
las notas con: el objetivo establecido, duración del sprint,
funcionalidades de la pila del producto comprometidas, hora fijada para
las reuniones diarias y fecha prevista para la reunión de revisión del
sprint.
B.- Una franja para ordenar los elementos de la pila del producto
de mayor a menor prioridad.
C.- Una franja paralela para descomponer cada elemento de la pila
del producto en las correspondientes tareas de la pila del sprint.
Pruducto
Sprint
Objetivo del sprint
Otra forma de ver el tablero de
mando
Otra forma de ver el tablero de
mando
Recordemos
Hours Un Sprint Burndown Chart
Tareas L M M J V
Codificar UI 8 4 8
Codificar Negocio 16 12 10 7
Testear Negocio 8 16 16 11 8
Escribir ayuda online 12

50
40
30
Hours

20
10
0
Mon Tue Wed Thu Fri
Escalabilidad
 Normalmente los equipos son de 7 ± 2
personas
◦ La escalabilidad proviene de equipos de equipos
 Factores a tener cuenta
◦ Tipo de aplicación
◦ Tamaño del equipo
◦ Dispersión del equipo
◦ Duración del proyecto
 Scrum se ha utilizado en múltiples proyectos de
más de 500 personas
Expansión a través de Scrum de
scrums
Scrum de scrums de scrums
Scrum of Scrums / Meta-
Meta-Scrum
Scrum
EL JUEGO DE LA
ESTIMACIÓN
Poker Game
 Planificación de póquer es una variación del método
Delphi.
 Es simple, se burla y los resultados de estim
 Planificación de póquer se utiliza para estimar el
esfuerzo o el tamaño relativo de las tareas en el
desarrollo de software de manera fiable.
 Los miembros del equipo del proyecto se reúnen y
en unas pocas rondas mediante el Poker Game llegan
a un consenso sobre el tamaño de cada tema o tarea.
La baraja de Cartas
 Cada juevo de cartas incluye los
números 0, (0,5), 1, 2, 3, 5, 8, 13, 20, 40,
100, y, a veces, un café tarjeta.
 Cada miembro del equipo necesita una
baraja de cartas
La reunión de planificación (1)
 Al comienzo de la planificación de póquer,
cada estimador se le da un mazo de cartas.
 Para cada Historia de Usuario o tema que se
va a estimar, un moderador lee la descripción.
 El moderador suele ser el propietario del
producto o una analista. Sin embargo, el
moderador puede ser cualquier persona, ya
que no hay privilegio especial asociado con el
papel.
La reunión de planificación (2)
 El Dueño del producto (Product Owner) responde
todas las preguntas que tienen los estimadores.
 Después de todas las preguntas cada estimador
selecciona una carta de forma secreta e individual.
 Las tarjetas no se muestran hasta que todos hayan
hecho su estimación. Luego todos muestran al mismo
tiempo la carta elegida
 El grupo puede discutir la historia y sus estimaciones
durante unos minutos más. Principalmente se indaga
a las personas que están lejanas de la media que
explique su posición.
 Tras el debate se hace otra ronda de estimacion en
privado.
La reunión de planificación (3)
 Valores altos de tiempo implican
◦ Baja granularidad
◦ Alta complejidad
◦  se recomienda en lo posible dividir en
tareas más pequeñas.
 Si sale (?) Implica que no se tiene idea de
que se esta hablando
 Si sale la taza de café, indica que la
persona esta casada.
Resultados
 En muchos casos, las estimaciones
convergen en la segunda ronda. En caso
contrario se debe repetir el proceso.
 El objetivo es converger a una única
estimación.
Donde seguir?
 www.mountaingoatsoftware.com/scrum
 www.scrumalliance.org
 www.controlchaos.com
 scrumdevelopment@yahoogroups.com
Una lista de lecturas sobre Scrum
 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
Aviso de Copyright
 Usted es libre de:
◦ Compartir- copiar, distribuir y trasmitir el trabajo
◦ Modificar- adaptar el trabajo

 Bajo las siguientes condiciones


◦ Atribución. Ud. debe atribuir el trabajo en la manera especificada
por el autor o licenciante (pero de ninguna manera que sugiera
que ellos aprueban su uso del trabajo).

 Nada de lo dispuesto en esta licencia


menoscaba o restringe los derechos morales
del autor.
 Para más información ver http://creativecommons.org/licenses/by/3.0/
Información de Contacto
Presentado por: Mike Cohn
mike@mountaingoatsoftware.co
m
www.mountaingoatsoftware.com
(720) 890-6110 (office)
Tomado de:
 Una introducción a Scrum - Ernesto
Grafeuille.

You might also like