- Introducción
- Conceptos en "Scrum"
- Los roles
- Las reuniones
- Los documentos
- Todo junto: Resumen de un proceso "Scrum"
- Conclusión
- Bibliografía
Desarrollado en 2001 por Kent Beck y otras personalidades, el "Desarrollo Ágil" del "Software" (véase "Manifiesto Ágil", por otras fuentes) se presenta como una nueva forma de desarrollarlo, "haciéndolo y ayudando a otros a que lo hagan". Así, las distintas metodologías de desarrollo ágil llegan a valorar:
A los individuos y su iteración con el software, por encima de los procesos y herramientas para el desarrollo del mismo.
El software funcional, por encima de una documentación objetiva y exhaustiva del mismo.
La colaboración de los desarrolladores con los clientes, por encima de la negociación contractual.
La respuesta del software al cambio, por encima del seguimiento de un plan para con el mismo.
No obstante, y pese a que en esta nueva visión de la Ingeniería del Software se valoran más estos aspectos, no hay que olvidar la importancia de los demás.
Así, ¿Que entendemos por Desarrollo Ágil?. La respuesta es clara:
Sin ser la antítesis a la Ingeniería del Software tradicional, esta nueva forma de desarrollar software es la combinación de una filosofía (entregas tempranas, necesidades del cliente satisfechas, equipos pequeños, métodos informales, simplicidad,…) y unas directrices de desarrollo (entregas por encima de análisis y diseño, comunicación activa desarrollador-cliente,…).
Por ello, las metodologías de desarrollo ágil presentan una ayuda para la superación de debilidades reales, presentes en la Ingeniería del Software tradicional.
A continuación se nombrarán algunos ejemplos de metodologías ágiles conocidas:
Programación Extrema (eXtreme Programming – XP).
Desarrollo Adaptativo de Software (Adaptative Software Development).
Método de Desarrollo de Sistemas Dinámicos (MDSD).
Melé (Scrum),
Cristal (Crystal Clear).
Desarrollo Conducido por Características (Featured Driven Development).
Modelado Ágil (Agile Modeling).
Agile Unified Process – AUP.
Essential Unified Process – EssUP.
Lean Software Development – LSD.
Open Unified Process – OpenUP.
Todas las metodologías nombradas son fieles al "Manifiesto Ágil", si bien no son aplicables a todo tipo de proyectos software.
Metodología propuesta: Melé – Scrum
Una de las metodologías de desarrollo ágil del software más conocidas es Melé, en inglés "Scrum". A continuación pasaremos a explicar el funcionamiento y aspectos importantes de esta metodología, con el fin de un mejor entendimiento y uso de la misma.
¿Qué es?
Conocemos su contexto, conocemos los aspectos más importantes de la Ingeniería del Software ágil, pero ¿Qué es Scrum?.
Primeros pasos
Como breve introducción a esta metodología, podemos decir que Scrum es un enfoque ágil al desarrollo del software. Una de las metodologías más conocidas y utilizadas presentes en el "Manifiesto Ágil".
Con Scrum, los proyectos software avanzan a través de una serie de iteraciones llamadas "Sprints". Cada "Sprint" tiene una duración de 2-4 semanas.
Así, si bien un enfoque ágil se puede utilizar para gestionar varios tipos de proyectos, Scrum es ideal para aquellos que cambian rápidamente, o cuyos requisitos emergen continuamente, como es el caso del desarrollo de software.
¿Metodología o marco de trabajo?
No obstante, más que un proceso completo de desarrollo o una metodología en si misma, Scrum es un marco de trabajo (aun así, en este documento hablaremos de Scrum en todo momento como una metodología).
En palabras de Ken Schwaber -importante desarrollador software, que junto a Jeff Sutherland formuló las primeras versiones del proceso de desarrollo software con Scrum-, "Scrum no es una metodología, es un marco de trabajo". Esto quiere decir que Scrum no te va a decir exactamente lo que debes hacer, y que normalmente deberemos utilizarlo en conjunto con otra metodología de desarrollo ágil (comúnmente XP).
Historia y Características
Pasaremos ahora a describir los hechos más importantes en cuanto a la historia de esta metodología, así como sus características más importantes.
Historia
El origen del concepto lo encontramos en 1986, año en que se realizaron estudios sobre nuevos procesos de desarrollo software, utilizados en Japón y Estados Unidos.
Fueron desarrollados grandes proyectos de éxito a partir de estos nuevos procesos, y los equipos que los desarrollaron partían de requisitos software muy generales, novedosos, y con un límite de tiempo para salir al mercado realmente reducido. En los mencionados estudios se comparaba el patrón de trabajo de estos equipos con la colaboración de los jugadores de los equipos de Rugby, y su formación, llamada Scrum (Melé en español).
El primer Scrum se desarrollo en 1993, cuyo objetivo era el desarrollo de software, formalizado en 1995. Más tarde, en 2001, varias personalidades en cuanto al desarrollo ágil del software presentaron los valores fundamentales de los procesos ágiles ("Manifiesto Ágil").
Ya desde 1995 gran cantidad de empresas empezaban a utilizar Scrum para el desarrollo de sus proyectos, desde empresas pequeñas a grandes multinacionales.
En la actualidad, Scrum se usa para multitud de tipos de negocios, especialmente en el desarrollo de software, para lo que fue inicialmente pensado.
Características
Scrum recoge todas las prácticas y actitudes reconocidas como buenas para el desarrollo ágil del software, y las sitúa en el centro del proceso. De ahí se deducen sus características, que podemos resumir de la siguiente forma:
Desarrollo Sofware iterativo e incremental: En Scrum, la planificación del proyecto maneja explícitamente los requerimientos del cliente, y realiza una priorización de los mismos en función del valor que proporcionan al cliente y su coste de desarrollo (ROI), desarrollando el producto de manera incremental, de manera que el cliente no tiene que esperar hasta el último día para conseguir un producto funcional, pudiendo dirigir de manera individualizada y sistemática cada iteracción del producto(véase "El Sprint"). Así, el cliente puede ir recuperando poco a poco su inversión, y no todo de golpe al final, como pasaba en las metodologías tradicionales; puede utilizar un producto al que le falten características poco relevantes, puede sacarlo al mercado sin que este llegue a su fase final de desarrollo, hacer nuevas sugerencias o peticiones a medio camino de desarrollo, etc…
Orientación a personas: En Scrum se le da mas responsabilidad y autoridad al equipo, al ser un equipo multidisciplinar. Se quiere que sea este el que decida como funcionar de manera eficiente, de modo que sea el propio equipo el que mejore su entorno de trabajo y pueda mostrar resultados de manera regular; también se fomenta la innovación en el mismo, con respecto al proyecto que se está desarrollando, facilitando la motivación y realización personal de los miembros del equipo.
Planificación con tiempo, tareas y personas: En Scrum, la planificación se orienta a los objetivos y requerimientos que plantea el cliente, y esta es realizada por el propio equipo, el mismo que se ocupa de la planificación de cada iteración del producto, asignándose tareas y tiempos para cada miembro, las cuales son detectadas por el equipo en conjunto, siendo así más fiables, ya que se basan en las experiencias e información de todos los miembros del equipo.
Control del progreso del proyecto: En Scrum, es el equipo el que se compromete a informar diariamente del progreso de las tareas que el mismo se ha asignado (véase "Las reuniones"), informando del avance de las mismas así como de los problemas que vayan surgiendo. Esto mejora la transferencia de información así como de experiencias y de soluciones, y produce una sinergia mucho más fuerte entre los miembros del equipo. En Scrum, más que un jefe de proyecto, hay un facilitador (véase "Los roles") que vela por la participación de todos los miembros del equipo.
Gestión de cambios: En Scrum, los cambios están permitidos y aceptados en el inicio de cada iteración, considerándose como algo natural, y permitiendo al cliente presentarlos una vez demostrados los resultados de cada iteración. Esto mejora la flexibilidad del proyecto, permitiendo al cliente adaptarlo de mejor manera a sus necesidades e intenciones.
Retrospectivas y análisis "post mortem": En Scrum las retrospectivas se hacen al final de cada iteración (véase "El Sprint"), permitiendo que un mejor aprendizaje por parte del equipo, que puede ser de esta manera más productivo a la hora de desarrollar el proyecto.
Timeboxing: El "timeboxing" consiste en fijar un tiempo máximo para una tarea, la toma de una decisión determinada, etc… y considerar este tiempo como máximo en vez de trabajar hasta conseguir el objetivo. En Scrum, esta técnica se utiliza en todas las tareas, lo que facilita la toma de decisiones y el enfoque de resultados.
Una vez comprendidas las características generales de esta metodología, pasaremos a desarrollar sus conceptos más importantes, los cuales hay que manejar con fluidez para comprender un proceso de desarrollo software con Scrum.
El "Sprint"
Como hemos comentado anteriormente (Vease "Primeros pasos", en este documento), un "Sprint" es una iteración en Scrum, durante la cual se desarrolla una parte "funcional" del proyecto, de manera que el cliente, al final de cada Sprint, puede ver parte de su inversión.
Un Sprint está acotado en el tiempo, dependiendo del equipo en cada caso, pero siempre tiene una duración máxima de un mes (30 días), y es el periodo durante el cual el Equipo (véase "Los roles") trabaja para desarrollar ciertos requisitos del Product Backlog (véase "Los documentos") en un Incremento del Producto.
No obstante, pese a que la duración de un Sprint es variable, la duración ideal del mismo se estima en torno a dos semanas (más de 4 semanas de duración hacen perder agilidad al equipo, y menos de 2 ponen en duda que se pueda sacar algo de valor o "funcional" del mismo). El objetivo prioritario de un Sprint es conseguir algo "de valor" que presentar al Product Owner y los Stakeholders (véase "Los roles"). Así, ciñéndonos al estándar de las dos semanas, podemos decir que cada Sprint:
Proporciona Feedback sobre lo que se está haciendo en cada momento con el proyecto.
Reduce riesgo de fallas en el diseño y otros aspectos, ya que un fallo afecta solamente a la iteración presente.
Aumenta la facilidad de respuesta ante cambios de requerimientos, ya que estos se pueden añadir o adaptar en el siguiente Sprint del producto.
Mejora la capacidad de adaptación del equipo, analizando en cada momento la forma en que trabajan.
Fuerza al equipo a seguir un enfoque ágil del proyecto, en vez de recurrir a metodologías tradicionales.
Al principio de cada Sprint se planifican todas las tareas, objetivos y actividades que se van a desarrollar durante el transcurso del mismo, lo que se considera la "Meta del Sprint" (véase Planificación del Sprint, en "Los documentos"). Si por cualquier motivo no se puede alcanzar la "Meta del Sprint", este se cancela (o si ciertas circunstancias anulan el valor de esta meta).
Durante el desarrollo del Sprint se va midiendo el progreso del mismo, mediante el Sprint Backlog (véase "Los documentos") y un gráfico BurnDown (véase "Los documentos"). También se llevan a cabo reuniones diarias, que explicaremos en la sección concerniente a "Las reuniones" en este documento.
Al finalizar cada Sprint, se lleva a cabo una Revisión del Sprint (véase "Las reuniones"), para revisar la parte desarrollada y presentarla, y también una Retrospectiva del Sprint (véase "Las reuniones") para analizar formas de mejorar el rendimiento o técnicas del equipo en función de la experiencia adquirida en esa iteración.
En Scrum los roles se dividen en dos categorías, atendiendo a la implicación en el proyecto de los miembros de esas categorías.
Así, podemos distinguir la categoría de los "cerdos", y la de las "gallinas".
"En un plato de huevos con tocino el cerdo está comprometido, la gallina solo está involucrada"
Roles Cerdo: Los integrantes de este rol son aquellas personas comprometidas con el proyecto, los que responden ante sus fallos, y los que se comprometen a desarrollarlo con calidad. Así, dentro de este rol podemos distinguir:
El Dueño del Producto o "Product Owner": Integrante del proceso que representa la voz del cliente, lo que este necesita y desea. Sus responsabilidades son variadas:
Se sitúa como representante de todos los interesados(clientes, usuarios finales,…) en el proyecto, tiene capacidad para tomar decisiones concernientes al mismo y actúa como interlocutor único ante el equipo.
Define objetivos del proyecto, así como dirige sus resultados y se preocupa por la priorización de los requisitos del cliente (ROI –Return Of Investment-) para formar el Product Backlog (véase "Los documentos"). Además, colabora con el equipo de manera activa, para llevar a cabo la planificación, revisión, etc… de cada iteración o Sprint.
El Facilitador o "Scrum Master": Se sitúa como protección del equipo, a modo de barrera ante los obstáculos que éste tenga para llevar a cabo cada Sprint. No obstante, no es el líder del equipo, ya que como ya dijimos (véase "Características"), el mismo se auto-organiza. Todo esto se puede resumir en:
Se encarga de hacer cumplir las reglas a todos los integrantes del equipo, lo que implica asegurarse de que la lista de requisitos priorizados esté lista antes de cada iteración, y facilitar las distintas reuniones que se hacen en Scrum (véase "Las reuniones").
Se encarga, como ya hemos comentado, de situarse como barrera ante los impedimentos que surjan, y eliminar los mismos. Estos impedimentos se detectan en las reuniones que se realizan diariamente (véase "Las reuniones").
El Equipo o "Scrum Team": El equipo está compuesto por un conjunto de personas que toman la responsabilidad de desarrollar el producto con calidad y de acuerdo a todo lo especificado en cada iteración o Sprint y en el proyecto en general. De manera general, sus características son las siguientes:
Tiene un tamaño medio-reducido, de entre 5 y 9 personas. Esto sucede por que un número inferior a 5 personas provoca un riesgo ante imprevistos con algún miembro del equipo, y un número superior a 9, provoca problemas de comunicación entre los miembros del mismo, y por tanto, una deficiente colaboración, pudiéndose formar subgrupos. No obstante, existen técnicas utilizadas para casos con equipos demasiado grandes o pequeños (como el "Scrum de Scrums", véase "Las reuniones").
Lleva a cabo una auto-organización de sus miembros, de manera que sus integrantes confían los unos en los otros, y comparten información. Para auto-organizarse ellos mismos, llevan a cabo tareas como la selección de los requisitos a los que se compromete cada uno, estimar la complejidad de los mismos, decidir como van a realizar el trabajo, etc…
Se trata de un equipo multidisciplinar, lo que significa que todos los miembros del equipo están integrados en todo el proyecto, teniendo el conocimiento y las habilidades para manejar todo tipo de tareas en el proyecto. Además, el equipo debe ser estable, trabajar en una misma localización, y dedicarse a tiempo completo al proyecto, dependiendo en la menor medida de lo posible de medios externos al proyecto.
Roles Gallina: Los integrantes de este rol son aquellas personas que no están tan comprometidas con el proyecto, aquellas que simplemente están interesadas en el mismo –"La gallina alimenta al proyecto "poniendo huevos", no se ve comprometida como el cerdo que va al matadero"- , por que están invirtiendo un dinero en él, etc. No son parte del proceso Scrum, pero deben tenerse en cuenta. Por tanto, las influencias de los integrantes de este rol se tienen en cuenta, hasta el punto en que no entorpezcan el proyecto. Dentro de este rol podemos distinguir:
Los Usuarios del Producto: Es el destinatario del sistema, aquel para el cual el sistema está diseñado. Participa en cada Sprint, al inicio del mismo, dando a conocer sus requerimientos y necesidades al Product Owner. También participa al finalizar cada Sprint.
Los Clientes, Proveedores, Inversores,… o "Stakeholders": Son quienes ponen el dinero y esperan los beneficios por parte del proyecto. Participan sobre todo revisando las iteraciones o Sprints, evaluando estos incrementos o velando por el cumplimientos de las metas y tiempos de desarrollo.
Los Administradores: Se trata de gente encargada de la contabilidad, secretaria, servicios, etc…
Durante todo el proceso de desarrollo del producto, se llevan a cabo distinto tipo de reuniones, tanto a nivel de Sprint, como diariamente:
Reuniones diarias: Durante el transcurso de cada Sprint se desarrollan una serie de reuniones de carácter diario. Estas son:
Daily Scrum: En esta reunión diaria se tratan aspectos relacionados con el estado actual del Sprint en curso del proyecto. La duración suele ser de 15 minutos, independientemente del tamaño del equipo, y todos los integrantes de la misma se sitúan de pie, para contribuir a que la reunión sea breve. Además, se suele "castigar" a aquellos que lleguen tarde a la misma. La ubicación y hora de la reunión es la misma todos los días. Algunas de las preguntas típicas de este tipo de reuniones son:
¿Qué has hecho desde ayer?
¿Qué es lo que estás planeando hacer hoy?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?
Scrum de Scrums: Se trata de una de las técnicas utilizadas cuando los equipos (véase "Scrum Team", en "Los roles"), son demasiado grandes, y se forman grupos de personas que forman equipos individuales. Se suele hacer después del Daily Scrum. En ellas los distintos grupos de equipos discutir los aspectos importantes de su trabajo, asistiendo una persona de cada equipo. Algunas de las preguntas típicas que se hacen en este tipo de reunión, aparte de las ya presentes en el Daily Scrum, que se mantienen, son:
¿Qué ha hecho tu equipo desde nuestra última reunión?
¿Qué hará tu equipo antes de que nos volvamos a reunir?
¿Hay algo que demora o estorba a tu equipo?
¿Estás a punto de poner algo en el camino del otro equipo?
Planificación del Sprint (Sprint Planning): Se lleva a cabo antes de empezar con el siguiente Sprint o iteración del proyecto (cada 15 o 30 días). Se suele dividir en dos partes, ambas con una duración máxima de 4 horas:
Selección de los Requisitos: En esta parte el equipo recoge los requisitos priorizados del cliente, que van a reflejar lo que se quiere del proyecto. El cliente puede preguntar dudas, y el equipo selecciona aquellos requisitos más importantes, y se compromete a desarrollarlos para esa iteración que comienza. De esta forma, se establece el contenido del String Backlog (véase "Los documentos).
Planificación de la Iteración: En esta parte, una vez obtenidos los requisitos priorizados, se planifican las tareas que son necesarias desarrollar para el cumplimiento de esos requisitos. Los miembros del equipo se auto-asignan las tareas.
Revisión del Sprint (Sprint Review): Al igual que cada una de las dos partes de la Planificación del Sprint, tiene una duración máxima de 4 horas. En este caso, la reunión se realiza al finalizar el proceso de desarrollo del Sprint, y en ella el equipo se encarga de transmitir al cliente la finalización de la iteración y le presenta los requisitos completados, mediante la entrega del incremento funcional del producto (o "demo"). Así, el cliente puede evaluar la iteración y plantear los cambios o actualizaciones que considere necesarios, re-planificando de esta manera el proyecto desde la primera iteración.
Retrospectiva del Sprint (Sprint Retrospective): Duración máxima de 4 horas, al igual que la anterior reunión. En esta, que se realiza después de la revisión del Sprint, el equipo analiza su manera de trabajar en la anterior iteración, ya finalizada, y plantea cambios en la misma con el fin de mejorar el rendimiento del desarrollo del producto, así como su productividad. Por otra parte, el facilitador (véase "Los roles"), se encarga al mismo tiempo de ir eliminando los obstáculos que se vayan presentando y siendo identificados.
A lo largo de un proyecto con Scrum, es necesario redactar diferentes tipos de documentos, tanto a nivel de proyecto, como de Sprint. Los más importantes son:
Lista de Objetivos/ Requisitos Priorizada (Product Backlog): Este documento representa lo que el cliente espera del proyecto en cuanto a objetivos y requisitos, así como entregas. Por tanto, el propio cliente se encarga de crear y gestionar esta lista, con la ayuda de un facilitador y el equipo, quien se encarga de establecer un presupuesto para completar cada requisito. Tiene las siguientes características:
Para cada objetivo o requisito de la lista, se refleja también el valor que este ofrece al cliente y el coste de desarrollo, de manera balanceada, es decir, se utiliza el Retorno de la Inversión (ROI). La lista puede ir evolucionando durante el desarrollo del proyecto, e incluirse nuevos requisitos.
Se reflejan todas las entregas o Sprints esperables, es decir, las entregas o incrementos del sistema que el cliente espera recibir a medida que se desarrolla el producto.
Además, se en ella se incluyen riesgos y obstáculos y las medidas para solventarlos.
Lista de Tareas de la Iteración (Sprint Backlog): En este caso se refleja la totalidad de tareas para la iteración o Sprint en curso, con el fin de cumplir los objetivos o requisitos para esa entrega o incremento, y entregar algo funcional al cliente acorde con lo esperado. Por tanto, esta lista se desarrolla al principio de cada Sprint (véase "Planificación del Sprint" en "Las reuniones"). Tiene las siguientes características:
Para cada objetivo o requisito se reflejan todas sus tareas, como se ha auto-asignado el equipo esas tareas y el esfuerzo necesario para completarlas. Además, se pueden observar aquellos puntos donde se tienen problemas o no se avanza, permitiendo una más fácil toma de decisiones.
Cada objetivo o requisito está ordenado por (ROI), es decir, están priorizados, según el valor que aportan al cliente y el coste de desarrollo.
Si hay una dependencia de una tarea sobre otra, se coloca esta tarea por debajo de la que depende.
El tiempo aproximado de desarrollo de cada tarea debe rondar entre las 4 y 16 horas, de manera que todas las tareas estén balanceadas (una duración mayor dificultaría el control del progreso en la tarea, y una duración menor crearía tareas poco relevantes ).
Gráficos de Trabajo Pendiente (BurnDown Charts): Se trata de gráficos, que reflejan la velocidad con la que avanza nuestro proyecto. Es decir, en el podemos ver que nos queda por hacer y que tenemos pendiente, ofreciéndonos una vista general de la rapidez con la que el proyecto en general o el Sprint en curso en particular está avanzando. Por tanto, podemos distinguir dos tipos de gráficos:
Gráfico de los días pendientes para completar el proyecto (Product BurnDown Chart), que se construye a partir del Product Backlog.
Gráfico de las horas pendientes para completar la iteración o Sprint en curso, que se construye a partir del Sprint Backlog.
Una vez vistos todos los conceptos de esta metodología, y entendido el proceso, la totalidad de un proceso Scrum para el desarrollo software puede resumirse con el siguiente esquema ([1]):
Después de una visión general de esta metodología, queda claro que Scrum es muy útil para el desarrollo de proyectos ágiles software, en particular para aquellos en constante cambio y con una necesidad de feedback por parte del cliente constante.
Por otra parte, se trata de una metodología considerada como un marco de trabajo, por lo que resulta en muchos casos imprescindible utilizarla en conjunto con otras metodologías software, sobre todo con XP (eXtreme Programming).
Wikipedia:
http://es.wikipedia.org/wiki/Archivo:Agile_Software_Development_methodology.jpg
http://es.wikipedia.org/wiki/Scrum
http://en.wikipedia.org/wiki/Ken_Schwaber
Campus Virtual UEM:
http://campusvirtual.uem.es/moodle/file.php/46797/Tema3.Desarrollo_Agil._2011-2012.PDF
Libros:
http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
"Scrum y XP desde las trincheras" – Henrik Kniberg.
Otros sitios web:
http://www.mountaingoatsoftware.com/topics/scrum
http://www.donpoligono.com/news/index.php?option=com_content&view=article&id=1999:curso-de-qmetodologia-efectiva-de-gestion-de-proyectos-scrumq&catid=43:noticias&Itemid=86
http://www.proyectosagiles.org/historia-de-scrum
http://www.proyectosagiles.org/scrum-proceso-trabajo-2-0
http://www.proyectosagiles.org/timebox
http://www.proyectosagiles.org/que-es-scrum
http://www.dosideas.com/wiki/Sprint
http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum/proceso-roles-de-scrum.html
http://www.proyectosagiles.org/cliente-product-owner
http://www.proyectosagiles.org/equipo-team
http://www.proyectosagiles.org/facilitador-scrum-master
http://rolandojaldin.blogspot.com/2011/04/los-roles-gallina-scrum.html
http://www.proyectosagiles.org/planificacion-iteracion-sprint-planning
http://www.proyectosagiles.org/retrospectiva-sprint-retrospective
http://www.proyectosagiles.org/lista-requisitos-priorizada-product-backlog
http://www.proyectosagiles.org/lista-tareas-iteracion-sprint-backlog
http://www.proyectosagiles.org/graficos-trabajo-pendiente-burndown-charts
Autor:
Enviado por:
Ricardo Martínez Cobo
[1] Enlace a la imagen del esquema (para mayor resolución): http://es.wikipedia.org/wiki/Archivo:Ficha_scrum.png