¿Cuándo funciona la programación de pares? ¿Cuándo evitarlo?

La investigación compilada por Laurie Williams indica que la programación de pares funciona mejor en equipos industriales cuando

• Los pares trabajan en la especificación, diseño y tareas complejas de programación : los experimentos indican que no se muestra una mejora de la calidad cuando se trabaja en tareas simples en un par, pero puede haber mejoras en la velocidad. También tenga en cuenta que la "programación" de pares a menudo incluye otras actividades además de escribir código.
• Cada individuo en un emparejamiento tiene aproximadamente el mismo nivel de experiencia , mientras que la programación de pares es excelente para la capacitación, los pares se involucran más cuando están en el mismo nivel.
• Los roles giran con regularidad : la rotación regular ayuda a mantener al copiloto activo mientras las personas tienden a contribuir más cuando conducen o sienten que están a punto de conducir.
• Los pares rotan regularmente : los equipos han expresado su comodidad al conocer las diferentes partes del sistema que están construyendo. La rotación de pares ayuda con la transferencia de conocimientos, lo que reduce ciertos riesgos en el proyecto. En un entorno académico, las parejas a menudo se asignan, sin embargo, la industria generalmente se autoasigna a menudo durante las paradas. En ambos casos, el par es más efectivo cuando ambas personas son participantes dispuestos que ven valor en la actividad de emparejamiento.

En mi experiencia personal, descubrí que mi equipo de XP gasta en promedio aproximadamente el 60% de nuestro tiempo de desarrollo en programación de pares. El resto del tiempo se dedica al desarrollo individual. No es infrecuente asociarse para crear un diseño inicial, trabajar solo en el diseño durante algunas horas y luego volver a unirse para terminar las partes difíciles o difíciles del código.

También encontré que la programación de pares es más efectiva en bloques de aproximadamente 1,5 a 2,5 horas. Cualquier cosa mucho menos tiende a requerir demasiados gastos de configuración, mientras que mucho más y las parejas tienden a ponerse de mal humor y cansados. Malhumorado y cansado significa que no se está comunicando bien y podría dejar que los defectos ingresen al sistema.

La programación de pares me ha funcionado en muy, muy pocas situaciones.

Donde la programación de par falla para mí

  

El cuento es que la programación de pares no funciona para mí como la principal forma de desarrollar software. Puedo emparejar el programa por un día, o tal vez una semana, especialmente si estamos enfocados en un problema en particular. ¿Pero después de eso? He terminado. Tostada. No quiero ver a nadie, hablar con nadie, y necesito al menos un par de días en una cueva hasta que sea apto para la compañía humana nuevamente.

     

Es una historia triste, pero lo gracioso es que ahora estoy mucho más feliz con la forma en que terminó. Estoy felizmente contratado en un contrato en el que trabajo desde casa o en una cafetería, he hecho nuevos amigos y explorado más de San Francisco de lo que nunca creí posible. Tengo una bicicleta y una computadora portátil, y siempre que cumpla con mis fechas límite y verifique el código regularmente, mi tiempo es mío.

     

Enumeraré los grandes problemas que tengo con la programación de pares por adelantado y te daré los detalles y las anécdotas más adelante.

     

1. Foco dividido.
  
2. Sin experimentación.
  
3. No hay notas altas.
  
4. No hay orgullo en la propiedad.
  
5. No hay escape ...
  

... Le pregunté a mis compañeros de trabajo si vieron lo que vi, si me faltaba algo, cualquier cosa, no vi cómo podría funcionar esto, cómo las personas podrían seguir haciendo esto. Dijeron que me estaba yendo bien, que solo me tomó tiempo acomodarme y ajustarme. Que fue difícil para todos al principio.

     

