La programación por pares o por parejas fue propuesta como parte del enfoque ágil denominado "programación extrema" a finales de la década de los noventa; desde entonces, su popularidad ha crecido y su estudio se ha realizado desde diferentes ángulos de interés. Aottiwerch y Kokaew (2018), por ejemplo, consideran que cada pareja de programadores debe ser cuidadosamente elegida para que el trabajo sea efectivo; por esta razón, crearon un algoritmo que selecciona al mejor compañero de una persona con base en los siguientes criterios: actitudes, competencias de programación y comportamientos de aprendizaje.

A lo anterior, Poonam y Yasser (2018) añaden que los factores humanos y las características de la personalidad son también importantes para el éxito de los proyectos cuando se programa por parejas. En su investigación, identificaron que los aspectos técnicos de los proyectos se han estudiado más extensamente que los factores humanos. Al conducir un experimento, los autores encontraron una relación significativa entre las personalidades de los programadores, su ubicación de trabajo, local o remota, y el desempeño de las parejas.

Otro aspecto poco estudiado de la programación por pares es el uso de entornos integrados de desarrollo (IDE). Gómez y Aguileta (2018) hicieron aportaciones a esta área con una investigación cuyos resultados indican que, en proyectos sencillos, el uso de un IDE aumenta el número de defectos para programadores solitarios y parejas; sin embargo, en programas más complicados las parejas tienen significativamente menos defectos con el IDE. Estos autores concluyen que los estudiantes deberían realizar sus prácticas iniciales con un simple procesador de textos y un compilador, pero enseguida deben incorporar el uso de un IDE, en especial si trabajan en la modalidad de parejas.

Sadath, Karim y Gill (2018) destacan la brecha que existe entre la enseñanza de la ingeniería de software en las aulas y la realidad actual en el mundo de los negocios. Por este motivo, ellos centran su estudio en la educación universitaria y proponen un marco de trabajo que reúne las mejores prácticas que han probado ser efectivas en la industria. El marco de trabajo incluye la programación por pares como práctica fundamental para potenciar los conocimientos compartidos entre los participantes.

Smith, Giugliano y DeOrio (2018) coinciden en la importancia de trabajar por parejas en los cursos universitarios de ingeniería y programación, pues prepara a los estudiantes para las actividades del mundo real, las cuales no se realizan con frecuencia en solitario. Estos autores efectuaron un estudio para determinar el efecto de la programación por pares en el desempeño académico de los alumnos a largo plazo. Sus resultados muestran que esta manera de programar tuvo un efecto positivo: quienes trabajaron en pares en los cursos introductorios obtuvieron después calificaciones más altas en cursos más avanzados.

Lee et al. (2016) llevaron a cabo una investigación para relacionar las horas de estudio y el desempeño académico de los estudiantes que programan en parejas. Encontraron que se obtiene un mejor desempeño para los estudiantes en riesgo de reprobar con mayores horas de estudio independiente antes de la programación por pares en el laboratorio. Concluyen que la preparación individual aunada a la programación en parejas resulta benéfica para evitar el bajo desempeño en estos cursos.

De acuerdo con Du et al. (2015), la programación por pares es una herramienta útil que mejora la comunicación entre los estudiantes de cada pareja, así como la comprensión de los temas académicos, sin importar las calificaciones de cada integrante. Estos autores también encontraron que el trabajo en parejas desencadena nuevas ideas. Para su estudio, utilizaron lenguaje C con los temas de flujo de control, funciones, apuntadores y archivos. Sus evaluaciones estuvieron basadas en entrevistas a estudiantes y en la percepción de los maestros. Por su parte, Saltz y Shamshurin (2017) destacan los resultados positivos de la programación por pares al aplicarla al área del análisis de datos con R. Estos autores realizaron una investigación con estudiantes organizados en parejas y observaron que los participantes mejoraron sus niveles de comunicación; además, escribieron mejor código en menos tiempo y obtuvieron buenas percepciones sobre los resultados que alcanzaron.

