Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Explicando Scrum A Mi Abuela
Explicando Scrum A Mi Abuela
Introduccin
El otro da me encontraba hablando con un compaero de trabajo a travs del telfono
mvil, cuando mi abuela me escuch nombrar palabras raras en la conversacin.
Una de esas palabras era Scrum, y por la forma en la que hablaba fue lo que ms
atencin la llam, as que cuando colgu, lo primero que me pregunt fue con quin
hablaba, de qu hablaba, y que era eso de Scrum.
Imaginaros la cara que se me qued, porque... cmo explicar Scrum a mi abuela?.
Aunque mi abuela es muy avanzada para la mayora de la gente de su edad, la verdad es
que no es fcil explicarla muchos de los aspectos tecnolgicos emergentes, pero bueno,
es mi abuela y tena que intentar explicrselo de forma convincente.
Aqu, os transcribo aquella inverosmil conversacin.
La conversacin y sus explicaciones
De que hablabas?, pareca interesante eso que decas de Scrum. Qu es
exactamente?
Ah s! Scrum es una metodologa.
Y para que se utiliza?
Se utiliza en mi profesin, 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 tenis que usar ese tal Scrum?
En realidad no. No es estrictamente necesario.
Scrum por sus caractersticas no es vlido para cualquier proyecto ni para cualquier
persona o equipo de personas. Es ms, Scrum segn muchos especialistas de esta
metodologa, es ptima para equipos de trabajo de hasta 8 personas, aunque hay
empresas que han utilizado Scrum con xito con equipos ms grandes.
Yo dira que para el 90% de los proyectos y empresas, es una metodologa vlida, pero
no es una metodologa vlida al 100%. Es ms, no hay metodologa mejor que otra ni
vlida al 100% para todas las personas y empresas.
Scrum es por lo tanto, una metodologa ms de las muchas que hay, y sta en concreto,
se basa en la filosofa del desarrollo gil que fue expuesto por dos japoneses alrededor
del ao 1986.
Siempre estos japoneses... has dicho desarrollo gil varias veces... que es eso
exactamente?, a m eso s que me suena a japons o a chino
El desarrollo gil pone de manifiesto bsicamente lo siguiente:
Product Owner
Scrum Master
Scrum Team
Usuarios o Clientes
Algo que no te he dicho an, 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 misin es tambin hacrselo 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 metodologa guiando
las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su
Product Backlog
Sprint Backlog
Daily Scrum Meeting
Una pregunta ms... 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?
El Sprint Planning Meeting es una reunin que tiene por objetivo, planificar el
Sprint a partir del Product Backlog. El objetivo de esta reunin es la de mover
las tareas del Product Backlog al Sprint Backlog. En esta reunin, suelen
participar el Product Owner que es como te dije antes quien prioriza las tareas, el
Scrum Master y el Scrum Team.
Del Sprint Planning Meeting, sale tambin el Sprint Goal, que es un pequeo
documento o una breve descripcin que indica lo que el Sprint intetar alcanzar.
En el Sprint Review se revisa en unas 2 horas como mximo el Sprint
finalizado. Al llegar a este punto, debemos tener "algo" que el Cliente o el
Usuario pueda ver y tocar. En esta reunin, suelen asistir el Product Owner, el
Scrum Master, el Scrum Team y personas que podran estar involucradas en el
proyecto. El Scrum Team es quin 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 el Sprint Backlog concluido, se aplicarn los cambios y ajustes
si son necesarios, y se marcarn 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 sera ms fcil 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 cul entenders que es mejor hacer esto as
que de otra forma.
Supongamos el caso de la construccin 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 da en varias ocasiones como estoy haciendo las cosas, como lo
llevo y cuales son mis avances, te aseguro que no terminaremos la construccin del
edificio en el tiempo planificado ni de broma. Adems, seguro que querrs cambiar o
modificar algo cada da o incluso varias veces en el mismo da.
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 trmino 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 metodologa 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 metodologa ideal. Yo siempre digo que si hubiera algo ideal, todo el mundo lo
usara, pero s te digo, que Scrum se acerca bastante a esa idea general de la gestin
ideal de proyectos.