Razones para la programación de parejas


13

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?


2
Creo que es útil en situaciones muy específicas. Pero como modelo de desarrollo general, es un poco inútil.
Ryan Kinal

44
Puede depender del software, que podría colorear su vista. Si tiene muchos pequeños widgets y trabaja en diferentes pequeñas piezas de software personalizadas todos los días, probablemente no sea útil. Se vuelve extremadamente valioso cuando se trata de un gran sistema empresarial en el que los desarrolladores deben tener en cuenta la cascada en todo el sistema creada por la funcionalidad que implementan. Escribir una clase que afecta los datos utilizados en más de 30 lugares distintos generalmente puede ser mejor razonado por 2 personas que tendrán diferentes procesos mentales para ello. Es como un método de Monte Carlo para la búsqueda previa al defecto.
Jimmy Hoffa

@JimmyHoffa ¿Entonces el proceso de pensamiento principal es que si encontramos los errores antes de que lleguen a las pruebas de aceptación, podemos reducir en gran medida el tiempo perdido en las revisiones / pruebas de código en el futuro?
Jeff Langemeier

3
@JeffLangemeier En realidad es más que eso; Si ve las fallas en el diseño de la sección A1 del subsistema A, incluso antes de que A1 esté escrito debido al discurso natural que ocurre entre dos desarrolladores en medio de la implementación del subsistema A, no solo está ahorrando el tiempo que se dedicaría a reparar la sección A1, y las secciones A5 y A7 que dependen de A1 (o encontrar errores en esas secciones dependientes debido a la cascada de la fijación de A1), está ahorrando el tiempo al no escribir esa sección incorrecta por completo. Reduce el tiempo de prueba sí, pero reduce aún más el tiempo de desarrollo de esta manera.
Jimmy Hoffa

@ MartinWickman Esto no es un duplicado. En su enlace realmente estaban buscando Contras, a pesar de que el título pedía Pros y Contras. Además, se dio una respuesta más completa de los profesionales en este caso; hasta el punto de que es beneficioso para la comunidad tener este incluso si está cerca del otro.
Jeff Langemeier

Respuestas:


25

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 por la gran respuesta. Todavía no me gusta mucho la idea, pero presentas bien sus beneficios.

Me gusta el corte de su foque señor, esta explicación en realidad hace que esto se sienta viable.
Jeff Langemeier

99
Prefiero un modelo híbrido donde los emparejamientos son más ad hoc según las necesidades actuales. Además, hay momentos en que trabajar solo es más eficiente y momentos en que trabajar con un compañero es mejor. Forzarme en parejas permanentes me parece arbitrario e inflexible.
jfrankcarr

Muy buena respuesta. También soy programador en un equipo ágil y hacemos muchos emparejamientos. Al principio también estábamos escépticos, pensamos que trabajar solo es la mejor manera de hacerlo. Luego, en algún momento de la evolución del equipo, impusimos la programación de pares. NO se confirmó ningún código de producción si no se programó el par. Esta fue una aplicación artificial del concepto de emparejamiento, pero ayudó mucho al equipo. Finalmente, después de que todos nos acostumbramos a la técnica y entre nosotros cambiamos nuestro estilo y estamos formando un equipo ad-hoc y principalmente cuando la implementación es más compleja o propensa a errores.
Patkos Csaba

@jfrankcarr, nadie sugirió pares permanentes; No estoy seguro de dónde se te ocurrió esa idea. (Observe que esta respuesta menciona específicamente "cuándo rotar pares"). Nuestro equipo descubrió que es una muy mala idea mantener a las mismas dos personas emparejándose entre sí durante más de un día o dos; comienzas a meterte en la rutina. Algunos equipos rotan cada hora y media (enlace PDF).
Joe White

3
  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.

3

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

When two developers work together design pattern quality improves-> esa frase no tiene ningún sentido. Al menos no más sentido que When two bakers work together wheat quality improveso When two race drivers work together asphalt quality improves.
phresnel

Esa es una cita del blog que puede consultar. Sin embargo, mi intención era enfatizar un mejor enfoque en el diseño técnico y la calidad del código, con algún tipo de responsabilidad, ya que cada desarrollador se esfuerza por estar orgulloso del código que se crea.
Yusubov

2

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 .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.