ARTÍCULO DE ACTUALIZACIÓN

 

Aplicando SCRUM

 

Applying SCRUM

 

 

M.Sc. Reynaldo J. Zeballos D.
reynaldozeballos@hotmail.com

 

 

---

RESUMEN

En el entorno laboral, frecuentemente llegamos a establecer buenas prácticas de trabajo cuando estamos a cargo de proyectos de software. SCRUM es un método ágil de proyectos de desarrollo de software Este trabajo muestra de manera práctica y precisa, las directrices para aplicar SCRUM mientras estamos a cargo de un proyecto.

Palabras clave:

Gestión; Desarrollo ágil de software; Directrices; Método; Proyectos

---

ABSTRACT

In the workplace, we often come to establish good working practices when we are in charge of software projects. SCRUM is an agite method for software development project. This paper presents a practica/ and precise guideline to implement SCRUM while we are in charge of a project.

Keywords:

Management; Agite Software Development; Guidelines; Method; Projects

---

 

 

APLICANDO SCRUM

En todos mis años de experiencia en análisis, diseño. programación e implementación de Sistemas de Información, siempre me encontraba con estas disyuntivas "Cómo hacer que mi equipo de trabajo cumpla lo comprometido en tiempo y producto final?". ''Cómo trabajar bajo un enfoque integral y flexible donde mi equipo trabaje unido para alcanzar el objetivo deseado?".

Cuando empecé con la elaboración de Sistemas de Información, seguía el clásico ciclo de vida de un sistema de información, pasando por las etapas de Análisis. Diseño, Implementación, Pruebas, y finalmente Mantenimiento, en esencia estaba aplicando el Modelo en Cascada.

El 'Manifiesto Ágil" fue producido por iniciativa de un grupo de desarrolladores, quienes pusieron en evidencia una nueva forma de pensar para desarrollar software. A partir de estos principios salieron nuevas metodologlas, entre estas aparecen Programación Extrema (XP), Proceso de Unificación Ágil (AUP), SCRUM y otras.

SCRUM es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el Desarrollo Ágil de software.¹

En esencia SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, para definir el proceso de desarrollo que se ejecutará durante un proyecto.

Los roles principales en Scrum son el ScrumMaster(Director del Proyecto), que mantiene los procesos y coordina con todos los componentes, el ProductOwner (Dueño del Producto), que representa a los interesados externos e internos, en esencia es la voz del cliente, y el Team (Equipo), que incluye a los desarrolladores. Asimismo, se denomina Sprint (tramo de iteración), a un período de tiempo de trabajo, que podría ser un período de entre una semana a cuatro semanas, este período lo define el equipo. Durante cada Sprint, el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada Sprint, viene del ProductBackLog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar.

Los elementos del ProductBackLog que forman parte del Sprint se determinan durante la reunión de Sprint Planning (Planificación de los tramos). Durante esta reunión, el ProductOwner identifica los elementos del ProductBackLog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina cuánto de ese trabajo puede comprometerse a completar durante el siguiente Sprint. Durante el Sprint, nadie puede cambiar el ProductBackLog, lo que significa que los requisitos están congelados durante el Sprint.

Scrum permite la creación de equipos auto organizados impulsando la relocalización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucradas en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan, y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y concentrándose en maximizar la capacidad del equipo para entregar rápidamente sus desarrollos y responder a requisitos emergentes.

Existen diferentes formas para gestionar el proceso de Scrum, que van desde notas en la agenda, las notas amarillas "post-it", pizarras y hasta paquetes de software².

Mi experiencia versus SCRUM

Intuitivamente, durante mis primeros años de consultor al frente de equipos de trabajo, fui implementando una modalidad de trabajo parecida, por supuesto. que no tuve el tiempo necesario para escribir al respecto, pero compartía mis resultados con otros compañeros que estaban a cargo de equipos de desarrollo y algunos también habían llegado a implementar procesos parecidos, e intercambiando experiencias fui mejorando cada vez mi capacidad de trabajar en equipo y hacer que el equipo se integre y responda adecuadamente.

