Dentro de la familia de las metodologías ágiles, ese nuevo paradigma que llegó hace unas cuantas décadas para quedarse, la metodología Scrum es la integrante más destacada. Sin duda alguna, Scrum es la que más compañías ha conquistado y mejor se ha posicionado en el mundo empresarial.
Este modelo cambia drásticamente la forma como las personas trabajan: le concede mayor valor a las actividades colaborativas y en equipo. Constituye una forma creativa y práctica de abordar los procesos implicados en un proyecto, de modo que sean más fluidos y rápidos.
¿De qué se trata este modelo? ¿Para qué sirve la metodología Scrum? ¿A qué proyectos puede aplicarse? Todo esto y mucho más es lo que veremos a continuación.
¿Qué es la metodología Scrum?
La metodología Scrum es un sistema para trabajar en equipo, cuya finalidad es entregar valor al cliente. El término Scrum proviene del rugby y hace referencia a un estilo de trabajo en el que los proyectos se dividen en pequeños bloques, llamados sprints, de modo que se vaya revisando y mejorando la fase anterior.
En el proceso Scrum se aplica un conjunto de buenas prácticas para trabajar colaborativamente en equipo, de modo que se pueda obtener el mejor resultado posible. Forma parte de las metodologías ágiles y es la más exitosa de este género.
La metodología Scrum ofrece excelentes resultados, especialmente en proyectos muy complejos o que requieran la ejecución simultánea de varias actividades. Así mismo, en aquellos en los que se necesita cumplir los objetivos en el menor tiempo posible, de manera flexible y con miras a satisfacer las necesidades del cliente.
De otro lado, aplicar esta metodología puede ser muy conveniente para aquellos proyectos en los que hay problemas con los tiempos de entrega, la calidad no es aceptable o no se está entregando al cliente lo que necesita.
El origen de la metodología Scrum
Como ya lo anotamos, la palabra scrum viene del rugby y en principio tiene que ver con una disputa física por la pelota de juego. El término fue introducido por Ikujiro Nonaka e Hirotaka Takeuchi en los años 80. Los dos llevaron a cabo un estudio sobre la forma como desarrollaban los productos grandes empresas como Fuji-Xerox, Canon, Honda, Brother, 3M y otras.
Estos dos personajes publicaron un artículo llamado El nuevo juego para el desarrollo de productos, en 1986. El texto apareció en la Harvard Business Review y sentó las bases de lo que luego se convertiría en la metodología Scrum.
Más adelante, en 1993, Jeff Sutherland y su equipo de Easel Corporation adaptaron la metodología Scrum al desarrollo del software. Esa es la razón por la que a este sistema también se le conoce como metodología de desarrollo de software Scrum. Lo cierto es que en la actualidad se aplica a prácticamente cualquier área de la empresa y a todo tipo de proyectos.
Características de la metodología Scrum
En términos generales, la metodología Scrum se basa en tres grandes pilares o características: transparencia, inspección y adaptación. Veamos:
- Transparencia: Todas las personas que trabajan o están implicadas con la metodología Scrum saben qué ocurre en el proyecto y cómo ocurre.
- Inspección: En este método hay un seguimiento continuo para verificar el progreso y detectar posibles problemas.
- Adaptación: Los equipos que trabajan con esta metodología están permanentemente dispuestos a cambiar para ajustar lo que sea necesario, con tal de lograr los objetivos.
De una manera más puntual, se ha establecido que las principales características de la metodología de desarrollo Scrum son las siguientes.
Organización autónoma
En esta metodología cada equipo puede decidir de manera autónoma cuáles son sus metas y cómo debe operar para conseguirlas. Las metas deben ser cada vez más complejas, pues se espera que haya una evolución ascendente que lleve a un «gran descubrimiento».
Procesos flexibles
Aunque la metodología ofrece unas pautas básicas, lo cierto es que no propone ningún proceso rígido, sino que se espera más bien que la actividad y la forma de operar fluya de manera creativa. De este modo, se facilita la aparición de respuestas más novedosas.
Desarrollo simultáneo
En la metodología Scrum no hay cronogramas fijos ni compartimentados, de modo que varios individuos pueden trabajar de manera simultánea en el mismo proyecto, con tiempos y ritmos diferentes. Aunque esto implica mayor riesgo, lo que busca este sistema es que se produzca una integración más creativa entre los diferentes puntos de vista y así surjan respuestas mucho más innovadoras.
Aprendizaje múltiple
Este sistema fomenta el aprendizaje individual continuo a partir de la investigación del entorno. A su vez, ese aprendizaje se pone en común en el equipo, de tal modo que todos se nutran de otras perspectivas. Esto fortalece el conocimiento del grupo y hace más fácil el camino hacia el descubrimiento de algo nuevo.
Multiplicación del aprendizaje
La metodología Scrum tiene un efecto de contagio que termina por impregnar a toda la organización. Por lo tanto, puede comenzar por un área específica, pero luego es posible que se convierta en un método general de trabajo, con relativa naturalidad.
Control tenue
En este sistema de trabajo colaborativo hay una supervisión que no se enfoca a controlar, sino a canalizar. Para que el entorno creativo no se vuelva anárquico, se aplican algunas pautas básicas:
- Talento humano con sinergia. Los equipos se conforman de tal modo que haya personalidades que contrasten y a la vez sean complementarias.
- Mantener el enfoque en las necesidades del cliente, en todo el equipo.
- Propiciar una participación activa de todos los miembros del grupo.
- Gestionar el conflicto y prevenirlo.
- Tolerar los errores y adoptar una perspectiva de aprendizaje.
- Ofrecer un margen de libertad adecuado a cada miembro del equipo.
Roles, fases y artefactos en la metodología Scrum
La metodología Scrum define unos roles para quienes están involucrados en un proyecto. De igual manera, señala unas etapas definidas en el desarrollo del trabajo y define unas herramientas aptas para adelantar el proceso. Enseguida veremos cada uno de esos aspectos.
1. Los roles en la metodología Scrum
En la metodología de desarrollo Scrum hay tres roles principales y uno auxiliar. Los principales son: product owner, o propietario del producto; scrum master, o facilitador; y el equipo desarrollador. El rol auxiliar comprende a los stakeholders, o interesados de alguna manera en el proyecto. Veamos qué papel cumple cada uno de ellos.
Product owner, o propietario del producto
La función central del product owner es la de servir de interlocutor entre el cliente, el equipo y todos los interesados en el proyecto o stakeholders. Por lo mismo, esta persona es la encargada de gestionar el Product Backlog. Este último es una lista ordenada y priorizada de los requisitos del cliente.
Solo una persona puede ejercer el rol de product owner. Debe tener buenos conocimientos sobre el negocio y puede formar parte del equipo de desarrollo o no. Su propósito final es el de maximizar el valor del grupo de trabajo.
Scrum master, o facilitador
El scrum master es el encargado de hacer que la organización comprenda y aplique las técnicas Scrum. Su labor consiste en identificar y solventar los impedimentos o dificultades en la implementación de la metodología Scrum. En pocas palabras, elimina los obstáculos que le impiden al equipo alcanzar sus objetivos.
El scrum master también es el encargado de conformar los equipos y servir como facilitador en todas las reuniones. Como en el caso anterior, su labor se orienta a lograr que el proceso Scrum le aporte valor a las labores que se realizan.
Equipo desarrollador
Es el grupo de personas encargado de desarrollar las tareas requeridas y priorizadas por el product owner. Debe ser un equipo multidisciplinar y autorganizado, de preferencia no mayor a 10 personas. En este no se conforman subequipos y, por lo mismo, rinden cuentas como si fueran una sola persona.
Stakeholders, o interesados
Dentro de este rol auxiliar se encuentran todos aquellos que tienen algún interés en el proyecto y se mantienen como observadores en el desarrollo del trabajo. Pueden ser clientes, directivos, patrocinadores, expertos o terceros. Eventualmente, su opinión es tomada en cuenta, sobre todo cuando se hace la revisión o evaluación del proceso.
2. Fases de la metodología Scrum
La metodología Scrum tiene varias fases en su implementación. Cada una de ellas corresponde a una parte del proceso. Son esas fases las que convierten a este modelo en una estructura funcional.
Dentro de esta metodología hay un concepto esencial al que se le denomina sprint, que en español vendría a ser algo así como una aceleración, o cambio de ritmo, repentino y corto. Sin embargo, se le traduce como iteración, es decir, repetición o reiteración. El sprint es el corazón de este sistema y marca todas las etapas del modelo Scrum.
Un sprint es como el contenedor o marco que incluye los hitos del proyecto. No puede durar más de un mes y su duración depende de la retroalimentación que se obtenga del cliente. Al terminar un sprint se inicia otro, hasta que se completen todas las tareas y se cumplan los objetivos del proyecto.
Ahora bien, ¿cuáles son las fases de la metodología Scrum? Son cuatro: sprint planning, o reunión de planificación; daily meeting, o reunión diaria de sincronización del equipo; sprint review, o reunión de revisión; y sprint retrospective, o retrospectiva del proceso. Veamos cada una de estas etapas.
2.1. Sprint planning, o reunión de planificación
Esta es la primera reunión y en ella el equipo define el objetivo del sprint y decide qué tareas va a realizar. Para un sprint de un mes, esta reunión no debe durar más de 8 horas. En esta sesión se debe establecer lo siguiente:
- Definir qué y quién desarrollará las tareas. Esto implica establecer los roles de equipo con sus tareas asignadas.
- Decidir dónde y cuándo, es decir, el plazo y el contenido del sprint.
- Señalar por qué y cómo se emplearán las diferentes herramientas de esta metodología.
El resultado final debe ser un sprint goal, u objetivo del sprint. Es decir, un objetivo único que debe ser alcanzado, con base en el Product Backlog o lista de producto. Así mismo, se debe obtener como resultado de esta reunión un sprint backlog, o lista de tareas del sprint.
2.2. Daily meeting, o reunión diaria de sincronización del equipo
Es una reunión que se debe hacer todos los días, con una duración máxima de 15 minutos. En ella deben participar el equipo de desarrollo y el scrum master, pero no es necesario que se haga presente el product owner.
En cada reunión se debe responder a las siguientes preguntas:
- ¿Qué se hizo ayer?
- ¿Qué se hará hoy?
- ¿Existe algún impedimento que necesita solución?
Esta reunión es el principal espacio de seguimiento. Permite inspeccionar las tareas y definir un cambio de rumbo, si hay necesidad de ello.
2.3. Sprint review, o reunión de revisión
Es una reunión que se hace al final de cada sprint y que tiene una duración máxima de 4 horas, para un sprint de un mes. El objetivo es revisar el valor que se le va a entregar al cliente y este último puede, y debe, estar presente.
Este espacio está a cargo del product owner, quien debe presentarle al cliente lo que se ha desarrollado, al tiempo que el equipo desarrollador expone el funcionamiento o los detalles del resultado. Por su parte, el cliente debe validar o no tal resultado y hacer las objeciones o solicitudes del caso. Estas serán agregadas al Product Backlog.
2.4. Sprint retrospective, o retrospectiva del proceso
Esta es la última reunión y tiene una duración de 3 horas para un sprint de un mes. El objetivo es evaluar la forma en que se ha aplicado la metodología Scrum. Es importante consignar la lista de mejoras que se deben implementar para el siguiente sprint y hacer las autoevaluaciones correspondientes.
3. Artefactos en la metodología Scrum
Los artefactos son herramientas diseñadas para garantizar la máxima transparencia durante la aplicación de la metodología Scrum. No solo permiten organizar toda la información clave, sino que también hacen posible el seguimiento, la inspección, la identificación de patrones de trabajo y las diferencias entre las metas y los resultados.
Básicamente existen tres artefactos y dos conceptos asociados a ellos. Los artefactos son el Product Backlog, el Sprint Backlog y el Incremento. Los conceptos asociados son Progresos y Terminado. Veamos.
3.1. Product Backlog
Es el listado de todas las tareas comprendidas en un proyecto. Lo elabora el product owner, quien está en permanente contacto con el cliente, el cual, finalmente, es la fuente de donde se desprenden las actividades a realizar.
La lista se diseña por orden de prioridad y en la reunión de planeación el equipo elige las tareas que serán desarrolladas en el sprint. Este listado puede ir cambiando en función de las necesidades del cliente, las condiciones del mercado y la tecnología disponible, entre otros.
3.2. Sprint Backlog
El sprint backlog es una lista de tareas seleccionadas del Product Backlog para desarrollar en el sprint actual. Esa selección se lleva a cabo durante la primera reunión, o reunión de planeación. También, se podría definir como una lista de pendientes que se va actualizando día a día, a medida que se evacúan las actividades.
En el sprint backlog quedan definidas las tareas que cada miembro del equipo va a desarrollar y el tiempo que tiene para hacerlas. También, debe marcar un objetivo para el sprint.
3.3. Incremento
Corresponde al entregable del sprint, o su resultado. Este debe estar «Terminado» y debe ser aplicable o utilizable. Conceptualmente, el incremento es el avance concreto en el producto o el aspecto trabajado, al terminar cada sprint. Se podría decir que es una nueva versión de ese producto o de ese aspecto sobre el cual se aplicó la metodología Scrum. Así mismo, podría afirmarse que es el producto, o aspecto, con el valor añadido por el proceso.
En esta metodología deben diseñarse criterios para definir cuándo hay un «Progreso» y cuándo el proceso está «Terminado». Esto permite supervisar de manera más objetiva la aplicación de la metodología.
Implementar la metodología Scrum
Por obvias razones, la implementación de la metodología debe seguir las etapas del modelo Scrum. En términos generales, consiste en definir el objetivo del sprint, dividirlo en tareas, asignarlas, efectuar reuniones diarias para hacer el seguimiento y resolver problemas, y realizar las evaluaciones correspondientes al final.
La metodología Scrum se centra en la repetición de ese mismo ciclo hasta que se evacúe por completo el proceso fijado. Un paso a paso lógico sería el que se expone a continuación.
1. Preparación del sprint
Lo primero que se debe hacer es llevar a cabo una serie de tareas preliminares para definir el sprint, de tal modo que se siga una secuencia ordenada. Dicha preparación incluye las siguientes acciones.
Reunión con el cliente
Todo comienza y termina con el cliente. Lo primero es hacer una reunión con este para que este defina sus requerimientos y necesidades. Esto permitirá elaborar una lista de objetivos y tareas a cumplir.
Definir el product owner, y configurar el equipo
Se comienza con la asignación del product owner. Esta persona debe conocer exactamente cuáles son las necesidades a cubrir y tener una idea muy clara del proyecto. A partir de esto debe elaborar el Product Backlog.
La segunda labor del product owner es la de conformar el equipo. Es necesario insistir en que este debe ser, preferiblemente, multidisciplinario y estar constituido por personas con caracteres complementarios, que puedan hacer contraste entre sí, sin generar conflicto. En algunas ocasiones la selección debe hacerla el scrum master, en caso del que product owner sea un elemento externo o no esté familiarizado con el personal.
Lo más aconsejable es conformar varios equipos, si la lista de objetivos y tareas es muy amplia. El número ideal de integrantes es de tres a siete. El product owner debe decidir quién va a ser el scrum master del grupo; este debe ser alguien con liderazgo, experiencia en manejo de equipos y mucha empatía.
Lo que sigue es contactar a los stakeholders e informarles del proceso, para contar con su concurso y sus aportes en el momento adecuado.
Definir criterios
El product owner también debe definir los criterios de aprobación de cada entregable, es decir, las pautas para establecer si se produjo un «Progreso» o algo ya está «Terminado». Estos son criterios internos, ya que el sí definitivo debe darlo el cliente.
2. Reunión de planificación y sprint diario
La primera reunión debe centrarse en la priorización de los objetivos y las tareas, a partir del Product Backlog, para luego seleccionar aquellas de las que se va a ocupar el equipo. El resultado final debe ser el sprint backlog. El equipo debe ser informado sobre los criterios de aprobación.
El scrum master debe llevar a cabo reuniones diarias para evaluar el estado del proyecto. Todos deben conocer el grado de desarrollo de las tareas de los demás. Lo conveniente es que estas reuniones tengan una duración de entre 5 y 15 minutos.
En cada reunión se debe hablar acerca de los problemas que han surgido, cómo se van a solucionar y qué dificultades se deben prevenir. Así mismo, se definirán los cambios a realizar, si es necesario, teniendo cuidado de no afectar el objetivo planteado.
3. Revisión del sprint
Una vez se complete la iteración, es necesario realizar una reunión de revisión con todo el equipo. Por lo general, ese tipo de reuniones tienen la siguiente estructura:
- Descripción de lo que se ha hecho y de lo que no se ha conseguido.
- Discusión sobre los problemas que han surgido y cómo se han resuelto.
- Planteamiento de nuevos sprints. Entre todos se decidirá lo que se va a hacer a continuación.
- Revisión de las fechas de finalización del proyecto, con base en los cambios dados durante el proceso.
- Revisión de tiempo, presupuesto y mercado para la próxima entrega prevista del producto.
Es importante evaluar tanto los entregables, como el método mismo de trabajo. Se espera que el scrum master aporte pautas o consejos sobre las mejoras a adelantar. Finalmente, el product owner debe dar el visto bueno del sprint y sus resultados.
4. Retrospectiva del sprint (o iteración)
La retrospectiva se realiza una vez que el producto final ha sido terminado y aprobado por el cliente. Esto sucede, por lo general, después de varios ciclos de iteraciones. El objetivo de esta reunión es promover la mejora continua y compartir aprendizajes.
En la retrospectiva del sprint se evalúa cómo fue el desempeño de las personas implicadas y el uso de las herramientas. Lo aconsejable es que la reunión gire en torno a los siguientes interrogantes:
- ¿Cuáles fueron los mejores sprints, o los más productivos? ¿Por qué?
- ¿Cómo se obtuvieron los hallazgos más relevantes? ¿Cuál fue la clave de esos éxitos?
- ¿Cuáles fueron los errores? ¿Cuál fue la causa de los mismos?
- ¿Qué aspectos mostraron un progreso? ¿Cuál fue la clave de la mejora?
A la reunión deben asistir todos los involucrados con el proyecto, incluyendo a los stakeholders. Es conveniente compartir los aprendizajes con otros equipos para generar conocimiento colectivo.
Ventajas y desventajas de la metodología Scrum
Las ventajas y desventajas de la metodología Scrum tienen mucho que ver con la forma como se aplica. Bien ejecutado, este es un método que definitivamente permite ver resultados en corto tiempo. Mal llevado a cabo, puede convertirse en caos y pesadilla.
Los expertos indican que la metodología Scrum es particularmente apta para aquellos proyectos que exigen resultados rápidos, en especial si se basan en los siguientes aspectos: innovación, productividad, flexibilidad y competitividad.
Enseguida veremos las ventajas y desventajas de la metodología Scrum.
Ventajas de la metodología Scrum
Dentro de las ventajas de la metodología Scrum encontramos las siguientes:
- Le otorga un lugar decisivo al cliente, como tiene que ser. El cliente marca el ritmo y constituye el eje de todo el proceso. Puede participar en todas las etapas y proponer ideas y soluciones. Esto lleva a mejores resultados.
- Ofrece resultados anticipados. Como en esta metodología se llevan a cabo ciclos sucesivos, o sprints, no hay que esperar hasta el final para que el cliente vea los resultados. Él es testigo de los avances y puede validarlos.
- Permite gestionar mejor el riesgo. Los problemas se abordan en el mismo momento en que aparecen. Esto reduce el riesgo de perder tiempo y dinero con soluciones tardías.
- Es un mecanismo para evaluar el rendimiento. La supervisión y evaluación continuas hacen que también sea más sencillo detectar la forma como se desempeña el personal.
- Facilita el cambio de rumbo. En el modelo Scrum está implícito el cambio de rumbo, si es necesario, incluso desde un comienzo. No hay que hacer grandes esfuerzos para tomar nuevos caminos.
- Flexibilidad y adaptabilidad. Aunque la metodología Scrum se aplicó inicialmente solo al desarrollo del software, actualmente se puede emplear en cualquier tipo de proyecto y en cualquier área.
- Facilita la comunicación interna. Esta metodología lleva implícitos unos canales y protocolos para hacer que la comunicación interna sea más fluida.
- La metodología Scrum es muy fácil de aprender. Los roles, los hitos y la dinámica son fáciles de asimilar y aportan claridad al trabajo.
Desventajas de la metodología Scrum
No hay nada perfecto y la metodología Scrum no es la excepción. Dentro de sus desventajas encontramos las siguientes:
- El product owner tiene que ser una persona altamente especializada para que adelante su labor de la forma como se debe.
- El equipo debe tener competencias específicas. Un equipo no creativo, no innovador, no autónomo o no flexible, da al traste con los propósitos de la metodología.
- La necesidad de hacer equipos multidisciplinarios puede ser un obstáculo para algunas empresas.
- Los objetivos deben plantearse de una forma muy elaborada, ya que de lo contrario puede fallar la metodología.
- La definición de tareas y de plazos es una labor minuciosa y exhaustiva. Si esto no se hace de la manera adecuada, el Scrum se desvanece.
- El personal involucrado debe tener características de personalidad específicas. Un trabajador facilista, poco comprometido o conflictivo altera por completo el esquema.
- En situaciones de crisis estructural, la compartimentación en sprints puede no ser suficiente.
Ejemplos de metodología Scrum
Es claro que ninguna metodología es perfecta, ni garantiza el éxito. El propio Jeff Sutherland, creador del modelo Scrum tal y como lo conocemos hoy en día, concedió una entrevista para analizar un caso de éxito y uno de fracaso con su método.
Enseguida, y a manera de ejemplos, te contamos lo que dijo Sutherland al respecto.
Healthcare.gov, un ejemplo de fracaso con el modelo Scrum
Healthcare es un proyecto del gobierno de los Estados Unidos que se diseñó para ofrecer información y transparencia sobre el mercado de los seguros de salud en ese país. El objetivo era que los consumidores pudieran asegurarse de obtener el mejor valor. El proceso se puso en marcha bajo la metodología Scrum y el resultado fue muy desalentador.
El principal error de Healthcare estuvo en tomarse libertades, frente a la metodología Scrum, que entorpecieron el buen desempeño. Así pues, la primera gran falla estuvo en contratar a 20 grandes consultoras para que implementaran el proyecto. De este modo, la ejecución quedó completamente fragmentada y no había una cabeza que le diera coherencia al proceso. En otras palabras, no había uno, sino muchos product owners.
Así mismo, no adelantaron todas las fases de la metodología Scrum. En particular, le dieron poca importancia a las etapas en las que se producía generación de aprendizaje. Así mismo, la revisión final se adelantó de forma muy rápida.
Al respecto, Sutherland señaló: «Healthcare.gov es principalmente un proyecto en cascada que salió mal, y eso es bastante común. El 86 por ciento de los proyectos en cascada fracasan. La mayoría de ellos, aproximadamente la mitad de ese 86 por ciento son fallas totales».
Spotify, un caso de éxito
A diferencia del caso anterior, Spotify es un ejemplo de buena aplicación de la metodología Scrum. Han ejecutado el modelo de una forma muy sistemática y precisa. Han puesto empeño en conseguir buenos product owners, pero le han dado aún más importancia a la formación de los scrum masters que, finalmente, están al frente de todo el proceso.
En Spotify se crean equipos y estos a su vez dan lugar a escuadrones. Estos son pequeños grupos de trabajo que desarrollan una parte del producto en su totalidad. Los escuadrones interactúan entres sí, principalmente en la generación de conocimiento, a través de «tribus» compuestas por varios de estos equipos. La coordinación central de toda esta estructura es óptima.
Al mejor estilo del modelo Scrum, los equipos de trabajo desarrollan su labor de una manera autónoma y con autoevaluación constante. Esto ha vuelto mucho más ágiles sus procesos y desarrollos.
Palabras finales
La metodología Scrum se ha convertido en la más exitosa y popular de todas las metodologías ágiles. No es para menos, si se toma en cuenta que se trata de un modelo sencillo y práctico. Como hemos visto, el secreto está en aplicarlo de manera sistemática y respetando los roles y las fases, ya que es así como alcanza su mayor potencial.
Hablar de Scrum es hablar de marcas tan prominentes como Google o Microsoft. De hecho, hay muchas compañías tecnológicas que le apuestan a este modelo. Lo bueno es que en la actualidad esta metodología ya no solo se utiliza para desarrollar software, como ocurría al comienzo, sino que se aplica a todo tipo de proyectos.
La metodología Scrum es también un reto porque rompe con lo convencional. Exige compromiso, autonomía y creatividad por parte de quienes se decidan trabajar con este sistema. Sin embargo, lo que ofrece a cambio es extraordinario: más innovación, más efectividad y, por si fuera poco, resultados más rápidos.
Fuentes de apoyo
- Colla, P. (2012). Marco para evaluar el valor en metodología SCRUM. In de 13th Argentine Symposium on Software Engineering, la Plata-Argentina.
- Godoy, D. A. (2015). Diseño de un Simulador Dinámico de Proyectos de Desarrollo de Software que utilizan metodología Scrum (Doctoral dissertation, Universidad Nacional de La Plata).
- Mariño, S. I., & Alfonzo, P. L. (2014). Implementación de SCRUM en el diseño del proyecto del Trabajo Final de Aplicación. Scientia et technica, 19(4), 413-418.
