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¹.

	¿Uso de Mejora Continua?	¿Uso de Reingeniería?
Suposición	El proceso es sólido El proceso es estable y puede ser fácilmente documentado	El proceso no es sólido u obsoleto El proceso no es estable
Estilo	Analítico	Sintético
Esencia	El proceso existe y su desempeño es correcto Ejemplo: el proceso actual está trabajando, pero solo necesita una pequeña mejora	El proceso no existe o es muy caótico: Nuevo proceso para soportar a un nuevo servicio en línea. Nuevo tipo de cliente o paciente que requiere un nuevo proceso.
Enfoque	Una mejora incremental le proporcionará el resultado que necesita.	Una mejora incremental no es suficiente.
Nivel	Los supuestos fundamentales sobre cómo se realiza el trabajo siguen siendo los mismos (micro)	Los supuestos fundamentales sobre cómo se realiza el trabajo han cambiado(macro) Nuevas regulaciones Nueva tecnología clínica Nuevo hallazgo de la ciencia médica
Cambio	Limitado	Holístico
Meta	De mejora	Deliberadamente desafiante o ambiciosa.
Disciplina	Ingeniería Industrial	Investigación y desarrollo-Innovación
Dominio	Necesidad de mejorar algunos procesos que no son los centrales del negocio.	Existe una necesidad para desarrollar o rediseñar los principales procesos centrales que afectan a una gran parte de la organización.
Rol ejecutivo	Necesita un Campeón ejecutivo (apoyo)	Necesita la aceptación de arriba hacia abajo de líderes clínicos y administrativos senior para que ocurra el cambio (liderazgo)
Alcance	Extendido	Concentrado en iniciativas estratégicas
Rol de TI	Incidental	Fundamental

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.

Factor	Uso de Reingeniería	Justificación
Esencia	Nuevo proceso para soportar a un nuevo servicio en línea.  Nuevo tipo de cliente o paciente que requiere un nuevo proceso.	Los proyectos de nuevos productos o servicios suelen ser muy especializados y particulares cada proyecto tiene distinta complejidad.
Enfoque	Una mejora incremental no es suficiente.	Tratar de cubrir las variantes y complejidad de cada proyecto con procesos estandarizados como la gestión tradicional no sería opción, se necesita un nuevo enfoque en la flexibilidad de los procesos.
Nivel	Los supuestos fundamentales sobre cómo se realiza el trabajo han cambiado (macro) Nuevas regulaciones Nueva tecnología clínica  Nuevo hallazgo de la ciencia médica	Cada proyecto lleva consigo normas particulares y así como tecnologías diferentes.
Cambio	Holístico	Es necesaria una interacción permanente entre todos los involucrados
Disciplina	Investigación y desarrollo-Innovación	El CCAI está orientado al desarrollo e Innovación en la región.
Dominio	Existe una necesidad para desarrollar o rediseñar los principales procesos centrales que afectan a una gran parte de la organización.	Es necesario hacer cambios radicales para atender o mejorar la demanda de servicios del CCAI.

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.

Personas involucradas	Compromiso
Equipo	Tiene espíritu de colaboración y un propósito común (responde en conjunto).
Propietario del producto	Persona responsable de lograr el mayor valor de producto para los clientes (Dueño del proyecto).
Scrum Master	Persona responsable del funcionamiento de las reglas de Scrum.

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

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

Concepto	Definición
Pila del producto	Registra y prioriza los requisitos desde el punto de vista del cliente. (Check list)
Pila del Sprint	Refleja los requisitos desde el punto de vista del equipo.
Incremento	Resultado de cada Sprint.

3. Eventos

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

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

Concepto	Definición
Sprint	Duración de cada tarea. (La duración no debe exceder de cuatro semanas).
Reunión de planificación del Sprint	Determina el objetivo-tarea necesario a conseguir. (Marca el inicio de cada Sprint 4 horas).
Scrum diario	Reunión diaria para confirmar avances de las tareas. (No dura más de 15 minutos).
Revisión del Sprint	Análisis e inspección del resultado generado del Sprint. (Puede durar una o dos horas como máximo cuatro horas).
Retrospectiva del Sprint	Reunión al finalizar el Sprint (analizar y crear plan de mejora para aplicarlo en la siguiente iteración).

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

Comprometidos
Propietario del producto	Paloma Rodríguez Cruz
Equipo de desarrollo	Alondra Diego Garduño, Sarahí Rosas Monroy y Héctor Martínez Rodríguez
Implicados
Otras partes interesadas	Zona rural de “Jocotitlán”
Scrum Master	Luis Fernando Alva Legorreta, Esmeralda Ángeles Cruz, Rocío Rubio Nieto y José Luis Soriano Ávila

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.

ID – Asismed_1	Nombre: Registro de pacientes
Descripción: Cómo [rol del usuario] ¿Quién? Quiero ¿Qué quiere? [objetivo] Para ¿Cuál es el beneficio? Condiciones: Estimación: (0-100)
Prioridad:

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.

Prioridad	Descripción	Estimación (Semanal)
		L	M	M	J	V	L	M	M	J	V
Muy alta	Registro de paciente
Alta	Registro de practicante
Media	Registro de citas

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.

Día	Categoría	Tareas	Responsable		Estimado (0-100)
Registro de paciente
Miércoles 30/09/2020	Registro	Especificaciones para el registro de pacientes		Ga. A	100
Jueves 01/10/2020	Registro	Avance del código para el registro del paciente		Mtz. H	93
Viernes 02/10/2020	Registro	Terminación del código para el registro del paciente		Mtz.H	86
Lunes 05/10/2020	Evaluación	Aprobación del código para el registro del paciente y a su vez se hablará sobre el registro de practicantes		R. S	64
Registro de practicante
Día	Categoría	Tareas	Responsable		Estimado (0-100)
Martes 06/10/2020	Registro	Ejecución del código para el registro de los practicantes	Mtz. H		57
Miércoles 07/10/2020	Registro	Terminación del código para el registro del practicante	Mtz. H		50
Jueves 08/10/2020	Evaluación	Aprobación del código para registro de practicantes	Ga. A		43
Registro de citas
Viernes 09/10/2020	Registro	Comienzo del código para el registro de la agenda	R. S		36
Lunes 12/10/2020	Registro	Comienzo del código para el registro de la agenda	Ga. A		14
Martes 13/10/2020	Diseño	Avance del diseño de la agenda.	R. S		7
Miércoles 14/10/2020	Diseño	Avance del diseño de la agenda.	R. S		0

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.

¿Qué salió bien en la iteración?	¿Qué no salió bien en la iteración?	¿Qué mejoras vamos a implementar en la próxima iteración?
El análisis de los requerimientos fueron los adecuados. Se pudo hacer en menor tiempo algunas actividades en proceso.	Los datos requeridos no son suficientes. El diseño es muy simple y no es atractivo para el público. El código de la agenda tuvo errores, por lo que no se cumplió al 100 %.	Crear pantalla de bienvenida (ventana de inicio), antecedentes de la empresa, teléfono de servicio al cliente, correo electrónico de la empresa. Añadir e investigar datos requeridos. Partir de lo general a lo particular. Verificar que los tiempos se planifiquen en horas y no en semanas.

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.

Prioridad	Descripción	Estimación (semanal)
		L	M	M	J	V	L	M	M	J	V
Muy alta	Actualización pila producto (iteración 1)
Muy alta	Registro de paciente
Muy alta	Registro de practicante
Alta	Registro de citas
Alta	Codificación de la política de privacidad
Media	Calificación y comentarios para el practicante
Media	Codificación del diseño de la aplicación

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.

