SCRUM

Hola mi estimadisimo par de lector@s. Como comente a principios de semana estuve asistiendo a un curso de SCRUM ¿Y qué es eso se preguntará usted? Una forma de trabajar que se apropio del nombre de una jugada del Rugby y fue desarrollado en los 90's por unos tales Ken Schwaber y Jeff Sutherland. Para que no se me valla a olvidar del todo lo que aprendí en este curso y para quien pueda querer consultar algo al respecto procedo a anotar aquí mis impresiones del curso y un leve resumen de lo que vi pero advierto desde ya que no pretendo escribir una guía completa... para los demás, de antemano pido me disculpen por aburrirlos y los invito a volver la próxima entrada o a ver alguna otra entrada random que les apetezca más, gracias.

"A todo el mundo le gustará Scrum;
es lo que ya hacemos cuando estamos
entre la espada y la pared."
-- Jim Coplien

SCRUM es un método de desarrollo de software ágil, pero a diferencia de lo que muchos directivos podrían pensar o querer no es ágil por hacer lo mismo más rápido, si no que involucra cambios más profundos. SCRUM y los metodos agiles son alternativas a otros metodos como CMMI a los que considera rigidos y pesados. La metodología ágil trabaja con personas para generar productos mientras que los metodos tradicionales se enfocan en CONTROLAR el proceso.

Scrum no es un proceso o una técnica para desarrollar o crear productos, sino que es un marco en el que se pueden emplear diversos procesos y técnicas. El papel de Scrum es hacer aflorar la eficacia relativa de las prácticas de desarrollo empleadas por usted, para que pueda mejorarlas, a la vez que proporciona un marco dentro del cual se pueden desarrollar productos complejos, que ha diferencia de los procesos tradicionales se basa en la experiencia empírica y en tratar a las personas como personas variables y no en los tiempos y el control, su objetivo primordial es producir algo útil con lo que el cliente este satisfecho y no en que el gerente se sienta que tiene un control total de lo que hace su personal en todo momento. Trabaja de forma iterativa e incremental aunque sacrifica algunas cosas como definir de antemano cuantas horas exactas va a tardar cada actividad durante todo el proyecto y eso puede darle temor a los directivos.

• SCRUM es muy simple


• SCRUM es difícil de implementar


• SCRUM funciona en el contexto adecuado

¿A qué se refieren los puntos anteriores? Primero a que SCRUM es adaptable, no pide mucha documentación, los formatos te los puedes inventar tu, promueve la experimentación continua para buscar mejoras y cosas así. Lo segundo se refiere entre otras cosas a que es un cambio drástico respecto a los procesos tradicionales pero no solo en la forma de trabajar si no de la organización y para muchos hasta de forma de pensar y por ultimo se refiere a que no funciona para todo tipo de trabajo debido a su naturaleza cíclica e incremental. Ahora procedo a hablar un poco más a fondo de cada cosa.

Primero ¿Cuando es útil SCRUM? Cuando el proyecto es lo suficientemente complejo como para durar al menos una semana (puede ser menos pero entonces tal vez otras alternativas sean mejores que SCRUM) y cuando nuestro dominio de ante mano de la tecnología y los requerimientos del sistema nos impidan hacer fácilmente una planificación exacta con un método tradicional.

Si el proyecto ya lo tenemos bien dominando entonces experimentar con SCRUM, pero si no, entonces si se sugiere intentarlo.

En SCRUM no se planea todo exhaustivamente al inicio del proyecto si no que se busca obtener requisitos prioritarios y poder crear en base a ellos una primera base entregable que pueda funcionar pronto, y luego tomarse un ciclo de mejora y si es necesario otro y así hasta que quede listo. En cada ciclo se puede planear que va a estar listo para el final de ese ciclo pero probablemente no se sepa cuantos ciclos serán necesarios a ciencia cierta aunque se puede tener una idea general. Los resultados de cada ciclo sirven para que el cliente vea avance y como base para el siguiente ciclo más depurado y con más información. A cada uno de estos ciclos se le llama SPRINT.

