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

En lugar de un programa de emparejamiento servil todo el tiempo, usamos la programación de emparejamiento selectivamente en nuestro equipo. Creo que funciona mejor en las siguientes circunstancias:

• Incrementar a los nuevos miembros del equipo en un proyecto (en lugar de dejar que vayan por la documentación o el código por su cuenta).
• Tener personas junior y senior trabajando juntas (ayuda a mostrar algunas de las habilidades y trucos de los desarrolladores más experimentados, además permite que los perros viejos aprendan nuevos trucos a veces).
• Cuando alguien intenta rastrear un defecto, a menudo ayuda emparejarse con un par de ojos nuevos.

¿Cuándo usar el programa de pares y por qué?

¿Cuándo evitar la programación de pares? ¿Por qué?

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

• Los pares trabajan en tareas de especificación, diseño y programación compleja : 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 una pareja tiene aproximadamente el mismo nivel de experiencia : si bien la programación de parejas es excelente para el entrenamiento, las parejas se involucran más cuando están en el mismo nivel.
• Los roles rotan regularmente : rotar regularmente ayuda a mantener al copiloto actual comprometido ya que 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 conocimiento, lo que reduce ciertos riesgos en el proyecto. En un entorno académico, a menudo se asignan pares, sin embargo, la industria generalmente se autoasigna a menudo durante los stand-ups. En ambos casos, la pareja es más efectiva 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 aproximadamente el 60% de nuestra programación de pares de tiempo de desarrollo en promedio. El resto del tiempo se dedica al desarrollo individual. No es raro emparejarse para crear un diseño inicial, trabajar solo en el diseño durante unas horas, luego volver a unirse para terminar partes difíciles o difíciles del código.

También descubrí 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 demasiada sobrecarga para la configuración, mientras que mucho más y las parejas tienden a ponerse de mal humor y cansarse. Malhumorado y cansado significa que no se está comunicando bien y podría estar permitiendo que los defectos se introduzcan en el sistema.

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

Donde la programación de pares falla por mí

La historia corta es que la programación de pares no funciona para mí como la forma principal 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 cómo terminó. Estoy felizmente empleado en un contrato donde trabajo desde casa o desde una cafetería, y 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 plazos 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. Enfoque dividido.
2. Sin experimentación.
3. Sin notas altas.
4. No hay orgullo en la propiedad.
5. No hay escapatoria...

... Le pregunté a mis compañeros de trabajo si veían lo que yo veía, si me faltaba algo, cualquier cosa. No veía cómo podía funcionar, cómo la gente podía seguir haciendo esto. Dijeron que me estaba yendo bien, que solo tomó tiempo instalarme y adaptarme. Al principio fue difícil para todos.

Finalmente, me retiré en mí mismo. Entre los cefaleos dolores de cabeza, el insomnio y la necesidad insatisfecha de escribir código, dejé de responder a las entradas. Podía mirar una pantalla y no ver nada. Alguien podría hablarme inesperadamente y no los escucharía. Estaba cumpliendo los requisitos de memoria de mi trabajo, pero no estaba allí. Había usado todo lo que acababa de aparecer por 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 apto para el equipo cuando programaba parejas.

No solo

Escribí esto no solo para entenderlo, sino también para poder hablar sobre ello. Se presume que la programación en pareja funciona para la mayoría de las personas y es mucho más fácil y rápida que 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 pares tampoco funciona. Nosotros también importamos ...

Mi equipo ha realizado programación de 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 solteras si hay un número impar, o de vez en cuando para investigaciones, especialmente aquellas que implicarán jugar con equipos hostiles e intentar que funcionen.

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

La programación de 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 caer en un conejo de varias semanas) agujero haciendo lo incorrecto, o dos cosas correctas diferentes que entrarán en conflicto salvajemente). 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 pasaras más tiempo haciendo la programación de pares, probablemente te volcarías. O al menos te quemarías). Esto es excelente para el equilibrio entre el trabajo y la vida, y también ayuda a su organización cuando es importante tener una respuesta rápida (respuesta de baja latencia, en particular).

No es todo, completamente, 100% duraznos y crema; Encuentro que la programación de pares ocasionalmente es 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é algún tiempo con y sin pares; sin uno, me sentí más libre para perder el tiempo y probar experimentos sin realmente saber exactamente cómo explicar lo que estaba haciendo en cualquier momento. También hay algunas ventajas en trabajar singleton, poder ir por una tangente y hacer ciertas refactorizaciones salvajes (valoradas en la metodología XP) por 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 pareja nos ha ayudado a mantener una continuidad de la cultura a través de la expansión y a pesar de una pequeña 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 he sido parte de las tres circunstancias que ha enumerado. El escenario que mencionas parece más "programación regular" con fases de ayuda / entrenamiento. ¿No hicimos todo esto antes de que surgiera la "programación en pareja"? La programación en pareja, supongo 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 abordas 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 tengo la oportunidad de aprender y compartir mis conocimientos. Un equipo desequilibrado en el que todas las personas con las que trabaja están muy por delante de usted, o bien, muy por debajo de la media, puede resultar bastante poco interesante con bastante rapidez. Además, me daría miedo trabajar con personas que tienen sus creencias y son difíciles de convencer.

Hemos estado experimentando con la programación de pares en nuestro equipo durante los últimos meses. Siento que es bastante ú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 por pares ayuda a evitar errores.

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

Buenas noches

Muchas veces hemos debatido sobre las prácticas de programación extrema y la programación de pares . En el pasado, podemos entender que la programación es una actividad en solitario porque los programadores necesitaban concentración y aislamiento. Los programadores en ese momento estaban en la zona , un estado mental donde podían enfocarse eficientemente en el código y tomar decisiones agradables y creativas.

La programación de pares también parece ser arriesgada 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 en solitario, por ejemplo, será más fácil ser interrumpido, por lo que es casi imposible para un programador en solitario permanecer en la "zona".

La calidad del código es otra cuando la fecha límite está a la vuelta de la esquina. La gente siempre tendrá prisa, ya sea un par de programadores o un programador en solitario: no aplicarán ciertas mejores prácticas y simplemente se olvidarán de las pruebas unitarias.

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

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

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