Why and How Is Scrum Being Adapted in - En.es

Traducido del inglés al español - www.onlinedoctranslator.
com
Por qué y cómo se está adaptando Scrum

en la práctica: una revisión sistemática
Aceptado en Journal of Systems and Software
Michal Hron
Universidad de Aarhus
Fuglesangs Allé 4
8210 Aarhus V, Dinamarca
hron@mgmt.au.dk
Twitter: @michalhron
Nicolás Obwegeser
Universidad de Ciencias Aplicadas de Berna,
Brückenstr. 73,
3005 Berna, Suiza
nikolaus.obwegeser@bfh.ch
Twitter: @nikolaus_ob
Por qué y cómo se está adaptando Scrum
en la práctica: una revisión sistemática
Aceptado en Journal of Systems and Software
Resumen
Scrum, reconocida hoy como la metodología de desarrollo ágil más popular, se ha utilizado en una amplia gama de
configuraciones y para diferentes propósitos, dentro y fuera del contexto tradicional de desarrollo de software. El uso de Scrum
en entornos no tradicionales y para diferentes necesidades dio lugar a un corpus considerable de literatura académica que investiga,
presenta y discute modificaciones al método original, destinadas a adaptarlo a estas nuevas formas de aplicación.
Basado en una revisión a gran escala de la literatura existente, este estudio analiza sistemáticamente por qué y cómo se creó Scrum.
según se informa modificado en diferentes instancias y contribuye con una síntesis que puede servir como base para una
enfoque sistemático para la investigación y la práctica futuras. Explicamos nueve objetivos comunes de modificación para el cambio.
(p. ej., lograr un alto rendimiento, contextos no estándar, desarrollo distribuido) mapeado contra siete genéricos
estrategias de modificación (p. ej., guía de métodos, nuevos procedimientos o artefactos). Sobre la base de nuestra extensa literatura
análisis destacamos las brechas de investigación e identificamos áreas prometedoras para futuras investigaciones.
Palabras clave:Scrum, desarrollo ágil, revisión sistemática de literatura, desarrollo de sistemas de información
1. Introducción
Dos décadas después de la publicación del Manifiesto de desarrollo de software ágil (Kent Beck et al., 2001), ágil
Las metodologías han ganado una amplia aceptación (Dingsør et al., 2012), y Scrum se ha convertido en la más popular.
método de la familia ágil (VersionOne, 2020). El diseño original de Scrum se adapta mejor a los pequeños, ubicados en el mismo lugar
grupos de desarrolladores con diversas habilidades, trabajando en software para un cliente que participa activamente en el desarrollo
(Schwaber, 1995). A pesar de eso, debido a "su simplicidad percibida y enfoque 'ligero'" (Masood et al.,
2020, pág. 1), Scrum ha sido adoptado hoy por una variedad de instituciones en una variedad de contextos, que van desde la gestión
fuera de la ingeniería de software hasta la gestión de empresas enteras (Cloke, 2007; Greening, 2010). muchos de esos
circunstancias requieren adaptaciones o aumentos de diferentes aspectos del método, lo que condujo a una sustancial y
creciente cuerpo de estudios de investigación que discuten modificaciones a Scrum (Diebold et al., 2015; Forbes Insights & Scrum
Alianza, 2018).
Si bien esta atracción generalizada de Scrum a diferentes contextos fuera del dominio de la ingeniería de software puede ser
considerado un éxito y una confirmación para los desarrolladores del método, también dio lugar a una gran variedad de diferentes
adaptaciones (Brian Fitzgerald et al., 2002). La personalización y la adaptación de métodos son comunes y bien reconocidas.
fenómeno dentro del dominio de la ingeniería de software debido a la complejidad y contingencias de diferentes situaciones del mundo real.
los contextos difícilmente pueden reflejarse en un enfoque metodológico unificado (Goldkuhl & Karlsson, 2020). Sin embargo, algo de Scrum
Los evangelistas abogan firmemente por seguir las prácticas descritas “por el libro” para evitar introducir el mismo
ineficiencias y elementos disfuncionales que uno se propuso eliminar al introducir Scrum en primer lugar
(Schwaber, 2007).
Podría decirse que la motivación para adaptar un método a un contexto específico es aún más acentuada cuando se sale de su
disciplina prevista originalmente, es decir, fuera del dominio de la ingeniería de software. Sin embargo, en detrimento de la acumulación
construcción de conocimiento, dichas modificaciones se han informado en gran medida de manera fragmentada con un enfoque en el individuo
estudios de casos empíricos. Muchos resultados de investigación se presentan en conferencias regionales y no se han
asimilado hacia un cuerpo unificado de conocimiento. Subconjuntos de esta literatura, típicamente correspondientes a un aspecto específico
(es decir, desarrollo distribuido), han sido revisados en estudios anteriores (B. Kitchenham et al., 2010). Sin embargo, un
mapeo completo de la literatura sobre la adaptación de Scrum que mapearía las razones depor quéEsta siendo
modificado contracómose ha modificado, no se ha realizado. Esto viene a expensas de futuros investigadores,
buscando construir sobre hallazgos previos en lugar de repetir lo que otros ya estudiaron y practicantes que se beneficiarían
de orientación informada para apoyar sus necesidades específicas del contexto. Reunir el por qué y el cómo del contexto.
Por lo tanto, las adaptaciones de métodos específicos son importantes para permitir tanto el aprendizaje efectivo de los resultados anteriores como una
enfoque hacia futuras investigaciones.
Este estudio tiene como objetivo abordar esta brecha de investigación mediante la síntesis de la investigación existente sobre las modificaciones propuestas para
Melé. Realizamos una revisión sistemática de la literatura (SLR) a gran escala de casos documentados en la literatura académica.
para lograr eso. Nuestro estudio está guiado y estructurado por la siguiente pregunta de investigación:Por quéycómoes scrum
adaptado a diferentes contextos?
El documento primero analiza trabajos relacionados antes de presentar brevemente al lector las propiedades básicas del original.
Método Scrum. Después de delinear la metodología de investigación en la Sección 4, discutimos los resultados de nuestra revisión de la literatura.
y presentamos los resultados descriptivos que describen la forma general de la literatura en la Sección 5. En la Sección 6, sintetizamos
conocimiento existente extrayendo y mapeando siete estrategias de modificación contra nueve objetivos de modificación
reportado en la literatura académica. El artículo concluye con una interpretación y discusión de los hallazgos con
énfasis en posibles áreas de investigación futuras, así como en las implicaciones para los profesionales.
2 trabajos relacionados
La literatura primaria que mapea los ajustes a los métodos ágiles ha sido resumida regularmente por una serie de
revisiones sistemáticas. Tanto es así que se encuentra disponible una revisión de dichas revisiones (Hoda et al., 2017). Algunas reseñas del documento
la difusión del propio paradigma (Dingsør et al., 2012) o diversos usos que van desde la ingeniería de software global
(Dreesen et al., 2016) a la adaptación de métodos ágiles para cumplir con estándares como CMMI (Palomino et al., 2017).
Este documento contribuye a la literatura sobre desarrollo ágil y Scrum al proporcionar una descripción general exhaustiva de los
adaptaciones reportadas con énfasis en el enfoque metodológico utilizado.
Nuestro trabajo difiere de otras revisiones recientes sobre el desarrollo ágil de software en dos aspectos principales. Nos enfocamos en un
metodología específica (Scrum) en lugar de métodos ágiles en su conjunto, y nuestro objetivo era evaluar y revisar de manera inclusiva
todos los estudios potencialmente relevantes, incluidos los diseños de estudios tanto empíricos como conceptuales/teóricos, en lugar de utilizar
criterios estrictos de corte en nuestra estrategia de búsqueda. En cuanto al enfoque en un solo método, se puede observar que la mayoría
Las revisiones señalan una situación de desarrollo específica y luego examinan toda la gama de métodos de desarrollo ágil.
sobre este tema. Los ejemplos recientes incluyen ingeniería de sistemas globales (Hossain et al., 2009; Jalali & Wohlin, 2010) o
prácticas centradas en el usuario (Duechting et al., 2007). Seguimos el enfoque opuesto: nos enfocamos en un método específico
y las circunstancias exploradas en las que se ha introducido, y cómo. En relación con nuestra estrategia de filtro y búsqueda,
encuentran que, si bien estudios anteriores han abordado preguntas de investigación similares a las nuestras (Ashraf & Aftab, 2017; Diebold
et al., 2015), sus metodologías difieren notablemente de nuestro estudio en términos de confiar en un muestreo no sistemático de
literatura o generalizando a partir de una pequeña muestra de profesionales. Trabajos relacionados se encuentran en informes de la industria (Forbes
Alianza Insights & Scrum, 2018; Versión Uno, 2020). Si bien esos informes generalmente brindan datos sobre
métodos, no son metodológicamente transparentes y carecen de detalle en sus resultados.
Este documento amplía un documento de una conferencia anterior que analiza los resultados preliminares del mismo proyecto de investigación (Hron
& Obwegeser, 2018). Participamos en un proceso más amplio de búsqueda y filtro de literatura, incluidas más bases de datos académicas.
(tres en lugar de uno) y sin filtrado basado en el número de citas o el año de publicación. En consecuencia, nuestra muestra
aumentó de 31 a 925 estudios, apoyando un análisis y una discusión sustancialmente más profundos del fenómeno de
Adaptaciones Scrum.
3 Una breve revisión de Scrum

Scrum fue propuesto originalmente por Schwaber (1997) como una metodología de desarrollo simple que incorpora iterativo
y principios de desarrollo incremental. Comprende las llamadas ceremonias (también conocidas como rituales o procedimientos),
artefactos y roles. Como metodología de uso activo, sus creadores la actualizan periódicamente. El más reciente
La versión oficial de la Guía Scrum se lanzó en noviembre de 2020 (Schwaber & Sutherland, 2020). el melé
Primer proporciona una descripción general alternativa concisa del método (Deemer et al., 2012).
El desarrollo bajo Scrum se divide en los llamados sprints, que suelen durar entre dos y cuatro semanas. pique
La planificación ocurre al comienzo de cada sprint y se utiliza para definir qué se puede entregar en el próximo sprint y qué
hay que hacer para lograrlo. Al final de cada sprint, se lleva a cabo una retrospectiva del sprint para apoyar el aprendizaje continuo
y mejora en el equipo. Además, se lleva a cabo una revisión del sprint para demostrar el resultado del sprint al
cliente y recopilar comentarios e información relevante para el próximo incremento de trabajo. Scrum pone peso en
autonomía del desarrollador pero no a expensas de la disciplina. Los desarrolladores comienzan sus días de trabajo con reuniones de pie
para actualizarse mutuamente sobre el progreso y las tareas por delante. En el espíritu de autoorganización, en lugar de ser liderado por un proyecto
gerente, un equipo Scrum es facilitado por un Scrum Master. El principal punto de contacto es el propietario del producto, quien también
gestiona la acumulación de trabajo a realizar. En el desarrollo exitoso de Scrum, el cliente participa regularmente
aportando ideas para nuevas funciones (que se registran como historias de usuario y se mantienen en un registro pendiente) y firmando
en funciones completadas al final de cada sprint. Por último, Scrum ofrece herramientas para realizar un seguimiento de la productividad del equipo mediante
medir la velocidad de la tarea que se puede trazar en el llamado gráfico de quemado. El equipo estima cuánto tiempo lleva
las tareas de desarrollo particulares serán (expresadas en puntos de la historia) y el trabajo de autoasignación para un sprint determinado. El número
de elementos pendientes, expresados en puntos de la historia, realizado a lo largo del tiempo nos da una medida de la productividad o "velocidad" del equipo
en la jerga de Scrum. Medir la velocidad no solo motiva a los equipos al ver su productividad y progreso en la quema.
gráfico descendente, pero también ayuda a planificar el trabajo futuro.
Scrum fue desarrollado para pequeños equipos ubicados en el mismo lugar de diversas especializaciones (Schwaber, 1995) y, como muchos otros
métodos ágiles de desarrollo—se basa en ciertos supuestos (Ramesh et al., 2017; Turk et al., 2005). Esto incluye,
por ejemplo, la suposición de disponibilidad del cliente para interacciones frecuentes, que puede ser difícil de lograr
en la práctica.
4 Método de investigación
El objetivo de este estudio es comprender por qué y cómo se modificó Scrum, según lo informado en la literatura académica.
El desarrollo ágil con Scrum ha sido objeto de un número creciente de estudios académicos y, por lo tanto, un
se requiere una revisión sistemática que permita identificar, sistematizar y evaluar las contribuciones existentes (BA
Kitchenham, 2007).
Debido a la variedad de aplicaciones de Scrum dentro y fuera de la ingeniería de software, las preguntas de investigación requieren
una revisión inherentemente transdisciplinaria que se extiende a través de varias corrientes de literatura, por ejemplo, ingeniería de software, informática
ciencia, sistemas de información, gestión (Besson & Rowe, 2012).
Para garantizar la transparencia y replicabilidad de nuestro proceso de búsqueda, filtrado y análisis, optamos por seguir un proceso sistemático
enfoque de alcance y revisar la literatura existente (Paré et al., 2015; Webster & Watson, 2002) en conjunto con
recomendaciones específicas para realizar revisiones sistemáticas de la literatura (SLR) en el dominio de la ingeniería de software (B.
A. Kitchenham, 2007). La Figura 1 ofrece una descripción general de nuestro diseño de investigación que comprende búsqueda bibliográfica, filtro, codificación,
y análisis.
consultas de base de datos Filtración Codificación y Análisis
Alcance: 1.762 Proyección de títulos: 1.423 • Objetivo de modificación

IEEE explorar: 571 estudios restantes • Estrategia de modificación
WoS: 812 • Tipo de papel
Proyección de resúmenes: 925 • Enfoque empírico
Después de eliminar los duplicados: estudios restantes • Agregación y
2.209 estudios únicos síntesis de códigos
FIGURA1: ESTRATEGIA DE BÚSQUEDA Y ANÁLISIS DE LITERATURA PASO A PASO
4.1 Consultas a la base de datos

La muestra de literatura se recopiló mediante una consulta estructurada de tres bases de datos académicas importantes. Debido a la
naturaleza interdisciplinaria de nuestro estudio, optamos por buscar literatura relevante tanto en bases de datos amplias que cubran un
amplia gama de diferentes disciplinas y bases de datos específicas que se centran en la investigación de ingeniería de software. Para tal fin,
Las bases de datos Scopus y Web of Science fueron seleccionadas como bases de datos de propósito general con amplia cobertura. Además,
Se consultó IEEE Explore como una base de datos específica de dominio que también brinda una mayor cobertura de conferencias.
La consulta se desarrolló a lo largo de múltiples iteraciones de exploración de diferentes estrategias de búsqueda y discusión posterior.
entre los autores. La cadena de consulta final especifica el método en cuestión (Scrum) y un conjunto de términos que
operacionalizar nuestro enfoque en los cambios al método Scrum. Optamos por incluir un diccionario de sinónimos para especificar el
aspecto de cambio, que puede representarse como positivo (p. ej., mejorar, realzar), negativo (p. ej., límite, inconveniente),
o términos neutrales (por ejemplo, modificar, cambiar). Por último, utilizamos una cláusula de exclusión para la literatura deportiva utilizando los mismos términos
(es decir, Scrum como parte del juego de Rugby). En consecuencia, nuestra cadena de búsqueda de Scopus se proporcionó de la siguiente manera: TÍTULO-
ABS-KEY ("Scrum") Y TODOS ("software" Y "ágil") Y TODOS ([términos positivos] O [términos negativos] O
[términos neutros]) Y NO TODOS (“rugby” Y “deporte”). Siempre que fue posible, usamos el marcador de posición "*" para permitir
para variaciones de palabras. Se desarrollaron consultas analógicas para las otras dos bases de datos. Una lista completa de nuestra búsqueda.
Los términos y el diccionario de sinónimos se pueden encontrar en la Tabla 1.
TPODER1 SCONSULTA DE BÚSQUEDA ESTRUCTURADA

Términos positivos Términos negativos Términos neutrales Especificadores de temas
extender* límite* pedir* Melé,

acomodar* retirarse* requisito* software,
mejorar* defecto* necesitar* ágil,
adaptar* tema traje* excluyendo el rugby,
ensanchar* reto* modificación* excluyendo el deporte
enfoque* Abajo* alterar*