El corazón de SCRUM son los SPRINTs, que son iteraciones que se recomienda duren entre mínimo una semana y máximo un mes dependiendo del tipo de proyectos con que se trabaje y decisiones del equipo pero se ruega que en la medida de lo posible la duración de los Sprints sea constante pues se busca alcanzar un ritmo estable de trabajo debido a varias razones como la satisfacción del usuario y de los trabajadores en el equipo, para poder medir la velocidad de trabajo razonable del equipo y facilitar la planificación de trabajo futuro.

En cada sprint se debe de terminar algo funcional para el cliente y se debe empezar por lo más prioritario para el cliente ya sea porque es lo más básico o que genera más riesgo en caso de no estar. Lo demás se deja para posteriores sprints. Por eso es un método incremental.

Los Sprints se componen de: la Reunión de Planificación de Sprint, el trabajo de desarrollo, la Revisión del Sprint, y la Retrospectiva del Sprint.

AutoOrganizarse. Si el corazón de Scrum son los Sprints, La auto-organización de los equipos de trabajo es la clave. Consiste en que en lugar de tener roles fijos donde cada quien hace una cosa y solo esa, Scrum alienta la creación de grupos de trabajo pequeños de preferencia de entre 5 y 7 personas donde entre todos saquen la tarea haciendo lo que prefieran hacer pero sin que quede nada por hacer porque nadie lo halla querido tomar. Para eso se requiere un equipo comprometido y que todos puedan confiar en los demás dentro del equipo. El equipo debe tener la libertad e iniciativa de comunicarse entre si cada vez que sea necesario y tener retroalimentación para asegurarse de hacer las cosas bien. La comunicación oral cara a cara tiene prioridad dejando a la escrita solo como un medio de respaldo para conservar lo que no queremos que se pierda en la memoria.

Pollos y Cerdos. Si bien dentro del equipo de desarrollo no hay roles específicos pre-definidos por el método, si hay tres roles y dos tipos de personas en esto.

Un cerdo y un pollo van caminando por una calle. El pollo voltea a ver al cerdo y le dice: “oye, ¿por qué no abrimos un restaurante?, El cerdo voltea a ver al pollo y dice “Buena idea, ¿cómo quieres llamarlo?”, El pollo se pone a pensar y le responde: “¿Porque no lo llamamos Jamón y huevos?”, No me parece dice el cerdo, “Yo estaría comprometido, pero tú sólo estarías implicado”.

Entonces "los cerdos" están comprometidos en la realización  del software con regularidad y con frecuencia, mientras todos los demás son "un pollo" - interesados en el proyecto. ¿Y exactamente quienes son los pollos y quienes los cerdos?

A los pollos también se les llama "stakeholders" y son los que no son miembros del equipo, es decir el o los clientes, los usuarios finales y quien patrocine el proyecto. Y los cerdos son el equipo que hace el software.

Roles del Equipo. Los cerdos son los que forman el equipo scrum, es decir el equipo y se dividen en tres roles:

• Scrum Master. Cuyo trabajo primordial es quitar impedimentos y distracciones a la capacidad del equipo de entregar o terminar las metas del sprint. No es el líder del equipo si no un facilitador. Puede ser parte integral del equipo o no y este puesto puede irse rotando entre los miembros del equipo. Es responsable de asegurar que el equipo Scrum se adhiere a los valores, prácticas y normas Scrum.


• Product Owner. Representa la voz del cliente/usuario ante el equipo para que el cliente no interactue o distraiga al equipo durante el sprint, intermediario entre cliente y equipo.  El dueño del producto escribe los detalles desde el punto de vista del cliente (Historias de usuario), les da prioridad y los añade al back log del producto. Un dueño del producto puede ser parte el equipo Scrum pero no puede ser un Scrum Master. El Propietario del Producto es una persona, no un comité. Una vez empezado un sprint solo este rol puede detenerlo, ni los pollos directamente ni el equipo ni el scrum master pueden. Durante el sprint el Product Owner se mantiene en comunicación con el cliente para preparar los requerimientos para el próximo sprint.


