Introducción
Desde la inclusión del manifiesto ágil en el año 2001, las soluciones (en adelante marcos) ágiles han transformado la manera en la que se desarrolla software (Caffery, Taylor, y Coleman, 2007; Amir et al., 2013; Dingsøyr, Fægri e Itkonen, 2014). Estos marcos enfatizan en tolerancia al cambio, participación activa del cliente, entregas evolutivas, aumento en la calidad del producto y reducción del riesgo en cada entrega (Kalenda, 2017; Dingsøyr et al., 2014), entre otros. Algunos de los marcos más conocidos guiados por el manifiesto ágil son: Extreme Programming (XP) (Extreme Programming, s.f.), Lean Software Development (LSD) (Poppendieck y Poppendieck, 2003), Scrum (Schwaber y Sutherland, 2017). Los marcos ágiles permiten que equipos pequeños puedan desarrollar software de alta calidad (Schwaber y Sutherland, 2017); sin embargo, existen desafíos para lograr la misma ganancia de productividad a medida que utilizan técnicas de desarrollo ágil en proyectos a gran escala (Kalenda, 2017), por ejemplo: la comunicación y la coordinación se convierten en aspectos importantes a considerar para mejorar el éxito en el desarrollo de software (Ebert y Paasivaara, 2017; Dikert, Paasivaara y Lassenius, 2016). Para enfrentar estos desafíos han surgido nuevos marcos centrados en el desarrollo ágil a gran escala (en adelante DAGE), por ejemplo: LeSS (LeSS Framework, s.f.), Nexus (Schwaber, 2018), SAFe (SAFe for Lean Enterprises, s.f.), Disciplined Agile Delivery (DAD) (Project Management Institute, 2019).
Tomando como referencia el mapeo sistemático de la literatura presentado por Cañizares, Gómez y Pardo (2020), ha sido posible observar que algunos autores proponen soluciones como: (i) una taxonomía que clasifica y define los niveles de escala (Dingsøyr et al., 2014), (ii) principios ágiles para proyectos a gran escala (Dingsøyr y Moe, 2014; Laanti, 2014), (iii) modelos para el soporte de la arquitectura emergente en grandes entornos (Eckstein, 2014), (iv) artefactos que facilitan el desarrollo offshore a gran escala (Bass, 2016), y (v) factores de éxito y desafíos identificados en 42 casos industriales (Dikert et al., 2016). Sin embargo, hasta el momento ninguno de los estudios encontrados realiza la integración de las experiencias reportadas en los trabajos relacionados, o que integren los atributos comunes entre los marcos escalados más usados en la industria. Además, con la revisión de la literatura se encontró que aún no queda claro cómo llevar a cabo la adopción de un marco de DAGE (Dikert et al., 2016), y no se han logrado resolver preguntas cómo: (i) ¿cuándo es adecuado escalar?, (ii) ¿cómo adaptar un marco escalado de acuerdo con las necesidades de una empresa?, (iii) ¿qué herramientas existen para apoyar la implementación de prácticas ágiles en empresas con equipos y proyectos distribuidos geográficamente? y (iv) ¿cómo gestionar las dependencias que surjan entre equipos y proyectos?
Considerando lo anterior, este artículo presenta un modelo de referencia que integra los atributos comunes de los marcos LeSS, Nexus, SAFe y DAD, y las propuestas encontradas en trabajos relacionados, aplicando la estrategia de armonización de múltiples modelos (Gómez-Campo, Cañizares-Hernández y Pardo-Calvache, 2020) e integración de los resultados del mapeo sistemático de la literatura presentado en Cañizares et al. (2020). El modelo propuesto Scaled Agile Model (en adelante SAM) se compone de prácticas fundamentales y opcionales agrupadas de acuerdo con un conjunto de categorías, y roles fundamentales y opcionales agrupados en niveles de escalamiento (escala pequeña, mediana o grande, según la cantidad de colaboradores/equipos de la empresa). Este modelo pretende ser de gran beneficio para las empresas de desarrollo de software, ya que al integrar los elementos en común de SAFe, LeSS, Nexus, DAD y la información empírica reportada en la literatura, lo convierte en un modelo ágil escalado con el que se puede apoyar la transformación y la evaluación del desarrollo ágil a gran escala en la industria de software. Esto debido a que SAM permite tener una primera visión de cuáles son los elementos mínimos necesarios para empezar el proceso de escalamiento, también habilita la posibilidad de enfocar los proyectos de mejora de las empresas hacia alguno de los marcos en los que SAM está basado, además permite contrastar las prácticas implementadas con las prácticas de otros marcos y las prácticas reportadas como experiencia por otras empresas al momento de escalar, y, finalmente, SAM permite a las empresas evaluarse frente a las prácticas que se consideran fundamentales en un contexto de desarrollo ágil a gran escala.
El presente artículo está estructurado de la siguiente forma: primero, presenta los trabajos relacionados, el estado del arte y el modelo de referencia SAM. Más adelante presenta el proceso y los resultados de la evaluación del modelo mediante un grupo focal. Finalmente, aborda las conclusiones y el trabajo futuro.
Metodología
En esta sección se presenta un resumen de los trabajos relacionados y el modelo de referencia propuesto.
Trabajos relacionados
A partir de los resultados obtenidos del mapeo sistemático presentado en Cañizares et al. (2020), se evidenció que el interés de la comunidad científica en lo relacionado con el desarrollo ágil de software a gran escala está creciendo, especialmente, después de llevado a cabo el evento global Workshop XP2014 (Dingsøyr y Moe, 2014), cuyo tema central fue “Agile in the large”. De acuerdo con el mapeo sistemático presentado en Cañizares et al. (2020), enfocado en identificar aquellos atributos fundamentales dentro del proceso de escalamiento, se encontraron esfuerzos centrados en: (i) establecer aspectos para referirse al término “a gran escala”, estos son: duración del proyecto, número de personas involucradas, tamaño del proyecto y número de equipos en un proyecto; (ii) presentar los resultados de revisiones sistemáticas; (iii) ofrecer propuestas como modelos, artefactos, principios, prácticas, entre otros, para facilitar o guiar el proceso de escalamiento; (iv) presentar a través de un estudio de caso las experiencias de empresas de software que han decidido escalar; y (v) mostrar resúmenes de talleres o reportes investigativos sobre el desarrollo de software a gran escala.
Además, a partir de Cañizares et al. (2020), también fue posible encontrar: (a) 34 prácticas y recomendaciones consideradas como fundamentales para escalar en una empresa de software sus procesos de desarrollo; (b) 19 roles y estructuras de trabajo que se sugiere adoptar de acuerdo con la complejidad de la arquitectura (Eckstein, 2014) o de acuerdo con el propósito, por ejemplo: roles que apoyen la coordinación entre equipos (Gustavsson, 2017), (c) 21 desafíos inherentes al escalamiento; y (d) 16 factores de éxito que permitan abordar dichos desafíos. Además, con el fin de establecer los hallazgos más relevantes como atributos potenciales para el DAGE, en Cañizares et al. (2020) se clasifican prácticas, recomendaciones, factores de éxito y desafíos alrededor de los interrogantes: ¿qué tener en cuenta para escalar? y ¿cómo lograrlo? Esta clasificación reveló que, de 71 propuestas, el 60.6 % responde qué tener en cuenta para escalar y el 39.4 % responde a la pregunta de cómo lograrlo.
Los hallazgos presentados en Cañizares et al. (2020) permitieron evidenciar múltiples propuestas que buscan apoyar el escalamiento; sin embargo, estas propuestas necesitan más detalle a fin de aclarar los atributos que las componen, como por ejemplo: los artefactos para facilitar la coordinación y establecer valor compartido (Bass, 2016). Por otra parte, se pudo observar que los marcos escalados existentes proporcionan una idea central, ya que describen una ruta para alcanzar el escalamiento; sin embargo, muchas empresas declararon sentirse desorientadas al desconocer: (i) si están realizando correctamente la adopción de un marco escalado, (ii) qué nivel de completitud en la transformación ágil han alcanzado, o (iii) cómo abordar los desafíos inherentes al escalamiento (Laanti, 2017). También, en Bass (2019) se evidenció que la información reportada como experiencia de empresas que han escalado es complementaria a la documentación presentada en los marcos escalados al momento de implementar un marco de DAGE.
Modelo de referencia SAM
El modelo de referencia Scaled Agile Model (SAM) es el resultado de la integración de los atributos del modelo presentado por Gómez-Campo et al. (2020) y los hallazgos del mapeo sistemático sobre DAGE presentado por Cañizares et al. (2020). SAM tiene por objetivo servir de referencia para fomentar y apoyar el escalamiento de las prácticas definidas por algún marco ágil no escalado hacia prácticas ágiles para equipos de desarrollo dispersos geográficamente en empresas de desarrollo de software, o apoyar a aquellas empresas que desean evaluar el nivel de implementación de los procesos de una empresa respecto a los atributos fundamentales que deberían ser considerados en los enfoques ágiles a gran escala. La Figura 1 presenta a SAM, el cual está compuesto por: 16 roles -14 de ellos fundamentales y 2 opcionales-, 34 prácticas -19 de ellas fundamentales y 15 opcionales- y 8 categorías de prácticas -transversal, inicio, gestión del trabajo pendiente, planeación, implementación, revisión, despliegue e inspección y adaptación, las cuales se encargan de agrupar las prácticas del modelo-. SAM puede consultarse con mayor detalle en: https://scaledagilemodel.github.io. Cabe resaltar que las prácticas y los roles opcionales en su calidad de opcionales pueden ser implementados según la necesidad de cada empresa, se presentan como sugerencia frente a un posible escenario del escalamiento de procesos.
Roles SAM
En la Figura 2 se puede observar que SAM propone un conjunto de 16 roles y los agrupa en roles fundamentales (14) y opcionales (2) a través de 4 grupos de trabajo: (i) programa, un grupo de trabajo conformado por equipos ágiles SAM centrados en características específicas del producto, y un equipo de liderazgo encargado de la coordinación y orientación del programa; (ii) roles técnicos, un grupo de trabajo que comprende los roles que trabajan junto a los equipos de desarrollo para respaldar la ejecución de sus tareas y brindar apoyo en diseño, implementación y lanzamientos; (iii) roles de apoyo, un grupo de trabajo que introduce roles de forma provisional cuando se requiere superar un problema de adquisición de conocimiento especializado; y (iv) administración de líneas de producto, un grupo de trabajo que se encarga de cumplir las funciones de gobernanza y control de los proyectos.
Teniendo en cuenta lo anterior, con el fin de dimensionar la cantidad de personas que debería considerar una empresa para implementar SAM, se sugiere adoptar los roles de acuerdo con el nivel de escalamiento de la empresa en términos del número de equipos/colaboradores que posea, estos niveles se presentan en la Tabla 1.
Roles en empresas de escala pequeña
Las empresas que tienen entre 15 y 20 personas se organizan en un nivel de escalamiento de escala pequeña, y para ellas aplican los roles que pertenecen al grupo de trabajo Programa, es decir, los roles del Equipo ágil SAM y del Equipo de liderazgo. Debido a la cantidad de personas, en este nivel de escalamiento es posible que una persona pueda desempeñar más de un rol a la vez, por ejemplo, un líder de equipo puede desempeñarse a su vez como el líder de programa; en este sentido, analizar la sobrecarga de trabajo será responsabilidad de la empresa.
Roles en empresas de escala mediana
Las empresas que tienen entre 20 y 50 personas se organizan en un nivel de escalamiento de escala mediana, en el que, adicional a los roles del grupo de trabajo Programa, se incluyen los grupos roles de apoyo y roles técnicos, los cuales proporcionan una estructura de coordinación necesaria para respaldar los programas. De la misma manera, en este nivel de escalamiento, y debido a la necesidad de coordinación entre programas, se recomienda que los roles de liderazgo sean roles de dedicación completa.
Roles en empresas de escala grande
Las empresas que tienen más de 50 personas se organizan en un nivel de escala grande, y para ellas aplican todos los roles propuestos por SAM. A diferencia de las escalas pequeña y mediana, se propone un grupo de trabajo adicional llamado Administración de líneas de producto.
Prácticas SAM
SAM se compone de 34 prácticas, 19 de ellas fundamentales y 15 opcionales, agrupadas en 8 categorías de prácticas: (i) transversal, que contiene las prácticas que se presentan a lo largo del proceso de desarrollo de software; (ii) inicio, que abarca las prácticas necesarias para dar inicio al desarrollo; (iii) gestión del trabajo pendiente, que incluye las prácticas relacionadas con la gestión del backlog de producto, programa y equipo; (iv) planeación, que envuelve las prácticas relacionadas con planeación y asignación del trabajo pendiente; (v) implementación, que comprende las prácticas relacionadas con ejecución y construcción del trabajo asignado; (vi) revisión, que contiene las prácticas relacionadas con la validación del trabajo realizado en la implementación; (vii) despliegue, que abarca las prácticas relacionadas con la entrega del producto a los clientes o usuarios finales; (viii) inspección y adaptación, que incluye las prácticas relacionadas con la exploración de oportunidades de mejora del desarrollo ágil a gran escala y la creación de planes para abordar dichas oportunidades. Un mayor detalle sobre las prácticas y las categorías se puede consultar en: https://bit.ly/3js6iqV.
Relación entre prácticas y roles de SAM
La Tabla 2 presenta un extracto de la correspondencia entre las prácticas y los roles de SAM organizados en categorías de prácticas. De la misma manera, es posible identificar qué roles dan cumplimiento a cada práctica de acuerdo con el nivel de escalamiento de una empresa, dichos niveles se corresponden de la siguiente manera: uno (1), cuando el rol aplique para escala pequeña; dos (2), cuando el rol aplique para escala mediana; y tres (3), cuando el rol aplique para escala grande; asimismo, es posible que el rol aplique por ejemplo para 1, 2 y 3, lo cual indicaría que es un rol que aplica en cualquier nivel de escalamiento. No obstante, algunas prácticas no muestran roles asociados cuando se presentan a lo largo del proceso de desarrollo o cuando son prácticas opcionales. La Tabla 2 completa puede ser consultada en: https://bit.ly/3lB87oj.
Resultados
El modelo propuesto fue evaluado a través del método de investigación cualitativo llamado Grupo Focal (Mendoza-Moreno, González-Serrano y Pino, 2013). Algunas de sus ventajas son: la recopilación de información confiable a un costo menor en comparación con las herramientas de investigación tradicionales, la generación de nuevas ideas resultado del debate, y la rapidez y la eficacia en la recopilación de información de usuarios y profesionales (Kontio, Bragge y Lehtola, 2008). Las actividades llevadas a cabo en el grupo focal se describen a continuación.
Definición del problema de investigación
Inicialmente, se estableció un objetivo de grupo focal, el cual fue: conocer y analizar la opinión y la percepción de profesionales con experiencia en el desarrollo ágil de software a gran escala con respecto a las variables de completitud, idoneidad y claridad del modelo propuesto. Los objetivos de la evaluación se enfocaron en: (i) evaluar la propuesta; (ii) extraer lecciones aprendidas y recomendaciones; y (iii) ajustar la propuesta de acuerdo con las acciones de mejora identificadas a través del análisis de recomendaciones y sugerencias de los participantes.
Selección de los participantes
Para llevar a cabo esta actividad se definieron los siguientes criterios: (i) estar activo en la industria del desarrollo de software a gran escala (proyectos que cuenten con al menos dos equipos que se encuentren distribuidos geográficamente), (ii) tener conocimientos sobre enfoques ágiles o enfoques ágiles escalados y su aplicación en la industria de software, y (iii) ser profesional con experiencia en la industria de software (mínimo dos años de experiencia). Durante la selección de participantes, se definió una lista de 14 posibles asistentes, de los cuales se descartaron 3 y se eligieron 11, quienes cumplieron los requisitos establecidos. Posteriormente, se envió una invitación por correo electrónico a los posibles participantes seleccionados, para confirmar su asistencia y coordinar la sesión de discusión, y una vez obtenida la afirmación de los participantes, tres semanas antes de la sesión de discusión, se envió un segundo mensaje con la documentación de la propuesta y el protocolo definido. Finalmente, 8 participantes asistieron a la sesión del grupo focal. A continuación, en la Tabla 3 se presenta el perfil profesional de cada uno.
Realización de la sesión del grupo focal
La sesión de discusión fue conducida y coordinada por un moderador, y la captura de información estuvo a cargo del relator, ambos miembros del grupo de investigación. Durante la sesión, el relator tomó nota de las apreciaciones, los comentarios y las sugerencias relevantes, resultado de la intervención de cada participante; además, al finalizar la sesión del grupo focal, se solicitó a los participantes responder un cuestionario.
Análisis de la información y reporte de los resultados
Una vez obtenidas las respuestas de los participantes al cuestionario diligenciado al final de la sesión, el grupo investigador realizó el análisis de la información. Inicialmente, se contaron y analizaron las respuestas de cada participante a las preguntas cerradas. El cuestionario se elaboró teniendo en cuenta que las preguntas estuvieran destinadas a definir el grado de completitud (3 preguntas), idoneidad (6 preguntas) y claridad (7 preguntas) de la propuesta de investigación. La Tabla 4 presenta el conteo de respuestas a las preguntas cerradas 1 a 16. Para dar respuesta a las preguntas cerradas, se utilizó una escala Likert de la siguiente manera: muy mal, muy insatisfecho: valor (1); mal, poco satisfecho: valor (2); bien, suficiente, adecuado, algo satisfecho: valor (3); bastante bien, adecuado, satisfecho: valor (4); muy bien, muy adecuado, muy satisfecho: valor (5). Un resumen gráfico del conteo se presenta en: https://bit.ly/3CoAfka.
Posteriormente, se realizó el análisis a las preguntas abiertas, las cuales permitieron a los participantes proponer ajustes y recomendaciones sobre los elementos del modelo propuesto y realizar cualquier comentario adicional sobre él. Estas respuestas fueron recopiladas y analizadas como oportunidades de mejora para ajustar la propuesta. Como puede verse, existe un consenso común con la propuesta; es decir, que los elementos que se presentaron y evaluaron en la sesión del grupo focal son considerados relevantes para lograr el escalamiento de los procesos de desarrollo de software. Sin embargo, las respuestas a las preguntas 4, 9 y 12 fueron desfavorables (cinco participantes apuntaron mal/poco satisfecho según la escala Likert definida), estas preguntas estaban enfocadas en determinar si los roles propuestos eran suficientes, adecuados y claros para lograr el escalamiento de procesos de desarrollo de software. La principal discusión fue un exceso de roles, los cuales eran casi imposibles de adoptar teniendo en cuenta el tamaño de una empresa; por lo tanto, estos comentarios fueron abordados como acciones de mejora, una de ellas fue la reestructuración de 9 grupos de trabajo que se presentaban como roles fundamentales, pero se concluyó que no eran aplicables en todos los niveles de escalamiento. También se dimensionó el tamaño de una empresa y el número de roles que debería considerar; es decir, qué roles necesita adoptar una empresa teniendo en cuenta su tamaño en términos del número de personas/equipos.
Los demás comentarios y opiniones de los participantes también fueron seleccionados y tomados en cuenta para aplicar las acciones de mejora al modelo, resultando así una segunda versión, la cual se presenta en este documento. En resumen, las siguientes fueron las acciones de mejora aplicadas: (i) a través del dimensionamiento de roles de acuerdo con el nivel de escalamiento de una empresa, se disminuyó el número de roles fundamentales del modelo; (ii) se redefinieron algunos roles, ya que algunos participantes expresaron que estos no eran claros; (iii) se asociaron roles a las prácticas opcionales cuando aplicaba; y (iv) se realizó una evaluación de agilidad del modelo propuesto con el fin de presentar qué tan alineado estaba el modelo con los principios del manifiesto ágil.
Limitaciones del grupo focal
Durante el grupo focal surgieron las siguientes limitaciones: (i) los estilos de comunicación de los participantes y la falta de experiencia del moderador influyeron en la dinámica del grupo focal, esto fue corregido por el investigador más experimentado equilibrando la discusión y activando a los participantes menos activos; (ii) los participantes pudieron sentirse reacios de expresar sus pensamientos u opiniones de manera transparente, más cuando su opinión se oponía a las de otros participantes, esto fue abordado por el moderador, quien resaltó reiteradamente el valor de intervenciones y aportes de cada participante; y (iii) el riesgo de conocimientos limitados y comprensión sobre la temática evaluada de los participantes, lo cual fue abordado seleccionando a participantes con el mismo nivel de experiencia; además, se proporcionó un material de lectura del modelo SAM con 15 días de antelación al desarrollo del grupo focal.
Conclusiones
Con relación a las preguntas de motivación que se plantean en la introducción, desde el punto de vista de SAM, estas se pueden responder de la siguiente manera: (i) ¿Cuándo es adecuado escalar?, R/ Cuando la empresa tenga claros sus procedimientos y procesos para desarrollar software y que esta empresa de alguna manera se plantee el desafío de tener una distribución geográfica en sus equipos para apoyar el desarrollo global de software. (ii) ¿Cómo adaptar un marco escalado de acuerdo con las necesidades de una empresa? R/ SAM posibilita que una empresa pueda transformar su proceso de desarrollo de software convencional a una solución escalada, manteniendo algunas de las prácticas que inicialmente utilizaba e integrando y armonizando nuevas o mejores prácticas para el desarrollo global de software. (iii) ¿Qué herramientas existen para apoyar la implementación de prácticas ágiles en empresas con equipos y proyectos distribuidos geográficamente? R/ SAM incorpora las prácticas de los marcos ágiles escalados más utilizados en la industria y esto posibilita que una empresa que utilice SAM pueda decidir qué camino recorrer desde el punto de vista de su certificación; de la misma manera, se han incorporado algunos elementos de proceso como roles y equipos de trabajo para facilitar la comprensión, así como clarificar y proveer mayores herramientas a las empresas para su aplicación. Finalmente, (iv) ¿Cómo gestionar las dependencias entre equipos y proyectos? R/ Se pueden seguir, por ejemplo, las relaciones establecidas a nivel de estructuras de trabajo propuestas por SAM, las cuales son sensibles de ser adaptadas y mejoradas de acuerdo con las necesidades de la empresa y su nivel de escalamiento.
Evaluar el modelo de referencia propuesto a través de un grupo focal permitió reunir a expertos en el área de ingeniería de software, desarrollo de software distribuido y enfoques ágiles, quienes desde su experiencia y conocimiento identificaron oportunidades de mejora para el modelo propuesto. El uso de este método de investigación aportó retroalimentación, resultado de la discusión de diferentes puntos de vista entre los participantes y permitió evidenciar la aceptación del modelo por parte de los integrantes del grupo. Como resultado del grupo focal, se generó una nueva versión ajustada del modelo, la cual se presenta en este artículo.
El modelo de referencia SAM integra los atributos comunes de los marcos LeSS, Nexus, SAFe, DAD y las propuestas identificadas en la revisión sistemática de la literatura. El modelo de referencia plantea un conjunto de prácticas y roles fundamentales y opcionales que apoyan el desarrollo de software a gran escala. Este modelo ofrece beneficios para: (i) empresas que desconocen cómo empezar a escalar sus procesos, (ii) empresas que se encuentran en el proceso de escalamiento, (iii) empresas que han escalado y desean evaluar si han implementado prácticas que pueden resultar fundamentales en el desarrollo ágil a gran escala, y (iv) empresas que buscan un paso inicial que las lleve a adoptar y alcanzar una certificación de algún marco escalado como SAFe, LeSS, Nexus o DAD. Sin embargo, es necesario plantearse como trabajo futuro el iterar nuevamente el proceso de armonización, incluyendo los atributos no considerados en la primera iteración, tales como: fases, artefactos, principios, entre otros, que se puedan encontrar en la literatura y en los marcos LeSS, Nexus, SAFe y DAD. Asimismo, realizar un estudio de caso que permita evaluar nuevamente el modelo a fin de mejorarlo con las experiencias que se puedan recopilar de su aplicación en escenarios reales de la industria. Finalmente, crear un instrumento de evaluación a partir del modelo de referencia propuesto.