Cuando se resuelve un problema, hay que considerar el contexto, los elementos implicados y diferentes formas de resolverlos, de tal modo que se aprovechen las herramientas disponibles de la mejor manera para poder alcanzar el objetivo, la solución con la menor disrupción posible. Es decir, si es una situación del día a día, se busca hacerlo lo más rápido posible y usando los recursos de forma eficiente, mientras que, si es un problema más complejo, se tiende a planear para utilizar las herramientas más adecuadas según el tipo de problema.

De la misma forma, existen diferentes marcos de referencia ágiles que pueden ser utilizados en diferentes situaciones, dependiendo de lo que se quiera resolver, los cuales están diseñados para planear, gestionar y ejecutar el trabajo a desarrollar, no existiendo uno "mejor" que otro, ya que el mejor para la organización dependerá del tipo de industria, la madurez de la empresa, los equipos ágiles, los objetivos y la forma en la cual se implementa la agilidad organizacional. Por ello, en la siguiente experiencia de aprendizaje, revisarás diferentes marcos de referencia ágil, los cuales no son los únicos que existen, pero sí de los más utilizados.

XP

Extreme Programming (XP) es un marco de referencia agile que surge y es muy utilizado en desarrollo de software, el cual permite liberaciones frecuentes en sprints de desarrollos cortos que motivan al cambio cuando se requiere. Los valores esenciales de XP incluyen, de acuerdo con Berman (s.f.):

• Comunicación: la comunicación es importante para transferir el conocimiento entre un miembro del equipo y otro, entre las que destacan las discusiones cara a cara, apoyada de un pizarrón blanco u otro mecanismo para dibujar.
• Simplicidad: significa cuál es la forma más simple que funcionará. El propósito es evitar desperdicio y solo hacer las cosas necesarias para mantener el diseño tan simple como sea posible, para poder hacer sencilla el mantenimiento, soporte y revisión.
• Retroalimentación: ayuda a identificar áreas de mejora y revisar las prácticas a través de la retroalimentación continua, dando soporte al diseño simple.
• Coraje: acción efectiva para encarar el miedo, mostrando preferencia por otros principios para que los resultados no sean dañinos para el equipo. Por ello, se necesitará coraje para identificar las problemáticas organizacionales que reducen la efectividad del equipo.
• Respeto: debe darse entre los integrantes del equipo para comunicarse entre ellos, proporcionar y aceptar retroalimentación que ayuden a la relación.

Este marco de referencia aplica cuando:

• Los requerimientos de software cambian dinámicamente.
• Los riesgos causados por proyectos de tiempo fijo requieren nueva tecnología.
• Se requieren equipos de desarrollo pequeños y colocados.
• La tecnología permite unidades y pruebas funcionales automatizadas.

El ciclo de XP incluye los elementos mostrados en la figura 1.

Figura 1. Marco de referencia XP.

Fuente: SlideTeam. (2022). Agile methods it projects extreme programming XP in agile framework. Recuperado de https://www.slideteam.net/agile-methods-it-projects-extreme-programming-xp-in-agile-framework.html
Digité. (2022a). ¿Qué es la programación extrema (XP) y sus valores, principios y prácticas? Recuperado de https://www.digite.com/es/agile/programacion-extrema-xp/

El desarrollo de la figura 1 muestra un ciclo, a través del cual se desarrollan unidades de prueba, cada etapa ivvncluye:

• Planeación: etapa en la cual se desarrolla la estrategia de iteración para las user stories con los valores, pruebas de aprobación y requerimientos de aceptación.
• Diseño: se utilizan tarjetas CRC (clase, responsabilidad y colaboración), las cuales son usadas en lluvia de ideas para la colaboración del equipo, con interfaces simples, así como prototipos de soluciones spike -es una user story que se genera cuando el equipo no puede estimar el esfuerzo requerido-, por lo que se diseña un sprint de investigación, de tal forma que, a través de la exploración se aprende sobre las soluciones posibles (Onuta, 2019).
• Codificación: iteración en la que ocurre la programación o desarrollo del trabajo, también incluye refabricación cuando se identifican nuevos elementos, requerimientos o historias de usuario que deben ser incluidas. Se ejecuta de forma pareada, es decir, dos personas se encargan de la codificación, enfocándose una de ellas al código y la otra al aseguramiento de la calidad (QA) y cuando la que codifica se cansa, se intercambian las funciones, de tal forma que se tenga una integración continua de las unidades de prueba.
• Prueba: pruebas de aceptación para determinar si el desarrollo cumple con las características solicitadas por el cliente, identificando y corrigiendo posibles bugs en el código. Este tipo de pruebas son para obtener la aprobación del cliente.
• Liberación: ya que el cliente aprueba el incremento, se libera, obteniendo así un incremento de software. Una vez terminado, se recalcula la velocidad del proyecto con base en el desempeño del sprint y se vuelve a iniciar el ciclo a partir de la planeación.