• Equipo. Todos los demás cerdos que se encargan de desarrollar el producto. No hay roles fijos dentro del equipo y todos deben estar dispuestos a cooperar en lo que sea necesario de forma auto-organizada. Nadie - ni siquiera el ScrumMaster - dice al Equipo cómo convertir el Product Backlog en incrementos de funcionalidad entregable. El Equipo busca por su cuenta la mejor forma de hacerlo. Cada miembro del equipo aplica su experiencia a todos los problemas. La sinergia resultante mejora la eficiencia global de todo el Equipo, y la eficacia. El equipo debe trabajar en equipo de preferencia y no como una cadena de montaje para evitar que una pausa en un rol pare a todo el equipo.

El Propietario del Producto es el "cerdo" del Product Backlog. El equipo es el "cerdo" del trabajo del Sprint. El ScrumMaster es el "cerdo" del proceso de Scrum. Todo el resto de personas involucradas son "pollos". Los "pollos" no pueden decir a los "cerdos" cómo hacer su trabajo.

Estimación. Tienes una ventana de tiempo ¿Qué cabe en la ventana?

En SCRUM no se estima por horas si no en Puntos de Historia y esto es uno de los aspectos que requieren un cambio de paradigma que me parece más van a sacar de balance a los directivos acostumbrados a medir desempeños. Los puntos de historia son grados de complejidad de las tareas y ayudan a medir cuales y cuantas tareas entran en el sprint, es decir, en lugar de decir me tardo X horas en hacer Y actividad lo que pasa ahora es que tenemos un Sprint fijo para entregar resultados en digamos 2 semanas y lo que varia es que es lo que el equipo se compromete en tener listo para ese tiempo.

"La manera de enfrentarse a tareas imposibles
es cortalas a un número de tareas meramente
muy dificiles de realizar, y romper cada una
de ellas en un grupo de tareas arduamente
difíciles de realizar, y cada una de ellas
en trabajos complicados,
y cada uno de ellos..."
--Terry Pratchett

En Scrum además de no planificar las actividades en horas, se divide todo el proyecto en actividades que se hagan en máximo una jornada de trabajo y se pone enfasis en no dejarlas sin terminar. La idea es que todos los días el equipo valla haciendo actividades que pueda terminar el mismo día. Así, para planificar el equipo calculará la dificultad de los requisitos y asígnara cuantos días tomará hacer el trabajo, pero como la duración del Sprint es fija lo que haces es averiguar cuantas actividades es razonable que quepan en cada sprint y meter primero las que generen más valor y prioridad.

¡Si todo urge, NO urge nada! Hay que establecer y respetar las prioridades, dificilmente todo va a urgir en realidad.

Hay dos partes en la Reunión de Planificación del Sprint: la parte del "¿Qué?" y la parte del "¿Cómo?" En la primera parte, el Equipo Scrum aborda la cuestión del "¿Qué?". El Propietario del Producto presenta al equipo la parte más prioritaria del Product Backlog. Trabajan juntos para determinar qué funciones se van a desarrollar durante el próximo Sprint. La información de entrada para esta reunión es el Product Backlog, el último incremento del producto, la capacidad del Equipo y el rendimiento anterior del Equipo. La cantidad de Backlog que el Equipo selecciona es una decisión del Equipo. Sólo el Equipo puede evaluar lo que puede lograr en el próximo Sprint, aunque el Product Owner hallá definido las prioridades del cliente.

Una vez seleccionado el Product Backlog, se define un Objetivo para el Sprint. El Objetivo del Sprint es una meta que se alcanzará mediante la implementación del Product Backlog. Es una declaración que sirve de orientación al equipo acerca de por qué se está construyendo el incremento. El Objetivo del Sprint es un subconjunto del objetivo de la entrega.