Swamidurai y Umphress (2015), por otra parte, argumentan que el desarrollo de software no tiene que estar siempre acompañado de otra persona; por eso, proponen un enfoque llamado "programación por pares invertida", que consiste en dos programadores que inician diseñando soluciones juntos, pero se separan durante la implementación y después se reúnen de nuevo para realizar pruebas. Estos autores validaron su propuesta a través de dos experimentos, los cuales arrojaron que la programación por pares tradicional puede llegar a ser costosa y que la programación por pares invertida logra mayores o iguales niveles de calidad a un costo menor.

Para Meyer (2018), la programación por pares es una práctica de interés que debería usarse ocasionalmente, en especial en las partes más complicadas del software que se esté desarrollando. Él opina que no hay razón para imponerla como una modalidad única para crear software y recomienda no confundirla con la tutoría o acompañamiento, que es una actividad diferente. En este sentido, Meyer explica que los métodos ágiles no son una panacea, pues todavía tienen desventajas y retos que enfrentar. Asimismo, destaca la importancia de las mediciones y evaluaciones reales de estos enfoques para no caer en exageraciones o crear falsas expectativas.

La programación Mob, también llamada mobbing, ha comenzado a ser vista con interés en el desarrollo de software orientados a los negocios. Zuill (2015) ha sido uno de los pioneros en dar a conocer detalles sobre este enfoque, al que él se refiere como "un paso más allá de la programación por pares". Zuill, basado en su propia experiencia, propone principios para que la programación Mob funcione con éxito, como tratar a los demás con amabilidad, consideración y respeto; aplicar los roles de conductor y navegador, en los que el conductor utiliza el teclado mientras el navegador le expresa su idea y lo guía para concretarla en el programa; rotar ambos roles cada quince minutos; utilizar el teléfono y el correo electrónico como si se tratara de una sola persona, lo que implica tener una sola cuenta de correo y atender las llamadas en altavoz en una única extensión telefónica. De igual modo, recomienda organizar reuniones retrospectivas para reflexionar sobre lo que se ha hecho bien y aquello que se puede mejorar.

Pyhäjärvi y Falco (2018), creadores del primer material en formato de libro dedicado completamente a la programación Mob, explican que la persona que está utilizando el teclado no debe pensar, solo debe dejar que las ideas, los pensamientos y las reflexiones del resto del equipo fluyan para capturarlas e implementarlas en la tarea que está ejecutando. Así, quienes no usan el teclado también adoptan una postura activa.

Actualmente, quienes han empleado la programación Mob en entornos de negocios expresan que, aunque pasaron por etapas de adaptación, han obtenido beneficios al trabajar en equipos de más de tres personas; sin embargo, todavía no queda claro cuáles son estos, en qué medida se obtienen y cómo se alcanzan, pues los aportes provienen, principalmente, de relatos vivenciales que son difíciles de cuantificar.

Schartman (2014) menciona que su equipo de desarrollo de software adoptó la modalidad Mob tras motivarse con una charla en la que se decía que se podía llegar a ser hasta diez veces más productivo con este enfoque de trabajo. No obstante, apenas lograron ser igual de productivos como lo eran con otros enfoques que utilizaban antes. Schartman reflexiona sobre la importancia de contar con mediciones concretas sobre la programación Mob para que las expectativas estén apegadas a la realidad.

Por otra parte, Lilienthal (2017) destaca la falta de experimentos científicos orientados a conocer la utilidad de la programación Mob. Balijepally et al. (2017) coinciden en que, en la actualidad, apenas se cuenta con evidencia inicial de quienes han empezado a usar programación Mob, y que se requiere validación empírica tanto de ingenieros de software como de académicos. Por otro lado, identifican, a través del trabajo de Zuill (2015), los siguientes beneficios en la programación Mob: reduce los trámites administrativos, elimina obstrucciones en la comunicación de los participantes, disminuye la cantidad de decisiones que tomar para situaciones futuras; además, existe menor desperdicio, menos parches rápidos en el código, menos interrupciones externas, menos políticas, menos juntas extensas, más aprendizaje continuo, mayor satisfacción en los integrantes del equipo y mejor calidad en el software. Como posibles riesgos que pueden afectar la manera en la que el equipo trabaja, se señalan: la cultura organizacional, la falta de familiaridad con el desarrollo ágil, las personalidades dominantes, así como el cansancio físico y mental de los integrantes.

