La Integración continua: Netscape, la NASA, XP y dos mayordomos

En el artículo “La Integración Continua reduce el riesgo en proyectos software” comentábamos un poco el contenido del artículo de Martin Fowler que sacó en el 2005 sobre este mismo tema. En este artículo Fowler explicaba que la CI tenía un beneficio directo en los proyectos software reduciendo el riesgo, y  tuvo el efecto  añadido de  ayudar a que se difundiera con aún más fuerza.  Haciendo un guiño nostálgico a un anuncio del 2001 que decía “Si no sabes programar no sabes informática”, hoy en día “si no practicas la integración continua, no desarrollas software”. Volviéndome a ponerme nostálgico, ya lo decían en un anuncio de los 80: “la informática es mucho más que unas palabras”. Porque desarrollar software es mucho más que sentarse durante horas a escribir líneas de código.

programador3

Los que conozcan Extreme programming me dirán, “integración continua es una de las prácticas de XP”. Sí que lo es, es una de las 12 prácticas de XP, pero ¿cómo fue su evolución? y ¿a quién se le ocurrió por primera vez que debían hacerse integraciones automáticas lo más a menudo posible para reducir el riesgo en los proyectos? ¿Un día se levantó Kent Beck de la cama y dijo: “¡¡¡Eureka!!!”? y uno de los doce mandamientos será: integración continua. Nada más lejos de la realidad.

Os Dez Mandamentos 1

La CI fue propuesta y nombrada por primera vez en 1991 por Grady Booch en su método (Método Booch). En este caso Booch no hablaba en ningún caso de integrar varias veces al día. Grady Booch es conocido por desarrollar UML junto con James Rumbaugh. En 1991/94 desarrolló el método Booch. Se trataba de una técnica usada en ingeniería software para el diseño de objetos (predecesor de UML y RUP). Este método hablaba de uso de objetos, métricas, QA, patrones de diseño, formalismo, madurez de procesos y una notación robusta. Habla de sacar releases de arquitectura hasta llegar al sistema final (evolutivos)…si, es el precursor de RUP también, evidentemente.

image-83472-full

En los años 90 del siglo XX se producían dos temas importantes para el surgimiento de la integración continua. Uno fue que contrataron a Kent Beck (uno de los creadores de XP) en Chrysler con el objetivo de llevar un proyecto (El C3) de gestión de nominas, en el cual los requisitos eran un gran problema (¡¡¡no me lo esperaba!!!…). Parece ser que el sistema legacy de nóminas era bastante infumable (más de lo habitual supongo), se trataban de varias aplicaciones, cada uno de su padre y de su madre, que hacían lo mismo en algunos casos pero de forma diferente y donde los requisitos, como no, brillaban por su ausencia. El primer año que sacaron la primera release fue muy duro. Tan duro,  que  cliente, punto de contacto de Chrysler con el proyecto, tuvo que pedir la baja por estrés.

liberar-estress

Por otro lado, mientras se cocía la historia de Chrysler y XP, ocurre una historia paralela. Los ingenieros de calidad de Netscape, tuvieron una gran ocurrencia. Estos llegaron a la conclusión de que sería bueno poder realizar construcciones del código automáticamente de forma periódica. Tenían bastantes problemas con CVS (que acaba de surgir en los 90), ya que cada vez que iban a sacar una release, el código no compilaba correctamente: “en mi máquina funciona” decían los desarrolladores.

fz1t19.jpg

Se pusieron manos a la obra y crearon una herramienta muy sencilla llamada Tinderbox que les permitía realizar una construcción diaria de su software de forma que sabían en el mismo día si había habido un problema con la construcción del mismo (la build). En poco menos de un año, se dieron cuenta que bajando la cadencia de los builds, eran capaces de saber cuál había sido el problema de integración que había roto la build (a menos tiempo, menos commits realizados y más fácil detectar el problema de fallo). Progresivamente bajaron la cadencia hasta  realizar builds automáticos cada hora. Cuando en 1998 el código de Netscape es liberado, también es difundida su forma de trabajo a la comunidad de open-source. De esta manera la construcción frecuente de tu código de forma automática pronto se convirtió en una buena práctica en el mundillo del desarrollo software.

best-practices.jpg

XP lleva las mejores prácticas a niveles extremos. Por ejemplo la práctica de hacer test antes de desarrollar fue usada por la NASA en el programa Mercury Space por primera vez para tarjetas perforadas en 1960. XP la llevo al extremo con TDD. Aunque Kent beck no se considera a sí mismo el creador de Test Driven Development, fue el que implemento SUnit, un framework de tests unitarios para Smalltalk que fueron las bases de la familia xUnit (conjunto de frameworks basados en sus premisas como nUnit, phpUnit, junit, MsUnit, etc). Este framework se pensó para realizar TDD basándose en ideas de Gerard Weinberg y Leeds, Herbert D. en su libro (Computer Programming Fundamentals – 1960). Sí, he de afirmar que es curioso que en la portada original Weingberg no aparezca. Pero eso es otra historia.

51+GmuMoPYL._SX331_BO1,204,203,200_

Otra de las prácticas que se lleva al extremo es la integración continua. Kent Beck tomó la idea de Booch, las nuevas buenas prácticas de los build automáticos con las ideas de los servidores de builds automáticos emergentes y la inclusión del framework de test automáticos que había creado para dar forma a una de las prácticas de XP: Si aquellos tipos de Netscape podrían hacer construcciones del código cada hora, ¿por qué no íbamos a poder hacerlos en cada commit y además pasar automáticamente baterías de test automáticamente con sUnit? En 1999 Kent beck publica el primer libro sobre XP donde incluye el concepto como una de sus 12 prácticas.

circles.jpg

La integración continua ha ido evolucionando a medida de que han ido apareciendo nuevas tecnologías y herramientas. Si tenemos que pensar en cual fue la primera herramienta construida para este propósito, podemos pensar que fue Cruise Control que surgió en el 2001 como servidor de builds extensible. Esta herramienta estaba pensada para realizar builds automáticos usando Ant o Maven. Funcionaba (y funciona) a través de plugins que extendían su funcionalidad. Se trata de una herramienta gratuita y open-source.  Existe una herramienta para .NET similar denominada Cruisecontrol.NET que aparece en el 2003 con su versión 0.3.1 pero no es hasta 2005 que aparece la primera versión 1.0 estable. Es decir, que la integración continua basada en herramientas específicas (no el concepto como tal), tampoco es tan lejano. Fue cuando se estrenó “Batman begins”.

Batman-Begins-batman-555782_1024_768.jpg

Hudson es otra herramienta de integración continua escrita en Java que se ejecuta en un Apache Tomcat o en el servidor de aplicaciones GlassFish. Trabaja con CVS, Svn, Git y clearcase, y puede ejecutar Apache Ant y Maven así como procesos Windows. Hudson surgió en 2008 y se convirtió en una alternativa a Cruise control y otros servidores de builds de código abierto.  El desarrollador principal de Hudson fue Kohsuke Kawaguchi que actualmente es empleado de Sun Microsystems. Si dejas a un montón de desarrolladores software el código de una herramienta como esta, pasa lo que pasa: crean una comunidad y la llevan “hasta el infinito y más allá”.

kohsuke.jpg

Cuando más adelante Oracle compró Sun, este declaró que quería registrar el nombre de Hudson y desarrollar una versión comercial. Esto enfadó mucho a la comunidad de desarrollo de Hudson, la cual decidió, junto con Kawaguchi hacer un fork del código de Hudson y llamarlo Jenkins en 2011 (ambos son nombres típicos de mayordomos). Al final Oracle se da por vencido y en 2012 dona Hudson a la fundación Eclipse. En 2013 llevan muchos commits de Jenkins a Hudson. Lo que decía yo… “hasta el infinito y más allá”.

jenkins vs Hudson java

El caso es que los conceptos han cambiado poco desde final del siglo XX, ya que siguen siendo prácticamente los mismos. Si han aparecido nuevos, es porque han aparecido herramientas que ahora lo permiten y anteriormente no, o no con la misma facilidad. De la integración continúa se pasa a la entrega continua y de ahí al despliegue automático en producción. Hoy en día existen muchas herramientas y plugins desarrollados que están trayendo nuevos conceptos y capacidades de automatización, o quizá ya no tan nuevos en el momento de publicación de este post. Algunas organizaciones, hoy en día, son lo suficientemente maduras para automatizar tanto el desarrollo software y las pruebas, que con cada commit despliegan directamente en los servidores de producción  con seguridad (pocas son) (continuous deployment). Pero eso amigos, eso, es otra historia.

continuos deployment vs delivery.jpg

PDFicono EXTENDIDO

REFERENCIAS:

[1] Continuous Integration – Martin Fowler
[2] Continuous delivery  – Martin Fowler
[3] Extreme Programing Explanined:Embrace change – Kent Beck

Anuncios

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