Modelos Ágiles de desarrollo software para grandes Sistemas de Defensa
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Modelos Ágiles de desarrollo software para
grandes Sistemas de Defensa
Francisco José López García
fjlopezg@gmail.com
Julio 2021
Resumen
Como continuación del artículo sobre los modelos de reutilización
del software para grandes sistemas de defensa[1], en este artículo se
abordan los métodos llamados ágiles aplicados a los mismos. Se ofre-
ce una visión histórica de los métodos iterativos de desarrollo softwa-
re, precursores de la agilidad, mostrándose los conceptos que han ido
evolucionando desde el modelo en espiral hasta llegar al Scrum. Ade-
más, se identifican los principios y valores de la agilidad, y cómo estos
se emplean para la reducción de los tiempos de desarrollo, integra-
ción, pruebas y despliegue. Finalmente se realiza un breve repaso de
los métodos actuales aplicados a grandes sistemas, así como otras
alternativas de desarrollo.
Los métodos ágiles nacieron de la creencia de que una aproxima-
ción basada en la realidad humana, el aprendizaje, la innovación y el
cambio producirían mejores resultados que los métodos tradicionales.
Reseña histórica. Desarrollo iterativo e incremental.
El desarrollo iterativo e incremental es la piedra angular de los métodos ágiles,
donde aspectos como los incrementos de capacidades, la duración de la iteracio-
nes, el número de ellas o la realimentación de los usuarios, son aspectos clave
que se contraponen a las metodologías secuenciales de un solo paso, como lo
es el modelo en cascada (waterfall) .
Las primeras referencias históricas que tenemos están relacionadas con el
programa Mercury de la NASA y con desarrollos de IBM en la “Federal System
Division (FDS)” a principios de 1960. Para este programa ya se emplearon ite-
raciones muy cortas (la mitad de una jornada), revisiones técnicas de todos los
cambios y redacción de pruebas antes de cada micro-incremento. [2]
El mando y control para el primer submarino americano Trident (1972), con
más de un millón de líneas de código, se realizó con técnicas incrementales.
1
V.1 n.2
O´Neill, que fue el jefe del proyecto, planeó y ejecutó esta técnica a la que luego
llamó “Integration engineering”, organizando el proyecto en cuatro incrementos
de seis meses cada uno. [3]
También, en 1972 el proyecto de defensa balística para el ejército de tierra
americano, con un presupuesto de 100 millones de dólares, se desarrolló en cinco
iteraciones.
Otro megaproyecto coetáneo de IBM FSD, para la marina americana, es el
LAMPS (Light Airbone Multipurpose System), con el cual un buque extiende su
esfera de influencia mediante el uso de un helicóptero. Un proyecto de cuatro
años, desarrollado en 45 iteraciones, empleando a 200 personas-año y que inte-
gra siete millones de sentencias en ocho procesadores distintos.[4]
Un programa de éxito empleando estas técnicas, y realizado también con
la colaboración de IBM FSD, fue el software del transbordador espacial (Space
Shuttle) de la NASA. Desarrollado a partir de octubre de 1977 con 17 liberacio-
nes en 31 meses. En diciembre de 1978 el software estaba completo después
de nueve liberaciones, pero fueron necesarias 8 iteraciones más para incluir los
cambios de requisitos y actividades de corrección de discrepancias inherentes a
un programa grande, complejo y desarrollado por primera vez.[5]
A nivel académico, ya en 1975 Vic Basili and Joe Turner publican el artícu-
lo “Iterative Enhancement: A Practical Technique for Software Development ” [6],
donde se apuesta por el desarrollo del software de forma incremental. Se promue-
ve empezar con una implementación de un conjunto simple de requisitos, y de
forma iterativa ir creciendo y evolucionando el sistema con versiones sucesivas
hasta completarlo.
En 1985 Barry Boehm´s publica el modelo en espiral para el desarrollo softwa-
re, basado en su experiencia en la empresa TRW [7]. Con este modelo se prima
el análisis de riesgos, frente a una aproximación orientada a la documentación.
El modelo en espiral necesitaba ser parti-
cularizado para cada proyecto por perso-
nal experto en las áreas de contrato, es-
pecificación, hitos, revisión, planificación,
control y riesgos. Posteriormente en el año
2000 el propio Boehm aclaró el modelo en
el “Spiral Development Workshop”[8], don-
de se remarcan dos ideas fundamentales:
(1) se sigue una aproximación cíclica me-
diante la cual el sistema crece de forma
incremental mientras decrece el nivel de
riesgo, y (2) se establecen unos puntos de
control mediante los cuales nos asegura-
mos que las partes interesadas están sa- Figura 1 Modelo en espiral [7].
tisfechas con la solución encontrada.
En la segunda mitad de los años 90 el empleo del desarrollo incremental e
iterativo se populariza, apareciendo muchos métodos de este tipo. Este cambio
de mentalidad viene provocado por la gran cantidad de proyectos fracasados que
han seguido el estándar DoD-Std-2167 (1985) o la 2167A (1988),a pesar de ser el
estándar empleado durante años por los programas de defensa. . La Mil-Std-498
2/13
V.1 n.2
de 1994, que sustituye a las anteriores, ya describe que el desarrollo software
puede realizarse en uno o más incrementos, y para cada versión del software se
pueden superponer las distintas fases de forma iterativa. Finalmente, en el año
2000 la 498 fue reemplazada por el estándar DoD 5000.2, el cual recomienda
adoptar modelos evolutivos de adquisición o compra, así como técnicas iterativas
que expandan continuamente las capacidades de las versiones software.
Los métodos RAD (Rapid Application Development) fueron formalizados en
1991 por J. Martin [9] para distinguirlos de los métodos tradicionales en cascada.
Los métodos RAD se diseñan para un desarrollo más rápido y con más calidad.
Se basan en cuatro aspectos fundamentales: herramientas, metodología, per-
sonas y gestión de estas (management). Un ciclo de cuatro fases consiste en
la realización de la planificación de los requisitos, el diseño del usuario, la
construcción y la transición. En RAD se realizan sucesivas iteraciones, refina-
mientos y movimientos desde el prototipo al sistema final.
El método Rational Unified Process (RUP), basado en el anterior, es el de-
sarrollado por la empresa Rational Software (IBM), el cual fue descrito por Ivar
Jacobson, Grady Booch y James Rumbaugh en 1999. [10]
En la figura 2 se muestran las dos di-
mensiones del método[11]. El eje horizon-
tal se aprecian los aspectos dinámicos del
proceso del ciclo de vida divididos en cua-
tro fases: inicio, elaboración, construc-
ción y transición, dentro de las cuales se
realizan varias iteraciones en número va-
riable según el proyecto. El eje vertical re-
presenta las disciplinas tales como requisi-
tos, análisis, diseño e implementación. La
figura muestra como las iteraciones están
Figura 2 RUP
presentes en todas las disciplinas, sin em-
bargo, el énfasis varía en el tiempo.
RUP identifica 6 “buenas prácticas”, con las que los equipos de desarrollo
software trabajan de forma efectiva. (1) Gestión de requisitos, utilizando la nota-
ción de casos de uso y escenarios para representar los requisitos. (2) Desarrollo
software iterativo, con hitos especificados y en donde las actividades se repiten,
pero con distinto énfasis dependiendo de la fase del proyecto. (3) Desarrollo ba-
sado en componentes, donde el sistema se divide, en interfaces bien definidas.
(4) Modelado visual, usando UML (Unified Modeling Language) como lenguaje
visual para especificar, construir y documentar el software. (5) Verificación con-
tinua de la calidad, especialmente al final de cada iteración. (6) Gestión de los
cambios, mediante la cual se coordinan las acciones de cambio, en cualquier
fase del proceso ..
Metodologías ágiles
En 1999, Jeff Sutherland y otros, describen el método “SCRUM“ que utiliza
periodos de tiempo de 30 días por cada iteración [12]. El método toma su inspira-
ción de la aproximación japonesa empleada en los años ochenta para productos
3/13
V.1 n.2
de Honda, Canon y Fujitsu y descrita por Hirotaka Takeuchi y Ikujiro Nonaka como
una aproximación ágil. [13].
Asimismo, sobre finales de los noventa Kent Beck introduce el concepto de
Programación Extrema (Extreme Programming).[14]
Los principios de agilidad están muy presentes en la programación extrema
ya que ésta se basa en una planificación abierta y flexible, el desarrollo iterati-
vo e incremental, el equipo humano como fuente principal del éxito, el software
funcionando por encima de la documentación, la interacción continua del cliente
con los desarrolladores, así como en la respuesta rápida y eficaz ante posibles
cambios.
Además, la programación extrema se desarrolla teniendo en cuenta cinco va-
lores fundamentales: (1) Comunicación, entre los miembros del equipo y con los
clientes, rompiendo las barreras entre negocio y desarrollo. (2) Simplicidad, rea-
lizando una programación lo más simple posible, simplificando los diseños y re-
factorizando o rehaciendo el código conforme va creciendo. (3) Realimentación
(Feedback), integrando al cliente en el proyecto, realizando ciclos muy cortos de
desarrollo y mostrando continuamente los resultados. (4) Respeto, de tal forma
que el equipo pueda trabajar de forma eficiente y ofrecer un buen rendimiento.
(5) Valentía, diseñar y programar para hoy, no para el mañana, reconociendo los
errores tan pronto como se detecten.
En febrero de 2001, diecisiete impulsores de metodologías “ligeras” para el
desarrollo de software convocados por Kent Beck, se reunieron en Snowbird,
(Utah) para tratar sobre técnicas de desarrollo software. En la reunión se acuñó
el término “Métodos Ágiles” como alternativa a las metodologías formales que se
consideraban excesivamente “pesadas”. Los principios quedaron plasmados en
lo que se ha llamado el Manifiesto Ágil [15]
Figura 3 Manifiesto Ágil[15]
4/13
V.1 n.2
Principios del Manifiesto Ágil
Tras los cuatro valores descritos, los firmantes redactaron los principios que
de ellos se derivan[16]:
• Nuestra principal prioridad es satisfacer al cliente a través de la entre-
ga temprana y continua de software con valor. Software funcionando y
útil en pocas semanas.
• Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos ágiles aprovechan el cambio para proporcio-
nar ventaja competitiva al cliente. Los cambios han de asumirse como
parte del proceso de maduración.
• Entregamos software funcional frecuentemente, entre dos semanas y
dos meses, con preferencia al período de tiempo más corto posible. El
cliente se motiva viendo el software funcionando.
• Los responsables del negocio y los desarrolladores trabajamos juntos
de forma cotidiana durante todo el proyecto. La intervención temprana
de los usuarios puede reducir el costo y el tiempo.
• Los proyectos se desarrollan en torno a individuos motivados. Hay
que darles el entorno y el apoyo que necesitan, y confiarles la ejecu-
ción del trabajo. El ánimo, sentido de pertenencia y disposición del equipo,
son fundamentales en el proyecto software.
• El método más eficiente y efectivo de comunicar información al equipo
de desarrollo y entre sus miembros es la conversación cara a cara.
Establecer un buen sistema de comunicación.
• El software funcionando es la medida principal de progreso. El usuario
da realimentación conforme va utilizando el software aprobado..
• Los procesos ágiles promueven el desarrollo sostenido. Los promoto-
res, desarrolladores y usuarios debemos mantener un ritmo constante
de forma indefinida. Mantener ciclos sostenidos y constantes durante el
desarrollo.
• La atención continua a la excelencia técnica y al buen diseño mejora la
agilidad. La calidad vista desde el punto de vista del equipo y del usuario.
• La simplicidad, o el arte de maximizar la cantidad de trabajo no reali-
zado, es esencial. El equipo ha de centrarse en lo importante.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos
auto-organizados. Principio de responsabilidad colectiva.
• A intervalos regulares, el equipo reflexiona sobre cómo ser más efecti-
vo para, a continuación, ajustar y perfeccionar su comportamiento en
consecuencia. Estudiar el cambio para mejorar.
5/13V.1 n.2
SCRUM
Scrum es uno de los métodos ági-
les que sigue los principios anteriores,
es en la actualidad uno de los más po-
pulares y mayoritariamente implanta-
do en muchas organizaciones. Así se
muestra en “14th Annual State of Agi-
le Report” [17] donde se recoge la opi-
nión de más de 40.000 ejecutivos, pro-
fesionales y consultores que han par-
ticipado respondiendo a una encuesta
sobre la implantación de “Agile” desde
su inicio.
Figura 4 Metodologías Ágiles usadas [18]
En Scrum, tal y como se muestra
en la figura 5, el desarrollo se estruc-
tura en iteraciones o ciclos de trabajo llamados Sprints[18]. Cada uno de ellos
dura un tiempo fijo que dependiendo del proyecto se puede establecer entre una
y cuatro semanas.
El modelo Scrum está diseñado para optimizar la flexibilidad, la creatividad y
la productividad, definiéndose los siguientes tres roles:
• El propietario del producto (Product Owner), que se asegura de maximi-
zar el valor del producto y para ello gestiona la pila de producto (Product
Backloog) o fuente de requisitos/expectativas del producto, ordenándola,
optimizándola y haciendo que está sea entendible por el equipo.
• El equipo de desarrollo (Development Team), que es el encargado de rea-
lizar el trabajo para entregar un incremento de producto terminado en cada
Sprint. El equipo se autogestiona, es multifuncional, y es el responsable
en su conjunto, de la entrega. El equipo está formado por 7 ± 2 personas
y ha de incluir perfiles con conocimientos en análisis, desarrollo, pruebas,
interfaces, bases de datos, arquitectura y otros.
• El facilitador (Scrum Master), que es el responsable de que el equipo tra-
baje ajustándose a la teoría, realizando la función de interface entre las
personas externas y el equipo de desarrollo.
Se utilizan los siguientes artefactos:
• La pila de producto, donde se enumeran todas las características, fun-
cionalidades, requisitos, mejoras y correcciones, ordenados por orden de
prioridad, a realizar en las siguientes entregas.
• La lista de tareas del sprint (Sprint Backlog) que es el subconjunto se-
leccionado de elementos de la pila de producto que se desarrollarán en el
sprint actual, junto con su plan de realización.
• El incremento (Increment), la suma de todos los ítems usables de la lista
de tareas del sprint completadas por los desarrolladores, que satisfacen la
6/13V.1 n.2
“definición de hecho” más todos los incrementos realizados con anterio-
ridad, donde definición de hecho (Definition of Done), es el compromiso
acordado por todas las partes conforme a los estándares, convenciones y
guías de que algo se puede dar por realizado y concluido, es decir “hecho”.
Se realizan los siguientes eventos:
• El sprint es el corazón de Scrum y es donde las ideas se convierten en va-
lor. Cada sprint comienza cuando acaba el anterior y todo el trabajo necesa-
rio para alcázar el objetivo del producto, incluidas las siguientes reuniones
ocurren dentro del sprint.
• Reunión de planificación del sprint (sprint planning meeting), donde el
equipo decide que se desarrollará para el siguiente sprint en diálogo con
el propietario del producto. El equipo estudia la pila de producto para com-
prender el trabajo a realizar y se selecciona la cantidad de ítem que estiman
incluir en el sprint, siempre utilizando la priorización realizada por el propie-
tario del producto.
• Scrum diario (Daily Scrum), reunión diaria de unos 15 minutos donde se
discute el estado y el progreso del sprint. Estas reuniones mejoran la comu-
nicación, identifican impedimentos y eliminan la necesidad de otras reunio-
nes.
• Reunión de revisión del sprint (Sprint Review), también llamado demos-
tración, que se realiza cuando el sprint ha terminado y sirve para presentar
al propietario del producto y a otras partes interesadas, los objetivos con-
seguidos con el sprint.
• Retrospectiva (Sprint Retrospective), donde se inspecciona como se pue-
de producir una mejora en la productividad, la calidad del producto, la mo-
tivación del equipo y como fue la última iteración o como está yendo el
proyecto.
Figura 5 Scrum
7/13V.1 n.2
Métodos ágiles para grandes sistemas.
El desarrollo de grandes sistemas, con millones de líneas de código, requiere
grandes cantidades de desarrolladores y los métodos como Scrum recomiendan
que los equipos de desarrollo sean pequeños, entre 5 y 11 personas. Para re-
solver este problema de escalabilidad existen distintas metodologías de las que
podemos destacar las siguientes:
Scrum de Scrums (SoS)[19][20], donde en cada sprint, equipos Scrum se
coordinan entre si y son responsables de generar un conjunto de incrementos de
un único producto. Se define un Scrum de Scrums Master (SoSM) que facilita el
refinamiento de la pila de producto. Adicionalmente a las reuniones diarias del
Scrum, se realizan también una también otras diarias y conjuntas Scaled Daily
Scrum (SDS), en donde participan los Scrum Master de cada equipo además de
otras personas del mismo. En esta metodología solo existe una única pila de pro-
ducto y un único responsable denominado Chief Product Owner. Una variante
de esta metodología es Nexus[21]. La diferencia fundamental se encuentra en
que, en Nexus, el foco se pone en el equipo de integración Nexus (Nexus Inte-
gration team), que es el responsable de garantizar que un incremento integrado
se produzca al menos una vez por sprint.
(a) Figura 6 Scrum de Scrums (b) Figura 7 Nexus framework [21]
LeSS (Large-Scale Scrum)[22], en 2005 Vodde y Larman desarrollaron es-
te marco de trabajo que sigue los principios de Scrum, pero con el objetivo de
que sea empleado satisfactoriamente en grandes proyectos. Las diferencias con
Scrum se centran en que tanto el refinamiento de la pila de producto como la
planificación del sprint se descompone en dos reuniones diferentes. En la pri-
mera, un grupo representativo establece los objetivos globales del sprint. En la
segunda reunión cada grupo, de forma separada, detallan el trabajo a realizar.
La misma definición de “hecho” es aplicable a todos los grupos. Las reuniones
diarias del Scrum se realizan por cada equipo de forma individual, pero están
abiertas a miembros de otros equipos. Se añade una reunión global retrospectiva
con el propósito de explorar las mejoras globales. Dicha reunión se realiza una
vez por semana, con una duración de 45 minutos, donde participan el propietario
del producto, los facilitadores y de forma rotativa un miembro representativo de
cada equipo.
8/13V.1 n.2
Figura 8 LeSS Framework[22]
Pero el método ágil escalable más popular es el SAFe (Scaled Agile Frame-
work) [23], donde un conjunto de equipos llamado tren de despliegue ágil (Agile
Release Train, ART), trabajan en el mismo objetivo: el incremento de progra-
ma (Program increment, PI). A nivel de equipo, aquí llamado equipo ágil, SAFe
trabaja igual que Scrum. Hay que destacar que SAFe propone un conjunto de
prácticas de calidad que se han de seguir en cada incremento. A nivel de progra-
ma se trabaja con los mismos elementos, pero a escala (hasta 150 personas); el
equipo trabaja para crear un incremento de programa a entregar después de 5
sprints (10 semanas). El contenido de cada despliegue del tren (Release train)
es determinado por el gestor del producto (Product Manager), por medio de la pi-
la del programa (Program Backlog). Además, se define un facilitador del tren
(Train Scrum Master).
Un incremento del programa comienza con la reunión de planificación donde
asiste todo el equipo. Se planifican los próximos sprints basados en una parti-
ción por características (features) y se alinean las necesidades de los distintos
equipos. Los facilitadores de cada equipo y facilitadores del tren tienen reuniones
dos veces por semana para asegurarse la correcta sincronización de los equipos.
Normalmente se utiliza uno de los sprints para una verificación final, pruebas, pla-
nificación de la demostración a nivel de programa y replanificación del próximo
ciclo.
9/13V.1 n.2
Figura 9 SAFe Framework [23]
Otras aproximaciones.
No obstante lo anterior, las empresas suelen aplicar los métodos ágiles adap-
tándolos a su organización y a la forma en la que han venido realizado los desa-
rrollos tradicionalmente. Como ejemplo podemos ver la solución que ha adoptado
la empresa Lockheed Martin (LM), intentando unir lo mejor de las metodologías
ágiles ágil y el mundo de las líneas de producto de ingeniería (LPE) [24]. Para en-
carar una transformación como esta, LM formó a su personal en la metodología
SAFe, como base fundamental para aplicar las prácticas ágiles y la coordinación
entre los distintos grupos de trabajo. LM adopta un ciclo de entregas de una ver-
sión (release) cada cuatro meses, con sprints de dos semanas, (por lo tanto ocho
sprints forman una versión).
El trabajo de cada sprint está definido en la pila de producto como historias
de usuario, o mínima capacidad que aporta valor y puede ser implementada y
probada en uno o dos días. Cada historia de usuario se descompone en tareas,
que se corresponden con un trabajo de entre 8 o 16 horas. Las historias de usuario
se agrupan en capacidades (Features), o conjunto de historias de usuario que
formarán parte de la versión. Un conjunto de capacidades forma una Épica (Epic),
o capacidad mayor que se expande a múltiples versiones. La figura 10 muestra
una representación de esta descomposición. Los distintos equipos Scrum siguen
la metodología realizando las reuniones diarias, las revisiones y demo, así como
las retrospectivas de los sprints.
10/13V.1 n.2
Figura 10. Descomposición en épica, capacidades, historias de usuario y tareas.
Conclusiones y futuro
A pesar de que las grandes corporaciones se resisten a cambiar sus métodos
de trabajo, cada vez más las aproximaciones iterativas e incrementales, así como
los derivados de la filosofía ágil están ganando adeptos.
Los últimos informes del Standish Group[25] demuestran que los proyectos de
gran tamaño que siguen los métodos ágiles, tienen hasta seis veces más éxito y
la mitad de las posibilidades de fallar, que los métodos en cascada.
Grandes empresas tales como Lockheed Martin, Thales, Raytheon y en Es-
paña GMV[26], Indra[27] y Navantia[28] entre otras, están experimentando con
metodologías ágiles o bien están implementando sus propias variantes, con el
objetivo de obtener los beneficios de la reducción de tiempos en el desarrollo,
integración, pruebas y despliegue.
Seguramente estamos acercándonos a un cambio en la forma de hacer las
cosas, pero es indudable que hoy en día las estrategias ágiles son las más ex-
tendidas.
Para abordar el cambio del modelo tradicional al ágil se debería construir una
forma de desarrollo basada en los principios y valores ya expuestos en este artícu-
lo, pero a su vez deben utilizarse todas las herramientas disponibles, sin olvidar
integrar las mejores prácticas utilizadas hasta hoy.
Como en toda actividad humana hemos de aprender de nuestros errores y
construir evolucionando, creando valor a partir de unos principios como son los
que inspiran las metodologías ágiles.
bibliografía
[1] F. J. López García, “Del modelo tradicional a los modelos de reutilización
del Software para grandes Sistemas de Defensa.
” https://www.puentedehierro.org/ojs/index.php/pdh/article/view/8/10 (accessed Jun.
22, 2021).
[2] C. Larman and V. R. Basili, “Iterative and incremental developments. a brief
history,” Computer, vol. 36, no. 6, pp. 47–56, 2003, doi: 10.1109/MC.2003.1204375.
[3] D. O’Neill, “Integration engineering perspective,” The Journal of Systems
and Software, vol. 3, no. 1, pp. 77–83, 1983, doi: 10.1016/0164-1212(83)90006-7.
[4] H. D. Mills, “The management of software engineering, part I: Principles of
software engineering,” IBM Systems Journal, vol. 38, no. 2/3, pp. 289–295, 1999,
[Online]. Available:
https://www.proquest.com/scholarly-journals/management-software-engineering-
part-i-principles/docview/222415760/se-2?accountid=14495.
11/13V.1 n.2
[5] W. A. Madden and K. Rone, “Design, development, integration: space shuttle
primary flight software system,” Commun. ACM, vol. 27, pp. 914–925, 1984.
[6] V. R. Basil and A. J. Turner, “Iterative enhancement: A practical technique
for software development,” IEEE Transactions on Software Engineering, vol. SE-
1, no. 4, pp. 390–396, 1975, doi: 10.1109/TSE.1975.6312870.
[7] B. W. Boehm, “A spiral model of software development and enhancement,”
Computer, vol. 21, no. 5, pp. 61–72, 1988, doi: 10.1109/2.59.
[8] B. Boehm and W. Hansen, “Spiral Development: Experience, Principles,
and Refinements,” p. 47, Jul. 2000.
[9] J. Martin, Rapid Application Development. 1991.
[10] I. Jacobson, The unified software development process. Reading, Mas-
sachusetts: Reading, Massachusetts : Addison-Wesley, 1999.
[11] P. Kruchten, The rational unified process : an introduction, 3rd ed. Boston:
Addison-Wesley, 2003.
[12] M. Beedle, M. Devos, K. Schwaber, and J. Sutherland, “SCRUM: An ex-
tension pattern language for hyperproductive software development,” Dec. 1998.
[13] H. Takeuchi and I. Nonaka, “The New New Product Development Game,”
Harvard Business Rev, pp. 137–146, 1986.
[14] K. Beck and C. Andres, Extreme programming explained: embrace chan-
ge, 2a, 10a reimp. Boston: Addison-Wesley.
[15] “Manifiesto por el Desarrollo Ágil de Software.”
https://agilemanifesto.org/iso/es/manifesto.html (accessed Jun. 22, 2021).
[16] “Principios del Manifiesto Ágil.” https://agilemanifesto.org/iso/es/principles.html
(accessed Jun. 22, 2021).
[17] “14th Annual State of Agile Report,” 2020. Accessed: Jun. 15, 2021. [On-
line]. Available:
https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494.
[18] K. Schwaber and J. Sutherland, “The Scrum Guide The Definitive Guide
to Scrum: The Rules of the Game,” 2020. Accessed: Jun. 18, 2021. [Online].
[19] J. Sutherland, “Agile Can Scale: Inventing and Reinventing SCRUM in
Five Companies,” vol. 14, pp. 5–11, Dec. 2001.
[20] J. Sutherland, “The Scrum@Scale Guide Online | Scrum@Scale Fra-
mework.” https://www.scrumatscale.com/scrum-at-scale-guide-online/ (accessed
Jun. 21, 2021).
[21] “Online Nexus Guide | Scrum.org.” https://www.scrum.org/resources/online-
nexus-guide (accessed Jun. 21, 2021).
[22] “Overview - Large Scale Scrum (LeSS).” https://less.works/ (accessed
Jun. 21, 2021).
[23] “SAFe 5 for Lean Enterprises.” https://www.scaledagileframework.com/
(accessed Jun. 21, 2021).
[24] S. P. Gregg, R. Scharadin, and P. C. Clements, “The Best of Both Worlds:
Agile Development Meets Product Line Engineering at Lockheed Martin,” INCO-
SE International Symposium, vol. 26, no. 1, pp. 951–965, 2016, doi: 10.1002/j.2334-
5837.2016.00204.x.
[25] “Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch.”
https://www.infoq.com/articles/standish-chaos-2015/ (accessed Jun. 23, 2021).
12/13V.1 n.2
[26] H. Garzón, J. A. Chaos, B. Martín, and J. Garzás, “Un caso de estudio so-
bre transformación Ágil, en software para centros de control de satélites, basado
en Lean Change y Cherry Picking.”
[27] “Gestión Ágil en grandes empresas: la experiencia de Indra.”
https://www.slideshare.net/233gradosdeTI/gestin-gil-en-grandes-empresas-la-experiencia-
de-indra (accessed Jun. 22, 2021).
[28] J. I. Silvera, J. Luis, M. José, M. Luquero, and M. Bustelo, “Navantia’s
Digital Twin Implementation Perspective in Military Naval Platform Life Cycle.”
13/13También puede leer
