| |
Artículo Original
Evaluación de calidad en procesos ágiles desde la perspectiva del trabajo en equipo
Quality evaluation in agile processes from the perspective of teamwork
Noelia PINTO (1), César J. ACUÑA (2), Nicolás TORTOSA (3)
(1) CInApTIC (Centro de Investigación Aplicada en TICS) UTN Facultad Regional Resistencia ns.pinto@ca.frre.utn.edu.ar
(2) CInApTIC (Centro de Investigación Aplicada en TICS) UTN Facultad Regional Resistencia
(3) CInApTIC (Centro de Investigación Aplicada en TICS)
UTN Facultad Regional Resistencia
Resumen:
La industria del software requiere de productos y servicios de alta calidad, lo cual se logra mediante la aplicación de modelos y metodologías de calidad reconocidos internacionalmente. Sin embargo, estos modelos en pequeñas y medianas empresas (PYMES) son muy difíciles de implementar ya que ello implica una gran inversión en dinero, tiempo y recursos.
Con el objetivo de facilitar la adopción de prácticas ágiles que aseguren la calidad de los procesos de desarrollo de software se ha presentado Agile Quality Framework (AQF), un framework que integra un modelo de calidad junto a una herramienta de software que permite la automatización de dicho modelo y que se adapta a las características de las PYMES.
AQF surge, como una plataforma que contribuye con los equipos de desarrollo de software a partir de la evaluación de calidad en proyectos ágiles, considerando como objeto de la medición al proceso de desarrollo independientemente del enfoque ágil seleccionado.
En este artículo se presentan las características del proceso de evaluación de los equipos de trabajo en entornos ágiles que utiliza AQF, junto a los resultados de validación, a través de casos de estudio en ambientes reales de desarrollo.
Palabras Clave: Calidad de Software, Evaluación de Calidad de Software, Proyectos Ágiles
Abstract:
The software industry requires high quality products and services, which is achieved through the application of internationally recognized quality models and methodologies. However, these models in small and medium-sized enterprises (SMEs) are very difficult to implement since this implies a large investment in money, time and resources.
To facilitate the adoption of agile practices that ensure the quality of software development processes, Agile Quality Framework (AQF) has been presented, a framework that integrates a quality model together with a software tool that allows the automation of said model and that adapts to the characteristics of SMEs.
AQF emerges as a platform that offer to the software development teams a tool based on quality in agile projects, focused on measurement of the process of developing in agile projects.
In this paper we present the characteristics of the evaluation process of work teams in agile environments using AQF, together with the validation results, through case studies in real development environments.
Key Words: Software Quality, Software Quality Assessment, Agile Projects
Colaboradores: Gabriela TOMASELLI, Blas CABAS GEAT, Lucas IBAÑEZ
I. Contexto
El presente artículo está enmarcado en el proyecto “Evaluación de Calidad en Procesos Ágiles de Desarrollo de Software”, que es financiado por la UTN y ejecutado en el Centro de Investigación aplicada en TICS (CInApTIC) de la Facultad Regional Resistencia, con el código IAI4445TC y el proyecto PDTS “Mejora de la Competitividad de Empresas PyMES de Software del NEA” IP 253, financiado por el CIN-CONICET.
II. Introducción
Existen numerosas propuestas metodológicas que guían el ciclo del desarrollo de software y que inciden en distintas dimensiones del proceso. Las metodologías más tradicionales se centran especialmente en una rigurosa definición de: roles, actividades involucradas, artefactos que se deben producir, herramientas y notaciones que se usarán [1]. Sin embargo, estos enfoques no resultan ser los más adecuados para muchos de los proyectos relacionados a escenarios actuales, donde el entorno del sistema es muy cambiante y en donde se exige reducir drásticamente los tiempos de desarrollo, sin descuidar los niveles de calidad.
Como contraparte a las metodologías clásicas, surgen ciclos de desarrollo ágiles que persiguen principios tales como la entrega incremental al cliente, la mejora continua y el énfasis en la colaboración cercana entre el equipo de desarrollo y los expertos del negocio [2]. Estos enfoques se caracterizan por prácticas enfocadas en ciclos de desarrollos cortos, iterativos e incrementales, con equipos pequeños y auto organizados, refactorización de código, donde el desarrollo conducido por la prueba es práctica habitual y la participación de los clientes en forma frecuente permite presentar la evolución del producto en cada ciclo de desarrollo [3].
Diversos estudios demuestran que la adopción de prácticas ágiles se ha incrementado en los últimos años. Según el último reporte de VersionOne [4], más del 80% de las empresas usan algún enfoque guiado por prácticas ágiles para el desarrollo de sus aplicaciones, debido a que favorecen una adaptación más rápida a los cambios del mercado.
A la adopción de enfoques ágiles se suma la aplicación de modelos de calidad como alternativa para fomentar la mejora continua en las empresas de software, estableciendo procesos con insumos y resultados medibles, reduciendo costos y promoviendo la eficiencia. Con todo esto, las empresas se ven beneficiadas al poder ofrecer a sus clientes productos de mayor calidad y seguridad en el cumplimiento de los tiempos previstos [5].
En este sentido, y habiendo realizado un análisis de la literatura disponible, en su mayoría, los estudios se centran en analizar la relación entre calidad y procesos ágiles, sin evaluar cómo se implementan las prácticas ágiles utilizadas. Así, y teniendo en cuenta las particularidades de organizaciones tipo PYMES, resultados de estudios previos realizados [6][7], demuestran la ausencia de estrategias que permitan a las empresas integrar agilidad a sus ciclos de desarrollo sin dejar de lado aspectos relacionados a la calidad de software.
En este sentido, y como primera alternativa, se viene trabajando en la implementación y validación de un marco de trabajo que permita evaluar la calidad cuando se opta por trabajar con procesos ágiles de desarrollo de software. Dicho framework se denomina AQF (Agile Quality Framework) y su versión actual está formada por un modelo, QuAM (Quality Agile Model), compuesto por componentes cuyos niveles de calidad asociados pueden ser medidos a través de métricas, atributos y criterios, y por QuAGI (Quality AGIle), una herramienta de software que brinda soporte a dicho modelo a través de la automatización del seguimiento de proyectos y la visualización de diferentes informes.
Tras diversos casos de estudio, que preceden al que aquí se presenta, AQF[8], con su versión v2.0.0, ha mejorado el procedimiento de evaluación de calidad del proceso y actualmente se analizan resultados sobre experiencias de validación de esta nueva propuesta.
Los procesos de desarrollo de software utilizando prácticas ágiles dependen del funcionamiento de sus equipos de trabajo en forma flexible y con poder de decisión [9], deben estar integrados multifuncionalmente, colaborando en ofrecer conocimiento y enriquecer al cliente. son dinámicos y rápidamente reconfigurables, dando flexibilidad a la organización; son cooperativos, en y entre las compañías, permitiendo la cooperación intra y extra organizacional necesaria para aumentar la competitividad; y son virtuales, lo cual permite a la compañía combinar los recursos necesarios para cumplir los objetivos empresariales [10]. Tal como lo expresa Beck en los principios del manifestó de desarrollo ágil de software [2], un equipo de trabajo ágil puede mejorar la velocidad y la productividad logrando obtener las mejores arquitecturas, requisitos y diseño de software.
En base a ello, AQF incluye entre sus componentes a la evaluación de la calidad del proceso de desarrollo ágil teniendo en cuenta el flujo de comunicación entre los miembros del equipo a partir de la división de tareas y la transparencia del trabajo realizado en base a la definición de roles.
Por todo ello, en este artículo se presenta la nueva extensión de AQF v2.0.0 al incorporar a su esquema de componentes el análisis de los equipos de trabajo como factor que impacta directamente en la calidad de procesos de desarrollo de software bajo enfoques ágiles. Además, se incluyen los resultados de la validación a través de un caso de estudio diseñado a tal fin.
El resto del artículo se estructura como sigue: en la sección III se presenta brevemente el framework AQF v2 junto a sus componentes, y se describe, específicamente, la métrica asociada a la evaluación de los equipos de trabajo. En la sección IV se expone el diseño del caso de estudio junto al proceso de validación llevado a cabo. La sección V incluye el análisis de los resultados obtenidos. Y finalmente, en la sección VI se presentan conclusiones y la propuesta de trabajos futuros posibles.
III. Evaluación del equipo de trabajo en AQF
El framework de evaluación propuesto AQF v2.0.0 ofrece a las empresas valores cuantitativos respecto a la calidad de los procesos ágiles y apreciaciones cualitativas que caracterizan los niveles obtenidos. Su aporte significativo se centra en que el nivel de calidad de un proyecto ágil no puede estar definido únicamente por un valor numérico, sino que deben analizarse una serie de cuestiones, en base al contexto en el que se desarrolla el proceso, que seguramente condicionen la ejecución de este.
A.Componentes de AQF v2: La relación entre QuAM y QuAGI
Uno de los componentes de AQF v2 es QuAM [11], un modelo conceptual que tiene por objetivo proporcionar un método que permita evaluar la calidad de los procesos de desarrollo de software basados en prácticas ágiles, y por aplicaciones de software que dan soporte a la gestión de este modelo.
QuAM se compone de un esquema organizado por componentes (Ci, i = 1...4) que incluyen atributos medibles (Ai), cada uno de los cuales puede clasificarse como uno de dos tipos posibles: Atributos Positivos, aquéllos que se desean enfatizar y promover para aumentar los niveles de calidad, y Atributos Negativos, aquéllos que se deberán minimizar para que no afecten disminuyendo los niveles de calidad del proceso. Cada atributo de modelo puede ser cuantificado por una o varias métricas, dependiendo de cómo se realice la medición. La métrica contiene la información del método y la escala de medición (y / o cálculo) definidos.
En la definición de QuAM, la evaluación de cada componente se especifica a través del proceso de medición de las métricas asociadas a los atributos que lo componen, cuyo resultado ofrece evidencia empírica para poder comprender de mejor manera las diferentes dimensiones que engloban la calidad del proyecto ágil que se analice. El esquema completo de QuAM se presenta en la Figura 1.
En el caso del Componente Nº 2 “Evaluación del equipo de trabajo”, el framework considera como impacto positivo en la calidad a la definición clara de roles, y de impacto negativo, a la falta de organización del proyecto restándole importancia a la definición de sprints. Este componente, entonces, se evalúa en base a la medición de dos atributos:
• Atributo Positivo: Valor a la definición de roles y tareas
En primer lugar, forman parte del atributo positivo los criterios que permiten evaluar la manera en la que se definen y se asignan las tareas, buscando promover que los proyectos ágiles definan roles para cada uno de los integrantes del equipo y valoren la transparencia del proceso, de forma tal de implementar estrategias que permitan que todos estén informados de las tareas que realiza cada uno. Para lograrlo QuAM establece que se evaluará, por cada historia de usuario, que las tareas definidas tengan asignado un responsable dentro del equipo y que además la tarea esté clasificada (por ejemplo, Frontend, Backend, Testing, etc), de modo tal de ofrecer información al equipo sobre quién está realizado qué tipo de tarea en todo momento. Entonces, por ejemplo si todas las tareas del proyecto han sido completamente definidas, es decir tienen asignado un responsable y han sido tipificadas, el atributo positivo tomará el máximo valor posible. En el caso que ninguna de las tareas hayan sido completamente definidas, entonces QuAM establece que esta situación representa el valor más bajo de la escala y asigna el peor nivel de calidad para el atributo positivo.
FIGURA I: ESQUEMA COMPLETO DE QuAM
• Atributo Negativo:Valor al proceso por sobre el equipo
Por otro lado la evaluación del Componente #2 considera como factor de impacto negativo definir historias de usuario “islas solitarias”1 , es decir que no pueden incluirse en ningún sprint ni se componen de tareas que permitan mejorar su significado. Este atributo surge a partir de la experiencia empírica en ambientes reales donde fue posible observar que al restringir la representación de la necesidad del cliente a la mera definición de la historia de usuario, sin descomposición en tareas, ni agrupación en algún sprint, se otorga más valor al proceso de elicitación que a la organizaciòn del equipo que en definitiva trabajará sobre la necesidad. En estos casos, la priorización en el proyecto se torna difícil, debido a la escasa información con la que se cuenta, y a su vez se quita valor al equipo, pues pierde el foco de trabajo y se centra en tratar de descifrar el problema. Así, la calidad del proyecto sufre un impacto negativo el seguimiento del proceso no podrá realizarse correctamente sin tener la información clara ni del problema ni del equipo.
Finalmente en la Tabla I se muestra cómo el Componente N° 2 “Evaluación de Equipo de Trabajo” ha sido conformado teniendo en cuenta atributos, criterios y valores asociados.
TABLA I: ATRIBUTOS Y CRITERIOS DEL COMPONENTE N° 2
IV. Resultados y objetivos
EComo se expresó anteriormente, la primer versión de AQF ha sido validada a través de la ejecución de diferentes casos de estudios en empresas PYMES de desarrollo de software. Tras evaluar los resultados se hizo necesario que la plataforma fuera mejorada en un proceso de reingeniería, obteniéndose así una nueva versión del framework: AQF v2.
De esta forma, y con el objetivo de evaluación de esta nueva versión, se han diseñado nuevas experiencias a través de casos de estudios que permitan validar el framework en todos sus aspectos.
Así, en este caso se considera un caso de estudio que incluye la implementación de AQF v2 sobre varios equipos de trabajo diferentes trabajando en diversos proyectos ágiles.
A. Caso de Estudio
La experiencia que aquí se describe contempla la participación de 20 equipos de proyectos de software guiados por algún enfoque ágil (SCRUM, XP, Lean Kanban, entre otros), localizados geográficamente en Chaco y Corrientes. El objetivo del caso de estudio se centró en validar la información que AQF proporciona respecto a la calidad lograda a nivel de equipo de trabajo en cada proyecto, y cómo esto impacta en la mejora de los procesos asociados.
La metodología de evaluación implicó la implementación real de AQF como herramienta de seguimiento de proyecto, para lo cual se solicitó al equipo de la empresa que se registre en la plataforma QuAGI [12]. Luego desde la administración de QuAGI se establecieron permisos, indicando quién tendría el rol de Administrador del proyecto, que a su vez debe dar de alta al Cliente o Product Owner. Cabe destacar que de la experiencia participaron todos los integrantes del equipo, incluyendo al Product Owner.
Una vez configurado el equipo, se continuó con la carga de información relevante al proyecto (Fecha de Inicio, Metodología ágil, Nombre). Luego se solicitó se registren datos del sprint en ejecución, haciendo foco en el conjunto de historias de usuario y sus tareas correspondientes. En el caso de los equipos que debían trabajar sobre información cargada en otras herramientas de seguimiento, se realizó una importación de datos hacia QuAGI a cargo del equipo técnico de AQF.
Para iniciar la primera iteración de uso de AQF, se indicó al Administrador del proyecto que solicite obtener la calidad correspondiente al Componente N° 2, permitiendo que esa información quede registrada y pueda ser analizada a posteriori.
Respetando acuerdos de confidencialidad no es posible publicar información referente a cada empresa, ni a los proyectos considerados para este estudio.
Así, y habiéndose llevado a cabo la implementación de AQF, se exponen a continuación los resultados obtenidos de la experiencia.
B. Análisis de Resultados
En primera instancia, y como se muestra en la Figura 2, la mayoría de los proyectos participantes utilizan Scrum como framework de desarrollo ágil de software.
Figura 2. Enfoques ágiles usados
De acuerdo con lo que se observa en la Figura 3, y considerando la totalidad de proyectos estudiados, el valor obtenido durante la primera ejecución de evaluación de calidad de la métrica fue en promedio igual a 1, pues para el 75% de los casos el nivel de calidad de “Evaluación del equipo de trabajo” ha sido Regular. Esto sin haber implementado las recomendaciones de AQF.
 Figura 3. Nivel de calidad asociado a la métrica 2 durante la primer iteración
