Explicando Scrum a mi abuela

Explicando Scrum a mi abuela

Introducción

El otro día me encontraba hablando con un compañero de

trabajo a través del teléfono móvil, cuando mi abuela me
escuchó nombrar palabras raras en la conversación.
Una de esas palabras era Scrum, y por la forma en la que
hablaba fue lo que más atención la llamó, así que cuando
colgué, lo primero que me preguntó fue con quién hablaba,
de qué hablaba, y que era eso de Scrum.

Imaginaros la cara que se me quedó, porque... ¿cómo

explicar Scrum a mi abuela?.

Aunque mi abuela es muy avanzada para la mayoría de la

gente de su edad, la verdad es que no es fácil explicarla
muchos de los aspectos tecnológicos emergentes, pero
bueno, es mi abuela y tenía que intentar explicárselo de
forma convincente.

Aquí, os transcribo aquella inverosímil conversación.

La conversación y sus explicaciones

¿De que hablabas?, parecía interesante eso que decías de

Scrum. ¿Qué es exactamente?

¡Ah sí! Scrum es una metodología.

¿Y para que se utiliza?

Se utiliza en mi profesión, en el desarrollo del Software
concretamente, aunque hay gente por ahí que la usa o la
quiere usar en otras profesiones y áreas.

¿Y para eso del desarrollo del Software tenéis que usar ese
tal Scrum?

En realidad no. No es estrictamente necesario.

Scrum por sus características no es válido para cualquier

proyecto ni para cualquier persona o equipo de personas.
Es más, Scrum según muchos especialistas de esta
metodología, es óptima para equipos de trabajo de hasta 8
personas, aunque hay empresas que han utilizado Scrum
con éxito con equipos más grandes.

Yo diría que para el 90% de los proyectos y empresas, es

una metodología válida, pero no es una metodología válida
al 100%. Es más, no hay metodología mejor que otra ni
válida al 100% para todas las personas y empresas.
Scrum es por lo tanto, una metodología más de las muchas
que hay, y ésta en concreto, se basa en la filosofía del
desarrollo ágil que fue expuesto por dos japoneses
alrededor del año 1986.

Siempre estos japoneses... has dicho desarrollo ágil varias

veces... ¿qué es eso exactamente?, a mí eso sí que me
suena a japonés o a chino
El desarrollo ágil pone de manifiesto básicamente lo
siguiente:

• El mercado actual es altamente competitivo y la

tecnología es muy cambiante. En el desarrollo del
Software se pide básicamente rapidez, calidad y
reducción de costes, pero para asumir estos retos, es
necesario tener agilidad y flexibilidad.

• Los ciclos de desarrollo por otro lado, acostumbran a

ser largos, y lo que se exige por otra parte, es que
esos ciclos sean lo más cortos posibles.

El desarrollo ágil aboga por estas premisas principalmente.

Hay más detalles, pero no los voy a abordar ahora para no
marearte con información que nos desvíe la atención de la
propia explicación de Scrum.
Información adicional
Empiezo a entender algo más esto...pero... ¿en qué
consiste exactamente eso de Scrum?

Scrum es como decía antes, una metodología ágil.

Obedece a las necesidades anteriormente citadas, y no
responde a ninguna moda, sino a una necesidad realmente
demandada en el desarrollo del Software.

Scrum no es ni la mejor metodología ni la única, antes te

decía que hay muchas, pero sí, es una metodología que
está empujando muy fuerte por la facilidad de implantación
y por su agilidad en cuanto a cambios y lo que
propiamente aporta en comparación con otras
metodologías.
Por un lado, Scrum evita la burocracia y la generación
documental. No es que con Scrum no se deba o no se
pueda documentar, si no que con Scrum no se exige
documentar nada para iniciar un proyecto, algo que en
otras metodologías es impensable.

Con Scrum por otro lado, la idea principal es la de ponerse

a trabajar prácticamente desde el primer momento y
empezar a sacar frutos de ese trabajo para que el cliente
vaya viendo los avances y se quede satisfecho con lo que
se está haciendo y cómo se está haciendo.

Sí sí, vale... pero ¿cómo muestras al cliente esos progresos

en el trabajo?.

Bien bien, no te he contado aún mucho sobre Scrum, sólo

el cascarón que lo envuelve, pero ya que preguntas y te
veo realmente interesada, te voy a contar todo lo que hay
con más detalle.

De forma resumida y global, en Scrum vamos a diferenciar

dos aspectos importantes, los actores y las acciones.

Vaya, esto se pone interesante, sigue sigue que me está

empezando a gustar esto del Scrum.

¡Ja!, pues espera a que te cuente, que esto no ha hecho

nada más que comenzar.

