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:

El mercado actual es altamente competitivo y la tecnologa es muy cambiante. En el desarrollo del Software se pide bsicamente rapidez, calidad y reduccin 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 ms cortos posibles.

El desarrollo gil aboga por estas premisas principalmente. Hay ms detalles, pero no los voy a abordar ahora para no marearte con informacin que nos desve la atencin de la propia explicacin de Scrum. Informacin adicional Empiezo a entender algo ms esto...pero... en qu consiste exactamente eso de Scrum? Scrum es como deca antes, una metodologa 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 metodologa ni la nica, antes te deca que hay muchas, pero s, es una metodologa que est empujando muy fuerte por la facilidad de implantacin y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparacin con otras metodologas. Por un lado, Scrum evita la burocracia y la generacin 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 metodologas es impensable. Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prcticamente 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 cmo se est haciendo. S s, vale... pero cmo muestras al cliente esos progresos en el trabajo?. Bien bien, no te he contado an mucho sobre Scrum, slo el cascarn que lo envuelve, pero ya que preguntas y te veo realmente interesada, te voy a contar todo lo que hay con ms 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 ms que comenzar. Te deca que hay dos aspectos fundamentales a diferenciar, los actores y las acciones. Los actores son los que ejecutarn obviamente las acciones. Estos de forma general, sern:

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

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 relacin directa con los actores. Sin ellas, todo sera 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 rgida para impedir que se aplique errneamente esta metodologa. Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y forma de trabajar que a continuacin 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 deca 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 ms tareas que provienen del Product Backlog. Es decir, del Product Backlog se saca una o ms 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 modificacin o alteracin cuya tarea, formara parte de otro Sprint Backlog. El Daily Scrum Meeting es una tarea iterativa que se realiza todos los das que dure el Sprint Backlog con el equipo de desarrollo o de trabajo. Se trata de una reunin operativa, informal y gil, de un mximo de 30 minutos, en la que se le hace 3 preguntas a cada integrante del equipo.

Qu tareas ha realizado desde la ltima reunin (que he hecho). Sobre qu va a trabajar en el da actual (que voy a hacer hoy). Identificacin de obstculos o riesgos que impiden o pueden impedir el normal avance (que ayuda necesito). El Scrum Master, debe eliminar aqu cualquier obstculo que encuentre.

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?

Bien, esta es una pregunta tpica. Quizs 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 contina 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, deberamos tener algo, un entregable o algo que se pueda mostrar y que ensee los avances acometidos en el Sprint. En el Product Backlog tendremos ms 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 continuacin. Esto me est gustando muchsimo... Me alegro, a m me parece interesantsimo, y es ms, Scrum es de sentido comn, tanto, que yo sin saberlo ya lo utilizaba hace algunos aos sin saber que era realmente Scrum. Bueno, prosigo con esta explicacin. Como te deca, adicionalmente a las acciones anteriormente comentadas encontramos otras acciones ms. Antes para no saturarte, no te dije que entre el Product Backlog y el Sprint Backlog, hay algo, una reunin concretamente, que se denomina Sprint Planning Meeting.

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.

A m personalmente es la que ms me gusta y la que por experiencia, mayor satisfaccin suele dar, tanto al cliente o al usuario final como al equipo de trabajo.

Y no te creas que hay mucho ms que saber de Scrum, esta es la filosofa o idea general que espero te haya quedado clara y te haya servido para entender lo que hablaba con mi compaero de trabajo.