En 1986 HirotakaTakeuchi e IkujiroNonaka, un buen día dijeron "Hágase el SCRUM" y vieron los jefes de proyectos y consultores que era bueno, y volaron sombreros como en un gran festejo, pues se había inventado lo que iba a ser una de las implementaciones de Programación Ágil más populares del planeta.

Recién en el año 2002, gracias a Internet. encontré una referencia a SCRUM. y al leer el artículo fue como si alguien hubiera escrito, formalizado y por supuesto, corregido, completado y mejorado. todo aquello que personalmente aplicaba de manera intuitiva y basado en la experiencia.

Hoy en día Scrum es usado por empresas de todos los tamaños tales como Yahoo!, Microsoft, Google, Motorola, SAP, Cisco y otras.

 

DESGLOSANDO A SCRUM

Como podremos ver más adelante, los principios ágiles nos invitan a construir software que funcione y que se pueda usar rápidamente, en vez de pasarse mucho tiempo al principio escribiendo especificaciones. El desarrollo ágil se centra en equipos multifuncionales con capacidad para decidir por ellos mismos. en vez de grandes jerarquías y divisiones por funcionalidad.

En la figura nro. 1 presento el desglose general de Scrum, y en adelante realizaré la presentación de los componentes de Scrum, de una manera práctica y resumida, considerando siempre las ideas y los puntos importantes. de manera tal que si quisieras certificarte como un Profesional SCRUM, tendrás un buen punto de partida.

 

ROLES PRINCIPALES DE SCRUM³

ProductOwner (Dueño del Producto): Representa la voz del cliente. Se asegura de que el equipo SCRUM trabaje de forma adecuada desde la perspectiva del negocio. El ProductOwner escribe el guión del usuario, las prioriza y las coloca en el ProductBackLog.

ScrumMaster (Director del Proyecto): Es el Director de Proyecto, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del Sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Team: Es el equipo de desarrollo y trabajo multidisciplinario y altamente motivado y tiene la responsabilidad de entregar el producto. Un conjunto de personas con las habilidades transversales necesarias para realizar el trabajo de análisis, diseño, desarrollo, pruebas, documentación, etc.

 

REUNIONES DEL SCRUM

DailyScrum

Cada día de un Sprint, por equipo, se realiza la reunión sobre el estado del proyecto. Esto se llama "dailystandup" El Scrum tiene unas guías específicas:

•     La reunión comienza puntualmente a su hora. A menudo hay castigos, por supuesto acordados por el equipo, para quien llegue tarde (por ejemplo: multas en efectivo, flexiones, comprar una Coca, traer empanadas. etc.)

•     Todos son bienvenidos, pero sólo los responsables pueden hablar.

•     La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.

•     Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta).

•     La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

•     Durante la reunión, cada miembro del equipo contesta a tres preguntas:

o Qué has hecho desde ayer?
o Qué es lo que estás planeando hacer hoy?
o Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

Scrum del Scrum

Segunda reunión que se realiza cada día normalmente después del "DailyScrum":

•    Asiste una persona asignada por cada equipo

•     Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.

La agenda será la misma que del DailyScrum, añadiendo las siguientes cuatro preguntas:

1.   Qué ha hecho tu equipo desde nuestra última reunión?

2.   Qué hará tu equipo antes que nos volvamos a reunir?

3.   Hay algo que demora o estorba a tu equipo?

4.   Estás a punto de poner algo en el camino del otro equipo?

Reunión de Planificación del Sprint (Sprint Planning Meeting)

Al inicio del ciclo de cada Sprint, se lleva a cabo una "Reunión de Planificación del Sprint", donde se tocan los siguientes puntos:

•     Seleccionar qué trabajo se hará.

•     Preparar. con el equipo completo, el Sprint BackLog que detalla el tiempo que tomará hacer el trabajo.

•     Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.

•     Ocho horas como límite.

Al final del ciclo Sprint, dos reuniones se llevarán a cabo. la "Reunión de Revisión del Sprint" y la "Retrospectiva del Sprint".