Buchan y Pearl (2018) describen su experiencia en un equipo de desarrollo de software que trabajó con la programación Mob durante un mes para crear un producto dirigido al sector de servicios financieros. Ellos encontraron los siguientes beneficios en esta modalidad: las tareas se concluyeron más rápido, el equipo tuvo un mejor sentido de pertenencia hacia el código, el estilo de diseño y codificación fue más consistente, el uso de las herramientas fue más productivo, las personas conocieron más ampliamente el sistema en el que trabajaban, la confianza en el código se incrementó, los nuevos integrantes se incorporaron más rápido, y la estimación de tiempo requerido para las tareas fue más acertada.

Buchan y Pearl (2018) reportaron los siguientes riesgos y retos de la programación Mob: las personas pueden mostrarse renuentes a aceptar este enfoque de trabajo, también pueden estar motivadas al inicio y luego perder el interés, el código se genera lentamente cuando se comienza a programar en Mob, las relaciones interpersonales se incrementan y pueden alterar las capacidades del equipo para terminar el trabajo, algunas personas se aislan y se les dificulta comunicarse con sus compañeros, puede ser problemático conseguir las instalaciones físicas y el equipo necesario.

Wilson (2015) reporta la experiencia de su equipo al trabajar con programación Mob y explica que el enfoque puede ser adaptado a las necesidades de los proyectos. Ellos, por ejemplo, evolucionaron de una forma de trabajo puramente Mob a una híbrida que involucra programación por pares; utilizaron el enfoque Mob para modificar código de importancia crítica, encontraron que no todas las tareas requerían la atención de todo el equipo y se dieron cuenta de que, para ellos, este enfoque era más útil en escenarios donde se desconoce la solución que en los que esta es conocida, pero demanda mucho tiempo para implementarla.

Kerney (2015) describe cómo, a pesar de su personalidad fuerte, pudo convivir y trabajar con sus compañeros en la programación Mob y, al hacerlo de manera cotidiana, algunos rasgos de su carácter se transformaron de modo positivo; por ejemplo, mejoró su capacidad de escuchar y aumentó su consideración hacia los demás.

Arsenovski (2016) narra su experiencia con el desarrollo de software colectivo en un proyecto heredado con muchos defectos. A su enfoque de trabajo particular lo denomina swarm (enjambre), término que alude a varios programadores que colaboran para un proyecto común. Arse-novski menciona que utilizaron varios patrones como la "ramificación hacia afuera" (branch out), en la que un participante se separa con el objetivo de solucionar algún problema que afecta al equipo completo y luego se reincorpora. Por su parte, Lilienthal (2017) hace la diferenciación entre programación Mob y arquitectura Mob. Esta última se refiere a la creación y mejora de la arquitectura de los sistemas de software; esto lo realiza el equipo completo a través de herramientas automatizadas y de un navegador externo que inspecciona código fuente, modela vistas de arquitectura, solicita refactorizaciones y establece prioridades, siempre acompañado del equipo de desarrollo en el rol de observadores.

Bohekhout (2016) utilizó el enfoque Mob con buenos resultados para la programación y el diseño de flujos de procesos. Reconoce las bondades de esta forma de trabajar, explica que tardó en encontrar las configuraciones óptimas de tiempo, espacio, recursos y estrategias; al lograrlo combinó con éxito las modalidades individual y Mob. En la tabla 1 incluimos los hallazgos más importantes identificados en la literatura que consultamos sobre la programación por pares y Mob.

Tabla 1

Programación por pares	Programación Mob
•La programación por pares en cursos introductorios ayuda a que los alumnos obtengan calificaciones más altas en cursos avanzados (Smith et al., 2018) •La preparación individual aunada a la programación en parejas es benéfica para evitar el bajo desempeño académico de los alumnos (Lee et al., 2016)	•Hacen falta experimentos científicos orientados a conocer más sobre la programación Mob (Lilienthal, 2017) •Se requiere la validación empírica de la programación Mob (Balijepally et al., 2017)
•La programación por pares es una herramienta útil que mejora la comunicación entre los estudiantes, la comprensión de los temas y, además, desencadena nuevas ideas (Du et al., 2015) •La programación en parejas mejora los niveles de comunicación y reduce el tiempo en el que se escribe el código (Saltz & Shamshurin, 2017) •El desarrollo de software no tiene que llevarse a cabo todo el tiempo entre dos personas. Se pueden intercalar actividades en solitario y en pares (Swamidurai & Umphress, 2015) •La programación por pares puede usarse ocasionalmente, en especial en las partes más complicadas del software (Meyer, 2018)	•La programación Mob reduce los trámites administrativos y las juntas extensas; promueve el aprendizaje continuo, la satisfacción en los integrantes del equipo y la calidad del software (Zuill, 2015) •Con la programación Mob, las personas conocen más ampliamente el sistema en el que trabajan. Sin embargo, al inicio avanzan lentamente y pueden mostrar renuencia, perder el interés y aislarse (Buchan & Pearl, 2018) •Con la programación Mob, se puede mejorar la capacidad de escuchar y la consideración hacia los demás (Kerney,2015) •Puede pasar tiempo antes de encontrar las configuraciones óptimas de tiempo, espacio, recursos y estrategias para trabajar con programación Mob (Bohekhout, 2016)

Fuente: elaboración propia.

Nuestra investigación tuvo como objetivo comparar las percepciones de los estudiantes acerca de los enfoques de programación individual, por pares y Mob, con el propósito de contar con elementos validados empíricamente que permitan valorar la factibilidad de la implementación de alguno de estos tres enfoques. De esta manera, será posible establecer en el futuro acciones y estrategias que faciliten su adopción en cursos universitarios. Esto es importante porque en la actualidad las mediciones para determinar comparaciones son escasas en este contexto, en especial en el caso de la programación Mob.

Las preguntas orientadoras del estudio fueron: ¿cuál de estos tres enfoques (individual, por pares, Mob) es el más apropiado en el contexto de la docencia universitaria?, ¿cuál es la percepción de los alumnos respecto a estos?, y ¿cuáles son las diferencias que existen entre estas modalidades?

Para esta investigación, utilizamos un diseño explicativo secuencial (Hernández, 2014), que consiste en aplicar un enfoque cuantitativo, analizar los datos y obtener conclusiones para, posteriormente, emplear un enfoque cualitativo orientado a profundizar en estos resultados y lograr la interpretación del análisis completo (ver figura 1).

Figura 1 Fuente: Hernández (2014).

Aplicamos también un cuestionario y un análisis estadístico de datos para el enfoque cuantitativo, además de entrevistas en profundidad para el enfoque cualitativo.

Participaron 24 estudiantes que cursaban la materia de Programación intermedia en el tercer semestre de la Licenciatura de Tecnologias de la Información. Su edad oscilaba entre 19 y 25 años, con una media de 20.70 y desviación estándar de 2.01. De estos, 20 correspondían al género masculino y cuatro, al femenino. Durante el desarrollo de este trabajo, los alumnos asistieron a sesiones regulares de clase y no sabían que esta investigación se estaba efectuando; por ello, no les ofrecimos algún incentivo o remuneración por sus respuestas. Todos los participantes habían cursado y aprobado previamente los cursos universitarios Fundamentos de la informática y metodología de la programación y Programación básica. El primero se concentró en la lógica necesaria para realizar algoritmos computacionales y el segundo, en la solución de problemas con estructuras básicas de pro gramación en el lenguaje Visual Basic.Net.

Este trabajo se realizó en el laboratorio de cómputo al que los estudiantes asisten con regularidad a sus clases de programación. En este lugar tienen acceso a 30 computadoras con procesador Intel i5, monitores de 21 pulgadas y disco duro de 1 tb. Estos equipos tienen instalado el sistema operativo Windows 8 y el entorno integrado de desarrollo Visual Studio con el lenguaje Visual Basic.NET.

Todos los participantes tenían experiencia de trabajo individual, pues esa era la manera habitual de realizar sus prácticas hasta ese momento; sin embargo, desconocían los enfoques de programación por pares y Mob. Para fines de esta investigación, primero, en una sesión de clase, les solicitamos a los participantes programar de manera individual. En otra sesión diferente, les pedimos trabajar en parejas y, en una tercera sesión, con programación Mob. Finalmente, los invitamos a responder el cuestionario basándose solo en la experiencia de estos tres momentos de trabajo.

Cada sesión duró dos horas. El tiempo se distribuyó de esta forma: durante los primeros quince minutos esperamos a que todos los alumnos llegaran al laboratorio; después, pasamos lista y explicamos las reglas del trabajo de cada metodología empleada; en seguida, les presentamos el programa que debían realizar y asignamos, de manera aleatoria, los alumnos a las computadoras del laboratorio. En el caso de las modalidades por parejas y Mob, los equipos fueron creados también de modo aleatorio. Todas estas actividades se ejecutaron en veinte minutos. Los alumnos tuvieron 85 minutos para desarrollar el programa planteado. Durante la investigación, ningún alumno podía contactar a personas externas a su equipo. Tampoco les permitimos copiar el trabajo de alguien más; sin embargo, sí podían consultar información a través de internet.

En la modalidad individual, cada alumno fue asignado a una computadora. El programa que se solicito utilizo una arquitectura de software orientada a objetos de tres capas e implemento una lista de registros almacenados en una base de datos con una tabla.

Cada pareja de alumnos utilizó una sola computadora, donde cada participante tuvo que usar el teclado durante cinco minutos y luego cederlo a su compañero. Los investigadores cronometraron el tiempo y avisaron cuando era momento de cambiar el teclado. El programa solicitado utilizó una arquitectura de software orientada a objetos de tres capas e implementó diversas listas selectivas de registros almacenados en una base de datos con varias tablas.

Los estudiantes fueron asignados aleatoriamente a cuatro equipos de seis personas que se ubicaron en espacios de trabajo distintos, pero dentro de la misma área del laboratorio de prácticas al que ellos asisten a clase. A cada equipo se le asignó una sola computadora con las características descritas en el apartado "escenario" de este artículo. Además, dispusieron de seis sillas, un proyector, una superficie para proyectar, y un espacio de trabajo. Cada equipo se autoorganizó para trabajar. Ellos tuvieron esta libertad, siempre y cuando el equipo actuara de manera unida, respetuosa y afín a los principios de la programación Mob. El programa solicitado fue una interfaz gráfica para realizar diversas consultas de registros almacenados en una base de datos y utilizó una arquitectura de software orientada a objetos de tres capas.

Diseñamos un cuestionario con las preguntas que se muestran en la tabla 2 y lo entregamos a los estudiantes, les pedimos que evaluaran cada aspecto para cada modalidad de trabajo utilizando una escala del uno al diez, donde uno es la puntuación más baja, que representa "malo" o "poco", y diez es la más alta, que significa "excelente" o "mucho". Decidimos recurrir a esta escala por la sencillez que los alumnos encuentran al realizar evaluaciones con esta, pues la relacionan con las calificaciones escolares que ellos reciben en la universidad. Además, en una investigación anterior conducida por nuestro equipo, algunos alumnos mostraron dificultad para evaluar y expresar sus percepciones usando una escala del uno al cinco.

