La Integración Continua reduce el riesgo en proyectos software

Hace tiempo alguien me preguntó que como configuraría un TFS (Team Foundation Server) para poder pasar pruebas unitarias automáticamente. Le comenté que implantaría integración continua (IC), realizando compilaciones automáticas en el servidor con cada subida de código, desplegando la solución, ejecutando los test unitarios y generando los reportes. Se quedó sorprendido y me preguntó ¿para qué querríamos hacer eso tan a menudo? A veces hay conceptos que cuando los escuchas por primera vez te chocan pero cuando los pruebas acabas mirando al infinito sonriendo y con las palmas de las manos en volandas diciendo  “¡¡como he podido vivir antes sin esto!!”. La integración continua es uno de esos conceptos.

ninos-felices-viendo-la-pantalla_438-19316458 - free

La IC es un modelo informático que consiste en hacer integraciones automáticas en un proyecto lo más a menudo posible para detectar fallos lo antes posible. En este caso se entiende “integración” como la compilación y ejecución de pruebas. Este proceso se puede producir cada cierto tiempo en el servidor o tras un evento como puede ser una subida de código por parte de un desarrollador. La IC automáticamente descarga el código fuente del control de versiones, lo compila, ejecuta las pruebas automáticas y por último genera un informe. También puede incluirse una generación de un instalador para poder realizar pruebas manuales.

source control

IC es una de las prácticas fundamentales de XP. Esta técnica fue propuesta por Martin Fowler y se empezó a difundir con más fuerza fuera de XP a raíz de un artículo que pùblicó en Mayo del 2006 dedicado por completo a la IC. Se trata de un artículo que habla con detalle de la IC y donde al final del mismo, hablando de los beneficios, comenta que quizá el mayor beneficio es reducir el riesgo. Esta reducción se debe a que:

  • Detectamos fallos de forma temprana. Recordemos que un error detectado en fases tempranas de desarrollo nos va a ahorrar siempre mucho tiempo en el proyecto y consecuentemente dinero.
  • Vamos a saber en todo momento cual es el estado de nuestro código, por lo que a diario podemos tener un informe sobre la salud de la misma. De esta manera vamos a tener muchas pequeñas integraciones y no una única normalmente impredecible al final del desarrollo.
  • El efecto psicológico que produce la CI conduce a una disminución de bugs.

Pero desarrollemos un poco más estas ideas para saber realmente por qué IC reduce el riesgo en nuestros proyectos software.

Manage Your Risk in a dangerous world, company, workplace or ent

Martin Fowler comenta en su artículo que la idea de la IC le surgió durante un antiguo proyecto en el que trabajaba de QA manager donde se dedicaba entre otras cosas a sacar informes OLAP con el objetivo de predecir cuánto tiempo les iba a llevar integrar el software que estaban desarrollando. Cuenta que en este proyecto aprendió que la integración “suele ser larga e impredecible”. Se dio cuenta de que otros proyectos no trataban la integración como un evento aislado que se producía una vez recibida una release, sino que podían en cualquier momento pasar a integración el código actual en la rama de desarrollo en cuestión de minutos. Cualquier error de integración era encontrado rápidamente y arreglado. Comenta también que cuando intentaba explicar en otros sitios el concepto, se sorprendió del rechazo. Cualquier cambio que pone a prueba nuestro sistema de creencias siempre va a tener una resistencia asociada: si atamos a un elefante de pequeño a una estaca y cree que no puede escapar, seguirá atrapado toda su vida.

elephant

Una de las cosas que más cuesta entender es que tener IC implantada en nuestro desarrollo con una buena cobertura de tests no nos va a librar de tener bugs. Mucha gente piensa, que con un juego de pruebas adecuado y con una buena estrategia vamos a conseguir proteger nuestro código de esos molestos bugs, y este no es el objetivo de ningún tipo de prueba automática o manual. El objetivo de un conjunto de pruebas es aumentar la probabilidad de capturar errores en nuestro sistema. Por lo que en el caso de las pruebas unitarias y de integración automáticas, si las ejecutamos cada vez que hacemos un cambio en la rama de desarrollo, aumentamos la probabilidad de detectar errores debidos al cambio que hemos realizado. Diciéndolo de otro modo, si nuestro código es una novela, aumenta la probabilidad de que se detecte alguna incoherencia en un nuevo párrafo incluido con el resto de la misma.

taller-escritura

En resumen IC no nos va a librar de tener errores en el código pero si va a tratar de minimizar el número de los mismos. Algunos no prestan demasiada atención al número de bugs durante la fase de desarrollo. Se da por hecho de que es normal que surjan bugs porque la funcionalidad no está terminada y siempre se reserva un tiempo antes de la entrega para poder corregir esos bugs y realizar una entrega con calidad. Estos periodos de corrección de bugs suelen ser apocalípticos porque se pretende limpiar los bugs generados tras varios meses de desarrollo en 1 mes de corrección. Este tipo de desarrollos se caracterizan por subidas y bajadas del número de bugs justo antes de la finalización de hitos. Lo más curioso es que normalmente suele haber un tope mínimo de bugs que no se corrigen nunca: suelen ser aquellos que supondrían realizar cambios muy costosos en arquitectura… y claro si los dejas para el final, evidentemente nunca se corrigen.

costofdefects

Tratar de corregir bugs durante el desarrollo ayuda a controlar los picos altos de errores, pero sin una buena cobertura de test unitarios, es muy difícil mantener una rama de desarrollo sana. Esto es debido a que se sigue subiendo código simultáneamente a medida que los bugs se corrigen, de forma que al no existir una “alarma” que diga que una subida de código ha afectado a otra parte del sistema, cada subida de código contiene alta probabilidad de causar daños en otras partes del sistema. Hay que decir que la probabilidad de daño en cada subida es menor en arquitecturas con alta cohesión y bajo acoplamiento entre sus componentes que en aquellas donde existe un alto acoplamiento y baja cohesión (código espagueti). Tener una buena cobertura de test unitarios es un indicador de que tu arquitectura tiene alta cohesión y bajo acoplamiento. Por este motivo aplicar técnicas como TDD es más efectivo que realizar los test unitarios a posteriori ya que primero se crean las pruebas y luego el diseño, con lo que estamos forzados a crear componentes separados por interfaces y bien definidos si queremos conseguir una buena cobertura y unas pruebas realmente eficaces.

DevBranch

Como decía anteriormente, muchos creen que no merece la pena realizar el esfuerzo de corregir bugs durante el desarrollo porque de todos modos siempre hay que hacer ese esfuerzo al final del mismo (con test unitarios un esfuerzo muchísimo menor). Existe un fenómeno psicológico que dice que la gente pone menos esfuerzo en localizar bugs cuando hay muchos que cuando hay pocos. Este fenómeno se estudia en criminología y se denomina “Teoría de las ventanas rotas (Broken Window syndrome)”: Esta teoría dice que si consideras un edificio con una ventana rota, si la ventana no se repara, muy probablemente los vándalos tenderán a romper unas cuantas ventanas más. Cuando estén rotas, posiblemente irrumpan en el edificio, y si está abandonado, es posible que sea ocupado y prendan fuego dentro.

300px-Kristallnacht_example_of_physical_damage

La IC, intenta dar tolerancia cero a la rotura de ventanas mediante la detección temprana de bugs y la prioridad máxima para su corrección. Debido a esto, los desarrollos que tienen integración continua, tienen tendencia a tener menos bugs. No evitas tener seguramente un periodo de pruebas de regresión a final del desarrollo, pero si maximizas la corrección en el periodo establecido, habrá menos bugs, estarán más controlados y su corrección será mucho más sencilla.

Disciplina

Las herramientas que podemos utilizar para poder implantar integración continua en nuestro desarrollo software son muy variadas. Por si tenéis interés os enumero algunas con sus links: TFS – Team Foundation Server, Cruise control, Jenkins y  Atalassian Bamboo. Además de ayudarnos de estas herramientas, existen una serie de prácticas que maximizan la eficacia de IC. Estas son explicadas con detalle en el artículo de Martin Fowler por lo que sólo las listaremos:

  • Mantén un único repositorio de código fuente
  • Automatiza los build
  • Haz tu build autotesteable
  • Todo el mundo sube código diariamente
  • En cada subida de código se debería ejecutar la IC en una máquina limpia
  • Arregla los bugs cuanto antes
  • Testea manualmente en un clon de un enviroment de producción
  • Hazlo visible a todo el mundo el estado de la rama de desarrollo
  • Automatiza el despliegue

gear

