Se tiene que programar por parejas si se sigue un proceso ágil.
Esto es completamente falso. 'Ágil' es un término muy amplio definido sólo en términos de valores y principios, el más notablemente en el Manifiesto para el Desarrollo de Software Ágil. El manifiesto no menciona el programar por parejas y la mayoría de los métodos ágiles no lo incluyen en su aproximación.
Ya que programar por parejas es una práctica de XP, ha tenido mucha influencia en la comunidad ágil. Por consiguiente a menudo es mencionado como una práctica ágil – tomando como práctica algo que es comúnmente usado por la gente en proyectos ágiles. Pero esto es una observación, no una prescripción..


La Programación Extrema te obliga a programar por parejas
Esto es un cuestión de matiz. La programación por parejas es una de las prácticas de XP y lo ha sido desde su inicio. El matiz aquí está en si las prácticas XP son obligatorias para un equipo que dice seguir XP. Esto es en realidad un pregunta más difícil de lo que pueda parecer a primera vista. XP, como cualquier método ágil, espera que un equipo escoja su propio proceso. En “Programación Extrema Explicada” Kent dice que las prácticas son "la clase de cosas que verá que los equipos de XP hacen en el día a día". Yo diría que programar por parejas es habitual en equipos de XP. Pero no diría que un equipo que no programa por parejas no puede llamarse un equipo de XP. También advierto que para la mayor parte de los XPers que conozco, la pregunta de si un equipo es XP o no, no les es interesante; la verdadera cuestión es si un equipo es eficaz.
La situación en la que obligaría a programar por parejas sería decir que si quieres aprender cómo seguir XP, deberías probar con la programación por parejas y ver si te funciona..

No tengo que tratar de trabajar por parejas porque sé que no me gustará.
El problema con esta declaración es que muchas personas se han sorprendido por la programación por parejas. Ellos lo intentaron, esperando odiarlo, y encontraron que realmente les gustó.
Esto es bastante complicado porque mucha gente prueba trabajando en parejas mal – lo que puede dar una impresión falsa. Horas pasadas pasivamente mirando fijamente sobre el hombro de alguien en un cubo en una esquina no son programación en parejas. Asegúrese de que tiene alguien que realmente conoce cómo entrenarle, y entonces estará seguro de que evalúa lo verdadero.
El programar por parejas parte por la mitad la productividad de los programadores.
Mi respuesta impertinente a esto es: " sería verdadero si los más complicado de programar fuera teclear".
Los defensores de la programación por parejas los son porque creen que una pareja es en realidad más productiva que los dos programadores por separado. Esto es debido a la discusión continua y la revisión que introduce el trabajar por parejas. Se consiguen mejores diseños, menos errores, y más personas familiarizadas con el código. Toda esta compensación de cosas se consigue con menos gente tecleando.
Desde luego, ya que no se puede medir la productividad, nosotros no podemos saberlo con seguridad. Mi opinión es que debería intentarlo y el equipo debería reflexionar sobre si ellos sienten que son más eficaces trabajando en parejas o por separado. Como con cualquier nueva práctica, asegurese de que hace la prueba suficiente tiempo, y entonces tiene una posibilidad buena de cruzar el abismo para la mejora.
Sólo merece la pena la programación por parejas con código complejo, con código sencillo no da ventajas.
Pienso que hay una razón para esto - el programar por parejas mejora el diseño y lo errores se reducen al mínimo. El código sencillo de escribir produce pocas oportunidades para que el programar por parejas sea una diferencia.
Excepto esto: escribir código sencillo que aburre es un olor. Si se escribe código aburrido repetitivo es por lo general un signo de que he omitido una abstracción importante, una que drásticamente reducirá la cantidad de código a escribir. El trabajar por parejas le ayudará a encontrar aquella abstracción.


Lo que nos pasa a nosotros en los proyectos por lo general, es que nos sirve la programación por parejas cuando hacemos un trabajo de investigación o cuando llevamos adelante proyectos que tienen problemas a resolver que no los hemos visto en otro momento. En esas circunstancias las personas se ayudan y entregan una muy buena calidad de código en conjunto. En otras circunstancias no lo hacemos aunque no podemos decir tampoco si nos serviría o no.

Articulo original

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

 

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw