Programación en parejas cuando el conductor y el observador tienen diferentes niveles de habilidad y experiencia

Sé que la programación por pares es una técnica de desarrollo de software ágil en la que dos programadores trabajan juntos en una estación de trabajo. Uno, el conductor, escribe el código, mientras que el otro, el observador, revisa cada línea de código a medida que se escribe.

Pero me pregunto si la estrategia aún funciona en el caso. Por ejemplo

• si tienen un nivel de habilidad de programación muy diferente.
• si uno nunca experimenta en el dominio del problema mientras que otro sí.
• ¿Todavía está bien si tienen un bajo nivel de habilidad de programación?

¿Podría sugerir la estrategia de programación de pares en el caso anterior?

Suponiendo que la persona más experimentada de la pareja tiene el temperamento para guiar a la otra persona, emparejar a alguien con poca experiencia en el idioma o el dominio del problema con una persona experimentada facilitaría la transferencia de conocimiento. La persona menos experimentada tendría un mentor para instruirla sobre el idioma, el dominio, la aplicación y las mejores prácticas o convenciones del equipo.

Hay un resumen interesante en el wiki de C2 sobre la transferencia de conocimiento mediante la programación de pares . La persona de más edad, que fue contratada para servir como mentor del equipo, aprendió mucho de los programadores junior y su conocimiento incluso aumentó como resultado de ser emparejado con desarrolladores de software más jóvenes y menos experimentados. También hay algunas otras historias sobre programadores expertos que se emparejan con expertos en dominios.

Este es exactamente el caso de uso para el que se realizó la programación de pares: compartir experiencias entre barba vieja y saltamontes joven.

Este es un intercambio bidireccional: los insectos ágiles tienen mucho que enseñar a los cerebros reumáticos.

Cuando me ascendieron a mi equipo actual, era el novato en J2EE pero era el experto en el dominio. Mi senior (el nuevo líder del equipo) era experto en J2EE pero no en la plataforma.

Creo que aprendí más sobre Java2EE en estos 4 meses con programación de pares que leer un libro y el líder del equipo también aprendió sobre la plataforma.

La brecha de experiencia entre los dos es la clave para emparejar la programación en mi humilde opinión.

Describiré mi experiencia e intentaré sacar algo de "estrategia".

Una vez he programado en pareja con un no programador completo. Era experto en el tema del producto de software que desarrollamos. Por el contrario, no tenía experiencia en el dominio del problema. Y él también era mi supervisor en este momento (sé que esto puede sonar extraño :)

El principal beneficio de esta metodología fue que tuve que explicar la implementación de muchas cosas desde su dominio de conocimiento, asegurando así la exactitud de la implementación y su comprensión del proceso, lo que significaba que entendía por qué tomó este tiempo.

Otro beneficio es un enfoque fácil en la tarea, sin distracciones (ja, ja, imagina abrir Twitter ante las narices de tu jefe).

Sin embargo, a veces fue bastante intimidante, ya que incluso una pausa para el té se convirtió en una "distracción del trabajo" (no desde su punto de vista; era un inconveniente pedir un descanso, etc.).

Por lo tanto, esto no es realmente una programación de pares, ya que prácticamente no pudo revisar el código tal como fue escrito. Sin embargo, parecía ser una estrategia sensata (al menos por algún tiempo). En última instancia, funcionó en absoluto debido a la relativa simplicidad de la metodología de desarrollo (es decir, no estaban involucradas técnicas complejas de diseño de software como los patrones OOP) y el tema. Esto no funcionaría en caso de que tuviéramos que desarrollar un compilador, creo. Creo que todavía podría funcionar en caso de que un observador no programador participe en el proceso de desarrollo de piezas pequeñas claramente definidas. Digamos, está bien que vea la programación de una función "calcular el parámetro X de Y y Z mediante un algoritmo dado", pero puede que no esté tan bien que vea el proceso general de diseño del sistema (es decir, el desarrollo de la arquitectura del software, es decir, la jerarquía de clases

Creo que funcionaría aún mejor en caso de que tuviera algunas habilidades básicas de programación, ya que no tendría que explicar "qué es una matriz".

Espero eso ayude :)

En mi experiencia, si ambos programadores tienen un bajo nivel de habilidad, puede ser un problema. En ese caso, a menudo hay una tendencia a probar la programación de copiar y pegar. Creo que puede ser una buena idea no emparejar a dos programadores novatos hasta que alcancen un nivel específico determinado por el equipo.

De lo contrario, la programación en pareja puede ser una gran idea, suponiendo, por supuesto, que dos chicos estén listos para compartir lo que saben. No solo es una excelente manera de mantener a todos informados sobre el código fuente, sino que también actúa como un buen lugar para nuevas ideas y debates.

Mientras los miembros del equipo se respeten entre sí, la programación en pareja puede ser beneficiosa independientemente de los niveles de experiencia de los programadores. Incluso si un programador junior solo detecta algunos errores de sintaxis (¡que todos cometemos!) Antes que el programador más experimentado, todavía se ahorra tiempo en la compilación de código.

También creo que puede abrir la actitud de un programador hacia las capacidades de otros miembros de su equipo, especialmente si tienen una mente abierta y esperan que todos puedan enseñarle algo.