Finalmente, me retiré a mí mismo. Entre los dolores de cabeza cegadores, el insomnio y la necesidad insatisfecha de escribir código, dejé de responder a las entradas. Podría mirar fijamente una pantalla y no ver nada. Alguien podría hablarme inesperadamente y yo no los escucharía. Estaba cumpliendo con los requisitos de memoria de mi trabajo, pero no estaba allí. Me había agotado todo lo que había aparecido en el día. Comencé a revisar mi iPhone cuando mi otro compañero estaba escribiendo.

     

Finalmente, apenas tres meses después, y por primera vez en la historia, me despidieron por no ser un equipo apto para la programación de pares.

     

No solo

     

Escribí esto no solo para entenderlo, sino también para poder hablar de ello. Existe la presunción de que la programación en pares funciona para la mayoría de las personas y es mucho más fácil y más rápida de lo que lo sería la programación en solitario. Este puede o no ser el caso, pero como práctica a largo plazo, la programación de pares no funciona para mí. Hay muchas otras personas que la programación de par no funciona para ninguno de los dos. Nosotros también importamos ...

Mi equipo ha hecho programación en pares desde su inicio, mucho antes de que trabajara allí, como parte de una tienda de estilo de "programación extrema". La programación de pares es el estado predeterminado ; las personas solo se vuelven locas si hay un número impar, u ocasionalmente para investigaciones, especialmente aquellas que involucran jugar con equipos hostiles e intentar que funcionen.

"Junior / senior" no es el único camino a seguir. "Intermedio / junior" es útil; ayuda al individuo de nivel intermedio a sintetizar el conocimiento que ha obtenido al obligarlo a comunicárselo a otra persona. Los desafíos "Intermedio / Intermedio" dos personas trabajan juntas para compartir sus conocimientos, comunicarse y trabajar como parte de un equipo. E incluso si tiene dos jugadores realmente mayores, es probable que tengan diferentes áreas de experiencia y puedan llegar a diferentes enfoques. Los aspectos de intercambio de conocimientos no terminan una vez que alguien está vagamente "al día" en un proyecto. Más bien, la programación de pares es el epítome de una organización de aprendizaje . Nuevas técnicas y mejores prácticas se difunden rápidamente.

La programación en pares también ayuda a mantener la calidad del código (menos defectos) y la cordura del código (no solo hace lo que pretende, sino que hace lo que debería ... idealmente, sin pasar por un agujero de conejo de varias semanas haciendo lo incorrecto, o dos cosas correctas diferentes que tendrán un conflicto salvaje). Ayuda a los programadores a mantener su enfoque: aquí, en el corazón de Silicon Valley, hogar de la semana laboral de 80 horas, podemos trabajar solo 40 horas a la semana porque estamos haciendo una codificación intensa durante ocho horas al día, cambiando las cosas fuera el uno con el otro. (Además, si fuera más tiempo haciendo la programación en pares, probablemente se desvanecería. O al menos se agotaría). Esto es excelente para el equilibrio entre trabajo y vida, y también ayuda a su organización cuando es importante tener un cambio rápido (en particular, un cambio de baja latencia).

No es todo, completamente, 100% duraznos y crema; Encuentro que la programación de pares es ocasionalmente un obstáculo para mi aplicación de procesos cerebrales intuitivos que son útiles en ciertos problemas. Más recientemente, en una tarea de pérdida de memoria, pasé un tiempo con y sin pares; sin uno, me sentí más libre de perder el tiempo y probar experimentos sin saber realmente exactamente cómo explicar lo que estaba haciendo en un momento dado. También hay algunas ventajas en el trabajo de singleton, ser capaz de irse en una tangente y hacer ciertas refactorizaciones salvajes (valoradas en la metodología de XP) en un capricho.

Pero en general, los beneficios superan con creces los costos, y el emparejamiento ha funcionado espectacularmente bien para nosotros: desde la etapa inicial hasta la adquisición por parte de una empresa más grande, y nuestra posterior integración. (Hablando de eso, la programación en pares nos ha ayudado a mantener una continuidad de la cultura a través de la expansión y, a pesar de un poco de rotación).

(Desarrollamos un dispositivo de software en Perl, ~ $ 4,000- $ 40,000 precio de lista.)

Nunca he trabajado en una configuración de "Programación de pares" y, sin embargo, puedo afirmar que formé parte de las tres circunstancias que has enumerado. El escenario que mencionas parece más "programación regular" con fases de ayuda / entrenamiento. ¿No hicimos todo esto antes de que se creara la "programación en pareja"? Programación de pares, asumo que requeriría un enfoque más comprometido donde el proceso de compartir dentro de un equipo no se detiene en el momento en que aborda la tarea inmediata o el problema en cuestión. Pero entonces esto es lo que "pienso" no lo que "sé".

Personalmente para la programación en pareja Me gustaría trabajar en un equipo donde tenga la oportunidad de aprender y compartir mis conocimientos. Un equipo desequilibrado en el que todas las personas con las que trabajas está muy por delante de ti, o que está muy por debajo de la media, puede ser bastante poco interesante. Además, me da miedo trabajar con personas que tienen creencias y son difíciles de convencer.

Hemos estado experimentando con la programación de pares en nuestro equipo durante los últimos meses. Creo que es muy útil cuando estás trabajando en algo nuevo (nueva tecnología, nueva función, etc.), ya que puedes intercambiar ideas rápidamente con otra persona del equipo y validarlas / invalidarlas. Además, una revisión de pares de lado a lado ayuda a mantener los errores fuera.

Otro compañero de equipo intentó usar la programación de pares con una prueba para realizar ATDD y estaban muy contentos con los resultados (según sus cálculos, un aumento en el costo de desarrollo del 20% llevó a una disminución de alrededor del 50% en el tiempo de prueba)

Buenas noches

muchas veces hemos debatido sobre las prácticas de Programación Extrema y la programación por pares . En el tiempo, podemos entender que la programación es una actividad individual porque los programadores necesitan concentración y aislamiento. Los programadores en ese momento estaban en la zona , un estado mental en el que podían concentrarse de manera eficiente en el código y tomar decisiones agradables y creativas.

La programación de pares parece ser también un riesgo si se supone que un programador se interrumpe entre sí. Por otro lado, es más difícil interrumpir a dos programadores que trabajan juntos. En la programación Solo, por ejemplo, será más fácil interrumpirlo, por lo que es casi imposible que un programador solo permanezca en la "zona".

La calidad del código es otra cuando la fecha límite está a la vuelta de la esquina. Las personas siempre tendrán prisa, serán programadores par o programadores solos: no aplicarán ciertas prácticas recomendadas y solo se olvidarán de las pruebas de unidad.

Me quedaría con la programación de par. Porque cuando se trata de riesgos, cuando un programador se ha ido, siempre tendrás a otra persona para documentar el proceso y enseñar a todos los demás cómo funciona.

Trabajar en algo de complejidad no trivial tiende a ser un buen candidato para la programación en pares, de modo que varias personas entiendan el código en lugar de que solo un desarrollador conozca una parte del código base. Otro caso es cuando alguien quiere transferir algunas habilidades. Un ejemplo aquí puede ser que alguien que es realmente bueno en las pruebas unitarias se empareje con alguien que no esté tan familiarizado con el concepto y, por lo tanto, ayude a adquirir un hábito inicial en algo.

En cuanto a dónde evitar la programación de pares, trabaje con tareas de trabajo que sean sencillas donde sería mejor dividir el trabajo en dos grupos y dejar que cada desarrollador haga parte del trabajo por separado para realizar el trabajo. Algunas tareas pueden requerir un poco de escritura, pero no son tan grandes que valga la pena dedicar unas horas a intentar encontrar una mejor manera de hacerlo, ya que podría hacerse si cada desarrollador adopta un enfoque de fuerza bruta por unos pocos. horas.