Gestin gil con

Scrum
Predecir es muy difcil, especialmente el
futuro Niels Bohr, premio Nobel de fsica
ndice
Introduccin
Principios bsicos de las Metodologas Agiles
Scrum
Quin forma parte de un proyecto de Scrum?
Planificacin inicial
Product Backlog
Estimacin
Product Sprint
Daily Scrums
Seguimiento del Sprint
Reunin de demo del Sprint
Retrospectivas
Cmo empezamos?
Introduccin
Tradicionalmente, los proyectos informticos se han gestionado siempre
de la misma manera: inicio del proyecto, toma de requisitos, anlisis,
diseo, programacin, pruebas, puesta en produccin

Para garantizar que a lo largo de este proceso no nos alejamos del objetivo
perseguido por el cliente, se genera una cantidad ingente de
documentacin, actas, informes de seguimiento, solicitudes de gestin
de cambios, diseos, validaciones, etc

Al mismo tiempo, tratamos de acotar el alcance inicial y no desviarnos

de l, para evitar que los proyectos se alarguen en tiempo o coste

Recientemente han surgido las nuevas metodologas giles, como

Scrum, que ofrecen un planteamiento completamente diferente. Y estn
funcionando.
Diez principales causas de fallo de los proyectos
1. Escasa participacin de los usuarios
2. Requerimientos y especificaciones incompletas
3. Cambios frecuentes en los requerimientos y especificaciones
4. Falta de soporte ejecutivo
5. Incompetencia tecnolgica
6. Falta de recursos
7. Expectativas no realistas
8. Objetivos poco claros
9. Cronogramas irreales
10.Nuevas tecnologas

y fallan el 71% segn el Standish Group

Introduccin: Vida cotidiana de un jefe de proyecto
Un cliente pide una propuesta para conseguir un determinado producto de software

El cliente tiene una idea aproximada de lo que quiere, que intenta transmitirte

Con esta borrosa informacion realizas una estimacin de tiempo y coste, que acuerdas con el cliente:
esto lo tendrs dentro de 12 semanas por 100.000

La primera fase del proyecto es la toma detallada de requisitos. Comienzan a aparecer requisitos que
nunca imaginaste

Como el plazo y coste estn cerrados, te agarras a la respuesta tradicional: esto est fuera del
alcance

El cliente se incomoda. Te presiona para que aceptes. Tu jefe y equipo te presionan para que NO
aceptes

A lo largo del proyecto, surgen nuevas necesidades no contempladas inicialmente: funcionalidades

muy deseables en las que nadie pens, integraciones convenientes con otros sistemas, ideas brillantes
del propio equipo de desarrollo A todo decimos que NO para no desviarnos del alcance inicial
Introduccin: Vida cotidiana de un jefe de proyecto

Al cabo de 12 semanas el producto est terminado. El cliente lo ve por primera

vez, y descubre que:
No es eso exactamente lo que l tena en la cabeza.
Quiz no lo transmiti bien
El producto carece de funcionalidades muy importantes que
surgieron posteriormente al cierre del alcance, y no
pudieron incorporarse
El producto tiene ciertas funcionalidades que no resultan
muy tiles, o que podran haberse definido mejor
Y ahora cmo le cuento yo esto a MI jefe?

Por tanto, los 100.000 no se han empleado de la mejor manera posible. Y ahora
es cuando le pides otros 50.000 para lanzar la fase II, e incorporar todo lo que se
qued por el camino
Te van a volver a contratar?

Probablemente s, porque as es como todo el mundo hace las cosas.

No?
Introduccin: Qu es Scrum?
Introduccin: Principios bsicos de Scrum

Scrum supone un cambio radical de enfoque,

pasando de controlar a facilitar, de dirigir a
realizar coaching
Introduccin: Scrum se ha usado para
Desarrollo de software comercial
Desarollos internos
Proyectos a precio cerrado
Sistemas 24x7 con disponibilidad 99,999%
Joint Strike Fighter
Desarrollo de video juegos
Websites
Software de control de satlites
Telfonos mviles
Aplicaciones de networking
Algunas de las mayores aplicaciones en uso
Introduccin: Scrum acepta que

el problema no puede ser totalmente definido o comprendido desde el

principio

hay que maximizar la habilidad del equipo para adaptarse lo ms

rpidamente posible

el cliente NO es el enemigo

la mejor comunicacin es la comunicacin cara a cara

el software en funcionamiento es la principal medida de progreso

Principios bsicos de las metodologas giles

Individuos y su interaccin vs. Procesos y herramientas

Software que funciona vs. Documentacin exhaustiva

Colaboracin con el cliente vs. Negociacin contractual

Respuesta al cambio vs. Seguimiento de un plan

www.agilemanifesto.org
Manifiesto gil
1. Nuestra mayor prioridad es satisfacer al cliente a travs de la entrega temprana y continua de software
con valor.
2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos giles aprovechan el
cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software frecuentemente, con una periodicidad desde un par de semanas a un par de
meses, con preferencia por los periodos ms cortos posibles.
4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del
proyecto.
5. Construimos proyectos con profesionales motivados. Dndoles el entorno y soporte que necesitan, y
confiando en ellos para que realicen el trabajo.
6. El mtodo ms eficiente y efectivo de comunicar la informacin a un equipo de desarrollo y entre los
miembros del mismo es la conversacin cara a cara.
7. Software que funciona es la principal medida de progreso.
8. Los procesos giles promueven el desarrollo sostenible. Esponsores, desarrolladores y usuarios deben
ser capaces de mantener un ritmo constante de forma indefinida.
9. La atencin continua a la excelencia tcnica y los buenos diseos mejoran la agilidad.
10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseos surgen de equipos que se autoorganizan.
12. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo, entonces mejora y ajusta su
comportamiento de acuerdo a sus conclusiones.
Principios bsicos de Scrum
Entrega continua de VALOR al cliente
El producto progresa en iteraciones entre 2-4 semanas
Posibilidad de introducir nuevos requisitos en cualquier
momento
Equipos multidisciplinares y auto-organizados: cada uno
decide qu es lo mejor que puede hacer en cada momento para
aportar el mximo valor al proyecto. Cada equipo es una
nueva start-up.
Time-boxing para estimular el mximo aprovechamiento del
tiempo Modificaciones de requisitos
Comunicacin directa cara a cara, manipulacin fsica de
objetos
Aportaciones de valor al producto

No a las reuniones eternas

No a la produccin indiscriminada de documentacin
No a la separacin cliente / equipo o jefe / desarrollador
No a la planificacin inicial detallada
Principios bsicos de Scrum
Os gusta el sashimi?
Scrum: Cambian los roles

Team

Product Owner

Scrum Master
Scrum: Cambia el proceso

Obtencin del
Planificacin Demo del
Product A trabajar! Retrospectiva
del Sprint Sprint
Backlog

Daily Scrum
Quin forma parte de un proyecto de Scrum?

El viejo chiste de los cerdos y las gallinas

Quin forma parte de un proyecto de Scrum?

Quines son los cerdos? Los que se estn jugando el jamn

El equipo
El Scrum Master
El Product Owner

Quines son las gallinas? Los que pueden contribuir con un huevo

Usuarios
Negocio
Cualquier tipo de stakeholder

Sus opiniones sern bienvenidas, pueden contribuir con su

experiencia pero nunca intervenir en el trabajo del equipo
Quin forma parte de un proyecto de Scrum?

El equipo

Corresponde con lo que seran tradicionalmente analistas,

diseadores, programadores, equipos de pruebas, soporte tcnico

Se convierten en un equipo multidisciplinar y auto-organizado:

nadie le dice a nadie lo que debe hacer, y cualquiera puede abordar
cualquier tarea en caso de necesidad. Quiz un programador
tradicional se encargue de su propio diseo, o un probador eche
una mano programando.

Son los encargados de decidir de forma conjunta cmo llevar a cabo

los objetivos del Sprint, y tienen la responsabilidad conjunta de los
resultados
Quin forma parte de un proyecto de Scrum?
El Scrum Master

NO es un jefe de proyecto. No distribuye las tareas, no realiza el

seguimiento, no es el nico interlocutor con el cliente

Su misin es que nada interfiera con el trabajo del equipo. Protege al

equipo de interrupciones ajenas, y vela por que el proceso del Scrum se
siga correctamente. Por ejemplo:

Se asegura de que las reuniones diarias tienen lugar, y de la forma

correcta
Se asegura de que nadie introduzca tareas a los miembros del
equipo a mitad de un Sprint
Se asegura de que el Product Owner sepa hacer su trabajo
Si surge algn inconveniente se encarga de solucionarlo (desde
hace demasiado fro en esta oficina, hasta el servidor de
pruebas no ha llegado en la fecha prevista)
Se asegura de que la demo del Sprint se celebra en la fecha
prevista, y asisten todos los interesados

En resumen: es un gua, un facilitador del proceso, y no un

Quin forma parte de un proyecto de Scrum?

El Product Owner

En pocas palabras, es quien decide el alcance del proyecto: mantiene la

lista de funcionalidad (historias) a realizar, ordenada segn su prioridad

Es decir, decide que el producto final tendr por ejemplo un catlogo de

productos, una pasarela de pago, y que considera ms importante el
catlogo que la pasarela

Tiene autoridad para decidir qu entra y qu no entra en el proyecto, y la

importancia relativa de cada requisito frente a los dems. Por tanto, tiene
la foto final de la visin del producto, y capacidad para alterarla si lo
considera necesario.

Debe estar disponible para aclarar las dudas del equipo.

Quin forma parte de un proyecto de Scrum?
Y aqu quin manda?
Nadie. O mejor dicho, todos.
No hay un nico responsable del producto final. El equipo completo es
responsable de la funcionalidad implementada.
Este cambio de mentalidad es un aspecto crucial del Scrum. No se trata de
cambiar un desarrollo en cascada por desarrollo iterativo: se trata de que el
equipo se organiza de una forma completamente distinta para conseguir los
resultados
Los problemas de un individuo pertenecen inmediatamente a todo el equipo
Implica ms incertidumbre, ms madurez por parte del equipo, ms generosidad,
ms espritu de equipo, ms ganas de sacar el producto adelante.

Cmo nos sentamos?

War-rooms! Fuera cubculos y separaciones: habitaciones abiertas, con mesas
redondas para discusiones, pizarras y flip-charts cualquiera cosa que favorezca
la comunicacin cara a cara. Y todo el equipo junto!
Planificacin inicial

Qu necesitamos para planificar un proyecto de Scrum

inicialmente?

Dos cosas: una visin y un Producto Backlog

La visin describe por qu estamos emprendiendo el proyecto:

cul ser la situacin final. Si es un proyecto interno, cmo se
mejorar la operativa del departamento gracias al nuevo
producto, y si es externo cules sern sus principales
caractersticas, funcionalidades, y cmo afectar al mercado. Es
decir, por qu nos vamos a concentrar las prximas semanas en
esto en lugar de irnos de vacaciones
Product Backlog
Product Backlog - una lista ordenada de requisitos (historias en Scrum),
funcionales y no funcionales, que incorporar nuestro producto final y
permitirn conseguir la visin

Es el Product Owner el encargado de generar esta lista inicial y

de mantenerla actualizada
Cualquier persona puede introducir nuevos requisitos en la
lista en cualquier momento, pero
slo el Product Owner puede priorizarla
Es decir, cualquier usuario imaginativo puede decidir que le
gustara que el nuevo ERP dejara incorporar fotos personales:
introduce el requisito en el Product Backlog, y probablemente
el Product Owner le otorgue una prioridad 0 y lo enve al final
de la cola
Los elementos del Product Backlog estn priorizados y
estimados
Product Backlog
Product Backlog - qu campos incluye esta lista? Los mnimos necesarios para que
resulten tiles, como pueden ser:

ID un nmero para identificar la historia

Nombre breve descripcin de la historia. Muy breve, tipo: consulta de los datos del cliente,
o ver historial de pedidos
Categora para ayudar en bsquedas, repriorizaciones, etc. Ejemplo: facturacin,
reclamaciones, informes, etc
Solicitante qu persona incluy este requisito o lo traslad al Product Owner, para poder
ofrecerle informacin de cmo va
Prioridad cualquier nmero que sirva para ordenar su importancia respecto al resto de
historias. Se recomienda la regla ms alto = ms prioritario (es decir, prioridad 1 sera la
menor, y no la mayor)
Estimacin cunto trabajo es necesario segn el equipo para terminar la historia. La medida
suelen ser puntos de historia, que normalmente equivale a das ideales (ver ms adelante).
No es necesario que la estimacin sea exacta, pero una historia estimada en 10 puntos s
debera costar la mitad que una estimada en 20 puntos
Prueba breve explicacin de cmo se demostrar en la demo final que se ha cumplido con
este requisito: entrar en pgina de cliente, introducir el DNI de uno de ellos, y comprobar que
se recuperan los datos correctamente. Modificar uno de los datos, y recuperar de nuevo
Product Backlog
ID Nombre Categora Solicitante Prueba Prioridad Estimaci
n
1 Agregar Compras Marta Herreros Abrir un pedido 1000 2
producto al existente, dar a
carrito botn agregar,
seleccionar un
nuevo producto,
comprobar que
se ha agregado al
carrito

2 Recibir un Comunicacin Isabel de la Cruz Cambiar la fecha 950 0,5