Volviendo a inicio del artículo, cuando me preguntaron ¿para qué querríamos pasar los test en el servidor de TFS cada vez que alguien sube código? Contesté que  la integración continua minimiza el riesgo en tu proyecto gracias al aumento de calidad (tanto externa como interna) de tu producto y a la posibilidad de tener una alarma que te dice cual es el estado de salud del código desarrollado en todo momento. Parece ser que capté su atención, por lo que su siguiente pregunta era de esperar: ¿y eso cómo se produce? Le dije que se pusiera cómodo porque la respuesta podría ser perfectamente un artículo de ingeniería del software y me llevaría un rato exponerla.

PDFicono EXTENDIDO

REFERENCIAS:

[1] Continuous Integration – Martin Fowler
[2] Foundation of Software Testing  –ISTQB CERTIFICATION
[3] Implantar integración continua  – Javier Garzas  

Aumenta la productividad y calidad software con Pair Programming

Toda mi vida he escuchado que cuatro ojos ven más que dos y que dos cerebros son mejor que uno. A pesar de este hecho parece evidente, por algún motivo mi cabeza siempre había tendido a pensar que el hecho juntar sólo un ordenador y un teclado con cuatro manos era un impedimento para la productividad. ¿Qué me hizo dejar de pensar así? Pues os seré sincero, practicar Pair Programming y abrir mi mente conceptos nuevos, al menos nuevos para mí porque es una de las prácticas comunes de Extreme Programming (XP).

transformar-vida

Recuerdo haber escuchado muchas veces comentarios del estilo  “eso de programar dos en el mismo ordenador… lo hemos hecho muchas veces, nos ponemos dos a resolver un problema, no tiene ningún misterio” o “eso es una tontería, a mi me pones a alguien conmigo y me vuelvo medio loco, me va a retrasar en mi trabajo” o simplemente “eso no vale para nada”. He de reconocer que alguna vez pensé de la misma forma y puede que algunos de estos comentarios hubieran salido de mi boca alguna vez hace años. Por eso para la lectura de este articulo, si lo que conoces de Pair Programming es simplemente el nombre y lo que puedas imaginar al escucharlo, te aconsejo que olvides todo lo que sabes y leas el articulo como si habláramos de : Programación altamente productiva y de calidad e ignores cualquier tipo de pensamiento preconcebido que puedas tener al respecto. Esto es Pair Programming.

pairon

La programación en pareja requiere de dos desarrolladores que  participen en un esfuerzo combinado de desarrollo en un mismo ordenador. Existen varias estrategias o estilos y cada una tiene un objetivo principal bien distinto. Esto quiere decir que aunque todos por norma general tienen objetivos a largo plazo como pueda ser el aumento de la calidad, productividad, comunicación y aprendizaje, cada estrategia a corto plazo focaliza en alguno de ellos con mayor intensidad. Algunos estilos se pueden combinar o alternar.

  • Pair Programming distribuido. No es lo ideal y se puede utilizar tanto en tiempo real como no real. Se suele utilizar en equipos virtuales dispersos geográficamente y nos solemos ayudar con herramientas de comunicación y compartición de escritorio. Se puede usar en combinación con el resto de estrategias que se mencionan a continuación.

liderazgo-y-equipos-virtuales

  • Enseñando por medio de Pair Programming como mentoring. Esto creo que lo ha practicado todo el mundo alguna vez y funciona muy bien. El objetivo buscado no es la productividad a corto plazo si no la formación y training mediante un rol de mentor y un rol de alumno. Conviene utilizarlo durante unas semanas en nuevos miembros del equipo ya que fomenta su adaptación al equipo y aprendizaje. Recordad que el objetivo principal corto plazo en este caso nunca es la productividad, la persona siempre requerirá de una curva de aprendizaje.
  • Enseñando por medio de Pair Programming como transferencia de conocimiento. También lo habréis probado más de una vez. El periodo suele ser más corto y suele utilizarse cuando un miembro abandona el equipo, hay un cambio de tareas o simplemente como rutina de compartición de conocimiento. Su objetivo no es la productividad a corto plazo sino distribuir la información dentro del equipo. Si no practicas Pair Programming habitualmente es una buena manera de evitar silos (conocimiento aislado y no compartido en el equipo, departamento u organización) en el equipo si lo practicas cada cierto tiempo como rutina.

22-2-13-mentoring1

  • Pair Programming Ping-Pong. Ambos miembros cambian alternativamente en función de ciertas acciones. Por ejemplo, uno escribe el test, otro lo implementa, el otro compila, y siguiente refactoriza. Es bastante dinámico y puede combinarse con los anteriores. No se recomienda utilizar cuando el equipo no está acostumbrado a hacer programación en parejas ya que puede llevar al caos por falta de comprensión de la técnica y falta de disciplina. Su objetivo principal es sin duda buscar un aumento de productividad y calidad de código.

PUBLISHED by catsmob.com

  • Pair Programming controlador-navegante. Es el que veremos en profundidad porque creo que es el más habitual y por el que habría que empezar si no se tiene experiencia. Se puede combinar con los anteriores excepto con el Ping-Pong, aunque se pueden alternar con él. Su objetivo es sin lugar a dudas buscar la sinergia y conseguir un aumento de la productividad y de la calidad del código.

sidecar-300x225

En el estilo controlador-navegante, uno de ellos toma el rol de controlador que es el que está codificando y al mando del teclado, mientras que el otro es navegante que va decidiendo y aconsejando al controlador. Se sugiere que se cambien los papeles de cada poco tiempo (en torno a 30 minutos). La programación en pareja, requiere muchísima disciplina, ya que el no seguir ciertas pautas lo único que puede conseguir es que lo que hagamos es “programación con el compañero en el mismo ordenador” que no tiene nada que ver con las bases del Pair Programing.

Disciplina

Dos personas tratando de resolver un problema son dos cerebros funcionando. Lo que tú no ves lo ve tu compañero y lo que él no ve lo ves tú. Los dos están concentrados, no hay uno trabajando y el otro pensando en el fin de semana, charlando con otro compañero o enviando mensajes de texto. Ambos están centrados en lo que están haciendo. El controlador, debe ocuparse únicamente de codificar, pero ojo, esto requiere una gran disciplina para no ponerse a resolver el problema por sí mismo, ya que es el navegador quien decide que es lo que hay o no hay que hacer (aunque normalmente suele ser una negociación). Esto permite al navegador despreocuparse de la codificación y centrarse en resolver el problema global.

Cerebro Derecho e Izquierdo

A muchos desarrolladores les cuesta muchísimo ponerse delante de una pantalla y tener a alguien al lado diciéndote lo que tienes o no que hacer, o simplemente mirando la pantalla. A mí me pasaba. Simplemente es un ejercicio de disciplina y confianza tanto en el compañero como no en uno mismo. La mayor parte de los desarrolladores tienen un punto de introversión que les hace meterse en su mundo, imaginarse la solución y sentirse como dioses creando la vida entre línea y línea. No les suele gustar compartir ese rato de introspección, funcionan mejor solos y tranquilos. Sienten como una amenaza a la otra persona que está mirando por encima de su hombro, se ponen nerviosos, se sienten presionados y empiezan a cometer errores. Es totalmente normal y creo que prácticamente a todo el mundo le pasa que al ponerse a los mandos del teclado “nos volvemos más tontos”.  Pero no os dejéis engañar. Todo es simplemente una ilusión.

what-you-learn-working-as-a-programmer

En el Pair Programming, ambos desarrolladores deben estar totalmente centrados en la solución del problema, deben ser flexibles con las ideas y opiniones del otro, al final se trata de un trabajo colaborativo. Se debe rotar cada cierto tiempo, a ser posible cada 25 o 30 minutos. Dentro del periodo de trabajo, no se puede uno levantar o hacer un break. Para poder explicar estas reglas deberíamos entender el concepto de flow:  Una persona cuando está resolviendo un problema y está muy concentrado en ello, suele sufrir periodos de flow, periodos en los cuales ve tan claro lo que está resolviendo que la solución fluye, sus pensamientos y acciones están totalmente sincronizados. Este efecto, es lo que se intenta provocar de una manera sostenida mediante el Pair Programming para aumentar la productividad. El flow requiere mucho esfuerzo por nuestra parte y no puede mantenerse en el tiempo más de 25 minutos o media hora en sus niveles máximos ya que la concentración disminuye drásticamente debido al agotamiento mental. No sé si conocéis un método de administración del tiempo denominado pomodoro que se basa en el mismo principio. Digamos que cada miembro de la pareja cambia de rol cada 25 minutos para que su nivel de flow no decaiga debido a que se produce un cambio de rol y perspectiva. De esta manera se consigue mantener mayores niveles de flow y productividad a lo largo del tiempo que está haciendo Pair Programming. Tras 8 horas acabas exhausto pero con muy buen ánimo, y es que tener periodos de flow es el efecto que tiene, actúa directamente sobre el ánimo de la persona en positivo.

pomodoro