En la segunda parte de la Reunión de Planificación del Sprint, el equipo aborda la cuestión del "¿Cómo?". Durante la segunda mitad de la Reunión de Planificación del Sprint (bloque de cuatro horas para un Sprint de un mes), el Equipo debe determinar cómo convertirá en un incremento, el Product Backlog (el "Qué") seleccionado durante la reunión de planificación de Sprint. El Equipo por lo general comienza por el diseño del trabajo. Mientras diseñan, identifican tareas. Estas tareas son las porciones detalladas del trabajo necesario para convertir el Product Backlog en software que funciona. Las Tareas se deben descomponer para que se puedan completar en menos de un día. Esta lista de tareas se llama Sprint Backlog.

En Scrum sabes cuando termina el Sprint actual pero tal vez no sepas cuando termina el proyecto total, los nuevos requerimientos generan nuevos sprints. Debido a sus planificaciones cortas, el SCRUM esta preparado para los cambios entre cada iteración, que en metodos tradicionales son más dificiles de adaptar y piden replanificar los requerimientos mientras que en SCRUM se toman en cuenta en el siguiente SPRINT.

Luego cuando ya el equipo se pone a desarrollar el avance se puede ir viendo y monitoreando rapidamente con un par de tecnicas, una es llevar reuniones diarias de no más de 15 minutos y de pie para limitar el tiempo y darle prioridad a lo importante. En estas juntas se deben revisar 3 preguntas con el equipo.

• ¿Qué hiciste ayer? Rapido te das cuenta que es lo que ya esta hecho y si alguien no hace nada.


• ¿Qué vas a hacer hoy? Rapido puedes saber quien esta haciendo que.


• ¿Tuviste problemas? Así los problemas se saben en máximo un día.

Esta junta es responsabilidad del Scrum Master y meditante ellas se puede ver a diario que todos los miembros del equipo avancen, en que avancen y que problemas hay, así a diario se lleva el control del proyecto y se atacan rapidamente las causas de problemas que puedan haber surgido el día anterior.

La otra tecnica es el uso de un tablero (Task Board) donde se mantenga visible que hay que hacer, que se esta haciendo y que ya se hizo. Se propone hacerlo poniendo en el de forma breve y exacta cada actividad.

Durante el sprint el equipo trabaja, el Scrum Master se coordina con ellos y retira los obstaculos que surgen durante el sprint ¿Y el Product Owner? Seguramente quedaron requisitos fuera de los compromisos del sprint en proceso así que el Product Owner debe aclarar con el cliente estos requerimientos para tenerlos listos para la planificación del próximo sprint. También es su labor mantener al cliente informado y lo suficientemente tranquilo para que no interrumpa al equipo de trabajo. El P.O. es un embudo de requerimientos desde el cliente hasta el equipo.

El resultado del Sprint es un entregable rapido para el cliente, el cliente lo revisa y puede dar su visto bueno o no, también es posible tomar nuevos requerimientos si los hay y correcciones o cualquier otro feedback que surja y con eso preparar que es lo que se trabajará en el próximo sprint y volvemos a empezar. Por esto SCRUM no funciona sin cooperación del cliente para obtener Feedback.

PRINCIPIOS DE SCRUM

• Los proyectos se desarrollan entorno a equipos motivados.


• Prioridad a la comunicación oral cara a cara, lo escrito se deja para documentar los acuerdos y no dejarlo a la memoria.


• La medida de exito es el software funcionando, no los documentos ni el proceso.


• Se promueve un ritmo constante de trabajo, balanceado, sin horas extra o periodos de inactividad.


• Atención al diseño y excelencia tecnica.


• Simplicidad. Máximizar la cantidad de trabajo no realizado (ver principio KISS).


• AutoOrganización. Dejar que el equipo se ponga de acuerdo sobre como hacer las cosas.


• Reflexión y mejora periodicamente.

SCRUM no debe tener presión, si hay presión no es SCRUM.

Por ultimo, quiero recalcar un punto fundamental de SCRUM. Respetar los tiempos (timeboxes), si algo no se alcanzo a ver en una junta en el tiempo dado es porque hicimos mal la junta o porque no era más importante que lo que si se vio. Si se va a acabar el tiempo del Sprint y no vamos a terminar tampoco se alarga el Sprint, si no que tenemos que aprender de esto y dejar lo pendiente para el siguiente Sprint.

Para más información: www.scrumalliance.org