Día	Categoría	Tareas	Responsable	Estima do (0-100)
Actualización pila producto (iteración 1)
Jueves 15/09/2020	Actualización de datos	Corroborar que los datos obtenidos sean los correctos y concisos (duda)	R.S	100
Registro de paciente
Viernes 16/09/2020	Registro	Terminación del código de la agenda	Mtz. H	100
Lunes 19/09/2020	Evaluación	Finalización del perfil del paciente	Ga. A	93
Registro del practicante
Martes 20/09/2020	Evaluación	Finalización del perfil del practicante	Ga. A	86
Miércoles 21/09/2020	Diseño	Rediseño de la agenda	Mtz. H	79
Jueves 22/09/2020	Evaluación	Culminación de codificación de la agenda	R.S	71
Codificación de la política de privacidad
Viernes 23/09/2020	Registro	Codificación de la política de privacidad	Ga. A	50
Lunes 26/09/2020	Evaluación	Verificación de la política de privacidad	Ga. A	43
Calificación y comentarios para el practicante
Martes 27/09/2020	Registro	Codificación de calificación y comentarios	R. S	36
Codificación del diseño de la aplicación
Miércoles 28/09/2020	Evaluación	Finalización de códigos para asignación de calificación y comentarios para practicante	Mtz. H	29
Jueves 29/09/2020	Diseño	Rediseño de la codificación de la aplicación	Mtz. H	21

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.

¿Qué salió bien en la iteración?	¿Qué no salió bien en la iteración?	¿Qué mejoras vamos a implementar en la próxima iteración?
El diseño de la aplicación es atractivo. Se especificaron los datos para obtener más información sobre los usuarios. Ya existe una base de datos para la agenda.	El código no genera notificaciones a pacientes ni practicantes ante una cita previa.	Revisión del código a profundidad.

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.

Prioridad	Descripción	Estimación (semanal)
		L	M	M	J	V	L	M	M	J	V
Muy alta	Notificaciones pacientes
Muy alta	Notificaciones practicantes
Alta	Plataforma digital
Alta	Subir aplicación a plataforma

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.

Día	Categoría	Tareas	Responsable	Estimado (0-100)
Perfil del paciente y practicante en la agenda

Viernes 30/09/2020	Registro	Terminación del código de la agenda	Mtz. H	100
Lunes 02/10/2020	Registro	Finalización del perfil del paciente	R. S	93
Martes 03/09/2020	Registro	Finalización del perfil del practicante	Ga. A	86
Miércoles 04/10/2020	Evaluación	Rediseño de la agenda	Mtz. H	79
Jueves 05/10/2020	Evaluación	Culminación de codificación de la agenda	Mtz. H	71
Política de privacidad

Viernes 06/10/2020

Registro

Codificación de la política de privacidad

R. S

50

Lunes 09/10/2020	Registro	Verificación de la política de privacidad	R. S	43
Calificación y comentarios

Martes 10/10/2020	Registro	Codificación de calificación y comentarios	Ga. A	36
Miércoles 11/10/2020	Diseño	Finalización de códigos para asignación de calificación y comentarios para practicante	Ga. A	29
Jueves 12/10/2020	Diseño	Rediseño de la codificación de la aplicación	Mtz. H	21
Viernes 13/10/2020	Diseño	Rediseño de la codificación de la aplicación	Mtz. H	0

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.

¿Qué salió bien en la iteración?	¿Qué no salió bien en la iteración?	¿Qué mejoras vamos a implementar en la próxima iteración?
El diseño de la aplicación es atractivo. Ya existe una base de datos para la agenda. El código no genera notificaciones a pacientes ni practicantes ante una cita previa.		No hay próxima iteración, se obtuvo lo que se esperaba en la primera versión de la aplicación médica.

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.

Gestión tradicional (4)		Scrum Master (7)
Pasos	Tiempo estimado	Pasos	Tiempo estimado
Planificación de tu proyecto	3 semanas	Roles	1 semana
Elaboración de tu proyecto	1 mes con una semana	Artefactos	1 mes
Administración del proyecto	3 meses con una semana	Eventos	2 meses con dos semanas
Llevar tu proyecto a una conclusión	3 semanas	Medición y estimación ágil	1 semana
Total	24 semanas	Total	16 semanas

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.