He trabajado en algunas tiendas donde la gerencia me ha transmitido la idea de la programación de pares a mí u otro gerente / desarrollador, y no puedo respaldarlo en absoluto. Desde el punto de vista del desarrollador, no puedo encontrar una razón por la cual cambiar a este estilo de codificación sería beneficioso, ni como gerente de un pequeño equipo he visto algún beneficio.

Entiendo que ayuda con los errores de sintaxis básicos y puede ser útil si necesita resolver algo, pero los gerentes que están fuera del ciclo de programación parecen seguir viéndolo como una forma de evitar que sus diseñadores vayan a Facebook o Reddit. Una herramienta de diseño.

Como alguien cercano al piso de desarrollo que aparentemente no puede entender por un libro que me arrojó o una página wiki sobre el tema ... desde una posición de gestión de alto nivel, ¿cuáles son los beneficios de la Programación de pares cuando se trata de Scrum o Agile? ambientes?

En parte, depende de cómo esté haciendo la programación de pares. En algunos casos, el conductor del par está escribiendo código, mientras que el segundo miembro del par está observando y discutiendo los detalles de diseño e implementación del sistema. Otra instancia de programación de pares involucra a ambas personas escribiendo código simultáneamente: una persona está escribiendo la funcionalidad implementada y la otra está desarrollando activamente y escribiendo código de prueba a nivel de unidad e integración, nuevamente discutiendo los detalles de diseño e implementación del sistema.

Independientemente del tipo de programación de pares, sirve efectivamente como una revisión continua de código . Usted tiene los ojos de dos personas en el código, buscando errores antes de que escapen a un entorno de prueba de aceptación / sistema posterior o al campo. También tiene dos personas que entienden muy bien una parte particular del sistema, para que sirva como redundancia para minimizar su factor de bus . Tanto la detección temprana de defectos como la difusión del conocimiento del sistema en todo el equipo reducen el costo de construir un sistema.

La difusión del conocimiento no se limita solo al conocimiento técnico del equipo tampoco. Dependiendo de quién sea el par, puede permitir que la información fluya entre un miembro más antiguo de la empresa y un miembro nuevo sobre otras cosas que trascienden el proyecto: estilo de codificación, cultura de la empresa, expectativas, etc. También puede permitir que alguien más familiarizado con una tecnología o herramienta comparta sus conocimientos sobre esa tecnología o herramienta en un entorno aplicado en el mundo real.

Como mencionó, también ayuda a mantener a los desarrolladores enfocados y en flujo . Además del flujo, es menos probable que muchas personas interrumpan a varias personas que trabajan en algo que una sola persona que trabaja en algo. Si pasa por el escritorio de alguien y está trabajando solo, pero necesita hablar con él, puede llamar y hablar con él. Esto es menos probable si ve a dos o más personas trabajando en colaboración o discutiendo, no las interrumpirá. Las interrupciones cuestan tiempo, y pasar más tiempo significa mayores costos. Es en el mejor interés del negocio maximizar la productividad de los empleados.

Sin embargo, hay algunos desafíos que deben superarse para que la programación de pares sea viable. Considere cosas como choques de personalidad o elegir las parejas para distribuir adecuadamente el conocimiento. También se considera exactamente cuándo rotar los pares. La programación de pares hecha al azar probablemente no será efectiva como una planificada. Dependiendo de la composición de su equipo, podría no ser efectivo emparejar a las personas en absoluto.

1. Menos errores en el código final (eficiencia)
   No reemplaza completamente las revisiones de código, pero es muy eficaz para hacer las cosas bien desde el principio. Hay investigaciones por ahí que apuntan en esa dirección.

2. Finalización más rápida (efectividad)
   Hay varias investigaciones que lo señalan. Cuando se trata de características complejas, 2 cabezas son simplemente más efectivas. La experiencia en emparejamiento es imprescindible para esto.

(nota: este es su argumento de venta para el gerente: financieramente es una decisión sensata porque obtiene más eficiencia a través de un menor número de errores y más eficaz al completar más rápido)

1. Enseñanza de Juniors
   Puede agregar un junior directamente a un programador más experimentado. Si tiene un grupo de principiantes absolutos, es fácil quedarse y dejar que, en parejas, descubran lo básico. Quédate y da consejos. El concepto es aparentemente muy antiguo y proviene de la artesanía.

Respuesta rápida: la mayoría de los beneficios y costos se publican en Wikipedia , sin embargo, echemos un vistazo desde un ángulo diferente.

Me gustaría mencionar casos específicos de beneficios de programación de pares que se aplican al entorno de desarrollo ágil / scrum, tomados de la publicación del blog :

El éxito o el fracaso del software depende de su calidad, y la programación de pares mejora directamente la calidad de muchas maneras. Cuando dos desarrolladores trabajan juntos, la calidad del patrón de diseño mejora a medida que el par desarrolla código corto, simple y fácil de mantener con menos errores. Los errores son una importante preocupación de calidad en el desarrollo de software; Con dos pares de ojos escribiendo el código, se detectan más errores, lo que disminuye el costo de desarrollo. Los errores encontrados al final del proceso de desarrollo a menudo son costosos de solucionar. Encontrar defectos de software de manera temprana previene y ayuda a disuadir problemas difíciles en el futuro. La complejidad a menudo surge en la programación, y dos mentes que trabajan para resolver un problema juntas pueden ver más opciones y sacar conclusiones más rápidamente que una.

En resumen:

• Promueve la comunicación del equipo.
• Promueve la transferencia eficiente del conocimiento de la aplicación.
• Promueve la responsabilidad en el enfoque de diseño.
• Resultados en código mejor y fácil de mantener
• Ayuda a eliminar el código defectuoso en su etapa inicial
• Aumenta la productividad del equipo ya que los miembros del equipo recibirán toda la atención durante la codificación.
• Mejora las habilidades de comunicación y colaboración de los miembros del equipo.
• Construye camaradería en el lugar de trabajo
• Hace que el trabajo sea más divertido

Hay algunos beneficios para la programación de pares:

• Los dos programadores pueden colaborar juntos en el diseño, produciendo potencialmente una mejor arquitectura / código: dos pares de ojos pueden detectar errores
• El conocimiento de la institución se conserva mejor: si un programador se va o no está disponible, el otro debería poder continuar el trabajo sin mucha pérdida de productividad
• Es una forma de capacitar rápidamente a los nuevos desarrolladores: emparejarlos con un miembro experimentado del equipo de desarrollo y podrán experimentar la base del código desde la perspectiva de un veterano del equipo.
• Mejor disciplina: es probable que los programadores emparejados sean productivos durante un período de tiempo más largo, ya que uno u otro puede hacerse cargo de estallidos de actividad. Las tareas potencialmente tediosas, como las pruebas unitarias, pueden omitirse con menos frecuencia que para los desarrolladores individuales.

Wikipedia también tiene un buen resumen de los costos y beneficios en la entrada de wiki .