Te decía que hay dos aspectos fundamentales a

diferenciar, los actores y las acciones.
Los actores son los que ejecutarán obviamente las
acciones.
Estos de forma general, serán:

• Product Owner
• Scrum Master
• Scrum Team
• Usuarios o Clientes

Algo que no te he dicho aún, es que para que un proyecto

Software tenga éxito, el Usuario o Cliente, debe
involucrarse sí o SÍ.

Esto vale para todos TODOS los proyectos, aunque no

todos los Usuarios y Clientes lo entienden así, pero nuestra
misión es también hacérselo ver.

Prosigo.
El Product Owner conoce y marca las prioridades del
proyecto o producto.

El Scrum Master es la persona que asegura el

seguimiento de la metodología guiando las reuniones y
ayudando al equipo ante cualquier problema que pueda
aparecer. Su responsabilidad es entre otras, la de hacer de
paraguas ante las presiones externas.

El Scrum Team son las personas responsables de

implementar la funcionalidad o funcionalidades elegidas
por el Product Owner.

Los Usuarios o Cliente, son los beneficiarios finales del

producto, y son quienes viendo los progresos, pueden
aportar ideas, sugerencias o necesidades.

¿Y lo de las acciones?

Te veo con hambre de conocimiento, eso está bien.

Las acciones tienen relación directa con los actores. Sin
ellas, todo sería un caos.

En Scrum se indican claramente las acciones a acometer y

como acometerlas. Nuestra responsabilidad es hacerlo
siempre de una forma adecuada y algo rígida para impedir
que se aplique erróneamente esta metodología.
Las acciones de Scrum forman parte de un ciclo iterativo
repetitivo, por lo que el mecanismo y forma de trabajar
que a continuación se indica, tiene como objetivo
minimizar el esfuerzo y maximizar el rendimiento en el
desarrollo.

Las acciones fundamentales de Scrum son:

• Product Backlog
• Sprint Backlog
• Daily Scrum Meeting

El Product Backlog corresponde con todas las tareas,

funcionalidades o requerimientos a realizar. Antes decía
que el Product Owner es la persona que se encarga de
marcar las prioridades, y es al fin y al cabo, la persona que
mantiene y actualiza dado el caso, la lista de tareas.

El Sprint Backlog corresponde con una o más tareas que

provienen del Product Backlog. Es decir, del Product
Backlog se saca una o más tareas que van a formar parte
del Sprint Backlog. Las tareas del Sprint Backlog se deben
acometer (recomendado) en unas 2 semanas ó 4 semanas.
Hay Sprint Backlogs de 2 semanas y hay Sprint
Backlogs de 4 semanas. Eso debe de ser marcado antes de
iniciar el Sprint Backlog, de hecho, del Product Backlog se
sacará la tarea o tareas realistas para acometer el Sprint
Backlog. Una norma fundamental es que mientras
un Sprint Backlog se inicia, éste NO puede ser alterado o
modificado. Hay que esperar a que concluya el Sprint
Backlog para realizar la correspondiente modificación o
alteración cuya tarea, formaría parte de otro Sprint
Backlog.

El Daily Scrum Meeting es una tarea iterativa que se

realiza todos los días que dure elSprint Backlog con el
equipo de desarrollo o de trabajo. Se trata de una reunión
operativa, informal y ágil, de un máximo de 30 minutos, en
la que se le hace 3 preguntas a cada integrante del equipo.

• Qué tareas ha realizado desde la última reunión (que

he hecho).
• Sobre qué va a trabajar en el día actual (que voy a
hacer hoy).
• Identificación de obstáculos o riesgos que impiden o
pueden impedir el normal avance (que ayuda
necesito). El Scrum Master, debe eliminar aquí
cualquier obstáculo que encuentre.

Una pregunta más... has dicho que del Product Backlog se

sacan tareas que van al Sprint Backlog, pero entiendo que
no todas las tareas del Product Backlog van a la vez al
Sprint Backlog, así que... ¿que se hace cuando una tarea
del Sprint Backlog se finaliza?

Bien, esta es una pregunta típica.

Quizás no me he explicado bien, pero el Sprint Backlog,
una vez que se inicia, ni se toca.

Es decir, que una tarea se acaba, y punto.

Se continúa con otra tarea del Sprint Backlog y así hasta
que se acaben.

Lo que debemos tener claro, es que al finalizar un Sprint

Backlog (ya sea de 2 semanas ó de 4 semanas), debemos
haber acabado las tareas del Sprint Backlog.

Reitero que las tareas del Sprint Backlog deben de ser

realistas.

Así que cuando se ha finalizado un Sprint Backlog,

deberíamos tener algo, un entregable o algo que se pueda
mostrar y que enseñe los avances acometidos en el Sprint.
En el Product Backlog tendremos más tareas, y es posible
incluso que hayan salido nuevas tareas o que otras hayan
desaparecido, por lo que es cuando se acaba el Sprint
Backlog, cuando debemos hacer varias cosas importantes y
que te indico a continuación.

Esto me está gustando muchísimo...

Me alegro, a mí me parece interesantísimo, y es más,

Scrum es de sentido común, tanto, que yo sin saberlo ya lo
utilizaba hace algunos años sin saber que era realmente
Scrum.

Bueno, prosigo con esta explicación.

Como te decía, adicionalmente a las acciones
anteriormente comentadas encontramos otras acciones
más.

Antes para no saturarte, no te dije que entre el Product

Backlog y el Sprint Backlog, hay algo, una reunión
concretamente, que se denomina Sprint Planning Meeting.

• El Sprint Planning Meeting es una reunión que tiene

por objetivo, planificar elSprint a partir del Product
Backlog. El objetivo de esta reunión es la de mover las
tareas del Product Backlog al Sprint Backlog. En esta
reunión, suelen participar elProduct Owner que es
como te dije antes quien prioriza las tareas, el Scrum
Mastery el Scrum Team.

• Del Sprint Planning Meeting, sale también el Sprint

Goal, que es un pequeño documento o una breve
descripción que indica lo que el Sprint intetará
alcanzar.

• En el Sprint Review se revisa en unas 2 horas como

máximo el Sprint finalizado. Al llegar a este punto,
debemos tener "algo" que el Cliente o el
Usuario pueda ver y tocar. En esta reunión, suelen
asistir el Product Owner, el Scrum Master, el Scrum
Team y personas que podrían estar involucradas en el
proyecto. El Scrum Team es quién muestra los
avances realizados en el Sprint.
 • Al finalizar un Sprint Backlog y el Sprint Review, se
inicia el Sprint Retrospective. El Product
Owner revisará con el equipo los objetivos marcados
inicialmente en elSprint Backlog concluido, se
aplicarán los cambios y ajustes si son necesarios, y se
marcarán los aspectos positivos (para repetirlos) y los
aspectos negativos (para evitar que se repitan)
del Sprint.

Mira, te pintaré un diagrama que espero te ayude a

entender todas las acciones de Scrum.

¿Y porque es eso de las 2 ó 4 semanas?. ¿No sería más

fácil que cada equipo pusiera su franja de tiempo?
Sí claro, cada equipo, cada empresa, cada proyecto, puede
poner la franja horaria y frecuencia temporal que considere
oportuno así como cambiar aspectos de Scrum, pero te voy
a poner un sencillo ejemplo con el cuál entenderás que es
mejor hacer esto así que de otra forma.

Supongamos el caso de la construcción de un rascacielos o

de un edificio.

Si con el fin de controlar el proyecto y que no se te escape

nada ni metamos la pata en algo, me preguntas cada día
en varias ocasiones como estoy haciendo las cosas, como
lo llevo y cuáles son mis avances, te aseguro que no
terminaremos la construcción del edificio en el tiempo
planificado ni de broma. Además, seguro que querrás
cambiar o modificar algo cada día o incluso varias veces en
el mismo día.

Si me preguntas cada 6 meses por ejemplo, avanzaré

mucho sin interrupciones, pero a buen seguro que el riesgo
de desviaciones es mucho mayor y seguramente si
ocurren, reajustar esas desviaciones al proyecto tendrá
costes elevados asociados.

Un término medio es el ajuste temporal de 2 ó 4 semanas

que está basado en la experiencia de muchas personas en
muchos proyectos. No es lo mismo reconducir el proyecto
perdiendo 2 ó 4 semanas, que reconducirlo perdiendo 6
meses por ejemplo.

La idea de la metodología ágil es fundamentalmente que

adopte los cambios, que se pueda reconducir el proyecto
en un momento dado, y que afecte lo menos posible a los
costes, los tiempos y al equipo de trabajo.
No es la metodología ideal. Yo siempre digo que si hubiera
algo ideal, todo el mundo lo usaría, pero sí te digo, que
Scrum se acerca bastante a esa idea general de la gestión
ideal de proyectos.

A mí personalmente es la que más me gusta y la que por

experiencia, mayor satisfacción suele dar, tanto al cliente o
al usuario final como al equipo de trabajo.

Y no te creas que hay mucho más que saber de Scrum,

esta es la filosofía o idea general que espero te haya
quedado clara y te haya servido para entender lo que
hablaba con mi compañero de trabajo.
Sin duda que me ha parecido muy interesante. Muchas
gracias.

Published 9/5/2007 20:35 por Jorge Serrano

Fuente http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx