Spanish (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
1. INTRODUCCIÓN
Un factor fundamental en un equipo que desarrolla software está relacionado con la productividad [1]. Para mejorar la productividad de un equipo, se hace necesario conocer cómo se comporta de forma regular en unos intervalos de tiempo. En este sentido, se requiere recopilar y analizar datos durante dichos periodos como una vía o camino objetivo para aprender sobre este y generar información que posibilite la toma de decisiones. Tal proceder debe ser permanente y continuo; con la información generada, se pueden aplicar cambios o ajustes a la forma de trabajo e iniciar una nueva recopilación y análisis de datos.
El mejoramiento continuo en la forma como se desarrolla software ha sido un tema de indagación permanente [2]; en [3], se muestran diferentes formas innovadoras de alcanzar mejores desempeños cuando se construye software.
Para llegar a ser más productivas, las organizaciones han venido incorporando métodos que se basan en los valores y principios propuestos en el manifiesto por el desarrollo ágil de software (por sus siglas en inglés, asd) [1]. Estos fueron planteados en el año 2001 y han generado una serie de prácticas que, se cree, ofrecen mayor valor a los clientes. Diez años después de haber sido propuestos, en [4], se hace una revisión y análisis sobre los efectos; no obstante, este estudio se pude considerar un punto de partida para hacer nuevos análisis sobre el impacto y efecto que asd está teniendo en la industria del software y en la academia.
Estos métodos se basan en los principios enunciados en el manifiesto por el desarrollo ágil de software [5], y buscan desarrolladores de software motivados y capacitados, que confíen en la excelencia técnica y el diseño simple y agreguen valor al negocio mediante la entrega de un software funcional a los usuarios, en intervalos cortos y regulares de tiempo [6], [4]. En el centro de estas prácticas, está la idea de equipos autoorganizados, cuyos miembros no solo están colocados, sino que también trabajan a un ritmo que mantiene su creatividad y productividad [4].
Además, el principal objetivo del asd es proporcionar productos de software rápidamente [7], que solucionen problemas al cliente, pero a la vez permitan cambios frecuentes a las especificaciones.
Un elemento que faculta la recopilación de datos sobre el desempeño de un equipo son las métricas. Una métrica es comprendida como aquellos datos que se pueden obtener de la ejecución de un intervalo regular de tiempo (ciclo, incremento, iteración), al construir software en equipo [8]; asimismo, puede ser una simple fuente de datos o un conjunto de datos de múltiples fuentes.
Generalmente, las métricas poseen información sobre una variable que se desea conocer. Un ejemplo de métrica en la construcción de software en equipo es la velocidad [8], es decir, la capacidad que un equipo tiene sobre el tiempo, para hacer funcionalidades de un producto software que pueda solucionar el problema de un cliente.
El uso de métodos ágiles se hace más frecuente en la industria del software [9], [10] y las métricas pueden ser usadas para recolectar información relevante. Cuando se construye software desde un enfoque ágil, las personas involucradas desempeñan diferentes roles y poseen una variada experiencia [8]. En este orden de ideas, el significado de relevante pude cambiar según el rol; por ejemplo, uno de los marcos de trabajo más utilizados en asd es Scrum [6 ], [ 11] . Este método ágil presenta un conjunto de lineamientos para el desarrollo, despliegue y mantenimiento de software en equipo. Estos están categorizados por roles, eventos, artefactos y las reglas que los relacionan [12].
Al gestionar el proceso de hacer software con Scrum, el product owner -uno de los roles- puede estimar que lo importante es el número de funcionalidades desplegadas, que solucionan parte del problema al cliente.
Pero, un integrante del development team puede, a su vez, considerar que lo relevante es el nivel de complejidad que poseen las funcionalidades que se desarrollan. Los dos roles persiguen el mismo propósito, pero comprenden de manera diferente la manera de medir lo que están haciendo [8].
En el enfoque ágil, los valores y principios se pueden tornar abstractos al convertirlos en mediciones que proporcionen información. Por ejemplo, dentro de los principios del manifiesto ágil propuesto por Beck y otros [5], se plantea que, el software funcionando es la principal medida de progreso. El concepto software trabajando resulta ambiguo [8], porque puede estar dando respuesta a las funcionalidades, priorizadas para solucionar un problema del cliente; sin embargo, no consigue abordar atributos de calidad para desplegar el software [13].
Un ejemplo de lo anterior se da cuando la funcionalidad es hacer una transferencia de dinero de una cuenta a otra, pero la seguridad como atributo de calidad, impide que se pueda desplegar el software, sin haber tenido en cuenta todos los vacíos de seguridad que se puedan presentar durante esta acción.
Otro punto de reflexión sobre los principios del manifiesto ágil propuesto por Beck y otros [5] radica en la entrega temprana y continua de software con valor, es decir, el desarrollo de software de forma iterativa e incremental en intervalos regulares de tiempo. Esta acción hace que un equipo de desarrollo genere datos de manera permanente, pero sin una vista unificada [8], en diferentes sitios, a través del uso de diversas técnicas y herramientas. En este caso, para hacer seguimiento al trabajo del equipo, se puede utilizar un tablero Kanban [6], en el que sea posible visualizar, de la manera más simple, las tareas: pendientes, en progreso y finalizadas. Esta manera de hacer seguimiento al trabajo en equipo se puede hacer manualmente, a través de una plantilla o utilizando una herramienta software. Cada una de estas, representa una forma diferente de almacenar los datos para conocer cómo comprende el proyecto el equipo, la rapidez con que actúa y la consistencia para completar el trabajo [8].
Por otra parte, se debe partir del supuesto de que cualquier medida utilizada para decidir tiene que ser de bajo costo [8]. En este sentido, se debe estimar que, el recurso y el esfuerzo invertido para generar información no deben tener mayor peso que la recolección y el análisis de los datos. De igual forma, esta premisa es relevante para definir aquello que es importante medir. Frente a lo anterior, han surgido iniciativas como el agilismo moderno [14] y el corazón de lo ágil [1], en las cuales se reflexiona acerca de los métodos ágiles y se concluye que, desde la aparición del manifiesto por el desarrollo ágil de software [5], se han venido involucrando aspectos que han hecho perder el horizonte del sentido de lo ágil o han logrado superar los principios y valores expuestos en este.
La motivación por esta investigación surgió en la búsqueda de establecer métricas que permitan medir la productividad de un equipo en asd, que reduzcan la ambigüedad y la abstracción de los principios del manifiesto por el desarrollo ágil de software y se aproximen a las nuevas reflexiones sobre el agilismo.
2. TRABAJOS RELACIONADOS
Una métrica de equipo es entendida como la forma de recopilar y analizar datos y producir información objetiva que permita aprender sobre un equipo, aspecto que incluye aquellos ajustes en el comportamiento del mismo [8]. Como se expresa en [1], el comportamiento se asocia principalmente con la productividad o el desempeño. En la Ingeniería de Software, la productividad se define, con frecuencia, desde un punto de vista económico, y se entiende como la efectividad del esfuerzo productivo, es decir, la tasa de producción por unidad de entrada [1]. Generalmente, la unidad de entrada es el esfuerzo invertido en el desarrollo de software y la salida es el producto software. De acuerdo con el manifiesto que guía el desarrollo ágil de software [5], los principios que se relacionan con la productividad son:
-Satisfacer al cliente mediante la entrega temprana y continua de software con valor, a saber, el software debe solucionar un problema y la entrega se debe hacer de manera iterativa e incremental.
-Para que la entrega del software sea temprana y continua, se debe desplegar en periodos cortos de tiempo.
-Los proyectos se desarrollan en torno a individuos motivados, es decir, la productividad para el equipo se basa en el interés que sus integrantes tengan por invertir el esfuerzo en el cumplimiento de un objetivo, esto es agregar valor rápidamente mediante del software.
-El software funcionando es la medida principal del progreso, pero debe, además, agregar valor al cliente.
-La simplicidad o el arte de maximizar la cantidad de trabajo no realizado es fundamental para la mejora de la productividad.
Si se interrelaciona la definición de productividad [1] con los principios seleccionados del manifiesto por el desarrollo ágil de software [5] y el trabajo en equipo (ver Tabla 1), se puede establecer que la unidad de entrada corresponde al esfuerzo invertido por los integrantes del equipo. Este esfuerzo está orientado al cumplimiento de los principios del manifiesto por el desarrollo ágil de software relacionados con productividad, los cuales buscan entregar software de manera tempana y continua, en periodos cortos de tiempo, únicamente, mediante las tareas necesarias. Durante este proceso, los integrantes del equipo deben permanecer motivados. La salida corresponde no únicamente a un producto software que funcione; por el contrario, los principios del manifiesto por el desarrollo ágil de software invitan a que el resultado sea un software que agregue valor y satisfaga las necesidades del cliente.
Aunado a lo anterior, como resultado de más de cuatro años de cooperación entre la academia y las empresas de desarrollo de software, en [15] hacen una propuesta para desarrollar el proceso de medición, en la cual se plantea agrupar las métricas vinculadas con productividad organizacional y calidad del producto, en cinco categorías de medidas utilizadas en los sistemas de medición: proyecto, diseño, desempeño organizacional, producto y negocio. En este orden de ideas, las métricas de productividad en equipo se pueden clasificar en aquellas que aporten a la definición planteada de productividad en equipo desde asd, para las categorías propuestas por [15].
Existen varios estudios enfocados en identificar métricas en el desarrollo ágil de software. En [16], se analizaron las razones y efectos de usar métricas en la industria de software, enfocadas en las métricas para equipos ágiles. Con este fin, se hizo una revisión sistemática de literatura y se estableció un comparativo entre el uso de métricas tradicionales y ágiles. El trabajo adelantado permite concluir que el uso de métricas en asd es similar al desarrollo de software tradicional. Además, se deben incluir métricas relacionadas con los proyectos y Sprints para ser planeados y monitoreados; la calidad debe ser medida y los problemas en el proceso de software deben ser identificados y solucionados.
En [17], se analizó literatura sobre investigaciones vinculadas a factores que inciden en la productividad en asd, frente a lo cual se identificaron los conceptos, los métodos más utilizados, los niveles y las métricas de productividad. El análisis se hizo mediante un estudio de mapeo sistemático (sms), en el que se seleccionaron 25 artículos.
Esta investigación permitió identificar los principales factores que afectan la productividad en asd y el contexto en el cual los estudios seleccionados fueron realizados. El método de investigación que predomina es el estudio de caso, en el que se utiliza ampliamente la encuesta y la entrevista para la recolección de datos.
Asimismo, se estima que la mayoría de los factores que afectan la productividad en asd están relacionados con equipos ágiles y, aunque la calidad debe estar unida a la productividad, no fue considerada en todos los estudios.
En torno al marco del proyecto Q Rapids (Horizonte 2020) [18], se hizo un estudio de caso múltiple en cuatro empresas Agiles, para lo cual se aplicó el enfoque Goal-Question-Metric (gqm), a fin de investigar los motivos que explican la elección de las métricas de proceso en asd y los desafíos a los que se enfrenta cuando se operacionalizan. Los resultados reflejan que las empresas están interesadas en evaluar aspectos del proceso como velocidad, desempeño en las pruebas y precisión de la estimación, por lo que prefieren elaborar métricas personalizadas para estas evaluaciones. Adicionalmente, las empresas utilizan las métricas como un medio para acceder e incluso capitalizar los datos, hasta ahora inaccesibles debido a limitaciones técnicas o de proceso. Sin embargo, el contexto de desarrollo de una empresa puede obstaculizar la operacionalización de las métricas y se manifiesta principalmente como falta de disponibilidad de los datos.
En [19], se presentan los resultados preliminares de una revisión sistemática de literatura sobre el uso de métricas en asd. Como resultado, se identifica que las métricas se enfocan en las siguientes áreas: planeación y seguimiento de las iteraciones, motivación y mejora, identificación de problemas del proceso, calidad de un prelanzamiento y cambios en el proceso o las herramientas.
Al contrastar los hallazgos con los principios para el desarrollo ágil de software, se observa que el uso de métricas es un apoyo, con algunas excepciones.
Así mismo, se encontró poca evidencia del uso de métricas para el código y mucha sobre el uso de métricas de planificación y seguimiento.
En [20], se explora qué métricas son acordes con el proceso asd, el uso de esas métricas en la práctica, los beneficios percibidos y las herramientas relacionadas.
El análisis se basó en encuestas y entrevistas aplicadas a ingenieros de software de 24 empresas de desarrollo.
Además, se identificaron diez métricas que pueden ser beneficiosas para el proceso asd, en las que los réditos superan los gastos generales involucrados.
Existen trabajos que, si bien analizan las razones de la selección, uso y efectos de las métricas en asd -bajo la aplicación de técnicas como la revisión sistemática de literatura (slr) o a través de estudios de caso con encuestas y entrevistas-, exponen un vacío en relación con aquellas métricas que permiten medir la productividad de un equipo en asd.
3. METODOLOGÍA
Para lograr el objetivo de identificar las métricas que hacen posible medir la productividad de un equipo en asd, se utilizó como técnica la revisión sistemática de literatura (slr) descrita en [21].
3.1 Preguntas de investigación
Las preguntas de investigación formuladas se basan en la pregunta principal: ¿Cuáles son las métricas que permiten medir la productividad de un equipo en asd?
A partir de la pregunta principal, se derivaron las preguntas secundarias que dieron lugar al análisis y categorización de los estudios primarios:
RQ1. ¿Qué métricas fueron estudiadas?
RQ2. ¿Cómo se categorizan las métricas?
RQ3. ¿Qué mediciones plantean las métricas?
RQ4. ¿Cómo se articulan las métricas con las nuevas reflexiones sobre el agilismo?
3.2 Proceso de búsqueda
Como parte del protocolo para buscar estudios primarios, se identificaron las fuentes de información y se definió la cadena de búsqueda, según la pregunta de investigación principal. Las bases de datos que se utilizaron como fuentes de información fueron ScienceDirect y Springer. En el momento en que se desarrolló la revisión sistemática, se contaba con acceso libre a las fuentes de información descritas anteriormente; por esta razón, se tomó la decisión de trabajar con estas, con la pretensión de identificar métricas de productividad para equipos que hacen software y se fundamentan en asd. Con este artículo se busca, asimismo, generar un protocolo para la búsqueda de este tipo de métricas bajo el enfoque teórico de asd, que pueda replicarse a otros repositorios y que posibilite complementar este trabajo.
La cadena general creada para establecer los criterios de búsqueda se configura a partir de los datos mostrados en la Tabla 2.
La cadena de búsqueda fue elaborada construyendo expresiones que utilizan los operadores booleanos or y and. El operador or se usó para incorporar sinónimos del concepto de búsqueda, mientras que el operador and hizo posible agregar las palabras relacionadas en la cadena de búsqueda.
Para la ejecución de las búsquedas, se examinó el título, el resumen y las palabras clave, dentro de los resultados obtenidos gracias a los motores de búsqueda de cada fuente de datos seleccionada. La revisión de artículos se limitó a aquellos escritos en inglés y dentro de una ventana de observación entre el 2013 y 2018. Los valores y principios propuestos en el manifiesto por asd en 2001 tienen una revisión y análisis en [4], diez años después de haber sido propuesto.
A partir de esta reflexión, surgen iniciativas para indagar formas que permitan recopilar datos para analizar y generar información, a través de métricas, sobre el efecto e impacto que están teniendo las propuestas ágiles en la construcción de software [17], [7], [18]-[21].
Esta tendencia muestra que los principales estudios se desarrollan desde 2013, razón que justifica la revisión a partir de este año, por impacto, vigencia y tendencia.
3.3 Proceso de selección
Después de adelantar el proceso de búsqueda, se seleccionaron los estudios relevantes, es decir, aquellos artículos que permiten dar respuesta a las preguntas de investigación planteadas. Para determinar la relevancia de los estudios, se establecieron unos criterios de inclusión y exclusión, que se pueden observar en la Tabla 3.
Para la aplicación de los criterios de inclusión y exclusión, como parte de la selección, se definieron los filtros que se muestran en la Tabla 4.
En la Fig. 1, se pueden observar los resultados obtenidos de la aplicación de los filtros definidos en la Tabla 3. Cuando se aplica el filtro 2F, se profundiza de manera comprensiva -gracias a la lectura del título, palabras clave y resumen- sobre métricas que se puedan vincular con el desempeño en equipo para asd. En este filtro, se pueden descartar estudios que presentan aparente relación con el tema; no obstante, es tos se pueden centrar en otros aspectos diferentes al propósito principal de esta investigación. El mayor descarte se presentó principalmente en la fuente ScienceDirect. Cuando se aplica el filtro 3F, se hace la lectura de los resultados y conclusiones. En este punto, es cuando se descarta la mayoría de los estudios en la fuente Springer, porque, a nivel general, se encuentra que presentan aspectos de ingeniería de software -algunos analizados desde asd - o que directamente son abordados desde el agilismo, pero no corresponden con un proceso de medición sistemático, en el cual
se puedan llegar a identificar entidades y atributos medibles; un procedimiento para elaborar la medición -en el que las medidas y valores, puedan ser representados mediante un esquema de valoración subjetiva-; la productividad en equipo como una entidad en el proceso de medición. También puede ocurrir que, simplemente, no se relacionen con una productividad organizacional que se pueda transferir a un equipo de desarrollo de software.
3.4 Proceso de evaluación de la calidad
Posterior al proceso de selección, se realiza una nueva tarea para asegurar la calidad de los artículos encontrados, que corresponde a inspeccionar un conjunto de criterios que se muestran en la Tabla 5.
Para evaluar la calidad de los artículos se estableció una escala para inspeccionar el nivel de cumplimiento de los criterios, de la siguiente manera: Alto (2 puntos), Medio (1 punto) y Bajo (0 puntos). Los artículos que cumplieron con valoración igual o superior a 8 (Ver Tabla 6), del total de los puntos posibles, son lo que finalmente se eligieron.
Al finalizar el proceso de evaluación de la calidad, se incluyeron 10 artículos. En la Tabla 7, se presentan los estudios seleccionados.
3.5 Extracción de datos
Tras la evaluación de la calidad de los artículos, se extrajo la información; de cada estudio se obtuvieron los siguientes datos: fuente, autores, título, año de publicación, tipo de documento y nombre de la conferencia o revista en la que se presentó y publicó. En la Tabla 8, se pueden observar las variables analizadas por cada estudio, en relación con las preguntas de investigación formuladas.
4. RESULTADOS
Se analizaron diez estudios primarios. En la Fig. 2 se muestra una distribución de los documentos incluidos por año y tipo. El análisis incluye 6 artículos de conferencia (60 %) y 4 artículos de revistas (40 %); donde el 60 % son trabajos realizados entre los años 2017 y 2018.
A continuación, se presentan los resultados encontrados en relación con las preguntas de investigación.
4.1 Métricas estudiadas (RQ1)
Al identificar las métricas utilizadas en los diez estudios primarios, se encontraron 64 métricas en asd. Del conjunto de métricas encontradas, se extrajeron aquellas que trataran sobre la productividad en equipo para asd y cumplieran los criterios planteados en la Tabla 9.
Tabla 9 Criterios para seleccionar las métricas de productividad en equipo
Fuente: elaboración propia.
Al aplicar los criterios de inclusión y exclusión, se obtuvo un total de 21 métricas, como se puede observar en la Tabla 10.
En la Tabla 11, se presenta una relación de los estudios de los cuales se extrajeron las métricas.
Como se puede observar en la Tabla 12, la mayoría de las métricas encontradas miden la entrega temprana y frecuente de software (38,1 %), seguidas por aquellas que calculan el valor agregado al software (23,8 %). Cabe destacar que no se encontraron métricas para medir motivación del equipo y satisfacción del cliente.
4.2 Clasificación de las métricas (RQ2)
Una vez establecida la relación de las métricas con productividad en equipo para asd, se clasificaron en relación con la propuesta planteada en [15], que define las áreas de desempeño organizacional, diseño, negocio, producto y proyecto. Para esta clasificación, se contrastó la descripción de cada una de las 21 métricas seleccionadas con la información proporcionada por cada sub-área de la propuesta de [15]. Como se observa en la Tabla 13, la mayoría de las métricas de productividad en equipo están en primer lugar orientadas al desempeño organizacional (71,4 %), punto en el que se valora la entrega temprana y frecuente de software, así como el esfuerzo invertido en la tarea y el tiempo. En segunda instancia, se valora el proyecto (23,8 %), orientado expresamente a calcular el valor agregado al software cuando se hace una tarea.
Finalmente, está el área de negocio (4,8 %), en la que la métrica se orienta a medir el valor agregado al cliente.
4.3 Medición y medidas (RQ3)
La medición es un proceso en el que se hace una abstracción del mundo empírico al mundo formal y relacional [31]. En este sentido, una medida corresponde a un valor o a un símbolo asignado a una entidad, como resultado de la abstracción, que permite caracterizar un atributo de la entidad [31]. Una forma de asignar un valor o un símbolo son los esquemas de valoración subjetiva [31], entre los que se encuentran la escala Likert, la clasificación forzada, la escala de frecuencia verbal, la escala ordinal, la escala comparativa y la escala numérica. En la Tabla 14, se expone un ejemplo de esquemas de valoración frecuentemente utilizados.
En [31], se plantea que, para especificar mediciones en ingeniería de software, se deben identificar la entidad, el atributo, la medida y el esquema de valoración.
La entidad es el desempeño de un equipo, las métricas identificadas (ver Tabla 15) representan los atributos y la frecuencia es la medida más recurrente (52,4 %), seguida de la razón (23,8 %), el porcentaje (19 %). Finalmente, se reconoce la proporción como medida en una métrica.
En la Tabla 16, se puede observar que la mayoría de las métricas de productividad en equipo utilizan la escala numérica como esquema de valoración subjetiva (57,1 %), seguidas de la escala comparativa (42,9 %).
4.4 Articulación con las nuevas tendencias (RQ4)
Heart of agile [14] plantea simplificar el asd, porque considera que ha sido excesivamente decorado. En este orden de ideas, proyecta adelantar cuatro acciones [14] que permiten retornar al centro de la agilidad: a) colaborar, es decir, trabajar en equipo, generar y desarrollar mejores resultados en las primeras versiones de las ideas; b) entregar, entendida como hacer pequeñas pruebas iniciales para aprender sobre el domino del problema, corrigiendo y direccionando objetivos; c) reflexionar, entendida como pensar en la forma en que se aprende cuando se trabaja en equipo y cuál ha sido su incidencia en las entregas; d) Mejorar: a partir de la reflexión, se transforman ideas, técnicas y procesos.
Las cuatro acciones invitan a pensar y actuar, permanentemente. En sí, las métricas favorecen la recopilación de datos sobre la productividad en equipo (colaboración y entrega) y su transformación en información (reflexión), lo que da lugar a un ajuste (mejora) en el asd. Estas acciones están alineadas con el fin último de las métricas de productividad en equipo.
En modern agile [32], se plantean un conjunto de principios, que buscan, en primer lugar, hacer que las personas que intervienen en asd puedan desplegar toda su potencialidad. En segunda instancia, se proyecta hacer que la seguridad psicológica sea un elemento fundamental, antes de hacer cualquier esfuerzo. En tercer lugar, se debe entregar valor de manera segura, continuamente. Finalmente, se plantea que es importante aprender rápidamente; para lograrlo, es necesario experimentar frecuentemente, principio que es la base para alcanzar los dos primeros objetivos.
Con modern agile aparecen nuevos retos, porque surge un principio basado en la seguridad psicológica [32], en el que se argumenta que la productividad mejora cuando no se tiene miedo de ser uno mismo, de tomar riesgos, cometer errores, plantear problemas, hacer preguntas y estar en desacuerdo con los demás.
En este punto, se originan desafíos para el diseño de métricas, al identificar los atributos y las medidas necesarias para hacerlo. La entrega de valor, el aprendizaje rápido y la experimentación son acciones que se alinean con la recopilación sistemática de datos a través de métricas, para generar información que derive en una toma de decisiones para la mejora continua.
En síntesis, frente a las nuevas tendencias en asd, los principios que se están promoviendo son la colaboración, la entrega, la reflexión-experimentación y la seguridad psicológica. Al inspeccionar la relación que existe entre las métricas de productividad en equipo identificadas en este estudio con las nuevas tendencias, se encontró, como se expone en la Tabla 17, que el 57,1 % de las métricas propician la reflexión-experimentación y un 42,9 % se orienta a la entrega de software con valor.
No se encontraron métricas para colaboración y seguridad psicológica.
5. DISCUSIÓN
En las métricas identificadas, se determina que existe una tendencia mayor a hacer mediciones acerca del valor que le agregan las tareas o actividades al software y que estas se han definido a través de un método ágil. En este camino, se mide principalmente el esfuerzo invertido en la tarea, aspecto que puede ir en contraposición a los principios del manifiesto por asd, en el que se plantea que el software debe agregar valor al cliente y coincidir con las nuevas posturas del agilismo, y que se debe reflexionar sobre lo que se hace o experimenta. Además, se identifica ausencia en relación con mediciones centradas en el desarrollador, por ejemplo, en el caso de la motivación.
Las métricas se orientan a valorar atributos del software, como entidad resultante de un trabajo en equipo, y a medir el desempeño del equipo, expresado en el cálculo de la efectividad y eficiencia.
No obstante, se identifica una brecha entre el establecimiento de mediciones para la motivación del equipo y la satisfacción del cliente.
La mayoría de las métricas, para el proceso de medición, se dirigen al uso de escalas de valoración numérica y comparativa. Respecto a las medidas, se encontró que los valores más utilizados corresponden a la frecuencia, seguida de la razón y el porcentaje. En este sentido, solo se concibe hacer uso de formas cuantitativas de medición. Para métricas orientadas a la motivación y satisfacción, se puede explorar el uso de elementos cualitativos, sin desconocer que el análisis sea sistemático.
Las nuevas tendencias sobre agilidad invitan a permanecer en un estado de reflexión-experimentación, propiciado por el uso de métricas. Sin embargo, la usencia de métricas para colaboración y seguridad psicológica presenta una oportunidad para establecer procesos de medición, identificar atributos a medir y aplicar esquemas de valoración subjetiva -diferentes a los identificados en este estudio- o proponer nuevas maneras sistemáticas de medición con un enfoque cualitativo o mixto.
6. CONCLUSIONES
La revisión sistemática de literatura en dos fuentes de información (Springer y Science Direct) permitió identificar diez estudios primarios vinculados con métricas de productividad en equipo para asd, de los cuales se extrajeron 21 métricas.
Al establecer la relación entre productividad en equipo para asd y las métricas que se exhiben en los estudios primarios, se reconocen métricas para la entrega temprana y frecuente de software, para el valor que agregan las tareas al producto software e incluso para el esfuerzo invertido en el desarrollo de una tarea en un periodo específico. No se encontraron métricas para medir motivación en el equipo.
Cuando se clasificaron las métricas de productividad en equipo para asd, según la categorización hecha por [15], se encontró que estas se orientan principalmente a medir el desempeño organizacional y a valorar la efectividad y eficiencia del equipo.
El proceso de medición utilizado en las métricas de productividad en equipo para asd identificadas es cuantitativo y utiliza la frecuencia, la razón y el porcentaje como medidas. Además, los esquemas de valoración subjetiva utilizados son las escalas numérica y comparativa.
En la inspección de la relación que existe entre las métricas de productividad en equipo para asd con las nuevas tendencias sobre agilidad, la mayoría propicia la reflexión-experimentación y entrega de software con valor. No se encontraron métricas para colaboración y seguridad psicológica.
La principal limitación de este estudio fue el uso de dos repositorios de estudios primarios, en razón a lo cual, sería importante ampliar esta investigación y utilizar el mismo protocolo con otras fuentes de datos como acm Library e ieee Xplore Digital Library.