Reunión de Revisión del Sprint (Sprint Review Meeting)

•     Revisar el trabajo que fue completado y no completado

•     Presentar el trabajo completado a los interesados (alias "demo")

•     El trabajo incompleto no puede ser demostrado

•     Cuatro horas como límite

Retrospectiva del Sprint (Sprint Retros pecti ve)⁴

Después de cada Sprint, se lleva a cabo una retrospectiva del Sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el Sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

Sprint

El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los Sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de Sprint en particular (de 2 a 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada Sprint, el equipo deberá presentar los avances logrados, y el resultado obtenido es un producto potencialmente entregable al cliente. Asimismo, se recomienda no cambiar los objetivos del Sprint o Sprint BackLog a menos que la falta de estos cambios amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo.

 

DOCUMENTOS DEL SCRUM⁵

ProductBackLog

El ProductBackLog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, todas las funcionalidades deseables. etc., priorizadas según su nivel de importancia. Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones a groso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al ProductOwner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas.

Sprint BackLog

El Sprint BackLog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las tareas en el Sprint BackLog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.

Impediment List

La lista de impedimentos la administra directamente el ScrumMaster, y tiene el detalle de todos los impedimentos encontrados y hasta la fecha liberados o pendientes. Debe estar en un lugar visible, reflejar la verdad de !os impedimentos y fundamentalmente, actualizado de manera diaria. Asimismo, se puede complementar la lista de impedimentos con el diagrama Burn Down, que es una gráfica mostrada públicamente y que mide la cantidad de requisitos en el BackLog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, así podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien. en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el BackLog). Si durante el proceso se añaden nuevos requisitos, la recta tendrá una pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

 

CONCLUSIONES

Como conclusión los beneficios de Scrum son los siguientes:

• El cliente fija sus expectativas al indicar el valor que le aporta cada requisito del proyecto y cuando espera que esté completado.

•   El cliente podría utilizar los resultados más importantes del proyecto antes de que esté finalizado por completo.

•   De manera regular el cliente puede redirigir el proyecto de acuerdo a las nuevas prioridades, o según los cambios en el mercado.

•   De manera regular, el cliente maximiza el retorno de la inversión del proyecto.

•   Desde el comienzo el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto, de esta manera es posible resolverlas de manera anticipada.

•   Las personas trabajan más enfocadas y de manera más eficiente, cuando hay una fecha límite a corto plazo para entregar un resultado al que se han comprometido.

•   La estimación de esfuerzo y la optimización de tareas para completar un requisito es mejor si la realizan las personas que van a desarrollar el requisito, dadas sus diferentes especializaciones, experiencias y puntos de vista.

•   Los miembros del equipo sincronizan su trabajo diariamente.

•   Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al negocio.

•   Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo.

En resumen, Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

Claro está, considero que la clave de llevar adelante esta metodología, es un buen ScrumMaster. Y si estas a cargo de un proyecto, estas como un ScrumMaster, y depende de tu buen tino, experiencia y paciencia, para hacer cumplir las directrices sin dejar de motivar a todo el equipo, llevando además un seguimiento a los documentos Scrumy a los resultados planificados para así cumplir con el factor X, nuestro cliente.

 

NOTAS

¹ Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7 ³56-1993-X

²Rising, L., Janoff N.S. (2000). The Scrum Software Development Processfor Small Teams.

³ Schwaber, Ken. Advanced Development Methodv. SCRUM Development Process.

⁴Jeff Sutherland .Scrum Tuning: Lessons learned from Scrum implementation at Google.

⁵ Marc (M'ion, J. Dunlap (2003). What is SCRUM?.

 

REFERENCIAS

Ken Schwaber. Agüe Project Management with Scrum, Microsoft Press, January 2004.        [ Links ]

Rising. L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams.         [ Links ]

Schwaber, Ken. Advanced Development Methods. SCRUM Development Process.         [ Links ]

Jeff Sutherland. Scrum Tuning: Lessons learned from Scrum implementation at Google.         [ Links ]

Marc Clifton, J. Dunlap (2003). What is SCRUM^°?        [ Links ]