Scrum Explicado

Explicando Scrum
Scrum es una metodología. 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.
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.
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.
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.
De forma resumida y global, en Scrum vamos a diferenciar dos aspectos importantes, los
actores y las acciones.
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 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.
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.
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 el Sprint 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.
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.
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 el Sprint 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 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 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
Ownerrevisará con el equipo los objetivos marcados inicialmente en el Sprint 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.
¿Y porque es eso de las 2 ó 4 semanas?.
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 cuales 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.

Scrum Explicado

Cargado por

Copyright:

Formatos disponibles

Scrum Explicado

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Scrum Explicado

Cargado por

Copyright:

Formatos disponibles

Explicando Scrum

Scrum es una metodología. Se utiliza en mi profesión, en el desarrollo del Software

El desarrollo ágil pone de manifiesto básicamente lo siguiente:

El desarrollo ágil aboga por estas premisas principalmente.

El Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a

•Qué tareas ha realizado desde la última reunión (que he hecho).

Adicionalmente a las acciones anteriormente comentadas encontramos otras acciones más.

Supongamos el caso de la construcción de un rascacielos o de un edificio. Si con el fin de controlar el

También podría gustarte