mejorar* reducir* adaptar*
expandir* revisión*
chang*, sastre*, scop*
La consulta ejecutada a mediados de agosto de 2020 arrojó 3145 documentos desde 2002, que formaron la base de nuestra estrategia de tres pasos.
proceso de cribado y filtrado.
Fusionamos los resultados de las tres bases de datos primero haciendo coincidir el título y luego mediante la verificación manual. Scopus
proporcionó la mayor cantidad de artículos, por lo que verificamos los duplicados con los resultados de la consulta de Scopus. Con
cada uno de los artículos restantes, realizamos una verificación manual de duplicados. Aunque la misma organización
podría haber sido estudiado más de una vez, múltiples estudios informaron sobre diferentes subconjuntos de la organización. Para
ejemplo, yahoo! se usó como caso en un estudio sobre la integración del marco del proceso (Scotland & Boutin, 2008) y cómo
para abordar el desarrollo distribuido (S. Lee & Yong, 2010).
Por el contrario, tratamos los estudios que informaban sobre casos múltiples como un solo registro, ya que nos enfocamos en lo que los autores
considerada la alteración más significativa de Scrum. Esta es una preocupación menor ya que solo el 8% de nuestra muestra presentó
múltiples casos. La muestra inicial tras la eliminación de duplicados estaba formada por 2.209 artículos que posteriormente fueron
sujeto a selección de títulos y resúmenes.
4.2 Filtrado
Para llevar a cabo el proceso de selección, definimos un conjunto claro de criterios que se aplicarán en el proceso. Primero examinamos todos
artículos por títulos que indicaban modificaciones de Scrum y solo se eliminaban los que se centraban en otros temas. si en
duda, el artículo fue incluido para una posterior selección de resúmenes.
4.2.1 Selección de títulos

Participamos en un proceso de codificación de verificación, en el que ambos autores revisaron los títulos de los mismos 100 artículos por separado para
fortalecer la confiabilidad del proceso de codificación (Knudsen, 1975). Se midió el grado de fiabilidad entre revisores
usando kappa de Cohen (ϰ) (Spitzer et al., 1967), resultando ϰ = 0,96, lo que indica un alto grado de acuerdo entre
los autores. El kappa de Cohen se calculó de la siguiente manera:
miCUACIÓN1KCOEFICIENTE APPA
Pr(a) – Pr(e) 0,98 – 0,50

ϰ= = = 0,96
1 − Pr(e) 1 − 0,50
Pr(a) es el acuerdo relativo observado entre los investigadores, y Pr(e) es la probabilidad hipotética del azar
convenio.
Después de establecer claridad y acuerdo sobre los criterios de selección, dividimos los trabajos restantes entre ambos
autores y continuó examinando los títulos por relevancia por separado. De los 2209 artículos iniciales, encontramos 1423 como
potencialmente relevante basándose únicamente en los títulos.
4.2.2 Selección de resúmenes

Examinamos por separado los resúmenes de los artículos restantes (después de intercambiar los conjuntos de artículos para revisar) de acuerdo con
los mismos criterios. Esto redujo nuestra muestra a 1.054. Algunos trabajos fueron eliminados en la selección de texto completo (incluyendo
revisiones bibliográficas previas), dando como resultado una muestra final de 925 publicaciones. Los trabajos se incluyeron si cumplían
dos condiciones obligatorias:
Condición 1: el artículo introduce una modificación o extensión de la metodología Scrum
Condición 2: el documento establece una razón o motivación para introducir dicho cambio
Si bien el cuerpo de este artículo presenta una gran cantidad de artículos en la muestra final, los criterios de inclusión se explican mejor
presentando ejemplos que fueron excluidos. Por ejemplo, la primera condición no se cumplió en una encuesta que pretende
estudiar los efectos de Scrum en la productividad sin modificarla (Hanslo et al., 2020). La segunda condición no era
cumplida, por ejemplo, por un estudio de caso de Moe & Aurum (2008), que deriva varios consejos para la toma de decisiones
toma de decisiones en Scrum, pero está impulsado por un objetivo de comprender la toma de decisiones en los equipos Scrum y no por un deseo
modificar Scrum motivado por un objetivo explícito.
De acuerdo con las condiciones obligatorias para la inclusión descritas anteriormente, generalmente excluimos trabajos sobre aprender cómo
usar Scrum (es decir, el proceso de adopción del método), así como artículos que investigaron cómo enseñar Scrum en
universidades, si no describieron también modificaciones al método (p. ej., Santos et al. 2015). También ignoramos
artículos sobre la dinámica (psicológica o sociológica) de los equipos Scrum, que ofrecían descripciones académicas de
fenómenos como la madurez del equipo pero poco potencial prescriptivo para modificaciones reales del método (por ejemplo, Hasnain
y Hall 2009).
4.3 Codificación y análisis

Teniendo en cuenta nuestras preguntas de investigación, el objetivo principal de nuestros esfuerzos de codificación fue extraer categorías a lo largo de dos principales
dimensiones de cada papel en la muestra final:por quése pretendía una modificación, es decir, el objetivo de la modificación, y
cómoScrum debía ser modificado, es decir, la estrategia de modificación. Para garantizar un enfoque sistemático, nuestra codificación y
Los esfuerzos de análisis se inspiraron en la literatura de métodos relevantes sobre la síntesis de la literatura anterior (Cruzes & Dybå,
2011). El proceso de codificación fue realizado por ambos autores de manera similar al proceso de selección y filtrado. Primero,
codificamos un conjunto de los mismos 50 artículos por separado, desarrollando inductivamente y extrayendo categorías de codificación. Para
Por ejemplo, varios artículos motivaron la adaptación de su método al enfatizar la necesidad de control gerencial y
incorporar el proceso de desarrollo de software en la estrategia general de la organización, que codificamos como "Gerencial".
Extensión". De manera similar, en términos de estrategias de modificación, encontramos que muchos artículos se centraron en explicar cómo
usar y aplicar correctamente el método Scrum; así creamos la estrategia de modificación “Method Guidance”.
TPODER2CCATEGORÍAS DE OD
Categoría de codificación Rango de valores
Motivación primaria
Inductivo
Motivación Secundaria
Solución primaria Inductivo
Empírico Binario: si o no
Estudio de caso único, estudio de caso múltiple, experimento, propuesta
Método
conceptual, simulación, basado en encuestas
Marco teórico Teoría o modelo aplicado a la investigación marco
Recuento de citas Citas de Google Scholar

Evaluación de la calidad Evaluación de la calidad (rango de 1 a 5)
Después de la codificación inicial, comparamos y consolidamos las categorías de codificación hasta llegar a un acuerdo.
Posteriormente, codificamos otro conjunto de 50 artículos por separado, teniendo en cuenta los códigos preliminares ya establecidos.
pero también agregando nuevos códigos cuando sea necesario. Por ejemplo, inicialmente se usó una categoría para "Documentación", pero
posteriormente se fusionó con “Performance” o “Managerial Extensions” como el número de artículos dedicados a
las prácticas de documentación de software no saturaron una categoría a la par de los otros grupos. Posteriormente, volvemos a
comparó y consolidó nuestros códigos antes de dividir los artículos restantes entre los autores y codificarlos por separado.
Por último, comparamos y discutimos nuestro conjunto completo de códigos para llegar a un acuerdo sobre el esquema de categorización final.
Como nuestras principales dimensiones analíticas, codificamos para el objetivo de modificación (primario y secundario) y la modificación
estrategia (primaria y secundaria). El objetivo principal se refiere a la meta principal establecida en el estudio que desencadenó el
adaptación del método, mientras que los objetivos secundarios también se codificaron cuando se mencionaron. Por ejemplo, Vlietland & Van
Vliet (2015) motivan su estudio por la necesidad de escalar Scrum a múltiples equipos en entornos empresariales y abordar la
extensiones gerenciales necesarias para gobernar la colaboración entre equipos. Del mismo modo, la estrategia de modificación primaria
se refiere al principal enfoque de adaptación utilizado, que en algunos casos estuvo acompañado de una estrategia secundaria. Para
ejemplo, De Melo et al., (2019) proponen una adaptación de Scrum para pequeñas empresas que se basa en la introducción de
un nuevo artefacto (una heurística basada en puntos) pero también describen nuevas herramientas (basadas en la técnica del Balanced Scorecard). Nosotros
también codificado para varios elementos descriptivos en nuestra muestra (ver Tabla 2). Categorizar el enfoque metodológico
de artículos en nuestra muestra, distinguimos entre estudios de casos (únicos, múltiples), experimentos, propuestas conceptuales
(es decir, desarrollos teóricos con ninguna validación empírica o limitada), simulaciones y estudios basados en encuestas.
Inspirándonos en (Dikert et al., 2016), también evaluamos y codificamos la calidad de los artículos en una escala del 1 al 5, con
la puntuación más baja se aplicó a estudios con objetivos de investigación poco claros, fallas aparentes o en procedimientos metodológicos transparentes.
sección y la puntuación más alta para los artículos que están bien anclados en la literatura anterior, lo que identifica una clara brecha de investigación y
objetivo, aplicando un método sistemático y riguroso y reflexionando críticamente sobre sus hallazgos. Sin embargo, decidimos
no usar la dimensión de calidad como un criterio de corte o filtro para garantizar que nuestra muestra represente la amplitud total de la
panorama actual de la investigación.
5 resultados
En nuestro período de muestra, observamos un volumen de producción académica en constante aumento, lo que sugiere un interés creciente en la
tema. La Figura 2 visualiza el crecimiento de la investigación académica relevante desde 2002, indicando tanto el número de
estudios por año, así como el crecimiento acumulado de citas totales en el período de muestreo. Debido a las diferencias
en el recuento de citas en las diversas bases de datos, optamos por utilizar una única fuente para las citas, Google Scholar, independientemente
de qué base de datos se encontró originalmente el documento. Según se informa, Google Scholar proporciona resultados de citas más precisos
que Scopus o Web of Science, especialmente para Ciencias Sociales, Artes y Humanidades e Ingeniería por ser mejor
cobertura de libros, actas de congresos y una gama más amplia de revistas (Harzing & van der Wal, 2008).
FIGURA2: PAGPUBLICACIONES Y CITAS A LO LARGO DEL TIEMPO
En cuanto a los medios de publicación, observamos que, en promedio, alrededor del 80 % de los trabajos se presentaron en congresos,
evidenciando aún más el pragmatismo del campo. La mayoría de los estudios residen en la cola larga de la distribución: más
Se publicaron 200 trabajos en actas de congresos, coloquios o talleres, donde cada evento generó
uno o dos trabajos en nuestra muestra. Entre los medios más utilizados se encuentran las series de actas de conferencias como
de springerApuntes de clase en informática(46) yApuntes de clase en el procesamiento de información empresarial(44), como
así como revistas comoTecnología de la información y el software(11) y elRevista de Sistemas y Software(11).

TPODER3MÉTODOS, qCALIDADATASACIONES,YmiEJEMPLOS
Múltiple Conceptual Único

Método Experimento Simulación Encuesta
Caso Propuesta Caso
Empírico 1 1 0 0 1 1
Calidad 3.00 3.15 2.51 2.85 2.58 2.66
media (St. dev) (1.01) (0.89) (1.17) (1.46) (1.01) (2.20)
(Rahmán (Griffith (Gary y (Lehnen
Ejemplo (Harvie y (Kettunen,
et al., et al., et al.,
Aga, 2016)
Alabama.,
2009)
2018) 2014) 2011) 2016)
Contar
36 86 227 11 477 88
Desde una perspectiva metodológica, la mayor parte de nuestra muestra siguió un diseño de estudio de caso único (477). Aparte
de eso, también contamos experimentos (36), estudios de casos múltiples (86), experimentos (36 estudios), propuestas conceptuales
(227), simulaciones (11) y estudios basados en encuestas (88).
Independientemente de su enfoque metodológico, encontramos que menos del 10 por ciento de los estudios en nuestra muestra contienen una
sustento teórico explícito; es decir, tienen una descripción dedicada de una lente teórica o incrustan su investigación
en estudios y teorías relacionadas. Los principios del Manifiesto para el desarrollo ágil de software, el marco CMMI,
o los principios de seguridad del software 4 +1 (Doss & Kelly, 2016a), a veces se mencionan, en lugar de un
teoría (Conboy, 2009; G. Lee & Xia, 2010). Excepciones notables a la mayoría de estudios de "teoría ligera" en nuestra muestra
incluir, por ejemplo, un estudio que explore la agilidad como aprendizaje organizacional (Lyytinen & Rose, 2006) u otro
discutiendo los "patrones básicos" de los enfoques ágiles (Greening, 2016).
La Tabla 3 acompaña el análisis con información empírica, evaluación de la calidad que va de uno (peor) a cinco
(mejor), y ejemplos (Tabla 3).
Confiando en Google Scholar como una fuente estandarizada de citas en todas las bases de datos, calculamos las citas promedio por
año para cada papel. Eso significa que para un artículo de 2010, dividimos el número total de citas entre diez porque
se publicó hace diez años. Este ajuste permite comparar documentos nuevos y antiguos.
Descubrimos que el artículo promedio obtiene solo 2,51 citas por año con una desviación estándar de 4,50. Menor
se pueden encontrar variaciones entre los diferentes enfoques metodológicos (ver Figura 3). Las publicaciones de la conferencia son
citado menos (1,96 citas por año, St. dev = 2,93) que las publicaciones en revistas (4,36 citas por año, St. dev = 7,40).
10.0
Promedio de citas de Google por año

7.5
5.0
2.5
0.0
caso múltiple
caso único
experimento
simulación
propuesta
encuesta
FIGURA3: unPROMEDIOGRAMOOOGLESCITAS ACADÉMICAS DE ESTUDIOS A TRAVÉS DE ENFOQUES METODOLÓGICOS
6 Modificación de objetivos y estrategias