Tabla 2

Pregunta	Aspecto a evaluar
1	Calificación global de la metodología
2	Facilidad de entender la metodología
3	Facilidad de implementar la metodología
4	Facilidad de adaptar la metodología
5	Facilidad para trabajar con la metodología
6	Experiencia al trabajar con la metodología
7	Detección de errores en el programa
8	Rapidez para finalizar el programa
9	Calidad del proceso de desarrollo
10	Facilidad para comunicarse
11	Motivación para trabajar en el proyecto
12	Organización para trabajar
13	Nivel de confianza en el éxito del proyecto
14	Nivel de satisfacción con el trabajo realizado

Fuente: elaboración propia.

Todas las respuestas fueron capturadas en el paquete SPSS, en el cual se realizó un proceso de revisión y limpieza de datos. No encontramos valores perdidos o atípicos. Posteriormente, las respuestas se transformaron como se indica en la tabla 3. Estos valores en la nueva escala del uno al cinco fueron utilizados para todos los procedimientos y análisis efectuados en esta investigación.

Tabla 3

Valores antiguos (respuesta s proporcionadas por los estudiantes)	Valores nuevos (nuevos valores transformados)
1,2	1
3,4	2
5,6	3
7,8	4
9,10	5

Fuente: elaboración propia.

Después se realizó un análisis factorial considerando de la pregunta 2 a la 14. Encontramos tres dimensiones que identificamos con nombres representativos. Luego, calculamos el alfa de Cronbach para cada una de estas. En este proceso obtuvimos también la participación de cada pregunta en su respectiva dimensión. En seguida, calculamos un valor ponderado para cada dimensión; para ello, multiplicamos cada respuesta categorizada de los estudiantes por el porcentaje correspondiente a la participación de esta pregunta en esa dimensión.

Finalmente, realizamos pruebas de Friedman para distinguir diferencias estadísticas significativas entre los valores de cada una de las dimensiones para los tres enfoques metodológicos estudiados. También con la prueba de Friedman buscamos diferencias entre la calificación global que los estudiantes asignaron a cada uno de los tres enfoques metodológicos. La figura 2 presenta un esquema global de los pasos que comprendió el análisis de los datos cuantitativos.

Figura 2 Fuente: elaboración propia.

Para el componente cualitativo de esta investigación tomamos como referencia los resultados cuantitativos obtenidos: la programación por pares obtuvo las más altas puntuaciones, mientras que la programación Mob y la modalidad individual recibieron las más bajas. Por esta razón, realizamos entrevistas con preguntas abiertas orientadas a conocer más sobre las razones de estos hallazgos. Formulamos las siguientes preguntas: ¿cuáles son las ventajas que percibes de la programación por pares sobre la programación Mob y la programación individual?, ¿cuáles son los principales problemas que encontraste al trabajar con la programación Mob?, ¿cuáles son los principales problemas que encontraste al trabajar con la programación individual?, ¿qué opinas sobre la posibilidad de implementar la programación por pares o la programación Mob como práctica cotidiana en los cursos universitarios?

De los 24 estudiantes que intervinieron en la fase cuantitativa, cinco estuvieron disponibles y dispuestos a participar en las entrevistas de la fase cualitativa. Aunque solo dos brindaron entrevistas extensas y ricas en contenido, mientras que los otros tres aportaron ideas en frases cortas que estaban contenidas en las respuestas de los dos estudiantes que se presentan en este artículo.

En ese sentido, Hernández (2014) menciona que en enfoques cualitativos no es necesario que la muestra sea estadísticamente representativa de la población de estudio y que su tamaño se determina por tres factores: la capacidad operativa y de recolección de datos, la accesibilidad de las unidades de estudio y la saturación de categorías, que implica el número de casos que permitan responder las preguntas de investigación. Así, en estudios cualitativos también es posible la reformulación de la muestra. Esto quiere decir que en el proceso se pueden agregar casos no previstos al inicio, o bien, excluir otros que sí lo estaban.

