El objetivo de esta investigación fue adaptar el marco ágil Scrum al proyecto Asismed Service, como una propuesta para mejorar la planeación de proyectos de investigación y desarrollo en el CCAI (Centro de Cooperación Académica e Industrial). Al considerar que el desarrollo de nuevos productos se lleva a cabo en ambientes cambiantes, donde se encuentran diferentes personas y culturas, se requiere trascender de la planeación tradicional y/o predictiva a una evolutiva. Este marco de gestión ágil es el adecuado, ya que aporta valor en periodos cortos de tiempo, basado en tres pilares: transparencia, inspección y adaptación.

Como resultado se aprecia un ahorro aproximado del 20 % de tiempo total en la ejecución de un proyecto en el CCAI: utilizando la planeación tradicional, en promedio desarrolla el producto en seis meses, utilizando el marco ágil Scrum se consiguió en cuatro meses; además de proporcionar un ritmo de trabajo continuo y evolutivo.

Palabras clave: Gestión de proyectos, Scrum Master, diseño de nuevos productos, aplicación móvil.

The aim of this research was to adapt the agil Scrum Master methodology to the Asismed Service project, as a proposal to improve the planning of research and development projects at CCAI (standing for Centro de Cooperación Académica e Industrial). Bearing in mind that the development of new products is carried out in changing environments, where not only different people are found, but also different cultures, it is required to go beyond traditional and/or predictive planning to an evolving one. This agile management framework is the right one because according to Encarna Abellán, it is characterized by providing value in short periods of time based on three pillars: transparency, inspection and adaptation.

As a result, an approximate saving of 20% of total time can be seen in the execution of a project in the CCAI: using traditional planning, on average the product is developed in six months, while using the agile frame Scrum framework the product was achieved in four months; it provided a continuous and evolutionary pace of work.

Keywords: Project management, Scrum Master, new product design, mobile application.

Cuando se trata de la mejora de procesos, generalmente existen dos técnicas: la mejora continua o la reingeniería. Como lo menciona Larson¹, la elección depende de que tan “sólidos” sean los procesos, si son sólidos (funcionales) no será necesario reestructurarlos, o solo con la mejora continua será suficiente; por el contrario, si los procesos son “caóticos” o inexistentes la reingeniería sería la mejor opción. Larson también aporta una tabla comparativa entre mejora continua y reingeniería, esta es útil para facilitar la elección del uso de una u otra técnica:

Tabla 1. Mejora continua vs Reingeniería. Fuente: Larson, 2016¹.

Por otra parte, et al² mencionan que, en cualquier organización, la innovación se lleva desde el producto hasta los procesos; la innovación en el producto permite desarrollar nuevos productos o agregarle mejores características, la innovación en los procesos se enfoca en el rediseño de los procesos centrales que apoyan el posicionamiento del producto, tal como la manera en que se adquiere o se proporciona servicio a este. Para hacer este rediseño de procesos y clarificar el objetivo de la reestructuración, se considera el llamado “The Devil’s Quadrangle” (Figura 1), donde se debe analizar que la dimensión del desempeño buscado (Tiempo, Calidad, Flexibilidad o Costo) no afecte de manera crítica a las demás; se debe buscar un equilibrio entre las cuatro dimensiones ya que están interrelacionadas y cambiar una afecta a los demás.

Figura 1. The Devil´s Quadrangle. Fuente: .Dumas et al²

En la reingeniería de negocios, mencionan Hammer y Champy³, lo importante es “cómo queremos organizar el trabajo”, teniendo en cuenta el mercado y la tecnología actual, ya que muchos de los procesos de los negocios responden a necesidades y circunstancias de los inicios de la especialización del trabajo. La reingeniería se enfoca en cambios radicales en lugar de mejoras incrementales, solo se debe estar seguro que realmente es necesaria, ya que es “empezar de nuevo” y, como lo definen Hammer y Champy: “Reingeniería es la revisión fundamental y el rediseño radical de procesos para alcanzar mejoras espectaculares en medidas críticas y contemporáneas de rendimiento, tales como costo, calidad, servicio y rapidez”.³

La gestión de proyectos tradicionalmente se compone de cuatro etapas: planificación, preparación, implementación y cierre⁴. Dentro de la etapa de planificación se desarrolla una estructura de “desglose” del trabajo en tareas y subtareas, con la secuencia y tiempos estimados para su realización, en implementación se considera: la supervisión, el control, comunicación y la gestión de problemas.

En 1986 se publica en Harvard Business Review el articulo llamado “The new product development game”, por Hirotaka Takeuchi e Ikujiro Nonaka⁵, donde se sientan las bases de lo que después sería conocido como el “Método Scrum para la gestión de proyectos de innovación” o también llamado “Gestión ágil de proyectos”. El documento hace un análisis de los características que compartían empresas que habían tenido éxito en el desarrollo de nuevos productos y encontraron que destacan seis aspectos: inestabilidad incorporada, equipos de proyectos autoorganizados, fases de desarrollo superpuestas, multi-aprendizaje , control sutil y transferencia organizacional del aprendizaje.

Scrum, definido por sus creadores Jeff Sutherland y Ken Schwaber : “Es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos”⁶.

El propósito de este artículo es demostrar la utilidad del marco de gestión ágil llamado “Scrum” en proyectos de investigación en el Tecnológico de Estudios Superiores de Jocotitlán (TESJo), ya que esta institución educativa de nivel superior cuenta con uno de los primeros Centros de Cooperación Academia-Industria (Centros CAI) en México, que siguen el modelo de educación superior de Corea del Sur para una vinculación más estrecha entre las empresas de la región, personas investigadoras y estudiantes de la institución. Esto puede ser útil para que el CCAI resuelva sus investigaciones o proyectos de manera rápida, y así satisfaga al cliente a través de una entrega temprana y continua, se trabaje de manera unida, y exista motivación en todo momento del proyecto, así como una comunicación eficiente y efectiva. Así mismo, se puede maximizar la cantidad de trabajos de una manera simple sin dejar de lado la atención continua, ya que esto va a aumentar la agilidad; todo ello corresponde al marco “Scrum”.

Adecuar el marco ágil de proyectos Scrum para contribuir a la reducción del tiempo de entrega en los proyectos que se realizan en el Centro de Cooperación Académica e Industrial.

El Centro de Cooperación Academia e Industria (CCAI) desarrolla sus proyectos haciendo uso de la gestión de proyectos tradicional, dentro del cual existen algunos inconvenientes debido a la naturaleza de la institución, en la que se trabaja por semestres, esto ocasiona cambios en las condiciones y recursos como la participación de alumnos, periodos vacacionales, horarios etc.

Mejorar la respuesta a las demandas del CCAI para el desarrollo de nuevos productos se propone plantear una reingeniería tomando en cuenta los factores listados en la Tabla 1 (Mejora continua vs. Reingeniería), donde los factores de Esencia, Enfoque, Nivel, Cambio, Meta, Disciplina y Dominio, justificarían el uso de esta técnica.

Tabla 2. Justificación del uso de reingeniería en el caso del CCAI del Tecnológico de Jocotitlán. Fuente: elaboración propia.

Con base en la definición de Reingeniería, que plantea “un rediseño radical” de los procesos, se propone la implementación de la técnica Scrum que sustituiría a la gestión tradicional de proyectos con el objetivo de contribuir en la reducción de tiempos de entrega de un proyecto y así proporcionar un ritmo de trabajo continuo y evolutivo.

Se utiliza como caso de estudio el proyecto “Asismed Service”, dedicado a desarrollar una aplicación móvil para conectar a practicantes del área de odontología con las personas que viven en zonas marginadas ubicada en el municipio de Jocotitlán, México.

Se utilizó como guía para la aplicación de Scrum: “Scrum Master” versión 3.04, de Scrum Manager⁷.

Figura 2. Las reglas de Scrum. Fuente: Scrum Master⁷

Es de gran importancia resaltar los componentes del marco estándar de Scrum, los cuales son:

1. Roles: son todas las personas que ocupan un papel en el proceso con diferentes niveles de compromiso y responsabilidad.

Tabla 3. Roles. Fuente: elaboración propia.

2. Artefactos: son herramientas que flexibilizan la eficiencia del proceso de Scrum.

Tabla 4. Artefactos. Fuente: elaboración propia.

3. Eventos

Se detallan las tareas que constituyen la rutina de trabajo en Scrum.

Tabla 5. Eventos. Fuente: elaboración propia.

Para la implementación del marco ágil Scrum, se utilizaron distintas herramientas con la finalidad de llevar a cabo todas las mejoras en cada Sprint.