Nuestra investigación identificó nueve objetivos de modificación genéricos y siete estrategias de modificación comunes. Antes
discutiendo cada objetivo de modificación y las estrategias asociadas en detalle en la Sección 5.2, presentamos brevemente los principales
categorías para guiar al lector a través de nuestros hallazgos.
En respuesta a la pregunta:¿Por qué Scrum está siendo modificado?? Nuestra revisión identificó nueve objetivos genéricos de modificación.
El más común era un simple deseo de alcanzar una altaActuación, típicamente en línea con la gestión de proyectos
tríada (mayor calidad, menor costo, menor tiempo). El segundo más común fue el objetivo de acomodar un
específicoContexto. Otros documentos abordaron la necesidad de combinar Scrum con otro marco. Nosotros etiquetamos tal
modificación de objetivosYuxtaposición.Arquitecturase refiere a estudios en los que el objetivo declarado era especificar
resultados de desarrollo de nivel en planes de lanzamiento, especificaciones técnicas o similares.desarrollo distribuidosubsume
todos los esfuerzos dirigidos a usar Scrum en configuraciones no ubicadas pero distribuidas geográficamente. El objetivo deUsuario
Experienciacaptura aquellos esfuerzos que enfatizaron específicamente el papel de la experiencia del usuario al motivar a sus
adaptaciones de métodos. Extensiones gerencialesse refieren a la vinculación del proceso de desarrollo de software con el negocio
estrategia de las organizaciones. Estudios que se centraron en hacer que Scrum funcione para proyectos a gran escala que superarían
el entorno tradicional de Scrum se capturan en la categoríaEscalado de tamaño.Finalmente, algunos estudios motivan su
adaptaciones a Scrum a través de una mayor demanda deSeguridad,es decir, restricciones regulatorias o específicas de la industria o
demandas.
En respuesta a la pregunta:¿Cómo se está modificando Scrum?Hemos derivado siete estrategias de modificación comunes
de nuestra muestra.Guía de métodosincluye apelaciones a "aplicaciones por el libro" del método seleccionado, o
recordatorios de los principios del Manifiesto para el desarrollo ágil de software. Por ejemplo, Eloranta et al. (2016) identifican un
conjunto de prácticas Scrum dañinas y proponer estrategias de mitigación. Los consejos específicos pueden referirse al stand-up diario.
reunión (Dick, 2016; Stray et al., 2013) o equipos distribuidos (Lous et al., 2017).Procedimientosreferirse a la introducción de la novela
actividades en el método que pueden ser recurrentes (por ejemplo, pruebas; Tuomikoski y Tervonen, 2009) o realizadas en un
una sola vez (p. ej., durante el traspaso; Anwar et al., 2014).Infusióndescribe una reconsideración en profundidad de múltiples
elementos de Scrum, que se basa en otros procesos/métodos existentes como CMMI (Jakobsen & Johnson,
2008; Sutherland et al., 2007), Lean (Sikamani & Raj Dharmapal, 2016; X. Wang et al., 2012) o se hace para abordar
nuevos contextos, como el desarrollo de nuevos productos (Cooper & Sommer, 2016b; Lehnen et al., 2016).InstrumentosReferirse a
propuestas de herramientas que no modifican Scrum directamente pero ayudan a realizar una determinada tarea. Estas herramientas a menudo se pueden ver
como una forma de "complemento" del método original que se puede aplicar sin cambiar directamente el método en su funcionamiento.
Las nuevas métricas son ejemplos típicos de esta categoría, ya que son pequeñas adiciones que pueden enriquecer Scrum sin
cambiando significativamente el método (Greening, 2015; Padmini et al., 2015).Artefactosincluir la presentación de novedades o
artefactos alterados para Scrum, por ejemplo, el uso de pantallas digitales para equipos coubicados (Schwarzer et al., 2016) o distribuidos
(Esbensen et al., 2015).Pre-desarrollose refiere a la introducción de procesos adicionales, artefactos y, a veces,
roles que se ocupan específicamente de tareas como la definición de la arquitectura técnica, la articulación de una visión del producto o
crear hitos para el desarrollo, antes de que se inicie el desarrollo mismo. Se pueden adoptar múltiples perspectivas.
en la formulación de modificaciones previas al desarrollo. Los diseñadores a veces piden personas para comprender la tarea en cuestión.
(Sedeño et al., 2017); la gestión puede preocuparse por la planificación de la liberación (Heikkilä et al., 2015). Técnico
Es posible que sea necesario incluir requisitos, que a menudo son difíciles de abordar bajo el paradigma ágil (Bourimi &
Tesorero, 2014).Multiplicidaddescribe la multiplicación de un artefacto, un rol o todo el equipo. Esto solo fue codificado
cuando se introdujo explícitamente como una nueva enmienda. La multiplicidad del equipo está inevitablemente presente bajo
circunstancias de desarrollos distribuidos o a gran escala (Paasivaara & Lassenius, 2011). Los equipos pueden multiplicarse
según especialización: ej., equipo de diseño y equipo de desarrollo (Ferreira et al., 2011). la multiplicacion de
los artefactos pueden referirse a un backlog separado, dedicado solo a las pruebas (Aamir & Khan, 2017).
La Tabla 4 proporciona una descripción completa de los objetivos de modificación (filas) mapeados frente a las estrategias de modificación.
(columnas), incluido el número de documentos en los que se invocaron las estrategias de modificación dadas en respuesta a
cuyo objetivo de modificación. El sombreado de cada celda corresponde al número que muestra, es decir, sombreados más oscuros
indican un mayor número de estudios para una combinación específica de objetivo y estrategia. En las siguientes subsecciones,
presentaremos cada objetivo de modificación siguiendo un enfoque estructurado. Primero describiremos la categoría.
pertenecientes a nuestro contexto de investigación y luego discutir las estrategias de modificación más comunes y ejemplos comunes
como se indica en las tablas de resumen al comienzo de cada subsección. Finalmente, señalaremos la literatura dedicada o
revisiones que se centran en este aspecto particular de Scrum o prácticas de desarrollo de software ágil relacionadas.
TPODER4 norteNÚMERO DE TRABAJOS PARA OBJETIVOS DE MODIFICACIÓN Y ESTRATEGIA DE MODIFICACIÓN
Modificación metodológico Método Pre-

Procedimientos Infusión Artefactos Multiplicidad Totales
Guía desarrollo
Instrumentos
Objetivo Acercarse
no empírico 7 22 3 22 4 0 0
Actuación 237
Empírico 58 64 4 38 13 2 0
no empírico 6 13 20 1 0 0 0
Contexto 173
Empírico 54 22 48 1 5 1 2
no empírico 7 7 3 7 4 8 1
Arquitectura 115
Empírico 8 30 5 11 7 17 0
no empírico 8 0 26 0 0 0 1
Yuxtaposición 90
Empírico 7 2 43 1 2 0 0
Repartido no empírico 43 12 4 5 4 0 7
87
Desarrollo
Empírico 7 2 1 2 0 0 0
Gerencial no empírico 2 7 0 11 1 0 1
66
Extensiones Empírico 8 dieciséis 7 6 4 0 3
Usuario no empírico 0 8 2 1 1 0 0
sesenta y cinco
Experiencia
Empírico 12 dieciséis 8 1 3 9 4
Escala de tamaño 53
Empírico 20 14 4 0 1 0 10
Seguridad 39
Empírico 6 6 4 1 2 0 2
Totales 260 248 185 112 51 37 32 925
6.1 Rendimiento
Estrategia de modificación Uso primario uso secundario Ejemplo de uso principal
Guía de métodos sesenta y cinco 43 (Eloranta et al., 2016)
Procedimientos 86 33 (Tuomikoski y Tervonen, 2009)
Infusión 7 2 (Alqudah y Razali, 2018)
Instrumentos 60 20 (Kayes et al., 2016)
Artefactos 17 5 (Rubart y Freykamp, 2009)
Pre-desarrollo 2 2 (M.Ali et al., 2016)
Multiplicidad 0 2
TPODER5PPRIMARIA Y SECUNDARIAMETROODIFICACIÓNSESTRATEGIAS PARAPAGSRENDIMIENTO
El objetivo más frecuente de la modificación de Scrum es alcanzar un alto rendimiento bajo desarrollo estándar.
circunstancias (coubicación, con un equipo pequeño) o con una desviación limitada de dicho entorno. El objetivo es entregar
resultados en línea con la lógica de la tríada de gestión de proyectos (tiempo, calidad, costo). El rendimiento es una categoría amplia
que alberga numerosos enfoques, típicamente derivados de la práctica, que no necesariamente resultan en cambios estructurales profundos
al método. Más bien, estos documentos codifican con frecuencia alteraciones y adiciones menores, a menudo encontradas a través del uso y
experimentación.
Las estrategias de modificación más comunes son propuestas de nuevos procedimientos, que a menudo se combinan con métodos.
La orientación como estrategia de modificación secundaria. Los artículos también proponen el desarrollo de herramientas con procedimientos como
estrategias de modificación secundaria y guía de métodos. Por ejemplo, un documento propone un proceso novedoso para probar
(Tuomikoski y Tervonen, 2009). Otros estudios desarrollan métricas para priorizar los elementos del backlog (Kayes et al., 2016)
o herramientas para medidas alternativas de progreso (Miranda & Bourque, 2010). Un ejemplo típico del uso del método
la orientación como estrategia para mejorar el desempeño es Eloranta et al. (2016), en el que los autores identifican 14 anti-
patrones y proporcionar orientación sobre cómo abordarlos. Los artefactos son menos comunes para lograr un rendimiento general
mejoras, pero un ejemplo de un "tablero de trabajo cooperativo flexible" para mejorar las reuniones diarias ilustra cómo
se puede utilizar (Rubart & Freykamp, 2009). En algunos casos, se buscan mejoras en el rendimiento mediante un replanteamiento a gran escala de
Scrum (Alqudah & Razali, 2018). Se proponen algunos procedimientos recurrentes previos al desarrollo, por ejemplo, para evitar
riesgos
Los objetivos secundarios de modificación al Desempeño más frecuentes se encuentran en las Extensiones Gerenciales y
categoría de Arquitectura relacionada. Esto sugiere el deseo de los practicantes de imbuir Scrum con más rigidez para una mayor
actuación.
La atención prestada a esta categoría habla muy bien de la calidad del método Scrum original. Es lo suficientemente robusto para
se ajustan a una variedad de contextos y están diseñados para abordar un problema duradero. La prevalencia de los informes de orientación sobre métodos es
indicativo de la naturaleza práctica del campo.
6.2 Contexto
Guía de métodos 60 50 (Heeager & Rose, 2015)
Procedimientos 35 19 (Wagner, 2014)
Infusión 68 8 (Cooper y Sommer, 2016a)
Instrumentos 2 1 (Mendonça, Letícia Thaís, 2014)
Artefactos (Streule, Miserini, Bartlomé,
5 8
Klippel y De Soto, 2016)
Pre-desarrollo 1 2 (Hanschke et al., 2015)
Multiplicidad 2 2 (Aamir & Khan, 2017)
TPODER6PPRIMARIA Y SECUNDARIAMETROODIFICACIÓNSESTRATEGIAS PARACTEXTO
El segundo objetivo de modificación más común para modificar Scrum está conectado a contextos de desarrollo específicos que
Se introduce Scrum. Scrum ofrece un enfoque notablemente simple para trabajar, y se puede transponer a una serie de
diferentes configuraciones. Algunos de los contextos encontrados incluyen entornos regulados (Cawley et al., 2010),
operaciones de mantenimiento (Heeager & Rose, 2015) y proyectos de almacenamiento de datos (Goede, 2011). fuera de la
dominio de desarrollo de software, Scrum es visto como un método prometedor para la gestión de la innovación (Cooper & Sommer,
2016a). También se reporta su uso en la industria de la construcción (Streule, Miserini, Bartlomé, Klippel, & de Soto,
2016) o producción de cine animado (Sharma & Wherry, 2009).
Los contextos enumerados incluyen el desarrollo de software, pero también aplicaciones muy alejadas del contexto del software.
en total. El contexto puede motivar cambios, pero puede inspirar cómo se deben implementar esos cambios. mientras que
Es ampliamente reconocido que la contextualización juega un papel importante en la práctica de métodos ágiles (Brian Fitzgerald et al.,
2002; MacCormack & Verganti, 2003), el objetivo de los artículos de este grupo no es realmente reconocer la fungibilidad
del método tanto como para documentar un catálogo de modificaciones listas para usar que se ajustan a circunstancias particulares
como los enumerados anteriormente.
La estrategia de modificación genérica Infusión se usa aquí para denotar Scrum marcadamente alterado con elementos novedosos, y
Scrum imbuido de elementos de contextos específicos (Cooper & Sommer, 2016a). La guía de métodos es frecuentemente
invocado para abordar las consideraciones prácticas derivadas de la transposición de Scrum a un nuevo entorno (Heeager
& Rosa, 2015). También se ofrece como una estrategia de modificación secundaria que acompaña a la infusión o los procedimientos. Menor-
las alteraciones de escala en Scrum suelen agregar Procedimientos (Wagner, 2014). Los nuevos artefactos son raros (Streule, Miserini,
Bartlomé, Klippel, & De Soto, 2016) como Herramientas (Mendonça, Letícia Thaís, 2014).
Muchos de los contextos en los que se introduce Scrum ya tienen sus métodos y procesos codificados. Por lo tanto, observamos
La yuxtaposición como el objetivo de modificación concurrente más frecuente. Con menos frecuencia, notamos menciones explícitas
de objetivos de modificación para aumentar el rendimiento general del desarrollo con la categoría Rendimiento.
6.3 Arquitectura
estrategia de modificación Uso primario uso secundario Ejemplo de uso principal
Guía de métodos 15 20 (Angelov et al., 2016)
Procedimientos 37 36 (Gayer et al., 2016)
Infusión 8 3 (Harvie y Agah, 2016)
Instrumentos 18 8 (Farid, 2012)
Artefactos 11 13 (Alperowitz et al., 2017)
Pre-desarrollo 25 2 (Pastrana et al., 2017)
Multiplicidad 1 1 (Griffith et al., 2014)
TPODER7PRIMARIO YSSECUNDARIOMETROESTRATEGIAS DE ODIFICACIÓN PARAAARQUITECTURA
La categoría Arquitectura agrega el deseo común de especificar el resultado del proceso de desarrollo, al menos
en un alto nivel Con ese objetivo, los estudios comúnmente invocan estrategias de modificación en torno a nuevos artefactos, acompañadas de
procedimientos como una estrategia de modificación secundaria. Las actividades previas al desarrollo específicas a veces se destacan con
artefactos que los acompañan como una estrategia de modificación secundaria. Si bien Scrum originalmente sugiere que los equipos de alto nivel
la planificación y la arquitectura del software se llevan a cabo en un sprint que precede al desarrollo real (Schwaber, 1995), muchos
los profesionales ven la necesidad de atender esos procesos más cuidadosamente.
Debido a que los arquitectos técnicos no están especificados en el Scrum original, su rol no siempre está claro (Angelov et al.,
2016). Para complicar aún más las cosas, la tarea de "Arquitectura" se puede articular de diferentes maneras dependiendo de la
fondo elegido. Un miembro del equipo con mentalidad técnica puede solicitar "procedimientos de trazabilidad" (Gayer et al., 2016) o
un mejor enfoque de la fase previa al desarrollo y la mejora de la elicitación de requisitos (Pastrana et al., 2017) que
se puede apoyar con herramientas (Farid, 2012). En particular, los requisitos no funcionales parecen plantear un desafío (Farid,
2012). Un especialista en experiencia de usuario puede abordar este objetivo de modificación proponiendo artefactos como "visual
atrasos” (Alperowitz et al., 2017). Un miembro del equipo con mentalidad empresarial puede estar preocupado por la planificación del lanzamiento.
(Li et al., 2010) además de la obtención de requisitos. Los resultados de un estudio de simulación aconsejan mantener un paralelo
acumulación de emisiones de deuda técnica, por lo que exige multiplicidad (Griffith et al., 2014). A pesar de la fragmentación
por dominios, se han realizado reconsideraciones de alto nivel (Infusión) de Scrum para lograr una mayor disciplina arquitectónica
propuesta (Harvie & Agah, 2016). En conjunto, estas sugerencias tienen algo en común y abordan la inquietud
resultantes del principio ágil de “responder al cambio” (K Beck et al., 2001) y dar lugar a una tensión entre
surgimiento y control.
Las modificaciones de arquitectura a menudo se introducen con un objetivo secundario de modificación de aumentar el rendimiento
del proceso de desarrollo. La multitud de perspectivas sobre lo que definimos como la “tarea arquitectónica” se refleja en
la variedad de otros objetivos de modificación concurrentes. Las extensiones gerenciales reflejan la perspectiva empresarial. los
La perspectiva de la usabilidad se refleja en la categoría Experiencia del usuario.
Fuera del alcance de nuestra muestra de literatura, lecturas adicionales sobre la intersección de Scrum con Architecting en nuestra
vista de dominio se puede encontrar en el trabajo conceptual de Madison (2010), así como en revisiones sobre
facetas de la arquitectura centradas en el dominio, en particular la ingeniería de requisitos (Heikkila et al., 2015).
6.4 Yuxtaposición
Guía de métodos 15 23 (Schar et al., 2016)
Procedimientos 2 8 (Mc Mahon, 2016)
Infusión 69 3 (Sutherland et al., 2007)
Instrumentos 1 1 (Iónica et al., 2017)
Artefactos (N. Santos, Fernandes, Carvalho, et al.,
2 3 2016)
Pre-desarrollo 0 2
Multiplicidad 1 0
(Stålhane et al., 2012)
TPODER8PPRIMARIA Y SECUNDARIAMETROODIFICACIÓNSESTRATEGIAS PARAjUXTAPOSICIÓN
El cuarto objetivo de modificación más frecuente ocurre cuando se requiere que Scrum coexista con otros objetivos codificados.
frameworks, como Lean Development (X. Wang et al., 2012) o CMMI (Sutherland et al., 2007). Esta yuxtaposición
de dos estándares codificados puede deberse a requisitos institucionales, motivados por el deseo de aprovechar los beneficios de
ambos estándares, o puramente exploratoria. A menudo, la yuxtaposición de dos métodos está impulsada por el deseo de señalar la calidad.
El resultado de tal yuxtaposición suele ser una reelaboración sustancial o una infusión del método Scrum original con uno o más
más otros métodos. Tal reelaboración a menudo se acompaña con consejos prácticos, o Guía de métodos, como una herramienta secundaria.
estrategia de modificación.
Por requisitos institucionales, nos referimos tanto a los mandatos de arriba hacia abajo, como el estándar suizo Hermes (Schar et al.,
2016), pero también estándares adoptados voluntariamente para fines de control de calidad y señalización, como CMMI
(McMahon, 2016) o estándares de la industria (Stålhane et al., 2012). Algunos artículos exploran combinaciones de diferentes
metodologías, como el Rational Unified Process (Silva et al., 2017). La literatura primaria también presta atención a
la coexistencia de metodologías ágiles y tradicionales. Por ejemplo, la combinación del enfoque lineal (cascada)
con el enfoque iterativo de Scrum ha merecido el nombre de “Water-Scrum-fall” (Schlauderer & Overhage, 2015).
Scrum también se puede yuxtaponer con técnicas que proporcionan herramientas como Quality Function Deployment (Ionica et al.,
2017) o artefactos como modelos UML (N. Santos, Fernandes, Sameiro Carvalho, et al., 2016).
Una gran parte de los artículos de esta categoría carecen de conocimientos empíricos (35 de 90). Sin embargo, es interesante notar el orden
en el que se adoptan los diferentes métodos. En un escenario común, Scrum se introduce en un entorno gobernado
por un estándar diferente. En ese caso, se informa que Scrum acelera la velocidad del proceso de desarrollo y aumenta
satisfacción de clientes y desarrolladores (Morales Trujillo et al., 2011). En otro escenario, una organización que ya utiliza
Scrum opta por combinarlo con un segundo método. En ese caso, se informa que Scrum imbuye el proceso de desarrollo
con robustez y control, equipando a los desarrolladores con procedimientos para la arquitectura.
Con respecto a los objetivos de modificación concurrentes, la yuxtaposición se acompañó más comúnmente con contexto
porque Scrum a menudo se yuxtapone con un estándar que se origina en un entorno particular. Los métodos combinados a menudo
permitir que Scrum se desempeñe mejor en las dimensiones tradicionales de gestión de productos (a tiempo, dentro del presupuesto, cumpliendo
requisitos). Por lo tanto, el rendimiento se ha identificado como un objetivo de modificación concurrente. Por último, porque
Los elementos de otros métodos infundidos en Scrum a menudo proporcionan al método una rigidez adicional y un enfoque más sistemático.
enfoque, observamos Extensiones de Arquitectura y Gerenciales como objetivos de modificación concurrentes.
6.5 Desarrollo Distribuido

Guía de métodos 50 17 (Paasivaara et al., 2009)
Procedimientos 14 13 (Szoke, 2010)
Infusión 5 2 (Banijamali et al., 2017)
Instrumentos 7 1 (Sungkur y Ramasawmy, 2014)
Artefactos 4 2 (Esbensen et al., 2015)
Pre-desarrollo 0 0
Multiplicidad 7 6 (S. Lee y Yong, 2010)
TPODER9PPRIMARIA Y SECUNDARIAMETROODIFICACIÓNSESTRATEGIAS PARADISTRIBUIDODDESARROLLO
Cuando el desarrollo no se ubica en el mismo lugar, el proceso de desarrollo debe modificarse para admitir configuraciones distribuidas.
Los equipos distribuidos no necesariamente tienen que estar separados por varias zonas horarias; se pueden distribuir en un solo
país. Sin embargo, la deslocalización y la subcontratación (parcial) son razones comunes por las que muchos equipos de desarrollo en la actualidad
se distribuyen. Además del ancho de banda de comunicación reducido, las dificultades pueden surgir de la programación a través de
las zonas horarias, las barreras del idioma y los problemas de comunicación intercultural. Como resultado, la Guía de Métodos es el método dominante
estrategia de modificación para superar estos desafíos. Curiosamente, los Procedimientos específicos se mencionan más a menudo como un
estrategia de modificación secundaria, junto con la guía de métodos. Numerosos estudios discuten cómo los nuevos procedimientos o
formas particulares de multiplicidad pueden soportar Scrum en un entorno distribuido. En general, la mayoría de los estudios recomiendan la
multiplicación de equipos y, a veces, de procedimientos, mientras que los principales artefactos de Scrum (como el backlog) son
generalmente se recomienda compartir entre equipos.
Por ejemplo, Paasivaara et al. (2009) ofrecen una lista de actividades de apoyo concretas para facilitar Scrum distribuido, como
como reducir la independencia de los sitios y la sincronización de las horas de trabajo entre los sitios. La comunicación
El desafío se puede contrarrestar con artefactos como un tablero Scrum digital (Esbensen et al., 2015) o conocimiento
herramientas de gestión (Sungkur & Ramasawmy, 2014). Lee y Yong (2010) presentan una modificación más completa
usando el caso de Yahoo!, incluyendo una multiplicidad de procedimientos, nuevos roles y artefactos. En entornos distribuidos,
Se proponen procedimientos para distribuir el trabajo entre equipos (Szoke, 2010). Las yuxtaposiciones de métodos también pueden ser
empleados para entornos distribuidos (Banijamali et al., 2017).
Los documentos que abordan el desarrollo distribuido forman un cuerpo de trabajo relativamente maduro y coherente; por lo tanto, sólo unos pocos
podrían extraerse objetivos de modificación secundaria. Más comúnmente, "desempeño", particularmente en estudios que van
más allá del problema fundamental de establecer un equipo distribuido, sino intentar "afinar" el desempeño del trabajo en
ajustes distribuidos.
Fuera del alcance de nuestra investigación y muestra, hay revisiones de literatura dedicadas disponibles sobre distribución
desarrollo, centrándose, por ejemplo, en prácticas ágiles en el desarrollo global de software (Hossain et al., 2009; Vallon
et al., 2018) o ingeniería de software global (Jalali & Wohlin, 2010).
6.6 Extensiones Gerenciales

Guía de métodos 10 18 (Heikkila et al., 2013)
Procedimientos 23 8 (Bartón, 2009)
Infusión 7 0 (Haidar et al., 2017)
Instrumentos 17 6 (Reverdecimiento, 2015)
Artefactos 5 7 (Duraisamy & Atán, 2013)

Pre-desarrollo 0 2
Multiplicidad 4 0 (Hoda & Murugesan, 2016)
TPODER10PPRIMARIA Y SECUNDARIAMETROODIFICACIÓNSESTRATEGIAS PARAMETROEXTENSIONES ANAGERALES
El objetivo de "Extensiones gerenciales" se puede dividir en dos subpartes: la adición de niveles más altos de software
gestión de productos (como el mapeo de rutas y el establecimiento de una conexión con la estrategia general de una empresa) por un lado
por un lado, y por otro lado la integración de herramientas gerenciales de coordinación, reporte, documentación, etc.
modificaciones no pretenden cerrar la brecha entre el desarrollo y los procesos estratégicos de la empresa sino más bien
equipar el proceso de desarrollo con más rendición de cuentas y posiblemente una supervisión. Las modificaciones generalmente permanecen
dentro de los límites del proceso de desarrollo y mejorar los aspectos de coordinación. Las extensiones gerenciales son las más
frecuentemente abordado por nuevos procedimientos (Barton, 2009) con la Orientación de Métodos como una estrategia secundaria. Algunas veces,
Los artefactos y los procedimientos que los acompañan, como estrategia secundaria, se ofrecen a los roles existentes para lograr nuevos
tareas gerenciales. La guía de métodos es la tercera categoría de solución más común.
En el primer grupo encontramos estudios como el de Heikkilä et al. (2017), quienes demuestran cómo los requisitos fluyen de
La estrategia para lanzar desarrollos ágiles a gran escala requiere varias extensiones de Scrum, como roles de especialistas, para
gestionar el importante esfuerzo de coordinación. Otros estudios describen la necesidad de extensiones gerenciales en las pequeñas empresas
(Suwanya & Kurutach, 2009). En el segundo grupo encontramos propuestas para el manejo de documentación (Duraisamy
& Atan, 2013), herramientas como métricas (Greening, 2015).
Las extensiones gerenciales a menudo van acompañadas de la introducción de Scrum en un nuevo contexto. Además de la gestión
función es un contexto propio, señalamos contextos como una "organización de servicios" (Barton & Campbell, 2007) o
gestión de la innovación (Barton, 2009). El objetivo de modificación secundaria Performance reconoce explícitamente
objetivos para mejorar el rendimiento del desarrollo de Scrum, por ejemplo, superando el enfoque a corto plazo
(Dinakar, 2009) inherentes al desarrollo ágil. La co-ocurrencia de la arquitectura se manifiesta en papeles que modifican
Scrum por actividades previas al desarrollo o procedimientos para la documentación.
6.7 Experiencia del usuario

Guía de métodos 12 dieciséis (Hodgets, 2005)
Procedimientos 24 13 (Cavichi de Freitas et al., 2016)
Infusión 10 3 (de Carvalho et al., 2016)
Instrumentos 2 3 (Peixoto, 2009)
Artefactos 4 5 (Wautelet et al., 2016).
Pre-desarrollo 9 1 (Higuchi y Nakano, 2017)
Multiplicidad 4 1 (Budwig et al., 2009)
MESA11PRIMARIA Y SECUNDARIAMETROODIFICACIÓNSESTRATEGIAS PARAtuSERmiEXPERIENCIA
La experiencia del usuario es un factor crítico para la aceptación de muchos productos de software en la actualidad. Métodos ágiles de desarrollo,
y Scrum, en particular, tienen como objetivo lograr altos niveles de usabilidad al involucrar al usuario en el proceso de desarrollo,
así como especificar la aceptación del usuario como la condición final que debe cumplirse para que se considere un elemento pendiente
“hecho” (James, 2010). No obstante, los profesionales interesados en el diseño práctico y la usabilidad del software ofrecen
sus prácticas de trabajo que pueden ser absorbidas en Scrum. Estas prácticas suelen adoptar la forma de procedimientos o
orientación del método derivado de la experiencia (Hodgetts, 2005). A veces, un marco codificado que aborda la usabilidad o
El enfoque formalizado del campo de la experiencia del usuario se yuxtapone con Scrum, lo que resulta en una revisión significativa de
Scrum o infusión (de Carvalho et al., 2016). En esos casos, la Orientación sobre métodos a menudo acompaña la presentación de
una especificación Scrum radicalmente revisada. Los profesionales de la experiencia del usuario a menudo están involucrados al comienzo de la
proceso de desarrollo (Higuchi & Nakano, 2017), facilitando la elicitación de requisitos (categorizados como pre-
desarrollo). También se ofrecen herramientas, aunque en contadas ocasiones (Peixoto, 2009). Como tensión destacable, algunos autores abogan por
multiplicando el equipo de desarrollo e introduciendo la multiplicidad en forma de un equipo separado para diseñadores (Budwig
et al., 2009), mientras que otros afirman que a los desarrolladores se les deberían enseñar tareas de UX (Øvad et al., 2015).
El conjunto de disciplinas que incluye la experiencia del usuario, la usabilidad y las interacciones humano-computadora se ha desarrollado
una colección de métodos y estándares específicos de campo. En nuestra muestra, a menudo podemos ver tales técnicas siendo yuxtapuestas
con métodos codificados de desarrollo de software. Dado que el campo UX se ocupa principalmente de trabajar hacia un alto
nivel de ajuste entre los usuarios y el producto desarrollado, estas modificaciones a menudo caen en la categoría de Arquitectura (por ejemplo,
desarrollo de la persona, elicitación de requisitos).
Fuera del alcance de nuestra investigación y muestra, una revisión sistemática reciente resume los enfoques para incorporar UX
en Scrum (Kikitamara & Noviyanti, 2018).
6.8 Escala de tamaño

Guía de métodos 21 dieciséis (Heikkila et al., 2013)
Procedimientos 15 9 (Hofman et al., 2012)
Infusión 5 3 (Tanveer, 2016)
Instrumentos 0 1
Artefactos 1 3 (Bajo, 2016)
Pre-desarrollo 0 2
Multiplicidad 11 3 (Sutherland, 2005)
TPODER12PPRIMARIA Y SECUNDARIAMETROODIFICACIÓNSESTRATEGIAS PARASESCALA DE TAMAÑO
Hoy en día, Scrum se aplica a menudo en esfuerzos de desarrollo que superan la capacidad de un único equipo típico de Scrum (3-
6 personas; Schwaber, 1997, pág. dieciséis). En proyectos industriales para desarrollar grandes artefactos de software (por ejemplo, sistemas operativos),
muchos equipos suelen contribuir al desarrollo del producto en general. Aumentar el tamaño del equipo de desarrollo pone un
tensión en la coordinación, lo que exige una guía de método. Por lo tanto, una estrategia común es dividir a los desarrolladores en
varios equipos Scrum (es decir, utilizando la multiplicidad). Luego, estos equipos se organizan en estructuras como "Scrum of
Scrums” (Sutherland, 2005), que requiere una infraestructura de apoyo adicional en forma de nuevos procedimientos y
papeles Entonces surge una tensión con el principio ágil central de la autoorganización (K Beck et al., 2001). los
los desafíos de comunicación se encuentran entre aquellos para los que se proporciona orientación sobre métodos como una modificación secundaria. En
en otros casos, el asesoramiento se ofrece como estrategia principal y los procedimientos lo respaldan como estrategia secundaria. Línea de producto
la ingeniería puede proporcionar un mecanismo para lograr el control de la constelación de equipos Scrum (Hofman et al., 2012).
La escala de tamaño también se puede lograr mediante infusión con un método diferente, como el Proceso unificado de Rational (Tanveer,
2016).
Como ejemplo de guía de métodos en este contexto, Heikkila, Paasivaara y Lassenius (2013) presentan una decisión
marco para elegir entre métodos ágiles, híbridos y basados en planes en grandes organizaciones. Otros autores proponen
marcos de gobernanza para múltiples equipos Scrum (Paasivaara et al., 2012; Vlietland et al., 2016). además de nuevos
roles y procedimientos asociados, los nuevos artefactos también pueden resultar útiles para ayudar al desarrollo a gran escala (Bass, 2016).
Naturalmente, la escala de tamaño a menudo se aborda junto con entornos de desarrollo distribuidos (Bass, 2016). A medida que crecen los equipos
En tamaño, la infraestructura de gestión de apoyo a veces se amplía para dar cuenta de la coordinación eficaz entre
equipos y abordar la alineación entre el trabajo de desarrollo y la dirección estratégica; de ahí que encontramos “Gerencial
Extensiones” como motivación concurrente (Hofman et al., 2012). Las metodologías ágiles de desarrollo a veces son
forzados a coexistir con métodos basados en planes en entornos empresariales, lo que resulta en una yuxtaposición como
motivación.
Fuera del alcance de nuestra investigación y muestra, una revisión bibliográfica reciente abordó la ampliación de prácticas ágiles a grandes
organizaciones (Kalenda et al., 2018).
6.9 Seguridad
Guía de métodos 12 6 (Doss & Kelly, 2016b)
Procedimientos 12 8 (Y. Wang y Wagner, 2016)
Infusión 6 4 (Maier et al., 2017)
Instrumentos 5 0 (A. Ali y Ben Othmane, 2016)
Artefactos 2 3 (Y. Wang et al., 2017)
Pre-desarrollo 0 0
Multiplicidad 2 0 (Koc et al., 2019)
TPODER13PPRIMARIA Y SECUNDARIAMETROODIFICACIÓNSESTRATEGIASFOSSEGURIDAD
Scrum no se preocupa explícitamente por la seguridad del software resultante. No incluye procedimientos o roles para
realizando pruebas y no se adhiere a un estándar específico de seguridad. Sin embargo, existen numerosas aplicaciones en las que
la seguridad es de suma importancia. Los artículos de esta categoría permiten formas sistemáticas de abordar la seguridad en Scrum.
Treinta y nueve de los documentos revisados estaban motivados principalmente por garantizar o mejorar aspectos relacionados con la seguridad, y
otros ocho artículos mencionaron la seguridad como un factor secundario para modificar Scrum. La seguridad del software presenta una
desafío porque "las metodologías de desarrollo de software seguras establecidas se basan principalmente en modelos lineales...
haciéndolos inadecuados para un entorno ágil” (Maier et al., 2017). En esta muestra limitada, la más común
Las estrategias de modificación fueron la introducción de nuevos procedimientos como los del análisis de seguridad recurrente (Y. Wang &
Wagner, 2016) y Method Guidance, por ejemplo, en forma de principios (Doss & Kelly, 2016b). En nuestra muestra,
las soluciones explícitas a la seguridad a menudo estaban conectadas con un contexto específico. En dos casos, notamos que la seguridad
Se introdujeron prácticas de otros marcos formales (es decir, yuxtaposición) (Maier et al., 2017). Herramientas técnicas
puede ayudar a que las pruebas sean más eficientes (A. Ali y Ben Othmane, 2016), pero incluso el desarrollo disciplinado de
la documentación, como artefactos adicionales, puede ser útil (Y. Wang et al., 2017). Incluso es posible emplear una multiplicidad
de procedimientos y dedicar un sprint específicamente al aseguramiento de la seguridad (Koc et al., 2019). Las motivaciones secundarias en gran parte
reflejan los primarios.
La categoría de seguridad es reconocida como la más pequeña pero suficientemente distintiva. El creciente número de papeles
que provienen de años posteriores a la selección (los primeros de 2013) pueden ser un signo de un tema de investigación emergente.
7 Discusión
Nuestro estudio muestra que Scrum es un método increíblemente versátil que se utiliza mucho más allá de su entorno y propósito original. Como un
Fruto de su popularidad, Scrum se utiliza como plataforma de adaptación a innumerables contextos y objetivos diferentes o como
un bloque de construcción para otros métodos. Toda esta versatilidad ha sido documentada en un rico corpus de literatura. Sin embargo,
este campo de investigación altamente dinámico no se ha integrado de manera integral con un enfoque centrado en el método que
se interpone en el camino de la generación de conocimiento acumulativo. Esta situación es común en países emergentes y muy activos.
áreas de investigación (Keen, 1980). El fuerte interés de los profesionales actúa como un impulsor adicional para la diseminación—y
en consecuencia adaptación—del método Scrum a diferentes contextos (Dybå, 2013; VersionOne, 2018). Para tal fin,
Esperamos que nuestra revisión pueda ayudar a futuros diseños de investigación más sistemáticos.
Nuestra investigación es, hasta donde sabemos, la primera que proporciona una descripción general estructurada de la modificación.
objetivos y adaptaciones a Scrum. Algunos objetivos de modificación, comoActuacióno adaptación aContexto,
atraen mucho interés, mientras que a otros les gustaSeguridadpuede ver un mayor interés con la digitalización en curso de nuestro
sociedad y empresas. Utilizamos esta discusión para proporcionar primero más detalles sobre la validez empírica de nuestros hallazgos, antes de
pasando a las implicaciones y estrategias para futuras investigaciones. Antes de concluir, también reconocemos las limitaciones de
nuestro estudio.
7.1 Diversidad metodológica