correo cuando con cliente envo del pedido,
el pedido se comprobar que
vaya a retrasar se recibe un
correo en el mail
asociado al
cliente
Product Backlog
Cualquier usuario puede agregar historias (es un documento pblico y conocido por todos) pero:
Slo el Product Owner puede modificar la prioridad. Es l quien decide cul es la
importancia relativa de cada requisito, qu funcionalidad necesita antes
Solo el equipo puede insertar o modificar la estimacin

Tambin miembros del equipo pueden aadir, sobre todo requisitos no funcionales que consideren
importantes (escribir una descripcin general del diseo, para que ayude a todos los miembros a
no perder el norte). Estas historias tcnicas pueden en ocasiones mantenerse en una lista aparte.

Otro tipo de elementos en el Product Backlog:

Solucin de bugs: dentro de cada Sprint se puede incluir una historia para resolver los
bugs de las entregas anteriores, cuando el software ya est en produccin (o bien
una historia por cada bug, si tienen la entidad suficiente)
Refactorizacin de cdigo, mejoras tcnicas: es posible aadir tareas que contribuyan
a mejorar el cdigo existente, mejorar su legibilidad y usabilidad, etc
Hasta aqu

De momento ya tenemos:

Un equipo formado, con un Scrum Master y Product Owner seleccionados,

deseando empezar con el proyecto

Un Product Backlog perfectamente conocido por el Product Owner; ste debe

saber exactamente qu significan cada una de las historias, tanto si las ha
introducido l como cualquier otra persona

Estamos listos para empezar a estimar las historias ms prioritarias, y decidir

hasta dnde llegaremos en el prximo Sprint

Ahora a estimar!
Y ahora a estimar

Qu factores influyen a la hora de estimar con exactitud un requisito? El

grado de detalle en la definicin del mismo, tecnologa a emplear,
conocimientos del desarrollador, su estado de nimo e inspiracin en el
momento del desarrollo, interacciones con otros requisitos Conseguir dar
con una estimacin que resulte exacta parece una tarea imposible

Por tanto, el objetivo no debe ser dar una estimacin exacta, sino simplemente
un grado de aproximacin a la magnitud de los requisitos, en valor absoluto y
en relacin con los dems. Al finalizar cada Sprint, comprobaremos si hemos
acertado en las predicciones y el resultado servir para afinar ms en futuros
Sprints, y para actualizar las expectativas de todos los interesados

Es decir: no nos obsesionemos con determinar si un requisito tardar 4 6

das exactamente. Es mejor dar una estimacin de 5 y seguir rpidamente con
el siguiente, que invertir 30 minutos en una discusin
Estamos estimando todos lo mismo?
Resulta fundamental aclarar qu incluyen las estimaciones: slo codificacin?
tiempo de diseo y codificacin? tiempo de pruebas? tiempo de mejora del
cdigo y refactorizacin?

Todos los miembros del equipo tienen que acordar el significado de la palabra
terminado es decir, cdigo terminado puede querer decir programado,
revisado, realizadas las pruebas unitarias, actualizado el manual de usuario, y subido
al servidor de preproduccin. Si alguna de estas etapas falta, el requisito no est
finalizado, aunque el cdigo est programado

Es importante para estimar de forma homognea, y para predecir el tiempo a

invertir posteriormente. Por ejemplo, si no se incluyen tests unitarios, habr
que aumentar el tiempo estimado de la tarea de correccin de bugs

En los primeros intentos con Scrum, puede ser aconsejable aadir un campo
en el Product Backlog con la definicin de terminado para cada historia,
para que no haya problemas. O puede ser simplemente cuando el encargado
de pruebas del equipo diga que est terminado

Recordemos que en Scrum una historia que est terminada al 90% no est. O
es un entregable completamente funcional, o no contamos con l
Product Backlog
A
B
C Sprint 1
D
No hay cambios DURANTE el Sprint
E
Product Backlog F Una vez cerrados los requisitos de un Sprint,
slo los miembros del equipo pueden
G cambiarlos. Cualquier modificacin o aadido
deber dejarse para Sprints siguientes
H

Jugando a las cartas

La estimacin de cada historia es responsabilidad conjunta de todo el

equipo. Pero cmo evitar que el primero en hablar condicione el resto
de las opiniones?

Veamos qu sucede cuando se solicita una estimacin tradicional:

- Jefe: Entonces, cunto tardaramos en finalizar esta

historia?

- Equipo:
Jugando a las cartas
- A cree que lo sabe, est seguro de que se tardar 3 das, por tanto es
el primer en hablar (con seguridad absoluta)

- Esto despista totalmente a B y C, que haban pensado en una

estimacin mucho ms alta. D sigue durmiendo, y E no recuerda de
qu se estaba hablando
Jugando a las cartas