• Se ocupó Microsoft Teams para las reuniones (planificación, diaria, de revisión del Sprint, reunión de retrospectiva), lo que permitió la interacción correcta entre todas las personas involucradas en el proyecto.
• Se realizó un tablero Kanban, utilizando Miro® (pizarra online gratuita), una aplicación colaborativa para intercambiar ideas y ponerlas en acción de manera que la totalidad de integrantes puedan visualizar y/o actualizar de manera conjunta las tareas pendientes, en curso y terminadas.
• Se elaboró un diagrama Burn Down Chart, el cual muestra el rendimiento del equipo representando una serie temporal de trabajo pendiente para observar el avance diario de manera gráfica. El equipo lo actualiza durante el Sprint para monitorizar el ritmo de avance. En el eje Y se representan los puntos de trabajo que aún faltan por realizar; en el eje X se representan los días del Sprint.
• En el gráfico se encuentra el eje vertical que muestra la medida de trabajo pendiente que puede ser tareas, puntos de historia de usuario, entre otros; en la línea horizontal se ve la medida de tiempo (horas, días, minutos, semanas, etc.) y la línea de color rojo representa el progreso real en el tiempo⁷.

Enseguida se presenta la descripción del marco ágil que se elaboró para la reducción de tiempo en el proyecto Asismed Service:

Se hizo una reunión con el cliente con el propósito de definir la pila de producto para conocer los requisitos desde el punto de vista del cliente hacia la aplicación.

Luego de conocer la opinión del cliente se agendó una reunión con los Scrum Masters, el propietario del producto y el equipo desarrollador para definir los roles. Se estableció el objetivo de alcanzar los diferentes niveles de compromiso y responsabilidad entre las partes implicadas.

Tabla 6. Involucrados en el proyecto. Fuente: elaboración propia

Antes de la planeación del Sprint, el propietario del producto definió las historias de usuario junto con el Scrum Master, dando a conocer sus necesidades para, de esta manera, ayudar a priorizar las tareas a realizarse dentro del Sprint.

Se elaboraron las historias de usuario, el registro en donde se colocó un ID. Se descompusieron en tareas de menor tamaño, normalmente de un día de trabajo como máximo.

Figura 3. Historia de usuario. Fuente: elaboración propia.

Se hizo la pila del Sprint refinando la pila en donde el propietario del producto, junto con el equipo de trabajo, leyó cada historia de usuario; el propietario de producto se encargó de decidir cuáles son las historias de usuario con más prioridad, tomando en cuenta ahora la opinión del equipo, y se otorgó un intervalo de 0 a 100 para que las y los integrantes pudieran estimar la dificultad y/o trabajo necesario de cada historia de usuario. Esta actividad se realizó con la finalidad de agregar aspectos que se consideren importantes o hacer ajustes pertinentes (colocar requerimientos muy claros con más detalles). Esto se hizo con todas las historias de usuario.

Posteriormente inició el primer Sprint el 30 de septiembre 2020, con la finalidad de observar en cada reunión las mejoras que se podían hacer, esto permitió tener un mayor control de los resultados y, en consecuencia, un proyecto bien realizado, organizado y en un mínimo de tiempo.

Se hizo un acompañamiento al propietario del producto y al equipo desarrollador en la realización de los Sprints cada dos semanas, y se verificó que la asignación de avance en la gráfica fuera colocada correctamente.

Se recolectó información necesaria para el registro de datos sobre paciente, practicante y sus citas en la aplicación.

Organizar las tareas eficazmente a través de determinar la prioridad, de acuerdo con la necesidad de cada historia de usuario.

Tabla 7. Planeación del Sprint, primer Sprint. Fuente: elaboración propia.

Objetivo: Registrar las tareas para llevar un control de las mismas y se entreguen en tiempo y forma

A continuación se muestra el Sprint 1, formado por tres historias de usuario descompuestas en tareas previstas, la cual ayudará a estimar el tiempo de realización de cada uno.

Tabla 8. Sprint diario, primer Sprint. Fuente: elaboración propia.

El diagrama que se muestra a continuación permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado. En él se incluye la fecha, el avance esperado contra lo real. En este primer Sprint, desde el inicio de semana se finalizaron con las tareas de cada día, muy por debajo del tiempo esperado, es decir, se cumplieron con los puntos de historia de cada usuario en el tiempo ideal.

Figura 4. Burn Down Chart, primer Sprint. Fuente: elaboración propia.

El tablero Kanban implementado en el proyecto permite visualizar la gestión de las tareas a medida que fluyen, de manera que se evita la pérdida de tiempo entre el término de una tarea y el inicio de la siguiente, y se tiene claramente el orden de las tareas. En este primer Sprint hubo un avance, ya que solo quedaron dos actividades por hacer.

