Programación en pareja: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
La '''programación en pareja''' (''pair programming'' en inglés) es una técnica | {{Meta-bok|min=4}} | ||
La '''programación en pareja''' (''pair programming'' en inglés) es una técnica de desarrollo ágil de software en la que dos programadores trabajan conjuntamente en una misma estación de trabajo. Uno de ellos (el '''conductor''') escribe el código, mientras el otro (el '''observador''') lo supervisa en tiempo real. Ambos van alternando sus roles a lo largo de la sesión. | |||
El código desarrollado por programadores en pareja es más corto y de mayor calidad que el que realizarían de forma individual, porque el rol de observador permite la reconsideración y mejora continua de la estrategia en la | == Descripción == | ||
El código desarrollado por programadores en pareja es más corto y de mayor calidad que el que realizarían de forma individual, porque el rol de observador permite la reconsideración y mejora continua de la estrategia y del código que el conductor va desarrollando. La conversación continua entre los dos roles también acelera la detección de errores y la toma de decisiones de diseño. | |||
Es una práctica central de [[Extreme programming|Extreme Programming]] y forma parte del conjunto de prácticas de [[Agilidad técnica|agilidad técnica]]. La denominación que recibe en el manual Scrum Master v4.0 de Scrum Manager es ''trabajo en pareja'', señalando que el concepto es más amplio que la programación: aplica a cualquier trabajo en el que la calidad del resultado dependa principalmente del conocimiento de la persona que lo realiza. | |||
El manual cita ejemplos no tecnológicos de la misma lógica: los trenes circulan con maquinista y ayudante cuando la tecnología no puede evitar completamente el fallo humano, y las cabinas de los aviones tienen dos pilotos por la misma razón. | |||
== Cuándo es especialmente valiosa == | |||
* Cuando la tarea requiere un nivel de concentración alto y un error puede tener consecuencias significativas. | |||
* Cuando se trabaja en código heredado o en una parte del sistema que el conductor conoce poco: el observador puede aportar contexto. | |||
* Para la incorporación de nuevos miembros al equipo: el pair programming con un desarrollador experimentado es una de las formas más eficaces de transferencia de conocimiento tácito. | |||
* Cuando se trabaja con [[TDD]]: el ciclo rojo-verde-refactorizar funciona especialmente bien en pareja, alternando quién escribe la prueba y quién escribe el código que la hace pasar. | |||
== Programación en pareja con herramientas de IA == | |||
La incorporación de asistentes de código (GitHub Copilot, Cursor y similares) ha dado lugar a una nueva modalidad de trabajo en pareja: el desarrollador como conductor y la IA como observador/copiloto permanente. Esta modalidad tiene ventajas pero también un riesgo específico: | |||
En la programación en pareja humana, el observador cuestiona activamente las decisiones del conductor y puede percibir cuando la dirección no es correcta. La IA generativa no cuestiona ni tiene criterio sobre si la dirección estratégica es la adecuada: ejecuta sin juicio. El riesgo es que el desarrollador trabaje solo de facto, usando la IA como autocomplete avanzado, sin el beneficio del cuestionamiento activo que aporta un par humano. | |||
Para preservar el valor de la práctica cuando se trabaja con IA, es recomendable: | |||
* Combinar la IA como herramienta con pares humanos en las partes más críticas del trabajo. | |||
* Tratar la revisión del código generado por IA como una actividad de pair review: al menos una persona adicional verifica cada contribución significativa de la IA. | |||
== Error frecuente == | |||
<div class="bok-aviso"> | |||
'''Forzar el pair programming en todas las tareas.''' La programación en pareja aporta su mayor valor en tareas complejas, críticas o de alta incertidumbre. En tareas rutinarias o bien conocidas puede reducir la productividad sin una ganancia de calidad proporcional. La decisión de trabajar en pareja debe ser del equipo, orientada a las tareas donde la práctica aporta más valor, no una regla burocrática aplicada de forma indiscriminada. | |||
</div> | |||
== Recursos == | |||
<div class="bok-recurso"> | |||
📄 [https://www.scrummanager.com/files/scrum_master.pdf Manual Scrum Master v4.0] — Apartado: prácticas técnicas<span class="detalle">Descarga gratuita · Scrum Manager</span> | |||
</div> | |||
== Véase también == | |||
<div class="bok-tags"> | |||
[[Extreme programming]] [[TDD]] [[Agilidad técnica]] [[Refactorización]] [[Deuda técnica]] [[XBreed]] | |||
</div> | |||
<div class="bok-ecosistema"> | |||
<div class="texto"> | |||
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span> | |||
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span> | |||
</div> | |||
<div class="botones"> | |||
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div> | |||
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div> | |||
</div> | |||
</div> | |||
[[Category:Glosario de términos]] | [[Category:Glosario de términos]] | ||
[[Category: | [[Category:Prácticas técnicas]] | ||
[[Category:Prácticas ágiles]] | [[Category:Prácticas ágiles]] | ||
Revision as of 15:05, 15 May 2026
La programación en pareja (pair programming en inglés) es una técnica de desarrollo ágil de software en la que dos programadores trabajan conjuntamente en una misma estación de trabajo. Uno de ellos (el conductor) escribe el código, mientras el otro (el observador) lo supervisa en tiempo real. Ambos van alternando sus roles a lo largo de la sesión.
Descripción
El código desarrollado por programadores en pareja es más corto y de mayor calidad que el que realizarían de forma individual, porque el rol de observador permite la reconsideración y mejora continua de la estrategia y del código que el conductor va desarrollando. La conversación continua entre los dos roles también acelera la detección de errores y la toma de decisiones de diseño.
Es una práctica central de Extreme Programming y forma parte del conjunto de prácticas de agilidad técnica. La denominación que recibe en el manual Scrum Master v4.0 de Scrum Manager es trabajo en pareja, señalando que el concepto es más amplio que la programación: aplica a cualquier trabajo en el que la calidad del resultado dependa principalmente del conocimiento de la persona que lo realiza.
El manual cita ejemplos no tecnológicos de la misma lógica: los trenes circulan con maquinista y ayudante cuando la tecnología no puede evitar completamente el fallo humano, y las cabinas de los aviones tienen dos pilotos por la misma razón.
Cuándo es especialmente valiosa
- Cuando la tarea requiere un nivel de concentración alto y un error puede tener consecuencias significativas.
- Cuando se trabaja en código heredado o en una parte del sistema que el conductor conoce poco: el observador puede aportar contexto.
- Para la incorporación de nuevos miembros al equipo: el pair programming con un desarrollador experimentado es una de las formas más eficaces de transferencia de conocimiento tácito.
- Cuando se trabaja con TDD: el ciclo rojo-verde-refactorizar funciona especialmente bien en pareja, alternando quién escribe la prueba y quién escribe el código que la hace pasar.
Programación en pareja con herramientas de IA
La incorporación de asistentes de código (GitHub Copilot, Cursor y similares) ha dado lugar a una nueva modalidad de trabajo en pareja: el desarrollador como conductor y la IA como observador/copiloto permanente. Esta modalidad tiene ventajas pero también un riesgo específico:
En la programación en pareja humana, el observador cuestiona activamente las decisiones del conductor y puede percibir cuando la dirección no es correcta. La IA generativa no cuestiona ni tiene criterio sobre si la dirección estratégica es la adecuada: ejecuta sin juicio. El riesgo es que el desarrollador trabaje solo de facto, usando la IA como autocomplete avanzado, sin el beneficio del cuestionamiento activo que aporta un par humano.
Para preservar el valor de la práctica cuando se trabaja con IA, es recomendable:
- Combinar la IA como herramienta con pares humanos en las partes más críticas del trabajo.
- Tratar la revisión del código generado por IA como una actividad de pair review: al menos una persona adicional verifica cada contribución significativa de la IA.
Error frecuente
Forzar el pair programming en todas las tareas. La programación en pareja aporta su mayor valor en tareas complejas, críticas o de alta incertidumbre. En tareas rutinarias o bien conocidas puede reducir la productividad sin una ganancia de calidad proporcional. La decisión de trabajar en pareja debe ser del equipo, orientada a las tareas donde la práctica aporta más valor, no una regla burocrática aplicada de forma indiscriminada.
Recursos
📄 Manual Scrum Master v4.0 — Apartado: prácticas técnicasDescarga gratuita · Scrum Manager
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.