Normalmente cuando practicas Pair Programming, mejoras la disciplina y la capacidad de poder trabajar de manera colaborativa. Entiendes la importancia de la tolerancia y de que es humano equivocarse. Sin duda se hace mejor código ya que se disminuye la probabilidad de hacer malos diseños. Se aumenta la productividad debido a un flujo constante de trabajo y se mejora la moral debido a que cuando te acostumbras se trata de una experiencia mucho más agradable y amena que trabajar solos. Muchos estudios han demostrado que dos personas habituadas al Pair Programming son más de dos veces productivos y es que como en el caso de equipos se produce también un efecto de sinergia: 2+2 = 5… o bueno en este caso 1+1 = 3.

2-plus-2

Las palabras claves son disciplina, tolerancia y humildad. Pero ¿que suele ocurrir cuando se empieza? bueno aunque una pareja no es un equipo, se suelen pasar por los mismos estados de formación de un equipo: forming, storming, norming y performing. Ten en cuenta que cada uno tiene sus manías y su forma de ver las cosas. Todos tenemos nuestros pequeños egos. Algunos autores dicen que no todo el mundo puede realizar Pair Programming con todo el mundo, ya que ciertos caracteres no son nada compatibles y suelen chocar tanto que nunca se produce el efecto de flow buscado. Aunque esto sin duda puede ocurrir (y ocurre) y nunca debes forzar a los equipos a hacer Pair Programming, bajo mi punto de vista, creo que simplemente es una falta de disciplina que todo el mundo con buena actitud puede llegar a superar. Pondré algunos ejemplos de problemas que suelen darse:

  • Existe un desbalance de conocimiento, uno de ellos conoce mejor el problema, la técnica o el lenguaje. Puede que la persona de mayor conocimiento se sienta frustrada tratando de explicar cada paso que está haciendo y puede que la persona de menor conocimiento se sienta frustrada también al no poder seguir los pasos del otro y termine por desconectarse. Obviamente, no es un estado deseable de Pair Programming, ya que en este caso se está perdiendo el tiempo. Se está utilizando un estilo equivocado, se debería usar uno de los estilos de enseñanza y clarificar cual es el objetivo de la práctica. Recordad: No productividad, si enseñanza.

balanza

  • Existe diferencia extrema de carácter. Existen una serie de caracteres que suelen chocar. Debido a esto suelen producirse por norma general problemas de comunicación que suelen llevar a conflictos y que a su vez suelen llevar a no realizar el Pair Programming con la disciplina que requiere. Normalmente uno de los miembros de la pareja suele convertirse en pasivo dejando hacer el otro para que no haya problema alguno. Una de las cosas que hace el Pair Programming es acelerar el proceso de formación de equipos, haciendo más pronunciado el estado de storming en el equipo. Es un problema de conflicto y como tal es algo que se debe gestionar. Una de las posibilidades es que no hagan Pair Programming juntos, al menos por un tiempo, pero también fomentar la claridad de la técnica, sinceridad de los participantes y profesionalidad, suele funcionar. Ten presente que nunca debes forzarles.

conflictos-300x199

  • Uno haciendo otra cosa mientras el otro codifica. Por ejemplo, mirar el móvil, leer un e-mail. Falta de disciplina sin lugar a dudas. No entienden la técnica, hay que clarificarles los objetivos de la misma.
  • Mi teclado, mi tesoro. Personas muy acostumbradas a trabajar solos no pueden evitar reaccionar apoderándose del teclado en ciertos momentos, sobre todo tras la emoción de ver la solución y no tener el teclado para codificarlo, es algo instintivo. A mí me ocurría con un compañero que al que le ocurría exactamente lo mismo. Fue muy gracioso porque el teclado no paraba dar vueltas por la mesa. El caso es que si no produce ningún conflicto, quizá es mejor usar en estos casos el estilo ping pong, ya que posiblemente ambos se sientan más cómodos. Nosotros hacíamos ping pong sin duda, pero por tendencia natural y la verdad es que entre risa y risa funcionamos bastante bien. En caso de que existiera conflicto, habría que reforzarles clarificando el objetivo y la técnica y resolver las causas raíces del problema, que podría ser una diferencia de caracteres o no entender el propósito.

????????????????????????????????????????????????????????????????????????????????????

  • Estoy tecleando y no puedo escucharte”. Falta de comunicación entre ambos miembros debido a que uno de ellos es incapaz de escuchar por el motivo que sea. A mí me ocurría también y el motivo era que era incapaz de hacer dos cosas al mismo tiempo, me concentraba tanto en el problema que me aislaba sin querer…es una cuestión de disciplina y acostumbrarse. El sentido del humor y la sinceridad del compañero suelen resolver el problema por sí mismo. En caso de conflicto, tratarlo claro.
  • Haz lo que quieras…yo ya miro lo que haces”. El problema contrario, no se produce la comunicación que debería. La solución es la misma, sentido del humor y la sinceridad del compañero. En caso de conflicto, tratarlo por su puesto.

videopp

Algunos ejemplos

Una de las recomendaciones es que las parejas roten frecuentemente. Esto suele generar rechazo por parte de los desarrolladores (y de los managers) y como siempre los problemas que suelen describir para no hacerlo suelen ser de origen psicológico más que problemas reales. Hay gente que rota cuando se sienten frustrados o bloqueados, otros equipos usan timers y alarmas a intervalos estrictos. Se puede cambiar cada 1-3 días y los cambios deben ser aleatorios, pero esto sólo es una referencia ya que existen estudios que hablan de rotación cada 9 minutos con resultados interesantes. Algunos dirán que es muy poco tiempo y que cambiar de tarea a otra tarea puede hacer que la productividad a nivel de equipo baje: nada más lejos de la realidad, si no todo lo contrario. La excusa estrella es que las historias de usuario o tareas, van a durar más del tiempo estipulado para el cambio de pareja por lo que los desarrolladores “no quieren dejar un trabajo inacabado”. Además, el realizar una transferencia de conocimiento “podría llevar más tiempo”. Un argumento totalmente lógico y si ocurre esto realmente así no les fuerces. Pero ten en cuenta que el problema real que tiene el equipo en este caso es que no todo el mundo conoce el código lo suficiente y puede que tengáis tendencias a tener silos (con lo cual más motivo aún para realizar el cambio cada poco tiempo).

positions

Tened en cuenta que uno de los miembros de la pareja puede y debe quedarse en la tarea o historia de usuario y el otro miembro ser reemplazado. La transferencia de conocimiento se haría mientras hacen Pair Programming de forma natural, y el escaso retraso que pudiera haber se ve justificado por la garantía de que no haya silos en el equipo. El motivo real para no querer rotar cada poco tiempo es de origen psicológico y suele ser que la persona no tiene interiorizado que “el código es de todos, del equipo y aún tiene sensación de pertenencia individual del código que es algo muy común. Nunca les fuerces, ellos llegarán a darse cuenta por sí mismos, haz centrarse el equipo en solucionar el problema raíz, la posibilidad de tener silos, y llegarán a la misma conclusión por sí mismos.  En cuanto a las ventajas de la rotación, enumero algunas:

  • No habrá silos de conocimiento, con lo cual, cada uno de los miembros del equipo podría trabajar en cualquier historia de usuario o tarea.
  • Durante esta práctica se hacen pair reviews de forma natural, por lo que garantizas la calidad del código.
  • Todo el mundo trabaja de la misma manera y habla el mismo idioma. Tienen el mismo conocimiento tácito. Fomenta la alineación del equipo.
  • Mejora las relaciones entre los miembros del equipo, acelera de forma natural el paso por los estados de formación del equipo.
  • Se mantiene la motivación, la colaboración, la sinergia.
  • Reduce la cantidad de defectos y aumenta la calidad de diseño
  • Apoya la auto-disciplina.

isla_desierta

En definitiva, si pensabas que la programación en parejas era simplemente dos desarrolladores en un mismo ordenador, nada más lejos de la realidad. Se trata de una técnica de maximizar varios aspectos del equipo, entre ellos la calidad y la productividad. Los problemas suelen venir en gran parte por la falta de técnica en la ejecución. Cuando empecé a tocar la guitarra, me resultaba muy tedioso y no veía apenas mejoras. En ese momento podría haber pensado que la guitarra no podría servir jamás para tocar música. Sin embargo mi problema, era que no tenía la técnica suficiente. Tocar una grandiosa melodía, tiene su sacrificio y aprendizaje, pero sólo alcanzamos el éxito combinando y dominando los mejores instrumentos a tu alcance: la práctica lleva a la perfección.

PDFicono EXTENDIDO

REFERENCIAS:

[1] Pair Programming anti-patterns
[2] Normal Pair Programming session
[3] Programación por pares – Preguntas frecuentes
[4] Pair Programming is kryptonitel