Asimismo, en la Figura 4 se muestra la descomposición que se obtuvo, en general, para los valores del atributo positivo y del atributo negativo.
 Figura 4. Valores obtenidos por los atributos
En el caso del atributo positivo, es decir respecto a “Valorar la definición de roles”, en promedio se alcanza, de acuerdo con lo establecido por QuAM, un valor aproximado de 2, lo que significa que en la mayor parte de los proyectos analizados más del 80% de las tareas tienen definido responsable y tipo.. Para mejorar este rendimiento, se han identificado las historias de usuario que no se correspondían con lo recomendado por el modelo y se ha entregado dicha información a la empresa.
Respecto al atributo negativo, se obtuvo en promedio un valor de -1 lo que, según QuAM en AQF v2.0.0, significa que si bien todas las US se encuentran agrupadas en sprints solo el 80% tienen tareas definidas. Esto afectaría el seguimiento del proyecto, además de la priorización y la estimación para cada historias de usuario. Así, y si bien no forma parte del alcance de AQF v2.0.0 resolver cómo definir tareas en cada US, se recomendó al equipo llevar a cabo los siguientes pasos: (1) realizar un primer esquema y análisis técnico del proceso; (2) determinar el “Definition of Done” (DoD), de aquí surgirá la necesidad de diversas tareas (por ejemplo revisiones de código, preparación de la demo, entre otras); (3) realizar un mapa de historias de usuario que permita visualizar vertical y horizontalmente el proyecto completo.
Luego de esta primera iteración, el proceso de validación continuó a partir de la incorporación de mejoras, tomando como base las recomendaciones obtenidas a partir de la primera evaluación realizada usando AQF v2.0.0.
Ahora, como se ve en la Figura 5, los niveles de calidad asociados a la “Evaluación de Equipos de Trabajo” mejoraron notoriamente al incorporarse las mejoras recomendadas respecto a la información registrada en cada sprint backlog.
 Figura 5. Valores obtenidos por los atributos luego de implementarse las recomendaciones