- B y C dudan de su estimacin inicial, y deciden acercarse

ms a lo expresado por A

- D y E no se han molestado en calcularlo, as que el

movimiento ms seguro parece ser mostrarse de acuerdo
con A
Jugando a las cartas
De esta manera, terminamos con una estimacin totalmente condicionada
por la opinin del primero en hablar

Scrum funciona de otra manera: todo el mundo debe dar una estimacin
(no vale escaquearse), y todo el mundo debe hacerlo a la vez para no influir
a los dems. Cmo lo hacemos?

Cada miembro del equipo cuenta con un conjunto de cartas con distintos
valores

Una vez aclarado el significado de cada historia, cada miembro del equipo
selecciona la carta que ms se aproxima a su estimacin y la coloca boca
abajo. Cuando todos han terminado, se giran las cartas
Jugando a las cartas
No existen cartas para todos los valores posibles. Por qu?

Para agilizar el proceso, limitando el nmero de opciones

Para evitar una falsa sensacin de exactitud en las estimaciones ms altas.
Realmente alguien es capaz de prever si una tarea nos llevar 13 o 14 das?
Para animar al equipo a desmenuzar las historias grandes en otras ms
pequeas. Cualquier historia estimada en 20 o superior es conveniente
dividirla en dos historias ms breves

Algunos valores:

0 = esta historia ya est hecha, o son slo unos minutos de trabajo

? = ni idea. Si el uso de esta carta es habitual, es necesario trabajar ms en la
comprensin de las historias
Caf = me vendra bien una pausa!
Jugando a las cartas

Dos posibilidades:

Las estimaciones de todo el equipo son similares: bingo, es difcil

que todos estn muy equivocados. Se puede escoger la media
como estimacin final.

Existen estimaciones muy discrepantes: digamos que un

miembro del equipo dice que 2, y otro opina que 13. Lo ms
probable es que hayan entendido requisitos distintos en la historia,
o que uno de ellos se haya dado cuenta de una complicacin que
los dems no han visto. Se discute brevemente hasta aclarar la
situacin, y se vota de nuevo, hasta llegar a un consenso.
Velocidad del equipo
Supongamos que la estimacin de una historia son 5 das. Qu quieren decir esos
5 das?

Scrum recomienda estimar en puntos de historia, normalmente equivalentes a

dias ideales:

Ideal-man-days: si un buen programador se encierra en una habitacin sin

interrupciones, con comida y bebida, concentracin total y totalmente
enfocado en la programacin, tardara 5 das en terminar la historia descrita

La realidad es que en esos 5 das los telfonos suenan, el programador se

distrae, surge un bug crtico que debe resolver inmediatamente, tiene una
duda tcnica y debe investigar en Internet

Para conjugar ambos mundos existe el concepto de velocidad del equipo.

Veamos qu es.
Velocidad del equipo

Supongamos que nuestro equipo tiene 3 personas y nuestro Sprint

durar 4 semanas:

David: 20 das disponible

Ana: 10 das disponible (tiene 2 semanas de vacaciones justo
ahora)
Jorge: 18 das disponible (se incorpora 2 das tarde)

En total podemos asumir trabajo correspondiente a 48 das, y tenemos

las siguientes estimaciones realizadas segn das ideales:
8
A
B 12
C 6 eso significa que podemos asumir la
Product Backlog realizacion de las 5 primeras historias?
D 20
E 2

F 3
Velocidad del equipo
No. La historia A se estim en 8 das ideales no interrupciones, concentracin
total , en condiciones que nunca se darn.

Entonces cunto trabajo podemos asumir en nuestros 48 das?

Si ya has realizado varios Sprints, ya sabes cul es la media de trabajo que eres
capaz de absorber, cuntos puntos de historia terminas normalmente. Por ejemplo,
una velocidad de 20 significa que normalmente en cada Sprint el equipo termina
historias cuyas estimaciones ideales suman en total 20 puntos independientemente
de que el Sprint fueran 4 semanas de 3 personas

En este caso, si ya sabemos que la velocidad del equipo es de 20, sera razonable
asumir que en este Sprint se terminarn las dos primeras historias, la A y la B

Y qu ocurre en el primer Sprint? An no conocemos la velocidad del equipo.

Simplemente asume un valor razonable (por ejemplo, 50%; si dispones de 48
das/hombre, asume historias por valor de 24), y ya irs ajustando en Sprints
sucesivos. Normalmente tras varios Sprints, ya eres capaz de determinar una
velocidad aproximada que encaje con el equipo.
Continua en la 2 parte