Figura 5. Kanban, primer Sprint. Fuente: elaboración propia.

Al término del Sprint debe realizarse la “Retrospectiva del Sprint”, la cual tiene por objetivo analizar aspectos operativos de la forma de trabajo del equipo y crea un plan de mejoras, para que se aplique en la siguiente iteración.

Tabla 9. Retrospectiva del Sprint, primer Sprint. Fuente: elaboración propia.

Cumpliendo con el marco planeado, en el segundo Sprint se tuvo por objetivo mejorar los procesos que intervienen en la aplicación. Su planeación incluía coordinar las tareas tomando en cuenta las mejoras previstas para un resultado optimizado. En este segundo Sprint hubo fluctuaciones en la realización de las actividades por terminar, ya que había tres por hacer y tres en curso.

Coordinar las tareas tomando en cuenta las mejoras previstas para un mejor resultado.

Tabla 10.Planeación del Sprint, segundo Sprint. Fuente: elaboración propia.

Objetivo: anotar las tareas llevando un control de las mismas. Se muestra el Sprint 2, formado por seis historias de usuario, que a su vez se subdividen en tareas previstas: esta subdivisión ayudó a estimar el tiempo de realización de cada uno.

Tabla 11. Sprint diario, segundo Sprint. Fuente: elaboración propia.

El diagrama, mostrado a continuación permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado. En él se incluye la fecha, el avance esperado contra lo real. En este segundo Sprint hubo días de la semana en donde las tareas resultaron ser no finalizadas en el tiempo esperado y subió por encima, pero al término de la última semana fue por debajo; se cumplieron con los puntos de historia de cada usuario en el tiempo ideal.

Figura 6. Burn Down Chart, segundo Sprint. Fuente: elaboración propia.

En este segundo Sprint hubo fluctuaciones en la realización de las tareas por terminar, ya que había tres por hacer y tres en cursos.

Figura 7. Kanban, segundo Sprint. Fuente: elaboración propia.

Se realizó el análisis del segundo Sprint, como se muestra en la tabla siguiente.

Tabla 12. Retrospectiva del Sprint, segundo Sprint. Fuente: elaboración propia.

En seguimiento al marco planeado, se originó un tercer Sprint, que tuvo por objetivo el desarrollo preliminar de la aplicación para su buen funcionamiento en cuanto a agendar cita y la notificación al usuario. En este tercer Sprint ocurrió un gran avance, solo una actividad por hacer y todas las demás finalizadas.

Organizar tareas para el diseño y prototipado de la aplicación corroborando el buen funcionamiento de la misma.

Tabla 13. Planeación del Sprint, tercer Sprint. Fuente: elaboración propia.

Objetivo: anotar las tareas, llevando un control de las mismas.

Se muestra el Sprint 3, formado por tres historias de usuario, que a su vez se subdividen en tareas previstas, esta subdivisión ayudó a estimar el tiempo de realización de cada uno.

Tabla 14. Sprint diario, tercer Sprint. Fuente: elaboración propia.

El diagrama, mostrado a continuación permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado. En él se incluye la fecha, el avance esperado contra lo real. En este tercer Sprint hubo solo un día donde subió por encima del tiempo esperado, sin embargo, durante el resto de esta iteración se mantuvo por debajo del tiempo y se cumplió con los puntos de historia de cada usuario en el tiempo ideal.

Figura 8. Burn Down Chart, tercer Sprint. Fuente: elaboración propia.

Figura 9. Kanban, tercer Sprint. Fuente: elaboración propia.

En este tercer Sprint ocurrió un gran avance: solo una actividad por hacer y las demás finalizadas.

Se realizó el análisis al finalizar el tercer Sprint: en este caso no hay próxima iteración, los resultados fueron los esperados, acorde al objetivo planeado.

Tabla 15. Retrospectiva del Sprint, tercer Sprint. Fuente: elaboración propia.

Dentro del análisis expuesto, tras la realización de las iteraciones, el equipo se dio cuenta de que el marco ágil de Scrum fue ejecutado de manera correcta con las herramientas utilizadas durante el proceso.

A continuación, se muestran gráficas que permiten ver los resultados en cuanto al tiempo esperado de gestión tradicional y Scrum master.

Figura 10 .Grafica gestión tradicional. Fuente: elaboración propia.