Para fortalecer aún más los resultados cuantitativos obtenidos con AQF v2, se realizó una reunión con cada equipo a fin de obtener un feedback cualitativo a través de la recolección de sensaciones y percepciones in situ (en la mayoría de los casos la reunión se llevó a cabo de manera remota pues no fue posible acordar un horario y se quiso evitar interrumpir en demasía con el trabajo diario de cada PYME).
Así, los Administradores de Proyecto han manifestado que la primera acción llevada adelante para mejorar el rendimiento fue frenar la ejecución del proyecto y establecer una clara definición de roles, distribuyendo las tareas entre cada miembro del equipo de acuerdo a su perfil. Esto contribuyó, incluso, a una mejor comunicación e interacción con el cliente por parte del equipo, y brindó mayor claridad al seguimiento de cada proyecto.
Por otro lado, se identificaron aquellas US aisladas que dificultaban la distribución de tareas y por lo tanto afectaban negativamente con la estimación del proyecto. Luego, se asignó cada una de ellas, de acuerdo con su prioridad y a la necesidad que describían, al sprint correspondiente. En algunos casos la US identificada fue incluida como tarea en la realización de otra US. Algunos equipos han explicado que la inclusión del Story Map ofreció una visión integral del proyecto, y colaboró en una mejor definición de los requerimientos del mismo.
V. Conclusiones
Este trabajo presentó los resultados obtenidos a partir de la evaluación de calidad de proyectos ágiles en ambientes reales de desarrollo en PyMEs de Chaco y Corrientes, a través del uso de QuAGI (Quality AGIle), como herramienta de seguimiento de equipos de trabajo a partir de una nueva propuesta incluida en el modelo denominado QuAM (Quality Agile Model), y conformando ambos la configuración inicial del framework AQF (Agile Quality Framework). A través del diseño de una experiencia de validación que permitiera la ejecución del framework en ambientes reales, se ha observado que las empresas lograron incorporar fácilmente a QuAGI como herramienta de soporte al proceso de desarrollo y gestión de sus proyectos ágiles. Esto debido a, según expresan las mismas empresas, la plataforma proporciona a sus usuarios una interfaz amigable y con flujos de trabajo claramente definidos que alivianan los procesos asociados a la gestión. Y, respecto a los resultados obtenidos a través de la evaluación de calidad del componente “Evaluación de Equipos de Trabajo”, las empresas han manifestado que reflejan en gran medida lo esperado de acuerdo con las características particulares de cada una y se pudo concluir que aún era necesario establecer nuevas estrategias que permitieran mejorar la interacción en los equipos y por ende su productividad. El factor más crítico, de acuerdo con lo expresado por las empresas, está relacionado a la falta de claridad y organización en la distribución de tareas de acuerdo a los perfiles que participan en cada equipo. Y, fue en este sentido, en el que AQF ha colaborado fuertemente en la identificación de aquéllos aspectos que afectaban negativamente este desempeño.
Como trabajos futuros se pretende llevar a cabo más casos de estudio que permitan lograr la versión que se adecúe, en mayor medida, a la realidad de las PyMES, incorporando sus prácticas más comunes y permitiendo obtener el nivel de calidad más representativo a cada proyecto ágil que se evalúe a través de AQF. Además, resulta necesario incorporar al estudio de validación el resto de los componentes para analizar el funcionamiento integral del framework.
Finalmente, a pedido de las empresas, se continuará expandiendo AQF mediante la incorporación de un Asistente Virtual que actúe en función a eventos, libere de trabajo de monitorización a los Administradores de Proyecto y de soporte a la toma de decisiones de directivos de las empresas.
1. El término “islas solitarias” fue acuñado por el equipo que colaboró en el desarrollo del software que forma parte del framework AQF y hace referencia a historias de usuario que no pueden agruparse en ningún sprint y para las que además no se han definido tareas
VI. Referencias y Bibliografía:
[1] Letelier, P., Penadés, P. “Metodologías ágiles para el desarrollo de software: eXtreme Programming (XP)” Técnica Administrativa, Buenos Aires. ISSN 1666-1680 (2006).
[2] Alliance, A. “Agile manifesto”. Disponible en http://www. agilemanifesto.org (2001)
[3] Swebok,[Online].Available: ttp://www.computer.org/portal/web/swebok
[4] Pardo, César, JULIO ARIEL HURTADO, and CÉSAR A. COLLAZOS. "Mejora de procesos de software ágil con Agile-SPI Process." Dyna 77.164 (2010).
[5] Instituto de Fomento Empresarial – IFE. “Polo IT - Hacia la Certificación de un Sistema de Gestión de Calidad”,http://www.ife.gov.ar/articulo/articuloDetalle.aspx?articuloid=622
[6] Rujana, M., Romero Franco, N., Tortosa, N., Tomaselli, G., & Pinto, N. (2016). “Análisis sobre adopción de metodologías ágiles en los equipos de esarrollo en pymes del NEA”. XVIII Workshop de Investigadores en Ciencias de la Computación (WICC 2016)
[7] Noelia Pinto; César Acuña; Nicolás Tortosa; Blas Cabas Geat (2017) XXIII Congreso Argentino de Ciencias de la Computación. La Plata, Buenos Aires. Argentina. “Evaluating Quality in Agile Developments. A first validation experience with NEA Software SMEs.”
[8] Pinto, N., Acuña, C., Tortosa, N., & Cabas Geat, B. (2017). Evaluating Quality in Agile Developments. A first validation experience with NEA Software SMEs. In XXIII Congreso Argentino de Ciencias de la Computación (La Plata, 2017).
[9] Vadillo, M. T. P. (2013). Liderazgo y motivación de equipos de trabajo. ESIC Editorial.
[10] Manyoma Velásquez, P. C., & Alarcón Henao, A. M. (2013). Manufactura ágil: aclaraciones y confusiones.
[11] Pinto, N., et al (2016). Validación del diseño de componentes de QuAM: un Modelo de Calidad para procesos Ágiles. Publicado en Anales del IV Seminario Argentina-Brasil de Tecnologías de la Comunicación y la Comunicación (SABTIC 2016). ISBN 978-987-3619-15-1.
[12] Aplicación publicada en quagi.frre.utn.edu.ar
Recibido: 2019-04-30
Aprobado: 2019-06-15
Datos de edición: Vol.4 - Nro.1 - Art.1
Fecha de edición: 2019-06-28
URL: http://www.reddi.unlam.edu.ar
| |