Para encontrar las tres dimensiones que mostramos en la tabla 4, llevamos a cabo un análisis factorial exploratorio con el método de extracción de máxima verosimilitud basado en autovalores mayores de 1. El método de rotación fue Promax con Kappa = 4. Obtuvimos una medida KMO de 0.704; la prueba de esfericidad de Barlett arrojó los valores de Chi² = 364.60, gl = 78, y sig. = 0. La varianza total explicada con tres factores fue del 80.32%. El análisis factorial confirmatorio para encontrar exactamente tres factores dio los mismos resultados. Los cálculos del alfa de Cronbach y los porcentajes de aportación de cada variable a su dimensión se incluyen en las tablas 5, 6 y 7.

Tabla 4

Dimensión	Pregunta	Aspecto a evaluar
Aspectos de gestión del proceso y del equipo	2	Facilidad de entender la metodología
	4	Facilidad de adaptar la metodología
	9	Calidad del proceso de desarrollo
	10	Facilidad para comunicarse
	12	Organización para trabajar
	13	Nivel de confianza en el éxito del proyecto
Aspectos de implementación	3	Facilidad de implementar la metodología
	5	Facilidad para trabajar con la metodología
	6	Experiencia al trabajar con la metodología
	11	Motivación para trabajar en el proyecto
	14	Nivel de satisfacción con el trabajo realizado
Aspectos de depuración	7	Detección de errores en el programa
	8	Rapidez para finalizar el programa

Fuente: elaboración propia.

Tabla 5

Id	Aspecto a evaluar	Correlación tota l de elementos corregida	Participación de cada pregunta en esa dimensión
2	Facilidad de entender la metodología	0.846	0.170
4	Facilidad de adaptar la metodología	0.866	0.174
9	Calidad del proceso de desarrollo	0.795	0.160
10	Facilidad para comunicarse	0.872	0.175
12	Organización para trabajar	0.850	0.171
13	Nivel de confianza en el éxito del proyecto	0.732	0.147

Fuente: elaboración propia.

Tabla 6

Id	Aspecto a evaluar	Correlación tota l de elementos corregida	Participación de cada pregunta en esa dimensión
3	Facilidad de implementar la metodología	0.799	0.199
5	Facilidad para trabajar con la metodología	0.792	0.197
6	Experiencia al trabajar con la metodología	0.831	0.207
11	Motivación para trabajar en el proyecto	0.775	0.193
14	Nivel de satisfacción con el trabajo realizado	0.823	0.205

Fuente: elaboración propia.

Tabla 7

Id	Aspecto a evaluar	Correlación tota l de elementos corregida	Participación de cada pregunta en esa dimensión
7	Detección de errores en el programa	0.889	0.500
8	Rapidez para finalizar el programa	0.889	0.500

Fuente: elaboración propia.

La prueba de Friedman aplicada para establecer diferencias en la primera dimensión (aspectos de gestión del proceso y del equipo) resultó significativa (PValue = 0.005, Jí cuadrado = 10.564, n = 24, gl = 2); las puntuaciones más altas fueron para la programación por pares (rango promedio = 2.46) y las más bajas, para la programación Mob (rango promedio = 1.63). Aunque no encontramos diferencias estadísticas significativas en la prueba de Friedman, en la segunda dimensión (aspectos de implementación) (PValue = .108, Jí cuadrado = 4.447, n = 24, gl = 2), observamos tendencias aritméticas de la programación por pares para obtener las puntuaciones más altas (rango promedio = 2.31) y de la programación Mob para las puntuaciones más bajas (rango promedio = 1.83).

