Introduccion A SCRUM

UNA INTRODUCCIÓN A SCRUM
Jorge Hernán Abad Londoño

jorge.abad@gmail.com
AGENDA
 Manifiesto Ágil
 Historias de usuario
 El juego de la estimación
 Scrum
 Scrum Framework
2 05/04/2018
El Manifesto Ágil – una
declaración de valores
Individuos e Procesos y
sobre
interacciones herramientas
Documentación
Software que funciona sobre
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
Analicemos!!!
Diferencia entre aproximación tradicional y las aproximaciones ágiles.

(Chaos Report 2010)
 Según el Chaos Report de Standish Grupo La aproximación

tiene más probabilidades de éxito, frente a la forma tradicional
de abordar los proyectos de software (43% de éxito proyectos
ágiles vs 26% de proyectos tradicionales)
8 05/04/2018
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 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
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.
 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.
 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.
SCRUM
¿QUÉ ES CLAVE
PEOPLE
PARA
DESARROLLAR UN
BUEN PRODUCTO O
SERVICIO?
TECHNOLOGY
PROCESS
Underlying Premise of Process Improvement
“The quality of a product is

largely determined by the
quality of the process that is
used to develop and maintain
it.”
Based on TQM principles as taught by
Shewhart, Juran, Deming and Humphrey.
The Software Development Paradox
High-Quality but
Slow to Market
Not a Leader
Quality
Fast to Market
Speed but Low Quality
Low Customer
Satisfaction
[1]Booch
FRASE
 “LA METODOLOGÍAGARANTIZA EL
PROCESO PERO NO GARANTIZA EL
PRODUCTO”
Proceso
herramie
Personas
ntas
¿por qué?
29 05/04/2018
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
 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.
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:
•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:
 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”
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 a lo 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
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
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
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
Condiciones
del Negocio Planificación
• Decidir como alcanzar el objetivo
del Sprint (diseño)
Producto
• Crear el Sprint Backlog (tareas) en Sprint
Actual
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
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
Aplicación con B.Datos
necesarios para estudios de
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).
tableros de mando
Tableros de Mando
68
Otra forma de ver el tablero de mando
Recordemos
Un Sprint Burndown Chart
Hours
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
20
10
Hours
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-Scrum
Scrum
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.
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.com
www.mountaingoatsoftware.com
(720) 890-6110 (office)
Tomado de:
 Una introducción a Scrum - Ernesto Grafeuille.
 Modificado por Jorge Hernán Abad L.

Introduccion A SCRUM

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introduccion A SCRUM

Transféré par

Droits d'auteur :

Formats disponibles

UNA INTRODUCCIÓN A SCRUM

Jorge Hernán Abad Londoño

Diferencia entre aproximación tradicional y las aproximaciones ágiles.

 Según el Chaos Report de Standish Grupo La aproximación

 Como (rol) quiero (algo) para poder (beneficio).

“The quality of a product is

• Nos permite rápidamente y en repetidas ocasiones

Requisitos Diseño Código Test

En lugar de hacer todo de

Source: “The New New Product Development Game” by Takeuchi

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

 Define las funcionalidades del producto

COMO planificador Codificar la capa intermedia (8 hs)

Soportar más indicadores técnicos

 Bajo las siguientes condiciones

 Nada de lo dispuesto en esta licencia menoscaba

Presentado por: Mike Cohn

Vous aimerez peut-être aussi