¿Cuál es su opinión sobre la programación de pares?

Una cita (larga) a la que siempre vuelvo es de una entrevista con David Graeber (bookforum habla con david graeber 🙂

Tenemos un modelo falso de lo que es pensar. Porque realmente no puedes pensar solo, ¿verdad? Tienes que crear a alguien más en tu mente para explicarle las cosas y tener una conversación imaginaria. Esta idea fue inspirada en parte por el filósofo de la cibernética, Andy Clark, quien propuso algo que él llama la hipótesis de la mente extendida. Básicamente, el argumento es el siguiente: digamos que estás haciendo una división larga en un pedazo de papel en lugar de hacerlo en tu cabeza. Clark pregunta por qué el trozo de papel no es solo una parte de tu mente mientras haces ese cálculo como la parte de tu cerebro que hace los cálculos. Él dice que no hay ninguna razón en absoluto. Hay un millón de ejemplos similares que a los filósofos les gusta decir: tienes mala memoria, así que escribes todo. ¿Es ese pedazo de papel parte de tu mente?

“Mente” no es “cerebro”: el cerebro es solo un órgano; tu mente es la interacción dinámica de varios elementos móviles que culmina en el pensamiento. Los filósofos como Clark están dispuestos a llevar ese argumento hasta aquí, pero la pregunta que parece que nunca se les ocurre es la siguiente: cuando tienes una conversación con alguien más, ¿es su mente parte de tu mente? Hoy en día, a muchos filósofos de la conciencia les gusta observar cuán delgadas como esta “conciencia”, esa parte consciente de nuestras operaciones mentales, es realmente. La persona promedio rara vez puede mantener un pensamiento durante más de tres o cuatro segundos, ocho como máximo, antes de que la mente divague. Es muy inusual estar completamente consciente por más de un pequeño lapso de tiempo. Es decir, a menos que tenga una conversación con otra persona, en cuyo caso a menudo puede hacerlo durante largos períodos de tiempo, especialmente si la conversación es con alguien que le resulta particularmente interesante. En otras palabras, la mayor parte del tiempo somos conscientes cuando hablamos con otra persona o interactuamos intensamente; durante los momentos en que no estamos claros de quién es la mente de quién. Entonces la conciencia es interactiva, es diádica o triádica. Es una falacia imaginar que pensar es algo que en gran medida haces solo. En cierto nivel, por supuesto, ya lo sabemos. Pero no creo que hayamos comenzado a explorar todas las implicaciones.

Ya hay una conversación imaginaria que ocurre cuando uno codifica solo. Con la programación en pareja, esa conversación suele ser más sólida, ya que incorpora otra mente, se aventura por caminos desconocidos para el individuo solitario y obliga a una transición hacia un pensamiento centrado que, de lo contrario, sería susceptible a la intervención de los pensamientos de un individuo cada 3-4 (o 8) segundos (a menos que entren en el “flujo” meditativo raro y creativo).

Pero no todas las “conversaciones” son lo suficientemente interesantes como para justificar la inclusión de potencia mental extra. Casi nadie se queda despierto hasta tarde en la noche conversando sobre el clima de ese día. Por lo tanto, la programación de pares es innecesaria para muchos problemas de codificación que son bien entendidos o de naturaleza “mecánica”.

Como programador de pares durante aproximadamente 5 años y gerente de programadores de emparejamiento para 2.5, tengo una relación de emparejamiento de amor / odio.

He tenido una gran ganancia personal por el emparejamiento. Cuando me uní a la compañía, aprendí muy rápidamente de las personas con las que trabajé, mucho más rápido de lo que podría haber esperado trabajar solo. Aprendí no solo sobre el código, sino también sobre los productos, la historia pasada, la organización y otras áreas técnicas que no están estrictamente relacionadas con lo que estábamos haciendo. Aprendí a configurar túneles SSH inversos, atajos de teclado útiles de Eclipse, aprendí algo sobre analizadores y gramáticas de los proyectos paralelos de alguien. He visto a otros ganar lo mismo. En mi trabajo anterior, trabajando como desarrollador en solitario, podían pasar días enteros simplemente navegando por la red, sin alguien más a mano para mantenerte honesto, y cuando codifiqué, no compartí esa experiencia con nadie, ni lo hice. recibir la experiencia de otra persona, al menos no a ningún nivel significativo.

Cuando dos personas se emparejan, entiendo por qué se emparejan y cómo hacerlo, he visto que un código de mayor calidad se produce más rápido y una carga de arranque de beneficios colaterales junto con él. Me encanta tener discusiones y debates: descubrir que mi opinión sobre el código no es la opinión de todos los demás, o que mi idea de un buen nombre para una clase no es la idea de un buen nombre de otra persona, o que mi forma de hacer algo en Eclipse se puede lograr en la mitad del tiempo con un atajo de teclado rápido. El hecho de tener a alguien más allí para hablar sobre el problema generalmente me lleva a la solución mucho más rápido (cf. patito de goma). El emparejamiento con expertos me enseñó una visión real del desarrollo impulsado por pruebas, mucho más de lo que podría haber obtenido de libros o sitios web. La capacidad de intercambiar socios de emparejamiento puede desbloquear rápidamente piezas de trabajo que hasta ese momento han estado en un lodo.

También he tenido el lado frustrante del emparejamiento. La parte en la que preferiría dejar que sus propios dispositivos jueguen con el código que tratar de explicar lo que le está haciendo a otra persona. Los días que te emparejas con alguien que es extremadamente lento en el teclado, o que simplemente no comprende el problema con la misma velocidad que tú. Los tiempos se combinan con alguien que tiene puntos de vista violentamente diferentes sobre el desarrollo de software, ninguno de los dos está necesariamente equivocado, pero no puede encontrar un terreno común para progresar.

Y luego están las partes del emparejamiento que muelen mis engranajes. Los veo mucho más como gerente. El emparejamiento, especialmente si está intercambiando socios de emparejamiento, a menudo conduce a la falta de propiedad colectiva: ninguna persona siente que posee el código que acaba de escribir y espera o asume que alguien más lo hace. También veo que las personas extrapolan la programación de pares para emparejar el trabajo; en otras palabras, las personas comienzan a asumir automáticamente que necesitan emparejarse en todo . Veo que la gente se empareja escribiendo correos electrónicos o haciendo hojas de tiempo, y decidiendo que debido a que su pareja ha ido a una reunión, no pueden hacer nada más que navegar por HN hasta que regresen. Veo a personas temerosas de hacer cosas a menos que sea con un par de parejas. Escucho regularmente que la gente dice que verificar las cosas en solitario es francamente peligroso y seguro que romperá el mundo (pista: no lo es). Cuando una persona es disruptiva o desenfocada, interrumpe o desenfoca a dos personas en lugar de una.

Lo que me lleva a la conclusión de que mucho sobre el éxito de la programación en pareja depende del coraje. Coraje para tomar una decisión acerca de cuándo es correcto emparejar y cuándo puedes solo sin mucho riesgo. Ánimo para decirle a tu pareja que STFU y seguir trabajando. Ánimo de pedirle a tu pareja que te explique algo como si tuvieras 5 años, en lugar de verlos escribir y asentir con la cabeza esperando que las cosas se aclaren. Coraje para dar y recibir retroalimentación, y coraje para tener una discusión que podrías perder, mi lema: no ha sido una buena sesión de emparejamiento hasta que hayas tenido una discusión (en realidad, mi lema es algo más crudo que eso, pero Quora parece como un lugar demasiado educado para decirlo en su totalidad;). Valor para admitir que ambos están estancados y necesitan intercambiar parejas para traer un par de ojos nuevos al problema.

Entonces, si está preguntando porque quiere probarlo, hágalo. Pero hazlo con coraje.

El proceso de programación de pares es una metodología de trabajo defendida por eXtreme Programming (XP). Como su nombre lo indica, cada unidad de programación consta de dos desarrolladores en una sola computadora. Podemos incurrir en el pensamiento equivocado de que es un desperdicio de la capacidad humana, ya que hay dos elementos para realizar las tareas.

Sin embargo, este pensamiento no podría estar más lejos de la realidad.

Se espera que un equipo emparejado produzca la misma cantidad de código que se esperaría de dos desarrolladores individuales, sin embargo, con el valor agregado del código con mayor calidad. Una vez escribí sobre la importancia y el papel de la revisión de código en el desarrollo de software. Un proceso que también consume tiempo en el momento presente pero que nos permite ganar tiempo en el futuro a través de la mayor madurez y calidad del código que seguirá para los entornos de producción. Si uno elige esta metodología, se puede suponer que la revisión del código ya estará presente en el código desarrollado por el par de desarrolladores.

Cada desarrollador tendrá un rol específico: el “controlador” y el “navegador”.

Esto significa que uno escribe código mientras el otro lee y anticipa problemas. La mejor coincidencia ocurre cuando el teclado va de la mano sin que ninguno de los elementos se aferre a su función preestablecida. Como puede ver, la programación en pareja tiene muchas habilidades blandas y habilidades técnicas. No es fácil para un desarrollador abrir la mano de su opinión antes de probarlo. Como todas las habilidades blandas, es posible desarrollarlo, pero requiere tiempo y apertura por parte del individuo.

“Como voy a tener dos desarrolladores juntos, es mejor unirme a un senior junto con un junior, para que pueda aprender”.

Debes tener mucho cuidado con esta línea de pensamiento. Una relación de tutoría es muy diferente de una relación de pares. Si no se pretende reducir la productividad, el equipo debe estar formado por desarrolladores competentes, autónomos y al mismo nivel.

Hay compañías que prefieren definir los roles como “desarrollador” y “probador”, esto significa que el “desarrollador” debe escribir el código para pasar las pruebas unitarias escritas por el “probador”. El equipo cambiará de roles con frecuencia y, a veces, incluso en el mismo día. Como se puede imaginar, esto sería imposible si ambos desarrolladores no estuvieran al mismo nivel.

Otra indicación que ofrece la Programación eXtreme es “mover a las personas”. Es importante que los equipos de programación de pares cambien elementos regularmente. Con esto evitaremos la aparición de “islas de conocimiento”, que en el futuro pueden llevarnos a una deuda técnica si los poseedores de conocimiento deciden abandonar la empresa, un fenómeno temido por cualquier gerente de tecnología.

Por lo tanto, podemos darnos cuenta de que la programación de pares emparejada con una rotación interna de desarrolladores obtendremos mayor:

  • flujo continuo de desarrollo y entrega,
  • difusión del conocimiento de la base de código del proyecto,
  • calidad en el código de producción,
  • disminución de posibles deudas técnicas.

Personalmente en mis equipos no tenemos equipos de programación de pares a tiempo completo, es decir, hacemos programación de pares en proyectos con “alto riesgo” o simplemente en esos problemas de “alto riesgo”. En estas situaciones, considero que la “programación de pares” es un gran activo. Sin embargo, tenga cuidado con las habilidades blandas, de lo contrario su “equipo” no será productivo y ocurrirá más daño que bien.

En resumen, mi opinión es que funciona. He capturado mi experiencia y lecciones a continuación.

Enlace al informe completo: ANÁLISIS EXTREMO – Emparejamiento para analistas de negocios


ANÁLISIS EXTREMO – Emparejamiento para analistas de negocios

La programación de pares ha sido utilizada por los desarrolladores de software en la mayoría de las compañías de software progresivas para ayudar a producir productos de calidad y garantizar que el contexto se comparta entre los equipos. Para los no iniciados, la programación tradicional de pares (en resumen) es una práctica en la que 2 programadores trabajan en el desarrollo de una funcionalidad de software en conjunto.
Esta práctica ayuda a mejorar la calidad del código, ya que tiene 2 pares de ojos y cerebros tratando de resolver el problema y cuando una persona escribe el código, la otra lo revisa continuamente, eliminando así la necesidad de tener sesiones de revisión de código separadas. Además, si el par ha funcionado eficientemente, cualquier error en el diseño se ha detectado por adelantado, eliminando así cualquier desperdicio causado por defectos que se habrían descubierto en una etapa posterior. Este concepto se ha aplicado principalmente al trabajo de los desarrolladores de software y otros roles aún no lo han adaptado del todo.

¿Porque es esto importante? Los analistas de negocios (en general) están acostumbrados a trabajar en una capacidad individual ya que la mayoría de los equipos tienen un solo BA, y muchos analistas encuentran difícil trabajar con otros analistas de una manera amigable. Supongo que, dado que hay una escasez de oportunidades para trabajar con otros, las habilidades para trabajar con otros tienen la oportunidad de florecer.

“Los analistas de negocios, los analistas de experiencia de usuario (UX), los gerentes de proyectos y (en menor grado) los analistas de calidad están acostumbrados a trabajar solos y pueden necesitar resolver cómo lidiar con situaciones en las que ellos también necesitan colaborar entre la comunidad, y entregar “.

Mi función principal es la de Analista de negocios, y quería compartir mis experiencias sobre los proyectos que ejecuté en ThoughtWorks, donde pude vincularme con los otros BA con cierto nivel de éxito. Este artículo es mi intento de no solo compartir algunas de esas lecciones y experiencias, sino que también generará debates / debates saludables.

Los basicos

Antes de entrar en detalles sobre cómo emparejarse como analistas de negocios, primero necesitamos tener algunos conceptos básicos correctos.

Cualquier relación de trabajo exitosa debe tener estos elementos en el núcleo, la ausencia de estos hará que cualquier intento de emparejamiento sea inútil.

  • Compromiso de trabajo de las personas en cuestión.
  • Respeto mutuo
  • Igual reparto de tareas y responsabilidades.
  • Aproveche las fortalezas de cada uno y trabaje alrededor de los bordes ásperos.
  • Voluntad de recibir comentarios unos de otros y trabajar para mejorar
  • Ayudándose mutuamente a través de los tiempos libres personales asumiendo temporalmente la responsabilidad de las tareas
  • Capacidad para compartir risas y trabajar en situaciones estresantes.
  • Higiene personal, ya que la expectativa es que ambos se sienten razonablemente cerca uno del otro, la higiene personal será un factor importante. 😛

Prácticas de emparejamiento

Cuando miramos el análisis de negocios en un proyecto ágil, las siguientes tareas generalmente tendrían que llevarse a cabo en el día a día. Espero vincular las prácticas que utilizamos y defender mi caso de “ANÁLISIS EXTREMO”.

Registros diarios: el día generalmente comienza con un stand-up donde participa todo el equipo y luego los programadores, analistas de calidad y analistas de negocios se registran para sus tareas. Es importante que los BA se reúnan y enumeren las tareas que tienen la intención de elegir durante el transcurso del día y se inscriban en ellas en función de una distribución equitativa.
Esta actividad es importante ya que puede haber múltiples cosas (además del detalle de la historia) que deben abordarse durante el día, como responder a los correos electrónicos enviados por el cliente, aumentar los bloqueadores, revisar las historias analizadas, etc. Y estas tareas deben ser identificadas y respondidas a como un equipo.
Herramientas / Prácticas: cuando los BA se ubican conjuntamente, tiene sentido sentarse uno al lado del otro y enumerar las tareas en un cuaderno o notas adhesivas y eliminarlas a medida que se realizan. Sin embargo, cuando los BA están trabajando en diferentes zonas horarias (o geografías), además de una recuperación diaria de 15-30 minutos, las inscripciones se pueden administrar a través de un administrador de listas de tareas liviano como Trello. Es basado en la web, de uso gratuito y simple como el infierno.

Detalle de la historia: esta es la tarea más importante que los BA emprenden y el emparejamiento aquí puede ayudar a establecer una dirección mutuamente acordada que el BA que detalla la historia puede tomar.
Herramientas / Prácticas: La herramienta que se usa aquí es la más efectiva, es decir, las conversaciones. El BA que ha asumido la propiedad de una función explicará brevemente el enfoque que planea tomar y solicitará aportes de los otros BA. Esto garantiza que el contexto se comparta y también ayuda a construir una mejor historia por adelantado (falla rápidamente).

Revisión de la historia (interna): en la Programación extrema, los programadores utilizan la revisión por pares para garantizar que se sigan las prácticas de codificación. Teniendo en cuenta los mismos principios, los analistas de negocios deben hacer que sus historias sean revisadas por otro par de ojos solo para asegurarse de que todas las bases estén cubiertas.
Herramientas / Prácticas: Asegurarse de que todas las historias (especialmente las complejas) sean revisadas por pares al menos por un Analista de Negocios para capturar cualquier omisión / error obvio.

Revisión de la historia (con el cliente): las historias deben ser aprobadas por los clientes antes de que los programadores puedan recogerlas y estas reuniones se pueden gestionar mejor si trabaja en equipo. Si los BA han seguido los pasos anteriores, recibirán un mensaje uniforme y presentarán una voz unificada al cliente.
Herramientas / Prácticas: Tener funciones iniciales , donde, como equipo, presenta el esquema del requisito y recibe aportes del cliente.

Planificación de iteraciones : las historias que deben seleccionarse en las próximas iteraciones deben planificarse y comunicarse al cliente. Es importante que esta actividad tenga en cuenta las dependencias y prioridades asociadas con las historias y características.
Herramientas / Prácticas: Gire la responsabilidad de crear el plan de iteración entre los BA y luego revise el plan que se ha establecido como un equipo. Nuevamente, esto ayuda a obtener aportes de un grupo más grande y, en ausencia de uno de los BA, los otros pueden hacerse cargo de la reunión de planificación de iteración con el equipo y / o el cliente.

La programación de emparejamiento es útil cuando se incorporan nuevos miembros del equipo, o cuando es posible emparejar un desarrollador experimentado con un desarrollador inexperto. En general, estoy de acuerdo en que el código generado por pares es superior, sin embargo, es posible lograr una calidad similar con las solicitudes de extracción (consulte Solicitudes de extracción para equipos).

No estoy demasiado entusiasmado con los mandatos de la organización, como la programación forzada en pares. Ese tipo de mandato es una señal de alerta para la inflexibilidad organizacional (y un indicador principal de que la organización no puede ver el bosque por los árboles). Entonces, probablemente no tomaría un concierto donde el emparejamiento fuera un mandato.

La comunidad de desarrollo de software aprendió mucho de los movimientos de XP y Agile en los últimos 10-15 años, pero eso no significa que cada flecha en el carcaj sea aplicable a cada situación.

La programación en pareja es útil

  • Para los nuevos miembros que se unen a un grupo para acelerar la capacitación en la base de código
  • Para programadores senior para mentor programadores junior
  • Para componentes de infraestructura críticos que requieren una inspección minuciosa y verificación cruzada

La programación en pareja es la excepción.

Es demasiado costoso grabar dos programadores para la salida de uno.

La programación en pareja es para enseñar al final.

Corta duración, repita solo cuando sea necesario.

Es divertido si se hace correctamente y mejora la cohesión del equipo.

Demasiado de algo bueno es típicamente malo.

Los programadores necesitan libertad para crear de manera efectiva, lo que generalmente significa trabajar solo, excepto los breves períodos necesarios de retroalimentación / lluvia de ideas.

Creo que la programación de pares es una práctica que la mayoría de las empresas deberían probar en su proceso de desarrollo. De hecho, presentaremos la programación de pares en mi empresa, EL Passion, en los próximos meses. Por supuesto, no es algo para todas las empresas y desarrolladores. Necesita personas adecuadas que estén dispuestas a utilizar la Programación de pares. Si está disponible, puede funcionar muy bien.

Tiene muchos beneficios, especialmente menos código con errores, lo que significa una calidad superior y menos tiempo y dinero gastado en depuración. También hace que la difusión del conocimiento entre el equipo de desarrollo sea mucho más rápida y natural.

Creo que es una buena opción para nuevas empresas en crecimiento que necesitan productos de calidad. También hay una publicación en el blog de EL Passion sobre eso, así que si estás interesado solo sigue el enlace: ¿Por qué las startups en crecimiento deberían considerar la programación de parejas?

Personalmente, tengo trabajadores con los miembros de mi equipo de vez en cuando para analizar y hacer una lluvia de ideas sobre ciertos problemas, o para monitorear o ser monitoreado con un miembro junior / senior. ¿Cuenta como programación de pares? De lo contrario, también he compartido / planeado tareas con algunos miembros del equipo, aunque realmente no nos sentamos frente al mismo monitor y trabajamos en la misma computadora. Personalmente no lo disfrutaría. Necesito mi propio tiempo y ritmo para analizar y pensar en el código, que puede ser más rápido o más lento, o incluso podríamos querer ver diferentes partes del código o el problema. Por lo tanto, puede ser molesto y bloquear la mente, interrumpir el “flujo” (llamo a ese momento de concentración que tengo cuando codifico como “flujo”).

Entonces, para responder la pregunta, probablemente no esté tan emocionado con una compañía que fuerce la programación de pares, a menos que tengan argumentos muy convincentes.

Cuatro veces la calidad a más del doble de la velocidad. Si bien mi tasa máxima se alcanza al estallar trabajando solo en condiciones óptimas, mi tasa promedio sostenida en condiciones típicas (exceso de trabajo, estrés, necesidad de comer o dormir) es mucho mejor.

Todo lo anterior es relevante desde su POV (opinión sobre la experiencia). Como todo lo demás en el mundo de los blogs, la verdad es contextual. La pregunta es, ¿podríamos extender 2 es mejor que 1 a la programación acoplada n (n personas que trabajan en el mismo código) es mejor que la programación acoplada (np) donde n> p> 0?

More Interesting

¿Cuánto tiempo le tomará a un solo programador construir su propio software?

¿Cuál es el mejor software de simulación por computadora?

Si tuviera un año para prepararse antes de inscribirse en un programa de licenciatura en ciencias de la computación o ingeniería de software, ¿qué conceptos, materias, lenguajes de programación o contenido estudiaría para tener éxito?

¿Por qué es más divertido jugar videojuegos que programar?

¿Cuáles son algunos recursos, preferiblemente libros, que podría recomendar para comenzar a aprender compiladores?

¿Cómo es ser desarrollador en una startup?

¿Qué esperan los ingenieros de software de un increíble gerente de producto (en tecnología)?

Me acabo de graduar de la universidad y comencé a trabajar como ingeniero de software en Google. ¿Qué debo hacer ahora para maximizar el éxito en mi carrera?

Cómo aprender habilidades de desarrollo de software si tengo experiencia en soporte de TI y actualmente trabajo como ingeniero DevOps

¿En qué situaciones debemos usar los patrones de observación?

Viniendo de un entorno de Operaciones, ¿es difícil obtener un papel haciendo DevOps? ¿Alguien sabe de personas que vienen de Operaciones / Soporte a Devops?

¿Cuáles son las convenciones de versiones comunes?

¿Cuáles son algunas buenas preguntas de entrevistas basadas en la pizarra para evaluar el talento de ingeniería en una startup?

¿Qué es una carrera en pruebas de software?

Desde 'Hello World' hasta el inicio a tiempo completo, ¿cuánto tiempo le llevó construir su producto?