Para los investigadores y especialmente para los profesionales, la validez de nuestros hallazgos depende en gran medida del alcance de su
fundamentación empírica. Importa si las propuestas reportadas son solo ideas o han sido probadas empíricamente en un caso.
empresa. Informar a nuestros lectores sobre la fundamentación empírica de cada combinación de objetivo de modificación y
estrategia (por ejemplo, objetivo: yuxtaposición, estrategia: infusión), investigamos dos preguntas específicas para cada
combinación: (i) cuál es la proporción de estudios empíricos versus estudios conceptuales y (ii) cuán variados son los estudios empíricos
enfoques empleados (p. ej., estudios de casos individuales, encuestas) en cualquier combinación dada. Mesa14da una visión general de nuestra
resultados.
TPODER14METROPLURALISMO ETODOLÓGICO A TRAVÉS DE OBJETIVOS Y ESTRATEGIAS DE MODIFICACIÓN

Método Procedimiento Pre-
Infusión Artefactos Multiplicidad
guía es desarrollo
Instrumentos
58 (65) 64 (86)
4 (7) 38 (61) 13 (17) 2 (2)
Gini: 0,4 Gini: 0,5
Actuación Gini: 0,5 Gini: 0,81 Gini: 0,59 Gini: 0,67 0 (0)
8 3
diverso caso único diverso diverso
diverso diverso
54 (60) 48 (68)
22 (35)
Gini: 0,8 Gini: 0,9 1 (2) 5 (5) 1 (1) 2 (2)
Gini: 0,7
Contexto 6 0 Gini: 1,00 Gini: 0,87 Gini: 1,00 Gini: 0,67
0
único único caso único caso único encuesta diverso
diverso
caso caso
5 (8)
8 (15) 30 (37)
Gini: 0,8 11 (18) 7 (11) 17 (25)
Gini: 0,5 Gini: 0,5
Arquitectura 7 Gini: 0,45 Gini: 0,71 Gini: 0,8 0 (1)
0 3
único diverso caso único caso único
diverso diverso
caso
7 (15) 43 (69)
2 (2)
Gini: 0,7 Gini: 0,7 1 (1) 2 (2)
Gini: 0,6
Yuxtaposición 1 5 Gini: 1,00 Gini: 1,00 0 (0) 0 (1)
7
único único caso único caso único
diverso
caso caso
43 (56) 12 (15) 4 (5)
Gini: 0,7 Gini: 0,7 Gini: 1,0 5 (7) 4 (4) 7 (7)
Repartido 2 8 0 Gini: 0,60 Gini: 0,50 0 (0) Gini: 1,00
único único único diverso diverso caso único
caso caso caso
7 (7)
8 (10) 16 (23)
Gini: 0,9 6 (17) 4 (5) 3 (4)
Gerencial Gini: 0,5 Gini: 0,4
0 Gini: 0,67 Gini: 0,67 0 (0) Gini: 0,78
extensiones 0 2
único diverso diverso caso único
diverso diverso
caso
12 (12) 16 (24) 8 (10)
1 (2) 3 (4) 9 (9) 4 (4)
Usuario Gini: 0,6 Gini: 0,6 Gini: 0,6
Gini: 1,00 Gini: 1,00 Gini: 0,48 Gini: 1,00
Experiencia 1 7 7
multi. caso caso único diverso caso único
diverso diverso diverso
20 (21) 14 (15) 4 (5)
1 (1) 10 (11)
Gini: 0,5 Gini: 0,95 Gini: 0,83
escala de tamaño 0 (0) Gini: 1,00 0 (0) Gini: 0,80
7 único único
encuesta caso único
diverso caso caso
6 (12) 6 (12) 4 (6)
Gini: 0,7 Gini: 0,8 Gini: 1,0 1 (4) 2 (2) 2 (2)
Seguridad 8 9 0 Gini: 1,00 Gini: 1,00 0 (0) Gini: 0,67
único único único caso único caso único diverso
caso caso caso
Para cada combinación de objetivo de modificación y estrategia, la celda contiene tres líneas de información. la primera linea
aborda dos proporciones de artículos empíricos (i). Las líneas dos y tres abordan la diversidad metodológica (ii).
El número de casos empíricos se da en la primera línea, seguido del número absoluto de estudios entre paréntesis. Para
Por ejemplo, 43 (76) significa que encontramos 43 estudios empíricos de un total de 76 estudios para esta combinación. Estos números
en la primera línea de cada celda ya permiten evaluar la fuerza empírica de una determinada combinación. mientras estamos
Al no imponer nuestra escala o principio de evaluación al categorizar los artículos (p. ej., en empíricos bajos o fuertes), esperamos
apoyar a los lectores en su evaluación proporcionando esta descripción general.
Más allá de las fortalezas empíricas, empleamos el coeficiente de Gini como una medida del pluralismo metodológico, es decir, la
concentración o dispersión o variedad de diferentes tipos de enfoques empíricos que se han utilizado para estudiar un determinado
combinación (Roth, 2019). Nuevamente, no argumentamos que un diseño empírico, por ejemplo, una encuesta, puede ser más valioso
que un solo estudio de caso. Por el contrario, existe un acuerdo común entre los estudiosos de que el pluralismo metodológico
es particularmente beneficioso para los campos que estudian fenómenos contemporáneos y complejos, ya que puede compensar las limitaciones de
un método por la fuerza de otro (Chamberlain et al., 2011; Frost et al., 2014). En palabras de Barnes et al.,
2014), la pluralidad metodológica “produce comprensiones más complejas y ricas del tema que se investiga”.
(pág. 35).
En la segunda línea de cada celda, mostramos una medida de la concentración de enfoques empíricos para cada combinación,
diferenciar entre estudios de casos únicos, estudios de casos múltiples, diseños de encuestas y experimentos. Para calcular el
concentración, confiamos en el coeficiente de Gini ampliamente aceptado para medir la concentración estadística (Gini, 1912).
Específicamente, proporcionamos una forma normalizada del coeficiente de Gini, que da valores de cero a uno y permite
fácil interpretación. Los valores más altos del coeficiente de Gini normalizado significan que todos los estudios empíricos en la celda
se llevan a cabo utilizando un solo método. Cero denota una distribución equitativa en todos los métodos. El cálculo del Gini
coeficiente se llevó a cabo utilizando elRpaquete de software REAT de Wieland (2019, p. R4).
En la tercera línea de cada celda, informamos el diseño de investigación empírico más utilizado, o dominante, solicitado.
esta combinación Si el coeficiente de Gini puntúa por debajo de 0,7, indica que una multitud de diversas pruebas empíricas
enfoques se ha aplicado sin un único diseño dominante, en cuyo caso señalamos la combinación a ser
metodológicamente “diverso”.
7.2 Implicaciones para la investigación y la práctica
Como se destaca en la Tabla 4 y la Tabla 14, las ideas proporcionadas en este estudio tienen implicaciones directas para la
avance del campo en la investigación y la práctica. Para los profesionales, nuestra investigación ayuda a identificar fácilmente
estudios que pueden orientar situaciones donde surgen objetivos de modificación similares y evitar ensayos innecesarios y costosos
y experimentación de errores.
Para los académicos, nuestros hallazgos sirven para revelar áreas para futuras actividades de investigación prometedoras. Mostramos la relevancia de
ciertas combinaciones, como lo indica el número de estudios que buscan adaptaciones de métodos para un propósito determinado,
así como fortalezas o debilidades en términos de rigor, como lo indica la proporción de estudios empíricos y la amplitud
de métodos empíricos aplicados.
Por ejemplo, a los profesionales les puede resultar tranquilizador que la “orientación de métodos” como un medio para el objetivo de “gestión
Extensiones” se ha estudiado empíricamente en ocho de cada diez estudios, y que estos estudios aplicaron una amplia gama de
enfoques empíricos para observar este fenómeno (Gini = 0,50). Por otro lado, al observar el uso de "Herramientas"
para lograr una mayor "Seguridad", solo se ha realizado un único estudio empírico de cinco estudios totales,
lo que indica una falta de información sobre la aplicabilidad práctica de este enfoque de modificación.
El enfoque abrumador en los estudios de casos únicos como método empírico dominante sin un marco teórico conduce a
el estado actual del “empirismo Dustbowl” (Diccionario de Psicología APA, 2018). Más y más propuestas
abordando situaciones similares se están agregando al corpus de la literatura. Nuestro análisis muestra que la literatura carece de
tradición de investigación acumulada, sin poder vincular los hallazgos con investigaciones previas o beneficiarse de las revisiones de la literatura relevante.
Alrededor del 78 % de los artículos revisados se presentaron en congresos, donde el formato más breve normalmente no permite
para una revisión extensa de la literatura relacionada. Se pueden usar referencias a revisiones de literatura publicada en lugar de
revisiones dedicadas en artículos, pero no es una práctica común. La situación actual aparentemente satisface los pedidos anteriores de
investigación contextualizada en el dominio de la ingeniería de software (Clarke & O'Connor, 2012) que insta a la "investigación para
operar en contextos claramente definidos, lo que nos permite identificar suposiciones de trabajo realistas e identificar importantes, bien-
problemas definidos, así como crear oportunidades para evaluaciones realistas” (Briand et al., 2017). Sin embargo, a lo largo
la literatura, se informan modificaciones similares introducidas en respuesta a objetivos de modificación casi idénticos
repetidamente, y las nuevas publicaciones motivadas por problemas previamente abordados ignoran la literatura previa. Tal
El enfoque de la investigación es preocupante, ya que se interpone en el camino de la generación de conocimiento acumulativo y pone en riesgo el continuo
“reinvención de la rueda” (Hassan & Mathiassen, 2018; Keen, 1980).

Por ejemplo, la integración de profesionales de Experiencia de Usuario en Scrum, ambas propuestas de integración de diseñadores en el
equipo de desarrollo (Øvad et al., 2015) y mantenerlos separados (Singh, 2008) están documentados como funcionales. Cruz-
la comparación de esos enfoques, idealmente con respaldo, en teoría, sería interesante y muy relevante para el
avance del campo.
7.3 Estrategias para futuras investigaciones

Con base en nuestros hallazgos, vemos dos estrategias amplias que pueden ayudar a mejorar sustancialmente el avance sistemático
del campo: mejorar las citas cruzadas y el marco teórico.
La citación cruzada requiere que los futuros investigadores se basen en estudios previos y, por lo tanto, puedan acceder y ubicar fácilmente su investigación.
esfuerzo dentro del cuerpo existente de conocimiento. La sistematización que se ofrece en este trabajo es un paso destinado a
alentar y permitir tales esfuerzos. Los autores de trabajos empíricos futuros pueden usar la síntesis presentada de
modificación de objetivos y estrategias para categorizar sus planes de investigación frente a investigaciones similares y seguir
referencias enumeradas para identificar estudios previos relevantes fácilmente. Hay disponible una variedad de revisiones más estrechas y enfocadas, que
han sido referenciados a lo largo de este manuscrito. De esta manera, un enfoque sistemático para evaluar la novedad de la intención
o se apoyan las actividades propuestas que pueden contribuir al surgimiento de una tradición de investigación más acumulativa.
La segunda estrategia general para superar la aparente falta de tradición acumulativa es anclar la investigación empírica
estudios en marcos teóricos. Sin vincular explícitamente las modificaciones novedosas a los principios subyacentes de ágil
enfoques, es difícil evaluar qué modificaciones lo socavarán y cuáles lo harán cumplir. La falta de
El fundamento teórico se vuelve particularmente agudo a medida que las ideas de los enfoques ágiles han viajado desde el software
desarrollo a la gestión genérica de proyectos e incluso a campos como el diseño organizacional (Gerster et al., 2020).
Sin consolidación teórica y síntesis de las características y mecanismos clave del fenómeno, la
flujo de literatura corre el riesgo de ser reducido a un conjunto de técnicas y metodologías sin facilitar
comprensión (Cram & Newell, 2016). Esta preocupación se hace eco de llamados anteriores a “la necesidad de una mejor comprensión de
qué constituye 'agilidad'” (Abrahamsson et al., 2009; Conboy, 2009).
7.4 Limitaciones
Reconocemos que este estudio tiene ciertas limitaciones. Constantemente buscamos el más alto nivel de rigor y
transparencia en el proceso de búsqueda y filtro de literatura, pero aún existe el riesgo de sesgo del investigador que resulta en tener
pasó por alto estudios relevantes que no coincidían con nuestro diccionario de palabras clave (Feldt & Magazinius, 2010). Este riesgo era
mitigado por la discusión en curso entre los investigadores para diseñar un filtro tan completo como sea posible.
Muchos estudios en la literatura están escritos desde el punto de vista de promover el desarrollo ágil y, por lo tanto, la muestra
está sesgada hacia la presentación de resultados positivos. Esto se ve acentuado por el hecho de que muchas de las publicaciones son
informes de experiencia donde los autores participaron en el desarrollo. La confianza en los informes de experiencia
posibilidad de sesgo en la muestra. Sin embargo, sorteamos la ausencia de resultados negativos al construir nuestra revisión
en torno al esfuerzo de sistematizar contextos y estrategias particulares donde se informa que Scrum es exitoso
adoptado.
Nuestro proceso de codificación podría haberse visto afectado por un sesgo subjetivo. Intentamos contrarrestar esta amenaza a la validez mediante la
discusión en curso del proceso de codificación y suministro de literatura de apoyo para nuestras afirmaciones en el manuscrito mismo.
Aunque diferentes analistas podrían llegar a puntos de vista alternativos de los datos (como siempre ocurre cuando se trabaja
con datos cualitativos), ambos autores acordaron en el esquema de categorización como robusto y conducente a la perspicaz
discusión. Además, abordamos esta posible limitación al discutir las versiones de trabajo del manuscrito con
colegas bien informados.
Nuestro proceso de codificación también fue limitado en cuanto a la evaluación de las amenazas de validez y las estrategias de mitigación (Feldt &
Revista, 2010). Al carecer de un análisis detallado de la validez de cada estudio de nuestra muestra, optamos por un análisis menos
evaluación granular de la calidad para evaluar la literatura primaria, como se describe en la Sección 3.3.
Además, limitamos nuestra búsqueda bibliográfica a publicaciones en revistas académicas y actas de congresos, pero no
incluir literatura profesional relevante sobre el tema, a menudo publicada en blogs en línea o de la industria no indexada
revistas Si bien el gran tamaño de la muestra de nuestra revisión y la repetición de temas en los estudios de nuestra
muestra proporciona una amplia evidencia de nuestros hallazgos, alentamos a futuras investigaciones para ampliar nuestros conocimientos, por ejemplo, a través de
la inclusión o comparación con puntos de venta de profesionales.
8 Conclusión
Llevamos a cabo una revisión sistemática de la literatura a gran escala investigandopor quéycómoScrum está siendo modificado en
práctica. Al revisar una muestra final de 925 estudios, desarrollamos nueve categorías de objetivos de modificación
conectado a siete estrategias de modificación genéricas. Nuestra revisión confirma la aplicabilidad de Scrum a una variedad de
contextos (desde pequeños equipos estándar ubicados en el mismo lugar hasta desarrollo distribuido a gran escala), pero también destaca la necesidad
de buenas prácticas para garantizar que los beneficios de usar un método ágil se mantengan. La principal contribución de este
obra es la síntesis de un cuerpo fragmentado de literatura que carece de una tradición acumulativa. A través de esta síntesis, este
El estudio proporciona una visión exhaustiva y una discusión del conocimiento existente, que al mismo tiempo puede servir como un
anteproyecto para futuras investigaciones.

9 Agradecimientos
Nos gustaría agradecer a Keld Pedersen por sus comentarios a un borrador anterior de este documento, así como a los dos anónimos
revisores
10 Bibliografía
Aamir, M. y Khan, MNA (2017). Incorporar actividades de control de calidad en scrum en relación con el concepto de
acumulación de pruebas.Sadhana - Actas de la Academia en Ciencias de la Ingeniería. https://doi.org/10.1007/
s12046-017-0688-7
Abrahamsson, P., Conboy, K. y Wang, X. (2009). Mucho hecho, más por hacer: el estado actual de los sistemas ágiles
investigacion para el desarrolloRevista Europea de Sistemas de Información, 281–284. https://doi.org/10.1057/ejis.2009.27 Ali,
A. y Ben Othmane, L. (2016). Hacia una garantía de seguridad eficiente para el desarrollo de software incremental
caso de aplicación de carro zen.Actas - 2016 11ª Conferencia Internacional sobre Disponibilidad, Confiabilidad y
Seguridad, ARES 2016. https://doi.org/10.1109/ARES.2016.86
Ali, M., Hafeez, Y. y Hamid, B. (2016). Un estudio empírico y un marco para la gestión eficaz de riesgos en scrum.
Actas de la Academia de Ciencias de Pakistán.
Alperowitz, L., Scheuermann, C. y Von Frankenberg, N. (2017). De guiones gráficos a código: acumulación de productos visuales
en cursos de proyectos ágiles.Actas del Taller CEUR,1790, 69–72.
Alqudah, M. y Razali, R. (2018). Un estudio empírico de la formación de Scrumban basado en la selección de Scrum y
Prácticas Kanban.Revista internacional sobre ciencia avanzada, ingeniería y tecnología de la información.
https://doi.org/10.18517/ijaseit.8.6.6566
Angelov, S., Meesters, M. y Galster, M. (2016). Arquitectos en scrum: ¿A qué desafíos se enfrentan?Notas de lectura
en Ciencias de la Computación (incluidas las notas de clase de la subserie en inteligencia artificial y las notas de clase
en bioinformática). https://doi.org/10.1007/978-3-319-48992-6_17
Anwar, SA, Hafeez, Y., Asghar, S., Shabbir Hassan, M. y Hamid, B. (2014). Hacia un marco para scrum
proceso de entrega.Actas de la Academia de Ciencias de Pakistán,51(4), 265–275.
Diccionario de Psicología de la APA. (2018).“El empirismo del cuenco de polvo”.Diccionario de Psicología de la APA.
https://dictionary.apa.org/dustbowl-empiricism
Ashraf, S. y Aftab, S. (2017). Últimas transformaciones en Scrum: un estado de las últimas transformaciones en Scrum: un
Revisión del estado del arte.IJ Educación Moderna e Informática,Julio.
https://doi.org/10.5815/ijmecs.2017.07.02
Banijamali, A., Dawadi, R., Ahmad, MO, Similä, J., Oivo, M. y Liukkunen, K. (2017). Investigación empírica de
Scrumban en el desarrollo global de software.Comunicaciones en Informática y Ciencias de la Información.
https://doi.org/10.1007/978-3-319-66302-9_12
Barnes, J., Caddick, N., Clarke, NJ, Cromby, J., McDermott, H., Willis, M. y Wiltshire, G. (2014). metodológico
pluralismo en la investigación cualitativa: reflexiones sobre un metaestudio.Boletín QMiP,17(Primavera).
Barton, B. (2009). Scrum organizativo total como cadena de valor de la innovación.Actas de la 42.a edición anual de Hawái
Congreso Internacional de Ciencias de Sistemas, HICSS. https://doi.org/10.1109/HICSS.2009.57
Barton, B. y Campbell, E. (2007). Implementación de una organización de servicios profesionales utilizando scrum tipo C.
Actas de la Conferencia Internacional Anual de Hawái sobre Ciencias de Sistemas. https://doi.org/
10.1109/HICSS.2007.265
Bajo, JM (2016). Adaptación de artefactos y métodos ágiles en programas de desarrollo de software offshore a gran escala.
Tecnología de la información y el software,75, 1–16. https://doi.org/10.1016/j.infsof.2016.03.001
Beck, K, Beedle, M., Bennekum, A. Van, Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J.,
Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, RC, Mellor, S., Schwaber, K., Sutherland, J. y Thomas, D.
(2001).Manifiesto para el desarrollo ágil de software. La Alianza Ágil.
Beck, Kent, Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith,
J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, RC, Mellor, S., Schwaber, K., Sutherland, J. y Thomas,
D. (2001).Manifiesto ágil. Desarrollo de software.
Besson, P. y Rowe, F. (2012). Elaboración de estrategias de transformación organizativa facilitada por los sistemas de información: una
revisión transdisciplinar y nuevos rumbos. EnRevista de Sistemas de Información Estratégica. https://
doi.org/10.1016/j.jsis.2012.05.001
Bourimi, M. y Tesoriero, R. (2014). Requisitos no funcionales para interfaces de usuario distribuibles en Agile
Procesos.Actas del taller de 2014 sobre interfaces de usuario distribuidas e interacción multimodal - DUI
'14. https://doi.org/10.1145/2677356.2677668
Briand, L., Bianculli, D., Nejati, S., Pastore, F. y Sabetzadeh, M. (2017). El caso del software basado en el contexto
Investigación en ingeniería: la capacidad de generalización está sobrevalorada.Software IEEE,34(5), 72–75.
https://doi.org/10.1109/MS.2017.3571562
Budwig, M., Jeong, S. y Kelkar, K. (2009). Cuando la experiencia del usuario se encontró con Agile.Actas de la 27ª Internacional
Resúmenes extendidos de conferencias sobre factores humanos en sistemas informáticos - CHI EA '09, 3075. https://
doi.org/10.1145/1520340.1520434
Cavichi de Freitas, R., Rodrigues, LA y Marques da Cunha, A. (2016). AGILUS: un método para integrar
Evaluaciones de Usabilidad en Desarrollo Ágil de Software. EnConferencia Internacional sobre Interacción Humano-
Computadora(págs. 545–552). Saltador. https://doi.org/10.1007/978-3-319-39510-4_50
Cawley, O., Wang, X. y Richardson, I. (2010). Metodologías de desarrollo de software lean/agile en entornos regulados
ambientes - Estado del arte.Apuntes de clase en el procesamiento de información empresarial,65 LNBIP, 31–36.
https://doi.org/10.1007/978-3-642-16416-3_4
Chamberlain, K., Caín, T., Sheridan, J. y Dupuis, A. (2011). Pluralismos en la investigación cualitativa: De múltiples
métodos a métodos integrados.Investigación Cualitativa en Psicología,8(2), 151–169.
https://doi.org/10.1080/14780887.2011.572730
Clarke, P. y O'Connor, RV (2012). Los factores situacionales que afectan el proceso de desarrollo de software: Hacia
un marco de referencia completo.Tecnología de la información y el software,54(5), 433–447. https://
doi.org/10.1016/j.infsof.2011.12.003
Cloke, G. (2007). ¡Ponte tu monstruo ágil! Adopción ágil en Yahoo! Música.Actas - AGILE 2007.
https://doi.org/10.1109/AGILE.2007.30
Conboy, K. (2009). Agilidad desde los primeros principios: reconstruyendo el concepto de agilidad en los sistemas de información
Desarrollo.Investigación de Sistemas de Información,20(3), 329–354. https://doi.org/10.1287/isre.1090.0236 Cooper, RG y
Sommer, AF (2016a). Agile-Stage-Gate: Nuevo método idea-a-lanzamiento para productos nuevos fabricados
productos es más rápido, más receptivo.Gerencia de Mercadeo Industrial,59, 167–180.
https://doi.org/10.1016/j.indmarman.2016.10.006
Cooper, RG y Sommer, AF (2016b). El modelo híbrido Agile-Stage-Gate: un nuevo enfoque prometedor y un
Nueva oportunidad de investigación.Revista de gestión de la innovación de productos. https://doi.org/10.1111/jpim.12314
Cram, WA y Newell, S. (2016). ¿Revolución consciente o tendencia sin sentido? Examinar el desarrollo ágil como un
moda gerencial.Revista Europea de Sistemas de Información,25, 154–169.
https://doi.org/10.1057/ejis.2015.13
Cruzes, DS y Dyba, T. (2011). Pasos recomendados para la síntesis temática en ingeniería de software.Actas
del Simposio Internacional 2011 sobre Ingeniería y Medición Empírica de Software, ESEM '11, IEEE
Computer Society. https://doi.org/10.1109/esem.2011.36
de Carvalho, JMI, da Silva, TS y Silveira, MS (2016). Integración ágil y UCD basada en predesarrollo
Evaluaciones de usabilidad: un informe de experiencia. EnConferencia Internacional sobre Interacción Humano-Computadora
(págs. 586–597). Saltador. https://doi.org/10.1007/978-3-319-39510-4_54
De Melo, IF, Mendes, GAR y Gelmetti, SA (2019). Implementación sin scrum: un enfoque metodológico
para pequeñas empresas.Actas de la Conferencia Europea sobre Métodos de Investigación en Estudios Empresariales
y de Gestión,2019-Junio. https://doi.org/10.34190/RM.19.027
Deemer, P., Benefield, G., Larman, C. y Vodde, B. (2012).The Scrum Primer: una guía ligera para la teoría
y Práctica de Scrum. http://www.infoq.com/minibooks/Scrum_Primer
Dick, C. (2016). de las trincheras | Mejorando la Scrum Daily Standup Meeting. EnCrossTalk: El diario de
Ingeniería de software de defensa.
Diebold, P., Ostberg, JP, Wagner, S. y Zendler, U. (2015). ¿En qué varían los practicantes en el uso de scrum?Conferencia
Notas en el procesamiento de información comercial,212, 40–51. https://doi.org/10.1007/978-3-319-18612-2_4
Dikert, K., Paasivaara, M. y Lassenius, C. (2016). Desafíos y factores de éxito para Agile a gran escala
transformaciones: una revisión sistemática de la literatura.Revista de Sistemas y Software,119, 87–108. https://
doi.org/10.1016/j.jss.2016.06.013
Dinakar, K. (2009). Desarrollo ágil: superando un enfoque a corto plazo en la implementación de mejores prácticas.Proceder
del 24º ACM SIGPLAN Conference Companion on Object Oriented Programming Systems Languages and
Applications - OOPSLA '09, 579. https://doi.org/10.1145/1639950.1639952
Dingsør, T., Nerur, S., Balijepally, V. y Moe, NB (2012). Una década de metodologías ágiles: Hacia la explicación
Desarrollo Ágil de Software.Revista de Sistemas y Software,85(6), 1213–1221.
https://doi.org/10.1016/j.jss.2012.02.033
Doss, O. y Kelly, T. (2016a). Abordar los principios de garantía de seguridad del software 4+1 dentro de scrum.MCA
Serie de actas de conferencias internacionales. https://doi.org/10.1145/2962695.2962712
Doss, O. y Kelly, T. (2016b). Los principios 4+1 del aseguramiento de la seguridad del software y sus implicaciones para Scrum.
Apuntes de clase en el procesamiento de información empresarial. https://doi.org/10.1007/978-3-319-33515-5_27 Dreesen, T.,
Linden, R., Meures, C., Schmidt, N. y Rosenkranz, C. (2016). Más allá de la frontera: una comparativa
revisión de la literatura sobre prácticas de comunicación para proyectos de desarrollo de software subcontratados
globales ágiles. Actas de la Conferencia Internacional Anual de Hawái sobre Ciencias de Sistemas, 4932–4941. https://
doi.org/10.1109/HICSS.2016.612
Duechting, M., Zimmermann, D. y Nebe, K. (2007). Incorporación de la ingeniería de requisitos centrada en el usuario en Agile
desarrollo de software.Actas de la HCII 2007, 58–67.
Duraisamy, G. y Atan, R. (2013). Matriz de trazabilidad de requerimientos a través de documentación para metodología SCRUM.
Revista de Tecnología de la Información Teórica y Aplicada,52(2), 154–159.
Dyba, T. (2013). Contextualización de la evidencia empírica.Software IEEE,30(1), 81–83.
https://doi.org/10.1109/MS.2013.4
Eloranta, vicepresidente, Koskimies, K. y Mikkonen, T. (2016). Explorando ScrumBut - Un estudio empírico de Scrum anti-
patrones.Tecnología de la información y el software,74, 194–203. https://doi.org/10.1016/j.infsof.2015.12.003
Esbensen, M., Tell, P., Cholewa, JB, Pedersen, MK y Bardram, J. (2015). El dBoard: un tablero Scrum digital
para el Desarrollo de Software Distribuido.Actas de la Conferencia Internacional 2015 sobre Mesas y Superficies
Interactivas. https://doi.org/10.1145/2817721.2817746
Esfahani, HC, Yu, E. y Cabot, J. (2010). Evaluación situacional de fragmentos de métodos: un objetivo basado en la evidencia
enfoque orientado.Apuntes de conferencias sobre informática (incluidas las subseries Apuntes de conferencias sobre
inteligencia artificial y Apuntes de conferencias sobre bioinformática),6051 SNC, 424–438. https://doi.org/
10.1007/978-3-642-13094-6_33
Farid, WM (2012). La metodología Normap: ingeniería ligera de requisitos no funcionales para ágil
procesos.Actas - Conferencia de Ingeniería de Software de Asia-Pacífico, APSEC,1, 322–325. https://
doi.org/10.1109/APSEC.2012.23
Feldt, R. y Magazinius, A. (2010). Amenazas de validez en la investigación empírica de ingeniería de software: una encuesta inicial.
SEKE 2010 - Actas del 22º Congreso Internacional de Ingeniería del Software e Ingeniería del
Conocimiento, 374–379.
Ferreira, J., Sharp, H. y Robinson, H. (2011). Diseño de experiencia de usuario y desarrollo ágil: Gestión de la cooperación
a través del trabajo de articulación.Software - Práctica y Experiencia,41(9), 963–974.
https://doi.org/10.1002/spe.1012
Fitzgerald, B., Russo, NL y Stolterman, E. (2002).Desarrollo de sistemas de información: Métodos en acción. McGraw-
Educación de la colina.
Fitzgerald, Brian, Russo, N. y Stolterman, E. (2002).Desarrollo de Sistemas de Información: Métodos en Acción. Forbes
Insights y Scrum Alliance. (2018).LA EMPRESA ÁGIL ELUSIVA: Cómo la mentalidad de liderazgo correcta,
La fuerza laboral y la cultura pueden transformar su organización. https://www.forbes.com/forbes-insights/ourwork/
elusive-agile-enterprise/
Frost, N., Nolas, SM, Brooks-Gordon, B., Esin, C., Holt, A., Mehdizadeh, L. y Shinebourne, P. (2014). Pluralismo
en investigación cualitativa: El impacto de diferentes investigadores y enfoques cualitativos en el análisis de datos
cualitativos.Investigación cualitativa,10(4), 441–460. https://doi.org/10.1177/1468794110366802
Gary, K., Enquobahrie, A., Ibanez, L., Cheng, P., Yaniv, Z., Cleary, K., Kokoori, S., Muffih, B. y Heidenreich, J.
(2011). Métodos ágiles para software crítico de seguridad de código abierto.Software - Práctica y Experiencia,41(9), 945– 962.
https://doi.org/10.1002/spe.1075
Gayer, S., Herrmann, A., Keuler, T., Riebisch, M. y Antonino, PO (2016). Trazabilidad ligera para los ágiles
Arquitecto.Computadora,49(5), 64–71. https://doi.org/10.1109/MC.2016.150
Gerster, D., Dremel, C., Brenner, W. y Kelker, P. (2020). Cómo las empresas adoptan formas ágiles de diseño organizacional:
Un estudio de casos múltiples.Base de Datos de Avances en Sistemas de Información.
https://doi.org/10.1145/3380799.3380807
Gini, C. (1912). Variabilità y mutabilità.Memorie Di Metodologica Statistica. https://doi.org/Cited By (desde 1996)
41\rFecha de exportación 21 de septiembre de 2011
Goede, R. (2011). Almacenamiento de datos ágil: la idoneidad de Scrum como metodología de desarrollo. Enmcsis 2011.
Goldkuhl, G. y Karlsson, F. (2020). La Ingeniería de Métodos como Ciencia del Diseño.Revista de la Asociación de
Sistemas de información,21(5), 1237–1278. https://doi.org/10.17705/1jais.00636
Reverdecimiento, RD (2010). Scrum empresarial: escalar Scrum al nivel ejecutivo.Actas de la Anual de Hawai
Congreso Internacional de Ciencias de Sistemas. https://doi.org/10.1109/HICSS.2010.186
Reverdecimiento, RD (2015). Métricas empresariales ágiles.Actas de la Conferencia Internacional Anual de Hawái sobre
Ciencias del Sistema. https://doi.org/10.1109/HICSS.2015.597
Reverdecimiento, RD (2016). Patrones base ágiles en el canon ágil.Actas del Annual Hawaii International
Congreso de Ciencias de Sistemas,2016-Marzo, 5368–5377. https://doi.org/10.1109/HICSS.2016.664 Griffith, I., Taffahi,
H., Izurieta, C., & Claudio, D. (2014). Un estudio de simulación de métodos prácticos para la deuda técnica
gestión en el desarrollo ágil de software.Actas - Conferencia de simulación de invierno. https://
doi.org/10.1109/WSC.2014.7019961
Haidar, H., Kolp, M. y Wautelet, Y. (2017).Ingeniería ágil de línea de productos: el método AgiFPL.
https://doi.org/10.5220/0006423902750285
Hanschke, S., Ernsting, J. y Kuchen, H. (2015). Integración del desarrollo de software ágil y la arquitectura empresarial
administración.Actas de la Conferencia Internacional Anual de Hawái sobre Ciencias de Sistemas. https://
doi.org/10.1109/HICSS.2015.492
Hanslo, R., Vahed, A. y Mnkandla, E. (2020). Análisis Cuantitativo del Framework Scrum.Notas de clase en
Procesamiento de información comercial,376 LNBIP, 82–107. https://doi.org/10.1007/978-3-030-37534-8_5 Harvie, DP y
Agah, A. (2016). Scrum dirigido: aplicación del mando tipo misión al desarrollo ágil de software.
Transacciones IEEE sobre ingeniería de software,42(5), 476–489. https://doi.org/10.1109/TSE.2015.2489654 Harzing,
AWK y van der Wal, R. (2008). Google Scholar como nueva fuente para el análisis de citas.Ética en la ciencia
y Política Ambiental,8(1), 61–73. https://doi.org/10.3354/esep00076
Hasnain, E. y Hall, T. (2009). Introducción a las reuniones de pie en métodos ágiles.Actas de la conferencia AIP.
https://doi.org/10.1063/1.3146182
Hassan, NR y Mathiassen, L. (2018). Destilar un cuerpo de conocimiento para el desarrollo de sistemas de información.
Revista de sistemas de información,28(1), 175–226. https://doi.org/10.1111/isj.12126
Heeager, LT y Rose, J. (2015). Optimización de prácticas de desarrollo ágil para la operación de mantenimiento: nueve
heurísticas.Ingeniería de software empírica,20(6), 1762–1784. https://doi.org/10.1007/s10664-014-9335-7
Heikkila, VT, Damian, D., Lassenius, C. y Paasivaara, M. (2015). Un estudio de mapeo sobre ingeniería de requisitos
en Desarrollo Ágil de Software.Actas - 41st Euromicro Conference on Software Engineering and Advanced
Applications, SEAA 2015, 199–207. https://doi.org/10.1109/SEAA.2015.70
Heikkila, VT, Paasivaara, M. y Lassenius, C. (2013). ScrumPero, pero ¿importa? Un estudio de método mixto de la
proceso de planificación de una organización Scrum de varios equipos.Simposio Internacional de Ingeniería y
Medición Empírica de Software, 85–94. https://doi.org/10.1109/ESEM.2013.27
Heikkilä, VT, Paasivaara, M., Lasssenius, C., Damian, D. y Engblom, C. (2017). Gestión del flujo de requisitos
de la estrategia al lanzamiento en el desarrollo ágil a gran escala: un estudio de caso en Ericsson.Ingeniería de
software empírica, 1–45. https://doi.org/10.1007/s10664-016-9491-z
Heikkilä, VT, Paasivaara, M., Rautiainen, K., Lassenius, C., Toivola, T. y Järvinen, J. (2015). Liberación operativa
planificación en scrum a gran escala con múltiples partes interesadas: un estudio de caso longitudinal en la corporación F-
secure. Tecnología de la información y el software. https://doi.org/10.1016/j.infsof.2014.09.005
Higuchi, MM y Nakano, DN (2017). Diseño Agile: Un Modelo Combinado Basado en Design Thinking y Agile
Metodologías para Proyectos de Juegos Digitales.Revista de Gestión y Proyectos. https://doi.org/10.5585/gep.v8i2.528
Hoda, R. y Murugesan, LK (2016). Desafíos de gestión de proyectos ágiles de varios niveles: un equipo autoorganizado
perspectiva.Revista de Sistemas y Software. https://doi.org/10.1016/j.jss.2016.02.049
Hoda, R., Salleh, N., Grundy, J. y Tee, HM (2017). Revisiones sistemáticas de literatura en desarrollo ágil de software:
Un estudio terciario.Tecnología de la información y el software,85, 60–70. https://doi.org/10.1016/j.infsof.2017.01.007
Hodgetts, P. (2005). Experiencias que integran prácticas sofisticadas de diseño de experiencia de usuario en procesos ágiles.
Actas - Conferencia AGILE 2005. https://doi.org/10.1109/ADC.2005.24
Hofman, P., Stenzel, T., Pohley, T., Kircher, M. y Bermann, A. (2012). Modelado de características específicas de dominio para
líneas de productos de software.Actas de la 16ª Conferencia Internacional de Línea de Productos de Software sobre - SPLC '12
- Volúmen 1. https://doi.org/10.1145/2362536.2362568
Hossain, E., Babar, MA, Paik, H. y Verner, J. (2009). Procesos de identificación y mitigación de riesgos para el uso de Scrum
en Desarrollo de software global: un marco conceptual.2009 16.ª Conferencia de ingeniería de software de Asia-
Pacífico, 457–464. https://doi.org/10.1109/APSEC.2009.56
Hron, M. y Obwegeser, N. (2018). Scrum en la práctica: una descripción general de las adaptaciones de Scrum.Actas del 51
HawáiInternationalConferenceonSystemSciences,5445–5454. http://pure.au.dk/portal/files/
120140100/paper0681.pdf
Ionica, A., Leba, M. y Dovleac, R. (2017). Una integración de modelo basada en QFD en el desarrollo de software Agile.ibérico
Conferencia sobre Sistemas y Tecnologías de la Información, CISTI. https://doi.org/10.23919/CISTI.2017.7975995
Jakobsen, CR y Johnson, KA (2008). Agile maduro con un toque de CMMI.Actas - Conferencia Agile 2008,
212–217. https://doi.org/10.1109/Agile.2008.10
Jalali, S. y Wohlin, C. (2010). Prácticas ágiles en ingeniería de software global: un mapa sistemático.Actas - 5º
Conferencia Internacional sobre Ingeniería de Software Global, ICGSE 2010, 45–54. https://doi.org/
10.1109/ICGSE.2010.14
James, M. (2010).Tarjeta de referencia de Scrum. Nueva Sociedad.
Kalenda, M., Hyna, P. y Rossi, B. (2018). Escalamiento ágil en grandes organizaciones: prácticas, desafíos y éxito
factoresJournal of Software: Evolución y Proceso,30(10), e1954. https://doi.org/10.1002/smr.1954 Kayes, I., Sarker, M. y Chakareski, J.
(2016). Clasificación de la acumulación de productos: un estudio de caso sobre la medición de la calidad de las pruebas en scrum.
Innovaciones en Ingeniería de Sistemas y Software,12(4), 303–317. https://doi.org/10.1007/s11334-016-0271-0 Keen,
PGW (1980). Investigación MIS: disciplinas de referencia y una tradición acumulada.Conferencia Internacional sobre
Sistemas de información.
Kettunen, P. (2009). Adoptar lecciones clave de la fabricación ágil al desarrollo ágil de productos de software-A
estudio comparativo.Tecnonovacion,29(6–7), 408–422. https://doi.org/10.1016/j.technovation.2008.10.003 Kikitamara,
S. y Noviyanti, AA (2018). Un modelo conceptual de la experiencia del usuario en la práctica de Scrum.2018 10
Congreso Internacional de Tecnologías de la Información e Ingeniería Eléctrica, 581–586.
Kitchenham, BA (2007).Pautas para realizar revisiones sistemáticas de literatura en ingeniería de software. Keele
Universidad.
Kitchenham, B., Pretorius, R., Budgen, D., Brereton, OP, Turner, M., Niazi, M. y Linkman, S. (2010). Sistemático
revisiones de literatura en ingeniería de software: un estudio terciario.Tecnología de la información y el software,8, 60–70.
https://doi.org/10.1016/j.infsof.2010.03.006
Knudsen, EI (1975).Análisis cualitativo de datos: un libro de consulta de nuevos métodos(vol. 51, número 2).
https://doi.org/10.1016/0300-9629(75)90395-3
Koc, G., Aydos, M. y Tekerek, M. (2019). Evaluación del empleo confiable de Scrum para software ágil
Desarrollo basado en las Vistas de los Desarrolladores de Software.UBMK 2019 - Actas, 4ta Conferencia
Internacional de Ciencias e Ingeniería Informática. https://doi.org/10.1109/UBMK.2019.8907213
Lee, G. y Xia, W. (2010). Hacia ágil: un análisis integrado de datos de campo cuantitativos y cualitativos sobre software
agilidad de desarrollo.MIS Trimestral: Sistemas de información gerencial,34(1), 87–114.
Lee, S. y Yong, H.-S. (2010). Agile distribuido: gestión de proyectos en un entorno global.Software empírico
Ingeniería,15(2), 204–217. https://doi.org/10.1007/s10664-009-9119-7
Lehnen, J., Schmidt, TS y Herstatt, C. (2016). Llevar la gestión ágil de proyectos a los proyectos de los usuarios principales.
Revista internacional de desarrollo de productos,21(2–3), 212–232. https://doi.org/10.1504/IJPD.2016.078867 Li, C., van
den Akker, M., Brinkkemper, S. y Diepen, G. (2010). Un enfoque integrado para la selección de requisitos
y programación en la planificación de versiones de software.Ingeniería de requisitos,15(4), 375–396. https://
doi.org/10.1007/s00766-010-0104-x
Lous, P., Kuhrmann, M. y Tell, P. (2017). ¿Scrum es apto para la ingeniería de software global?Actas - 2017 IEEE
12ª Conferencia Internacional sobre Ingeniería de Software Global, ICGSE 2017. https://doi.org/
10.1109/ICGSE.2017.13
Lyytinen, K. y Rose, GM (2006). Desarrollo de Sistemas de Información Agilidad como Aprendizaje organizacional.europeo
Revista de Sistemas de Información,15(2), 183–199. https://doi.org/10.1057/palgrave.ejis.3000604 MacCormack, A. y
Verganti, R. (2003). Gestión de las fuentes de incertidumbre: proceso de emparejamiento y contexto en
desarrollo de software.Revista de gestión de la innovación de productos,20, 217–232. https://doi.org/10.1111/1540-
5885.2003004
Madison, J. (2010). ágil y arquitectura Interacciones ágiles-arquitectura.Software IEEE,27(2), 41–48.
https://doi.org/10.1109/MS.2010.27
Maier, P., Ma, Z. y Bloem, R. (2017). Hacia un proceso SCRUM seguro para el desarrollo ágil de aplicaciones web.
Actas de la 12.ª Conferencia Internacional sobre Disponibilidad, Confiabilidad y Seguridad - ARES '17, 1–8.
https://doi.org/10.1145/3098954.3103171
Masood, Z., Hoda, R. y Blincoe, K. (2020). Real World Scrum Una teoría fundamentada de las variaciones en la práctica.IEEE
Transacciones en Ingeniería de Software. https://doi.org/10.1109/tse.2020.3025317 McMahon, PE (2016). CMMI
de forma ágil en entornos limitados y regulados.Diafonía. Mendonça, Letícia Thaís, et al. (2014). Un sistema de
soporte Scrum integrado a un entorno de gestión de proyectos web.
29 Congreso Internacional de Computadores y sus Aplicaciones, CATA 2014.
Miranda, E. y Bourque, P. (2010). Seguimiento ágil utilizando la línea de equilibrio.Revista de Sistemas y Software,
83(7), 1205–1215. https://doi.org/10.1016/j.jss.2010.01.043
Moe, NB y Aurum, A. (2008). Comprender la toma de decisiones en el desarrollo ágil de software: un estudio de caso.
EUROMICRO 2008 - Actas de la 34ª Conferencia EUROMICRO sobre Ingeniería de Software y Aplicaciones
Avanzadas, SEAA 2008. https://doi.org/10.1109/SEAA.2008.55
Morales Trujillo, M., Oktaba, H., Pino, FJ, & Orozco, MJ (2011). Aplicación de prácticas ágiles y lean en un software
proyecto de desarrollo en una organización CMMI.Apuntes de conferencias sobre informática (incluidas las subseries Apuntes
de conferencias sobre inteligencia artificial y Apuntes de conferencias sobre bioinformática). https://doi.org/
10.1007/978-3-642-21843-9_4
Øvad, T., Bornoe, N., Larsen, LB y Stage, J. (2015). Enseñar a los desarrolladores de software a realizar tareas de UX.
Actas de la reunión anual del grupo australiano de interés especial para la interacción humana entre computadoras en
- OzCHI '15, 397–406. https://doi.org/10.1145/2838739.2838764
Paasivaara, M., Durasiewicz, S. y Lassenius, C. (2009). Uso de scrum en el desarrollo ágil distribuido: un múltiplo
caso de estudio.Actas - 2009 4ta Conferencia Internacional IEEE sobre Ingeniería de Software Global, ICGSE
2009. https://doi.org/10.1109/ICGSE.2009.27
Paasivaara, M. y Lassenius, C. (2011). Escalando Scrum en un gran proyecto distribuido.Simposio Internacional 2011
en Ingeniería Empírica de Software y Medición. https://doi.org/10.1109/ESEM.2011.49
Paasivaara, M., Lassenius, C. y Heikkilä, VT (2012). Coordinación entre equipos en gran escala distribuida globalmente
melé.Actas del Simposio internacional ACM-IEEE sobre ingeniería y medición empíricas de software
- ESEM '12, 235. https://doi.org/10.1145/2372251.2372294
Padmini, KVJ, Dilum Bandara, HMN y Perera, I. (2015). Uso de métricas de software en software ágil
proceso de desarrollo.MERCon 2015 - Conferencia de investigación de ingeniería de Moratuwa.
https://doi.org/10.1109/MERCon.2015.7112365
Palomino, M., Dávila, A., Meléndez, K., & Pessoa, M. (2017). Adopción de prácticas ágiles en organizaciones CMMI: A
revisión sistemática de la literatura.Avances en Sistemas Inteligentes y Computación,537, 57–67. https://
doi.org/10.1007/978-3-319-48523-2_6
Paré, G., Trudel, MC, Jaana, M. y Kitsiou, S. (2015). Sintetizando el conocimiento de los sistemas de información: Una tipología de
criticas literarias.Información y Gestión,52(2), 183–199. https://doi.org/10.1016/j.im.2014.08.008 Pastrana, M.,
Ordóñez, H., Ordóñez, A., & Merchan, L. (2017). Obtención de requisitos basada en la plataforma de inicio y
modelos de procesos de negocio en scrum.Comunicaciones en Informática y Ciencias de la Información,735, 327–339.
https://doi.org/10.1007/978-3-319-66562-7_24
Peixoto, CSA (2009). Sistema experto de interfaz humano-computadora para métodos ágiles.Actas de la Internacional
Conferencia sobre Interfaces de Tecnologías de la Información, ITI. https://doi.org/10.1109/ITI.2009.5196100
Rahman, SSMM, Mollah, SA, Anirban, S., Rahman, MH, Rahman, M., Hassan, MM y Sharif, MH
(2018). OSCRUM: Un scrum modificado para el desarrollo de software de código abierto.Revista Internacional
de Simulación: Sistemas, Ciencia y Tecnología,19(3), 20–21. https://doi.org/10.5013/IJSSST.a.19.03.20 Ramesh,
B., Cao, L., Kim, J., Mohan, K. y James, TL (2017). Conflictos y complementos entre culturas orientales
y métodos ágiles: una investigación empírica.Revista Europea de Sistemas de Información. https://
doi.org/10.1057/s41303-016-0023-0
Roth, AP (2019).Significado y método en las ciencias sociales: un caso de pluralismo metodológico. Cornell
Prensa Universitaria.
Rubart, J. y Freykamp, F. (2009). Apoyar las reuniones diarias de scrum con estructura de cambio.actas del 20
Conferencia ACM sobre Hipertexto e Hipermedia. https://doi.org/10.1145/1557914.1557927
Santos, AR, Sales, A., Fernandes, P., & Nichols, M. (2015). Combinando el aprendizaje basado en desafíos y Scrum
Framework para el desarrollo de aplicaciones móviles.Actas de la Conferencia ACM 2015 sobre Innovación y
Tecnología en la Educación en Ciencias de la Computación - ITiCSE '15. https://doi.org/10.1145/2729094.2742602
Santos, N., Fernandes, JM, Carvalho, MS, Silva, PV, Fernandes, FA, Rebelo, MP, Barbosa, D., Maia, P.,
Couto, M. y Machado, RJ (2016). Uso de Scrum junto con modelos UML: un proyecto de software de I+D colaborativo
entre la universidad y la industria. EnCongreso Internacional de Ciencias Computacionales y sus Aplicaciones (págs.
480–495). Saltador. https://doi.org/10.1007/978-3-319-42089-9_34
Santos, N., Fernandes, JM, Sameiro Carvalho, M., Silva, PV, Fernandes, FA, Rebelo, MP, Barbosa, D., Maia,
P., Couto, M. y Machado, RJ (2016). Uso de scrum junto con modelos UML: un proyecto de software de I+D colaborativo
universidad-industria.Apuntes de conferencias sobre informática (incluidas las subseries Apuntes de conferencias sobre
inteligencia artificial y Apuntes de conferencias sobre bioinformática). https://doi.org/10.1007/978-3-319-42089-9_34 Schar, B.,
Jungling, S. y Thonssen, B. (2016). Hacia una combinación ágil de procesos de ingeniería de requisitos
HERMES 5 y SCRUM.Actas - 2015 3ra Conferencia Internacional sobre Sistemas Empresariales, ES 2015. https://
doi.org/10.1109/ES.2015.17
Schlauderer, S. y Overhage, S. (2015). ¿Ampliamente utilizado pero también muy valorado? Factores de aceptación y sus
Percepciones en Proyectos Water-Scrum-Fall.icis, 1–19.
Schwaber, K. (1995). Proceso de desarrollo SCRUM. EnDiseño e Implementación de Objetos de Negocio(págs. 117–134).
https://doi.org/10.1007/978-1-4471-0947-1_11
Schwaber, K. (2007).La empresa y Scrum. Prensa de
Microsoft. Schwaber, K. y Sutherland, J. (2020). los 2020 Melé Guía.
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100
Schwarzer, J., Draheim, S., von Luck, K., Wang, Q., Casaseca, P. y Grecos, C. (2016). Superficies Ambientales: Interactivo
Se muestra en el espacio de trabajo informativo de los equipos Scrum coubicados.Actas de la 9.ª Conferencia Nórdica
sobre Interacción Humano-Ordenador - NordiCHI '16. https://doi.org/10.1016/S0140-6736(15)00947-2 Escocia, K. y
Boutin, A. (2008). Integrando scrum con el marco de procesos en Yahoo! Europa.Procedimientos -
Conferencia Ágil 2008. https://doi.org/10.1109/Agile.2008.22
Sedeño, J., Schön, E.-M., Torrecilla-Salinas, C., Thomaschewski, J., Escalona, MJ, & Mejías, M. (2017). Modelado
Requerimientos ágiles usando Historias de Persona basadas en Contexto.Actas de la 13ª Conferencia Internacional sobre
Tecnologías y Sistemas de Información Web, 196–203. https://doi.org/10.5220/0006220301960203 Sharma, R. y Wherry, B.
(2009). Desarrollo de software para la producción de largometrajes animados de Disney.Procedimientos -
Conferencia Ágil 2009, ÁGIL 2009, 410–415. https://doi.org/10.1109/AGILE.2009.60
Sikamani, TK y Raj Dharmapal, S. (2016). Uso de Key Six Sigma y Lean Metrics en la metodología Agile Scrum
para la mejora del rendimiento.Revista internacional de investigación en ingeniería aplicada ISSN,11(6), 973–4562.
Silva, RR, Kimura, FY, Bernardino, J., & De Castro Lima, J. (2017). Proceso personalizado a la pequeña empresa.
Actas del Congreso Internacional de Ingeniería del Software e Ingeniería del Conocimiento, SEKE, 622. https://
doi.org/10.18293/SEKE2017-31
Singh, M. (2008). U-SCRUM: Una metodología ágil para promover la usabilidad.Actas - Conferencia Agile 2008,
555–560. https://doi.org/10.1109/Agile.2008.33
Spitzer, RL, Cohen, J., Fleiss, JL y Endicott, J. (1967). Cuantificación de la Concordancia en el Diagnóstico Psiquiátrico: A
Nuevo enfoque.Archivos de Psiquiatría General,17(1), 83–87.
Stålhane, T., Myklebust, T. y Hanssen, G. (2012). La aplicación de scrum seguro al software certificable IEC 61508.
11ª Conferencia Internacional de Gestión y Evaluación Probabilística de la Seguridad y Conferencia Anual
Europea de Seguridad y Fiabilidad 2012, PSAM11 ESREL 2012. https://doi.org/10.1109/ICSE.2013.6606635 Stray,
VG, Lindsjorn, Y. y Sjoberg, DIK (2013). Obstáculos para las reuniones diarias eficientes en el desarrollo ágil
proyectos: un estudio de caso.Simposio Internacional de Ingeniería y Medición Empírica de Software. https://
doi.org/10.1109/ESEM.2013.30
Streule, T., Miserini, N., Bartlomé, O., Klippel, M. y de Soto, BG (2016). Implementación de Scrum en el
Industria de construccion.Ingeniería de procedimientos,164, 269–276. https://doi.org/10.1016/j.proeng.2016.11.619
Streule, T., Miserini, N., Bartlomé, O., Klippel, M., & De Soto, BG (2016). Implementación de Scrum en el
Industria de construccion.Ingeniería de procedimientos,164, 269–276. https://doi.org/10.1016/j.proeng.2016.11.619 Sungkur,
RK y Ramasawmy, M. (2014). Knowledge4Scrum, una novedosa herramienta de gestión del conocimiento para ágiles
equipos distribuidos.ENREDADERA,44(3), 394–419. https://doi.org/10.1108/VINE-12-2013-0068
Sutherland, J. (2005). Futuro de scrum: canalización paralela de sprints en proyectos complejos.Trámites - AGILE
Conferencia 2005,2005, 90–99. https://doi.org/10.1109/ADC.2005.28
Sutherland, J., Jakobsen, CR y Johnson, K. (2007). Scrum y CMMI nivel 5: La poción mágica para los guerreros del código.
Actas - AGILE 2007, 272–277. https://doi.org/10.1109/AGILE.2007.52
Suwanya, S. y Kurutach, W. (2009). Aplicación del marco de agilidad en las pequeñas y medianas empresas.Comunicaciones
en Informática y Ciencias de la Información,59 CCIS, 102–110. https://doi.org/10.1007/978-3-642-10619-4_13 Szoke, A.
(2010). Distribución de funciones optimizada en entornos ágiles distribuidos.Apuntes de clase en informática
(Incluyendo Subseries Apuntes de conferencias sobre inteligencia artificial y Apuntes de conferencias sobre bioinformática).
https://doi.org/10.1007/978-3-642-13792-1_7
Tanveer, M. (2016). Ágil para proyectos a gran escala: un enfoque híbrido.2015 Ingeniería Nacional de Software
Conferencia, NSEC 2015. https://doi.org/10.1109/NSEC.2015.7396338
Tuomikoski, J. y Tervonen, I. (2009). Absorbiendo las pruebas de software en el método scrum.Notas de clase en negocios
Procesamiento de información, 199–215. https://doi.org/10.1007/978-3-642-02152-7_16
Turk, D., Francia, R. y Rumpe, B. (2005). Supuestos subyacentes a los procesos ágiles de desarrollo de software.Diario
de Gestión de Base de Datos,57, 52–65. https://doi.org/10.4018/jdm.2005100104
Vallon, R., da Silva Estácio, BJ, Prikladnicki, R. y Grechenig, T. (2018). Revisión sistemática de la literatura sobre ágil
prácticas en el desarrollo global de software.Tecnología de la información y el software,96, 161–180. https://
doi.org/10.1016/j.infsof.2017.12.004
Versión Uno. (2018).12º informe anual sobre el estado de Agile. https://explore.versionone.com/state-of-agile
VersionOne. (2020).14.º Informe anual sobre el estado de Agile.
Vlietland, J., Van Solingen, R. y Van Vliet, H. (2016). Alinear equipos Scrum codependientes para permitir negocios rápidos
entrega de valor: un marco de gobernanza y un conjunto de acciones de intervención.Revista de Sistemas y Software,113,
418–429. https://doi.org/10.1016/j.jss.2015.11.010
Vlietland, J. y Van Vliet, H. (2015). Hacia un marco de gobernanza para cadenas de equipos Scrum.Información y
Tecnología de software,57, 52–65. https://doi.org/10.1016/j.infsof.2014.08.008
Wagner, S. (2014). Scrum para sistemas ciberfísicos: una propuesta de proceso.Actas de la Primera Internacional
Taller de Ingeniería de Software Continuo Rápido - RCoSE 2014, 51–56. https://doi.org/
10.1145/2593812.2593819
Wang, X., Conboy, K. y Cawley, O. (2012). Desarrollo de software “Leagile”: Análisis de un informe de experiencia del
aplicación de enfoques Lean en el desarrollo ágil de software.Revista de Sistemas y Software,85(6), 1287– 1299.
https://doi.org/10.1016/j.jss.2012.01.061
Wang, Y., Bogicevic, I. y Wagner, S. (2017). Un estudio de documentación de seguridad en un proceso de desarrollo Scrum.
Actas de los talleres científicos XP2017, 1–5. https://doi.org/10.1145/3120459.3120482
Wang, Y. y Wagner, S. (2016). Hacia la integración de un análisis de seguridad teórico de sistemas en un desarrollo ágil
proceso.Actas del Taller CEUR.
Wautelet, Y., Heng, S., Hitea, D., Kolp, M. y Poelmans, S. (2016). Unir conjuntos de historias de usuario con el modelo de caso de uso.
Apuntes de conferencias sobre informática (incluidas las subseries Apuntes de conferencias sobre inteligencia artificial y Apuntes de
conferencias sobre bioinformática). https://doi.org/10.1007/978-3-319-47717-6_11
Webster, J. y Watson, RT (2002). Analizar el pasado para prepararse para el futuro: Escribir una revisión de literatura
ANALIZAR EL PASADO PARA PREPARAR EL FUTURO: ESCRIBIR A.MIS Trimestral,26(2), 13–23. https://
doi.org/10.1.1.104.6570
Wieland, T. (2019). REAT: una caja de herramientas de análisis económico regional para R.REGIÓN,6(3), R1–R57.
https://doi.org/https://doi.org/10.18335/region.v6i3.267

Why and How Is Scrum Being Adapted in - En.es

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Why and How Is Scrum Being Adapted in - En.es

Cargado por

Copyright:

Formatos disponibles

Traducido del inglés al español - www.onlinedoctranslator.

Por qué y cómo se está adaptando Scrum

Aceptado en Journal of Systems and Software

Aceptado en Journal of Systems and Software

modificado contracómose ha modificado, no se ha realizado. Esto viene a expensas de futuros investigadores,

enfoque hacia futuras investigaciones.

adaptado a diferentes contextos?

adaptaciones reportadas con énfasis en el enfoque metodológico utilizado.

métodos, no son metodológicamente transparentes y carecen de detalle en sus resultados.

3 Una breve revisión de Scrum

gráfico descendente, pero también ayuda a planificar el trabajo futuro.

ciencia, sistemas de información, gestión (Besson & Rowe, 2012).

Alcance: 1.762 Proyección de títulos: 1.423 • Objetivo de modificación

FIGURA1: ESTRATEGIA DE BÚSQUEDA Y ANÁLISIS DE LITERATURA PASO A PASO

4.1 Consultas a la base de datos

Los términos y el diccionario de sinónimos se pueden encontrar en la Tabla 1.

TPODER1 SCONSULTA DE BÚSQUEDA ESTRUCTURADA

extender* límite* pedir* Melé,

enfoque* Abajo* alterar*

proceso de cribado y filtrado.

para abordar el desarrollo distribuido (S. Lee & Yong, 2010).

sujeto a selección de títulos y resúmenes.

duda, el artículo fue incluido para una posterior selección de resúmenes.

4.2.1 Selección de títulos

los autores. El kappa de Cohen se calculó de la siguiente manera:

Pr(a) – Pr(e) 0,98 – 0,50

potencialmente relevante basándose únicamente en los títulos.

4.2.2 Selección de resúmenes

dos condiciones obligatorias:

Condición 1: el artículo introduce una modificación o extensión de la metodología Scrum

modificar Scrum motivado por un objetivo explícito.

4.3 Codificación y análisis

Marco teórico Teoría o modelo aplicado a la investigación marco

Recuento de citas Citas de Google Scholar

panorama actual de la investigación.

de springerApuntes de clase en informática(46) yApuntes de clase en el procesamiento de información empresarial(44), como

así como revistas comoTecnología de la información y el software(11) y elRevista de Sistemas y Software(11).

Múltiple Conceptual Único

(227), simulaciones (11) y estudios basados en encuestas (88).

discutiendo los "patrones básicos" de los enfoques ágiles (Greening, 2016).

(mejor), y ejemplos (Tabla 3).

Promedio de citas de Google por año

6 Modificación de objetivos y estrategias

categorías para guiar al lector a través de nuestros hallazgos.

resultados de desarrollo de nivel en planes de lanzamiento, especificaciones técnicas o similares.desarrollo distribuidosubsume

el entorno tradicional de Scrum se capturan en la categoríaEscalado de tamaño.Finalmente, algunos estudios motivan su

(Esbensen et al., 2015).Pre-desarrollose refiere a la introducción de procesos adicionales, artefactos y, a veces,

Modificación metodológico Método Pre-

indicativo de la naturaleza práctica del campo.

2016) o producción de cine animado (Sharma & Wherry, 2009).

como los enumerados anteriormente.

los profesionales ven la necesidad de atender esos procesos más cuidadosamente.

La perspectiva de la usabilidad se refleja en la categoría Experiencia del usuario.

enfoque, observamos Extensiones de Arquitectura y Gerenciales como objetivos de modificación concurrentes.

6.5 Desarrollo Distribuido

generalmente se recomienda compartir entre equipos.

empleados para entornos distribuidos (Banijamali et al., 2017).

et al., 2018) o ingeniería de software global (Jalali & Wohlin, 2010).

6.6 Extensiones Gerenciales

Artefactos 5 7 (Duraisamy & Atán, 2013)

tareas gerenciales. La guía de métodos es la tercera categoría de solución más común.

& Atan, 2013), herramientas como métricas (Greening, 2015).