Scrum

Es de los marcos de referencia más conocidos que existen para equipos ágiles, el cual puede ser utilizado para resolver problemas adaptativos complejos, mientras se producen y entregan productos del más alto valor de forma creativa (Berman, s.f.). La palabra Scrum no tiene traducción, pero hace alusión a una formación de jugadores utilizada en rugby para reiniciar el juego, en la cual el equipo se mueve hacia adelante con los brazos entrelazados y la cabeza abajo, empujando hacia adelante a un grupo similar del equipo opuesto con el objetivo de tomar posesión del balón, el cual es arrojado al Scrum. Los valores de Scrum están basados en el manifiesto agile y son (Peek, 2022):

• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación excesiva.
• Colaboración con el cliente sobre negociación contractual.
• Respuesta al cambio sobre seguir el plan.

Scrum puede ser utilizado en casos donde se requiere (Thompson, s.f.):

• Un producto final con alto valor.
• Éxito definido por la respuesta a las solicitudes de los clientes.
• Los requerimientos cambian frecuentemente, mes con mes.
• El trabajo requiere invención constante y las estimaciones no son confiable.
• Existe un proceso cíclico, el cual se repite con cada sprint (periodo en el cual se genera el valor o se desarrollan las user stories) y la planeación con los sprints siguientes se empalman con el trabajo actual.
• No hay pasos que involucren tiempos largos o lotes de recursos especializados.
• Los resultados incrementales tienen valor significativo.

Figura 2. Marco de referencia Scrum.

Fuente: Scrum Alliance. (s.f.). Quick Guide to Scrum. Recuperado de https://www.scrumalliance.org/about-scrum

De manera general, los ciclos Scrum de la figura 2 se llevan a cabo a través de los eventos siguientes (Kneafsey, s.f.):

• Sprint planning: es el evento que marca el inicio de cada sprint, en el cual el product owner y desarrolladores discuten cuáles elementos del product backlog (PBI) serán incluidos en el sprint.
• Daily scrum: reunión diaria de 15 minutos, la cual no es obligatoria, en el cual se tiene la oportunidad de revisar el progreso contra las metas. Las preguntas para responder por parte del equipo de desarrollo son ¿Qué hice ayer? ¿Qué haré hoy? ¿Qué me detiene para continuar? En paralelo a estas actividades se llevan a cabo las ejecuciones del sprint o iteraciones.
• Sprint review: evento en el cual el product owner revisa que los requerimientos del cliente fueron satisfechos y se alcanzaron las metas del sprint a través del producto mínimo viable (MVP). En este evento cada miembro del equipo tiene la oportunidad de mostrar el incremento terminado (done) a los interesados e inspeccionar las características.
• Sprint retrospective: la retrospectiva es un evento final de retroalimentación hacia el equipo, en el cual se evalúa qué se hizo bien y se debería continuar haciendo, qué salió mal y se debería dejar de hacer, y qué no se hizo y se debería comenzar a hacer.

Kanban

Kanban es un marco de referencia ágil que surge a partir de la mejora continua, el cual es flexible en la gestión de tareas y flujo de trabajo, de tal forma que el progreso del proyecto completo sea entendido fácilmente de un vistazo. Kanban significa tarjeta, y todo gira en torno al tablero Kanban, el cual permite visualizar el proyecto completo para monitorear el flujo de este (Kissflow Inc., s.f.).

Kanban tiene su base sobre un sistema de tipo pull (jalar), el cual controla el flujo de trabajo reemplazando lo que ya se completó, enfocándose en dividir el trabajo en pequeñas tareas, visualizarlos y obtener los elementos más pequeños en un estado de trabajo dado. Kanban es muy simple y puede ser utilizado en cualquier trabajo que requiera conocimiento, aplicándose a situaciones donde el trabajo llega de forma impredecible pero que se tiene que desplegar tan pronto como esté terminado.

El tablero de Kanban utiliza las columnas que aparecen en la figura 3, en la cual se indica (Kissflow Inc., s.f.):

• Por hacer (to-do): tareas que se harán en el futuro.
• En proceso (doing): tareas que se están ejecutando.
• Hecho (done): tareas completadas.

Figura 3. Tablero Kanban.

Fuente: Kissflow Inc. (s.f.). Kanban Methodology: The Simplest Agile Framework. Recuperado de https://kissflow.com/project/agile/kanban-methodology/
Ojukwu, G., (2020). The Kanban Methodology and why you need it for your Software Team. Recuperado de https://community.atlassian.com/t5/Jira-Software-articles/The-Kanban-Methodology-and-why-you-need-it-for-your-Software/ba-p/1553608

Los componentes básicos de Kanban son los siguientes (Ojukwu, 2020):

• Señal visual: hace que los miembros fácilmente puedan visualizar y comprender el estatus de cada tarea.
• Columnas: cada columna representa un flujo de trabajo con tareas o tickets. La forma más básica es la mostrada en la figura 3, pero pueden adaptarse a tantos estados como se requieran por el equipo, por ejemplo: backlog, listo para desarrollar, en progreso, en revisión de código, en pruebas, verificado, hecho.
• Límites del trabajo en proceso (WIP): permite a los equipos establecer el WIP, el cual es usado para evitar cuellos de botella y sobrecarga de los miembros del equipo.
• Punto de compromiso: siempre hay un backlog desde donde se mantienen y se toman las ideas para ejecución. Este punto representa el momento exacto cuando la idea es tomada del backlog y el equipo comienza a trabajar en la misma.
• Punto de entrega: los miembros del equipo siempre tienen que recordar que la meta del equipo es conseguir el trabajo hecho (done) y minimizar el lead time (tiempo desde que se mueve la tarea del to-do hasta el done).

AUP/RUP

El Proceso Unificado Ágil (AUP) es una versión del RUP simplificada, basada en técnicas ágiles como Desarrollos Basados en Pruebas (TDD), Desarrollo Dirigido por Modelos (MDD) y gestión del software; mientras que, el Proceso Unificado de Rational (RUP) es un marco de referencia que usa prácticas de gestión de proyectos con iteraciones graduales, siguiendo ciclos de cuatro fases, guiándose por casos de uso, centrado en la arquitectura, incremental, paralelo, basado en riesgos, orientado a objetos, y que comienzan con funcionalidades generales para terminar con las específicas (Alhir, s.f.; Ferretti, 2021).

AUP surge de los elementos de agilidad como el valor, la cultura, estrategia y la ejecución, así como también se basa en principios como los que se mencionan a continuación (Alhir, s.f.):

• Los desarrolladores saben lo que hacen, por lo que no necesitan documentación excesiva.
• Facilidad de descripción, con pocas instrucciones en lugar de manuales.
• La aceleración es el principio básico.
• Enfoque en actividades importantes.
• Independencia de herramientas.
• Adaptabilidad del modelo a las necesidades de desarrollo.

Figura 4. Iteraciones/fases de AUP.

Fuente: Ferretti, A. (2021). A guide to Agile project management types. Recuperado de https://www.ariadgroup.com/es/blog/todo-sobre-scrum-agile-metodologia/tipos-gestion-proyectos-agile

AUP está compuesto con siete disciplinas: modelo, implementación, prueba, despliegue, gestión de la configuración, gestión de proyectos y ambiente, las cuales interactúan con las cuatro iteraciones de los procesos AUP que aparecen en la figura 4 y son adaptables, pero en general se enfocan en (Alhir, s.f.):

• Lanzamiento: obtención del alcance inicial del proyecto, arquitectura potencial del sistema, y la obtención del fondo inicial del proyecto y aceptación de los interesados.
• Diseño: proveer la arquitectura del sistema.
• Realización: construir software funcionando, en bases regulares e incrementales que satisfagan las necesidades con prioridades más altas de los interesados.
• Entrega: validar y desplegar el sistema en ambientes productivos.

Las disciplinas que se emplean de forma iterativa para definir las actividades que debe ejecutar el equipo de desarrollo para construir, validar y entregar software funcionando que satisfaga las necesidades de los interesados son (Alhir, s.f.):

• Modelo: entender el negocio y la organización, el dominio del problema a resolver e identificar la solución viable.
• Implementación: transformar los modelos en código ejecutable y desarrollar un nivel básico de prueba, en unidades de prueba particulares.
• Prueba: desarrollo de evaluación objetiva para asegurar la calidad.
• Despliegue: plan de entrega del sistema y ejecución del plan para dejarlo disponible.
• Gestión de la configuración: gestión de acceso a los artefactos.
• Gestión de proyectos: gestión de riesgos, y gestión y coordinación de personas para asegurar el tiempo y presupuesto.
• Ambiente: soporte al resto del esfuerzo para asegurar procesos adecuados, guía, y herramientas disponibles para el equipo de desarrollo.

En lugar de utilizar un enfoque de grandes desarrollos, a través de este enfoque se busca la liberación de pequeñas porciones en producción, de tal forma que poco a poco se vaya obteniendo la solución completa.

Lead FDD, DSDM

El Desarrollo Basado en Funcionalidades (FDD) fue introducido como práctica de desarrollo de software, basado en mejores prácticas de ingeniería como modelación de objeto dominio, desarrollo por características y código propietario. Se divide en cinco etapas iterativas, las cuales aparecen en la figura 5 (DELOS SANTOS, 2022).

Figura 5. Etapas iterativas de FDD.

Fuente: Ferretti, A. (2021). A guide to Agile project management types. Recuperado de https://www.ariadgroup.com/es/blog/todo-sobre-scrum-agile-metodologia/tipos-gestion-proyectos-agile

Cada una de las etapas consisten en (Digité, 2022b):

• Desarrollar un modelo global: construcción de diagramas de clase para describir los objetos del dominio y sus relaciones, reduciendo tiempo al ayudar a descubrir qué función agregar a qué característica.
• Construir una lista de funcionalidades: si una función no puede ser implementada dentro de un plazo de dos semanas, se divide en partes más pequeñas, características manejables.
• Planear por funciones: determinar las funcionalidades más urgentes, las que entregan valor más pronto, y estimar los tiempos, dependencias técnicas, riesgos, personas disponibles, cargas de trabajo, etc., las cuales servirán para priorizar.
• Diseñar por funciones: diseño de las características asignadas a los miembros del equipo en cada iteración.
• Construir por funciones: convertir cada característica en software funcional, probarlo y obtener retroalimentación de los expertos para verificar que funcione como debería.

El Método de Desarrollo de Sistemas Dinámicos (DSDM) es un marco de referencia que reúne las mejores prácticas bajo ocho principios que ayudan a dirigir al equipo y crear una mentalidad para la entrega a tiempo y dentro del presupuesto (DELOS SANTOS, 2022). Es un enfoque genérico de gestión de proyectos ágiles, con la diferencia de que hereda el rol de director de proyectos y lo considera compatible con otros enfoques de proyectos, tal como Prince2 y el PMI (agility.im, s.f.).

Como principios base, tiene los siguientes (Agility.im, s.f.; DELOS SANTOS, 2022):

• Enfoque en las necesidades del negocio: Todas las decisiones estarán basadas en este.
• Entrega en tiempo: el factor más crítico es la entrega a tiempo.
• Colaboración: los equipos siempre colaboran para obtener resultados sobresalientes.
• Nunca se compromete la calidad: la calidad del sistema debe ser la mínima.
• Construcción incremental desde las bases: desarrollar análisis y diseños anticipados.
• Desarrollo iterativo: al final de cada iteración, revisar y recibir retroalimentación.
• Comunicación continua y clara: mantener una comunicación activa.
• Demostración de control: gestión proactiva de los planes.

El DSDM es un enfoque basado en procesos, el cual busca enfocarse desde el inicio en el negocio, utilizando un enfoque exploratorio para poder cumplir con los requerimientos del negocio y generar el valor esperado.

Figura 6. Etapas iterativas de FDD.

Fuente: agility.im. (s.f.). What is DSDM Atern? Recuperado de https://agility.im/frequent-agile-question/what-is-dsdm-atern/

Las etapas del proceso de la figura 6 son (agility.im, s.f.):

• Preproyecto: enfocada en ayudar al inicio correcto del proyecto, previniendo un inicio pobre. Se identifican alternativas de proyectos candidatos, estimando los recursos para el proyecto.
• Factibilidad: evalúa que el proyecto sea técnicamente factible, y el caso de negocio sea viable.
• Fundamentación: el equipo pasa algunas semanas estableciendo el motivo y necesidades que cubre el negocio, la solución técnica y el enfoque.
• Exploración: ayuda a refinar las necesidades del cliente y a identificar las soluciones técnicas adecuadas.
• Desarrollo evolutivo: el equipo construye incrementos de características priorizadas en iteraciones del sistema.
• Despliegue: se implementa el sistema para uso operativo.
• Postproyecto: se cuantifican los beneficios del proyecto entregado.

SCRUM+XP+Kanban

Marco de referencia ágil que combina las prácticas de Scrum, XP y Kanban, para generar el mayor valor posible. La combinación de Scrum y Kanban normalmente es conocida como Scrumban, la cual es desarrollada para facilitar a los equipos Scrum la transición a Kanban y la exploración hacia enfoques esbeltos (GERMANOV, 2022).

La principal diferencia con los enfoques originales son que Scrumban tiene las siguientes características (GERMANOV, 2022):

• Utiliza iteraciones más cortas que los sprints de Scrum.
• Las tareas no están asignadas.
• Se establecen los límites del trabajo a realizar (WIPL).
• La magnitud de las iteraciones son medidas en semanas (se recomienda un máximo de 2 semanas).
• La planeación es basada en la demanda, no cada determinado tiempo.
• El disparador de la planeación son las actividades restantes por hacer.
• Utiliza un tablero basado en tiempo basado en cubos (buckets), los cuales son de tareas (3 meses), requerimientos (seis meses) e ideas (1 año).

En el caso de XP, la combinación trae como diferencias las siguientes características, con respecto a las originales (Giriraj, 2020; Scaled Agile, 2022):

• Dentro del Sprint existe una codificación propietaria colectiva.
• Se incluye la programación o trabajo en parejas.
• Integración continua a través de la inspección.
• Refabricación para lograr la adaptación.
• Pequeñas liberaciones.
• Desarrollo basado en pruebas y pruebas del cliente.
• Los roles cambian, para adaptarse al marco de XP, que pueda ser combinado con Scrum.

Al combinar los tres marcos se tendrían los beneficios de las combinaciones híbridas mencionadas.

A lo largo de esta experiencia se revisaron de manera general las familias de enfoques ágiles que son más comunes, pero todos ellas tienen la misma base; se basan en valores comunes y tienen el mismo objetivo: generar valor al cliente a través del desarrollo de un producto que pueda ser utilizado al momento de la liberación.

Así, existen diferentes formas de ejecutar las actividades, siendo la mejor aquella que más se adapte a las condiciones del negocio, del nivel de preparación del equipo, del contexto organizacional, y de la forma de trabajo de los integrantes del equipo de desarrollo, de tal forma que al alinearlos se pueda generar el valor buscado sin impactar la calidad debido a desconocimiento o a curva de aprendizaje.

Además, como se revisó al final, cada una de las prácticas puede ser incorporada con otras, generando así los marcos de referencia ágiles; aunque algunos de ellos son más aplicados en entornos de desarrollo de software, no quiere decir que solo se puedan aplicar en dicha industria, sino que también pueden adaptarse y ejecutarse en entornos de negocio diferentes, para mejorar procesos, crear un producto y/o servicio, es decir, que ayude al logro de los objetivos buscados.

Asegúrate de:

• Conocer los marcos de referencia agile y su enfoque a la mejora continua, adaptación y generación de valor.
• Analizar los marcos de referencia Scrum, XP, Kanban, DSDM, FDD y sus características particulares.
• Analizar la utilidad de mezclar marcos de trabajo para poder obtener mayor valor, a través de la combinación de las mejores prácticas.
• Recordar que el mejor marco de referencia agile es aquel que se adapta a los requerimientos del negocio.
• Considerar que los marcos de trabajo necesitan adaptarse a los requerimientos del proyecto para poder ejecutarlos adecuadamente y generar el valor esperado.

Los siguientes enlaces son externos a la Universidad Tecmilenio, al acceder a ellos considera que debes apegarte a sus términos y condiciones.

Videos

Para conocer más acerca de Familias ágiles, te sugerimos revisar lo siguiente:

• AddKw. (2019, 17 de febrero). Marco de trabajo Ágil para la gestión de Proyectos: Scrum [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=QF5_RgOIpQQ
• CertCampus. (2021, 2 de noviembre). Enfoques Híbridos Para Gestión de Proyectos [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=VqNi72pjh3s
• Jaime Arcos. (2021, 4 de mayo). Marcos ágiles: Kanban y Modern agile [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=jAnE0MffRg4

Lecturas

Para conocer más acerca de Familias ágiles, te sugerimos leer lo siguiente:

• Asana. (2022). ¿Cuál es la Diferencia entre Waterfall, Agile, Kanban y Scrum? Recuperado de https://asana.com/es/resources/waterfall-agile-kanban-scrum
• Deloitte. (s.f.). Frameworks Agile, ¿cuál se adapta mejor a mi compañía? Recuperado de https://www2.deloitte.com/es/es/pages/technology/articles/frameworks-agile.html
• López, M. (2020). Scrum y Extreme Programming, no se trata de cuál, se trata de cómo. Recuperado de https://openwebinars.net/blog/scrum-y-extreme-programming-no-se-trata-de-cual-se-trata-de-como/

• agility.im. (s.f.). What is DSDM Atern? Recuperado de https://agility.im/frequent-agile-question/what-is-dsdm-atern/
• Alhir, S. (s.f.). The Agile Unified Process (AUP). Recuperado de https://www.methodsandtools.com/archive/archive.php?id=21
• Berman, J. (s.f.). AGILE FRAMEWORKS. Recuperado de https://www.planview.com/resources/guide/what-is-agile-program-management/agile-frameworks/
• DELOS SANTOS, J. (2022). XP, FDD, DSDM, and Crystal Methods of Agile Development. Project Management. Recuperado de https://project-management.com/xp-fdd-dsdm-and-crystal-methods-of-agile-development/
• Digité. (2022a). ¿Qué es la programación extrema (XP) y sus valores, principios y prácticas? Recuperado de https://www.digite.com/es/agile/programacion-extrema-xp/
• Digité. (2022b). Feature Driven Development: Evolution vs Revolution. Recuperado de https://www.digite.com/agile/feature-driven-development-fdd/
• Ferretti, A. (2021). A guide to Agile project management types. Recuperado de https://www.ariadgroup.com/es/blog/todo-sobre-scrum-agile-metodologia/tipos-gestion-proyectos-agile
• GERMANOV, I. (2022). What is Scrumban? [The Scrumban Guide In 2022]. Recuperado de https://ora.pm/blog/scrumban/
• Giriraj, R. (2020). Scrum and Extreme Programming (XP) – a perfect hybrid model for software development projects. Recuperado de https://www.linkedin.com/pulse/scrum-extreme-programming-xp-perfect-hybrid-model-raghavan/
• Kissflow Inc. (s.f.). Kanban Methodology: The Simplest Agile Framework. Recuperado de https://kissflow.com/project/agile/kanban-methodology/
• Kneafsey, S. (s.f.). The Five Scrum Events. Recuperado de https://www.thescrummaster.co.uk/scrum/the-five-scrum-events/
• Ojukwu, G., (2020). The Kanban Methodology and why you need it for your Software Team. Recuperado de https://community.atlassian.com/t5/Jira-Software-articles/The-Kanban-Methodology-and-why-you-need-it-for-your-Software/ba-p/1553608
• Onuta, A. (2019). How Agile Spikes help to improve your Agile Product Delivery? Recuperado de https://ancaonuta.medium.com/how-spikes-help-to-improve-your-agile-product-delivery-a0f104305911
• Peek, S. (2022). What is Agile Scrum Methodology? Recuperado de https://www.businessnewsdaily.com/4987-what-is-agile-scrum-methodology.html
• Scaled Agile. (2022). SAFe ScrumXP. Recuperado de https://www.scaledagileframework.com/scrumxp/
• Scrum Alliance. (s.f.). Quick Guide to Scrum. Recuperado de https://www.scrumalliance.org/about-scrum
• SlideTeam. (2022). Agile methods it projects extreme programming XP in agile framework. Recuperado de https://www.slideteam.net/agile-methods-it-projects-extreme-programming-xp-in-agile-framework.html
• Thompson, K., (s.f.). When to Use Scrum. Recuperado de https://www.cprime.com/blog/2012/09/17/when-to-use-scrum/