Figura 11. Scrum Master. Fuente: elaboración propia.

Las etapas de Scrum están diseñadas para una carga de trabajo, pero al mismo tiempo reducen plazos de entrega. La esencia de Scrum se encuentra en sus Sprints, es decir, en cada uno de ellos se desarrollan historias de usuarios (tareas) mismas que sirven para una entrega eficiente del proyecto principal. Se empieza con la planificación del Sprint, posteriormente el desarrollo para continuar con la revisión del Sprint y terminar con una retroalimentación, es adaptable a las circunstancias durante todo el desarrollo.

Mientras que la gestión tradicional es planeada de antemano, sin posibilidad de realizar cambios en los requerimientos y/o necesidades, este enfoque asume que el tiempo suele enfrentarse a cuestiones de demora en finalizar las tareas.

Es por ello, que se observó que Scrum es aplicable a cualquier equipo de personas, centrándose en ellas más que en los procesos para reducir el tiempo de entrega de un proyecto y así proporcionar un ritmo de trabajo continuo y evolutivo.

Tabla 16. Gestión tradicional vs Scrum Master. Fuente: elaboración propia.

Tras la realización de las iteraciones, el marco ágil Scrum fue ejecutado de manera correcta con las herramientas utilizadas durante el proceso.

De igual forma, la cantidad de puntos de historia donde el propietario del producto, sobre la base de su experiencia, asignó el estándar de 0 a 100 por actividad, en su mayoría se mantuvieron al margen de los puntos esperados a cumplir por tarea y coadyuvado en menor tiempo requerido, dependiendo del grado de dificultad. Se puede comprobar en la figura Burn Down Chart; este gráfico simplemente tiene como intención mostrar el avance del proyecto.

Otro aspecto a destacar es que se obtuvo la primera versión de la aplicación que satisface todas las pruebas de aceptación definidas.

Cabe mencionar que en el CCAI la duración de un proyecto es de mínimo seis meses, periodo en el que se deben cumplir al menos 20 horas a la semana. Dicho de otra manera, si el proyecto Asismed Service se hubiese hecho en el CCAI (planeación tradicional) se hubiera tardado al menos 6 meses en la entrega final del proyecto y con la utilización de Scrum master se redujo el tiempo a 4 meses. Con el marco ágil se logró entregar el proyecto Asismed Service antes del tiempo esperado, con los mínimos recursos posibles, se cumplió con el objetivo planteado; evidente mejora organizacional, se logró incrementar progresivamente el desempeño y eficiencia de los integrantes del equipo desarrollador.

Vistos los resultados, se sugiere la aplicación del marco ágil Scrum como propuesta para el Centro de Cooperación Académica e Industrial (CCAI) en la gestión de sus proyectos.

1. LARSON, Jean Ann. Organizational and Process Reengineering Approaches for Health Care Transformation. Boca Raton, FL, USA : CRC Press, 2016. 186 pp. ISBN 13: 978-1-4822-2516-7.
2. DUMAS, Marlon; LA ROSA, Marcello; MENDING, Jan y REIJERS, Hajo A. Fundamentals of Business Process Management. 2a ed. Berlin, Germany: Springer-Verlag GmbH. 2018. 546 pp. ISBN: 978-3-662-56509-4.
3. HAMMER, Michel and CHAMPY, James. Reingeniería. Bogotá, Colombia : Norma S.A., 1994. 226 pp. ISBN: 958-04-2650-3.
4. CICERO, Nuria. Guía práctica para empresarios y ejecutivos, Dirección de Proyectos. Barcelona, España. Harvard Business Review, 2017. 95 pp. ISBN: 978-84-16454-20-4.
5. TAKEUCHI, Hirotaka and NONAKA, Ikujiro. New New Product Development Game. Boston, USA. Harvard Business School Publication Corp, Jan/Feb1986, Vol. 64 Issue 1. pp. 137-146. ISSN: 0017-8012.
6. SCHWABER, Ken and SUTHERLAND, Jeff. La Guía de Scrum, La Guía Definitiva de Scrum: Las Reglas del Juego. Scrum guides. [En línea]. Noviembre 2020. [Fecha de consulta: 21 de enero de 2021]. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-European.pdf
7. PALACIO, Marta. Scrum Master Temario troncal 1 Versión 3.04. Scrum Manager. Iubaris Info 4 Media SL, 2020. 72 pp. Derechos registrados en Safe Creative. Nº de registro: 2006034305256.