En la tercera dimensión (aspectos de depuración) sí reconocimos diferencias significativas con la prueba de Friedman (PValue = .031, Jí cuadrado = 6.969, n=24, gl=2); las puntuaciones más altas fueron para la programación por pares (rango promedio = 2.23) y las más bajas, para la programación individual (rango promedio = 1.65). En la calificación global que los estudiantes otorgaron a las metodologías no distinguimos diferencias significativas con un nivel de confianza del 95% como referencia, pero puede con siderarse significativa con un 90% de confianza como referencia, al tratarse de una investigación inicial. Los resultados de esta comparación con la prueba de Friedman fueron: PValue = 0.062, Jí cuadrado = 5.548, gl = 2. Las puntuaciones más altas correspondieron a la programación por pares (rango promedio = 2.29) y las más bajas, a la programación Mob (rango promedio = 1.75).

Las entrevistas para el apartado cualitativo revelaron que a los alumnos les gusta programar por pares porque lo perciben como un punto medio entre no programar con nadie y hacerlo con un grupo numeroso. Programar de manera individual puede provocar equivocaciones, tensión, bloqueo intelectual y aprehensión por la responsabilidad del trabajo; por otra parte, programar con demasiadas personas simultáneamente puede generar desorden, estrés, distracción y desbalance de trabajo entre los participantes. La tabla 8 contiene un resumen de las respuestas proporcionadas por los participantes.

Tabla 8

Pregunta	Resumen de respuesta s del participante 1 (hombre, 20 años, alumno regular de tercer semestre)	Resumen de respuesta s del participante 2 (hombre, 21 años, alumno regular de tercer semestre)
•¿Cuáles son las ventajas que percibes de la programación por pares sobre la programación Mob y la programación individual?	•Tener un compañero con quien resolver los problemas •Trabajo y comunicación están bajo mayor control •Se organiza mejor el trabajo • Se cuenta con el apoyo de otra persona en todo el proceso	•Responsabilidad compartida •Programar en parejas es un punto medio entre estar completamente solo y estar rodeado de muchas personas Así se superan las desventajas de trabajar solo y en Mob • Mayor capacidad de lograr acuerdos de trabajo
•¿Cuáles son los principales problemas que encontraste al trabajar con la programación Mob?	•Genera más estrés trabajar con tantas personas al mismo tiempo •El ruido afecta la concentración •Falta un espacio más privado para trabajar en equipo •El trabajo más pesado lo hacen unas pocas personas • No todos explican su trabajo a los demás	•Desorganización para trabajar y tomar decisiones •No todos colaboran con el mismo interés •Diversos niveles de habilidades y conocimientos • Las actitudes inmaduras de algunos participantes
PREGUNTA	RESUMEN DE RESPUESTAS DEL PARTICIPANTE 1 (HOMBRE, 20 AÑOS, ALUMNO REGULAR DE TERCER SEMESTRE)	RESUMEN DE RESPUESTAS DEL PARTICIPANTE 2 (HOMBRE, 21 AÑOS, ALUMNO REGULAR DE TERCER SEMESTRE)
•¿Cuáles son los principales problemas que encontraste al trabajar de manera individual?	•En ocasiones produce tensión o bloqueo especialmente si se desconoce cómo resolver los problemas que se presentan. Se tiene que pedir ayuda a otro compañero o al profesor	•Se siente la responsabilidad total del proyecto • Se cometen más errores y es más tardado encontrarlos y corregirlos
• ¿Qué opinas sobre la posibilidad de implementar la programación por pares o la programación Mob como práctica cotidiana en los cursos universitarios?	•Estaría bien implementar la programación por pares •Sería bueno que los alumnos puedan elegir a su compañero de trabajo • La programación Mob quizás podría implementarse en materias más avanzadas, con alumnos de semestres superiores que se conocen más entre sí y se enfocan más en su trabajo	•No estaría bien implementar la modalidad Mob si no hay espacios de trabajo más privados ni suficientes proyectores para cada equipo. A lo mejor también habría que entrenar a los alumnos para trabajar en equipo • La programación por pares estaría bien, pero se tendría que cuidar que cada pareja sea compatible para trabajar en un mismo proyecto

Fuente: elaboración propia.