Chemaclass - pair-programming

Pair Programming Efectivo

2024-03-28T00:00:00+00:00

¿Qué es el pair programming? Dos personas trabajando juntas en el mismo problema, al mismo tiempo.

No se trata de que una persona muestre sus habilidades frente a otra, ni de que una persona tenga miedo de cometer errores debido al síndrome del impostor.

Cada persona tendrá un rol:

Navegador: prestará atención al panorama general; ej: arquitectura, relación entre colaboradores, diseño de objetos, etc.
Conductor: prestará atención a los pequeños detalles; ej: naming, convenciones de código, sintaxis de escritura, diseño de objetos, etc.

La pareja podría, y debería, intercambiar roles ocasionalmente; ej: cada X commits pusheados, cada 10 min,… depende de ellos.

El pair programming no debería considerarse una práctica solo para “seniors” hacia juniors, sino independientemente del nivel de experiencia de los miembros del equipo.

Se trata del flujo de colaboración, la comunicación de calidad, la ausencia de sentirse juzgado y la idea de dar la bienvenida a la vulnerabilidad con tus compañeros, sabiendo que te apoyarán y ayudarán.

Se trata de desafiarse constantemente mutuamente, buscando la solución más pragmática mientras se mantiene simple. Siempre buscando retroalimentación rápida al hablar entre ustedes, pero también sobre la solución que acordaron implementar y su dirección.

Se trata del bucle de retroalimentación corto, rápido e inmediato mientras hablas con tu compañero, quien revisa tu código sobre la marcha. Puedes guiar como navegador o ayudar al conductor a validar sus ideas en un panorama más amplio.

Se trata de la atmósfera constante de compartir conocimiento por defecto, reduciendo bus-factors y áreas de conocimiento aislado al máximo. Aumentando el enfoque al tener dos mentes trabajando en la misma tarea simultáneamente.

Se trata de cohesión de equipo y afilar el sentimiento de que pertenecemos. Cuando entendemos las fortalezas y debilidades de cada uno, nos daremos cuenta de cuánto podemos ayudarnos a crecer mutuamente.

¿Cómo puedes practicar pair programming? #

El pair programming puede hacerse de diferentes maneras:

Puedes empezar y terminar una tarea con pairing. Puedes limitarlo a 30, 60, 90 minutos. De cualquier manera, se recomienda tener pausas en el medio - Pomodoro.
Puedes empezar la tarea juntos y parar cuando uno de tus compañeros se sienta lo suficientemente confiado para continuar solo.

Depende del equipo, y de la tarea en contexto, decidir cuándo y cómo aplicar pairing para sacar lo mejor de ello.

Esto no significa que debas trabajar constantemente “sin importar qué” en pareja. No se trata de crear reglas; por el contrario, se trata de abrazar esta práctica hasta el punto de que te sientas confiado para elegir cuándo y cómo usarla para sacar lo mejor de ella.

El pair programming podría convertirse en una de las mejores herramientas en la caja de herramientas de tu equipo para las interacciones diarias. No porque lo hayas leído en algún lugar, sino por los beneficios que tú y tu equipo encontrarán.

Patrones Comunes #

Diferentes estrategias para pairing efectivo #

Driver-Navigator: Una persona está conduciendo el código (con el teclado), enfocándose en el aspecto de detalle de la tarea en sí. La otra es navegadora (sin teclado), teniendo una imagen más abstracta de la tarea en mente.
Ping-Pong: Cambio frecuente de roles driver-navigator en pequeñas interacciones, ej: cada N minutos, cada N commits, etc.
Backseat driver: El navegador se involucra activamente con el conductor.
Tourist guide: El navegador aprende pasivamente con el conductor.

Anti-patrones mientras haces pairing #

The silent partner: El navegador no participa, está en silencio.
The solo act: El conductor ignora todas las aportaciones del navegador.
Distracted pair: La pareja no se enfoca en el problema a resolver.
The Dictator: Una persona está diciendo qué hacer, ignorando las aportaciones del otro.
Philosophical pair: La pareja está haciendo bikeshedding en temas irrelevantes.
The code war: La pareja no llega a un acuerdo y comienza una guerra innecesaria, que desperdicia tiempo y esfuerzo.

¿Quieres más? Mira esto: Learning Through KATAS

La conclusión #

El pairing no es una regla que imponer, es una herramienta a la que recurrir. Úsalo cuando la tarea es compleja, el conocimiento está aislado o lo que está en juego es importante. Sáltalo cuando el trabajo es trivial. El objetivo nunca es “hacer siempre pairing”, es mejor software y un equipo más fuerte. Elige una tarea real esta semana, hazla en pareja e intercambia roles a menudo. Los beneficios aparecen más rápido de lo que esperas.

Pull Requests vs Pair Programming

2021-04-01T00:00:00+00:00

Hablemos de los beneficios de los Pull Requests y el Pair Programming, y mis reflexiones sobre estos después de algunos años de experiencia con ellos.

Pull Requests #

Un Pull Request (PR) es una forma de mostrar tus cambios de código para que se comparen fácilmente con el código existente. Es parte de un flujo de trabajo que ayuda a compartir conocimiento sobre los cambios que se hacen en el sistema.

Un Pull Request es el momento donde pides a tus compañeros que revisen y examinen tus cambios de código.

Normalmente, también se usa:

Para discusiones sobre estilo de código.
Para detectar bugs potenciales.
Para discusiones de arquitectura o diseño una vez que la solución está hecha.

Los Pull Requests no son la mejor herramienta para todo #

El problema es que los PRs suelen estar listos cuando la funcionalidad o bug ya está terminado, en la última etapa del desarrollo. Un PR es una “propuesta de cambio ya hecha para fusionar en el sistema actual”.

El concepto de “Draft PR” existe para indicar que el PR aún no está listo para fusionar, pero ese es otro tema.

Los Pull Requests son una de las mejores herramientas para compartir conocimiento sobre cambios en el sistema, pero a veces se usan mal:

Discusiones sobre estilo de código. El estilo no debería discutirse en un PR. Ya debería haber un CI ejecutando un linter. Si quieres cambiar algo, proponlo en el linter, no en un PR aleatorio.
Detectar bugs. Los bugs y comportamiento esperado deberían cubrirse con tests automatizados. El desarrollador es el primer responsable.
Discusiones de arquitectura o diseño. Cuando una solución está desarrollada y lista para revisión, es difícil “deshacerla” y reescribirla. “¿Por qué lo harías? Ya está hecho y funciona.”

Tener a alguien extra revisando decisiones de diseño puede ayudar, pero podríamos haber resuelto posibles desacuerdos antes.

¿Cuál debería ser el propósito de un Pull Request? #

Compartir conocimiento sobre los cambios propuestos con el equipo.
Asegurar que el equipo está alineado con los múltiples cambios que se envían cada día. Sí, puede incluir verificar el diseño, pero… ¿y si ya es demasiado tarde?

Pair Programming #

El “Pair Programming” puede entenderse de varias formas: pair thinking, roles conductor-navegador, live coding… En realidad es más sencillo de lo que parece:

Miras y ayudas a la otra persona a escribir código, o
Escribes mientras tienes otro par de ojos mirándote y ayudándote.

El Pair Programming ayuda al equipo a trabajar juntos.

El pair programming es trabajar con un cerebro extra y otro par de ojos. La clave es construir un contexto donde ambos compartan el mismo objetivo para encontrar la mejor solución posible, aprendiendo el uno del otro. No se trata de dar con la mejor solución desde el principio. Se trata de hacerlo funcionar, compartir ideas y mejorar juntos. Luego ya refactorizas y limpias el código.

El Pair Programming es una revisión de código continua #

Los Pull Requests son una forma asíncrona de compartir cambios de código, mientras que el Pair Programming es totalmente síncrono porque sucede al mismo tiempo.

Los Pull Requests y el Pair Programming no son excluyentes, pueden coexistir. Son herramientas, y hay que elegirlas con criterio según nuestros objetivos.

El miedo más común que he visto al animar a hacer Pair Programming es la timidez. A algunas personas no les gusta tener ojos encima mientras programan:

Miedo a no saber qué programar o por dónde empezar.
Miedo a que otros se rían de sus soluciones.
Miedo a no tener éxito en público.
Miedo a no poder desarrollar la solución esperada por múltiples razones: malentender la tarea o falta de conocimiento.
Miedo a cambiar de opinión frente a otros.
Miedo a discutir y tomar decisiones en voz alta.
Miedo a estar en desacuerdo con otros.

Después de varios años de experiencia en este tema #

El patrón que rechaza el Pair Programming es básicamente el miedo a salir de tu zona de confort. Y viene de no entender qué es realmente el Pair Programming.

No se trata de presumir ni de ser juzgado, sino de ser transparente (mostrar tus habilidades tal como son) y mejorar como equipo.

Programar es un proceso iterativo que requiere refactorizar continuamente nuestra forma de pensar. Programar con otra persona (con otra forma de pensar) ayuda al equipo a sacar lo mejor de cada uno y a descartar malos hábitos.

El Pair Programming no tiene que usarse siempre ni para todo. Es una herramienta flexible: puedes elegir cómo, cuándo y por qué.

Una regla personal: antes de empezar tareas que tocan múltiples módulos o reglas de negocio complejas, haz un Pair Thinking rápido con un colega más experimentado en ese área.

Todo depende de un contexto y personas particulares: los desarrolladores, las parejas, las tareas, el estado de ánimo.

¿Todavía incómodo con el Pair Programming? #

Si aún te sientes incómodo con alguien a tu lado mientras programas, quizás no estés contento con tu propio código o con el proceso que sigues. Mi forma favorita de trabajar esto es practicar por mi cuenta y mejorar mis habilidades como desarrollador.

Crea y juega con tus propios proyectos personales.
Trabaja en katas de código por tu cuenta y con otros.

La práctica hace al maestro.

Mantén las pull requests, añade pair programming #

No me malinterpretes, los Pull Requests son geniales. Sigue haciéndolos.
La colaboración en equipo es esencial. El Pair Programming apunta a esto.
El Pair Programming anima al equipo a trabajar juntos proactivamente.
No tengas miedo de programar mientras tienes ojos a tu alrededor. Haz preguntas cuando algo no esté claro. Pide ayuda cuando no sepas cómo resolver algo.

Está totalmente bien no saber todo. Lo más importante es saber cómo trabajar juntos.

Compartiendo tus Parches de Git

2020-12-01T00:00:00+00:00

Descubre otra forma de compartir sugerencias con tu equipo de desarrollo.

Imagina esta situación #

Estás revisando un Pull Request (PR), y ves algunas mejoras menores o sugerencias que te gustaría compartir con el autor. Podrías escribir algunos comentarios, y normalmente, eso sería suficiente.

Imagina que para transmitir tu “idea completa” necesitarías cambiar algunos archivos porque simplemente comunicar la imagen completa acabará en un comentario enorme que podría no ser tan claro como podría ser.

¿Qué posibilidades hay aparte de solo comentarios en un PR? #

Bueno, hay múltiples opciones. La clave es ser consciente de ellas y usarlas sabiamente dependiendo de la prioridad de la tarea y los cambios en sí:

Como ya se mencionó, escribir un comentario como retroalimentación es una buena idea por defecto, pero no la única.
Siempre podemos hacer algo de pair-thinking, hablar en cualquier momento. La comunicación siempre es buena para aclarar la posible incertidumbre.
Compartir tus parches de git es otra buena opción.

¡Git diff al rescate! #

¿Y si tú (como revisor) pudieras compartir tu idea sin ningún commit o comentario en el PR, pero compartiendo tus cambios directamente con el autor?

Bueno, eso es realmente posible y muy fácil. Como ya sabes, el comando git diff te da las diferencias entre dos ramas cualesquiera.

git diff origin develop > ../my-origin-develop.patch

Lo que estamos haciendo aquí es redirigir la salida del comando diff a un archivo (también conocido como: parche), para poder compartir esa salida con cualquier otro compañero de equipo.

¿Y ahora qué? #

Bueno, teniendo ese archivo de parche, es bastante fácil aplicar esos cambios en tu máquina local sin hacer ningún commit:

git apply ../my-origin-develop.patch

Aplicar este parche simplemente cambiará tu sistema local de la misma manera que se creó el parche.

“Cómo hacerlo” por pasos #

Dividamos las responsabilidades en dos: el creador del parche y su usuario:

El creador del parche: la persona que creará el parche #

# Cambia a esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Haz tus sugerencias y cambios en la rama objetivo
# Genera el archivo de parche usando el comando diff
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Comparte el archivo de parche con el autor del PR

El usuario del parche: la persona que verá el parche #

# Asegúrate de estar en esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Aplica el archivo de parche
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

Referencias #

Documentación oficial de “git apply”

Programación Extrema Explicada

2020-03-05T00:00:00+00:00

Definición #

Extreme Programming (XP) es un framework ágil que busca producir mejor software y mejor calidad de vida para el equipo de desarrollo. Es el más específico de los frameworks ágiles en cuanto a prácticas de ingeniería.

Valores #

Los cinco valores de XP son comunicación, simplicidad, feedback, coraje y respeto.

Comunicación #

El desarrollo de software es un deporte de equipo. Depende de la comunicación para transferir conocimiento entre los miembros. XP enfatiza la comunicación cara a cara, preferiblemente con una pizarra a mano.

Simplicidad #

Simplicidad significa “¿qué es lo más simple que funcionará?” El objetivo es evitar el desperdicio y hacer solo lo necesario. Mantener el diseño lo más simple posible facilita el mantenimiento y la revisión. También significa abordar solo los requisitos que conoces ahora, sin intentar predecir el futuro.

Feedback #

Con feedback constante sobre el trabajo previo, los equipos identifican áreas de mejora y ajustan sus prácticas. El equipo construye algo, recoge feedback sobre el diseño e implementación, y ajusta el producto en consecuencia.

Coraje #

Kent Beck definió el coraje como “acción efectiva ante el miedo”. Necesitas coraje para:

Plantear problemas organizacionales que reducen la efectividad del equipo.
Dejar de hacer algo que no funciona y probar algo diferente.
Aceptar y actuar según el feedback, aunque sea difícil de escuchar.

Respeto #

Los miembros del equipo necesitan respetarse mutuamente para comunicarse bien, dar y recibir feedback de forma constructiva, y trabajar juntos en diseños y soluciones simples.

Principios #

Humanidad #

Los seres humanos desarrollan software. El libro menciona 5 cosas que necesitan los desarrolladores para crecer: seguridad básica, logro, pertenencia, crecimiento e intimidad.

La magia de los grandes equipos es que, una vez que desarrollan confianza, sus miembros se sienten libres de ser más ellos mismos.

Economía #

El software cuesta dinero. Alguien pagó o invirtió en él.

Asegúrate de que lo que haces tenga valor de negocio y sirva a sus necesidades. Resolver primero la necesidad más prioritaria maximiza el valor del proyecto.

Cuanto antes el software genere dinero, antes el desarrollo será valioso.

Beneficio Mutuo #

El beneficio mutuo en XP busca actividades que beneficien a todos los involucrados: a mí ahora, a mí después, y a los clientes.

El libro presenta 3 formas de comunicarte con el futuro:

Escribo tests automatizados que me ayudan a diseñar e implementar hoy. Los dejo para que los futuros programadores también los usen.
Refactorizo para eliminar complejidad accidental. Menos defectos y código más fácil de entender para quien venga después.
Elijo nombres de un conjunto coherente de metáforas. Acelera mi desarrollo y hace el código más claro para nuevos programadores.

Auto-Similaridad #

Copiar la estructura de una solución a un nuevo contexto.

Por ejemplo, la estructura básica del desarrollo: escribes un test que falla y luego lo haces funcionar. Esta estructura opera a todas las escalas. Ojo: es un buen comienzo, pero no siempre funciona.

Mejora #

Haz lo mejor que puedas hoy, pero esfuérzate por hacerlo mejor mañana. XP brilla aquí: se trata de mejorar siempre.

Pon la mejora a trabajar sin esperar la perfección. Encuentra un punto de partida, comienza y mejora desde ahí.

Diversidad #

Los equipos necesitan personas de diferentes orígenes, experiencias y actitudes. Así tienen diferentes formas de pensar y resolver problemas.

Los programadores deberían trabajar juntos en el problema y valorar ambas opiniones.

Reflexión #

Los buenos equipos reflexionan después de la acción, regularmente. Piensan sobre por qué y cómo están trabajando.

¿Por qué tuvimos éxito? ¿Qué deberíamos seguir haciendo?
¿Por qué fallamos? ¿Qué podemos hacer mejor?

Aunque todo parezca perfecto, siempre hay espacio para mejorar:

¿Por qué las cosas parecen perfectas? ¿Qué hacemos bien? ¿Qué podemos mejorar?

Flujo #

El flujo en desarrollo de software es entregar valor constante participando en todas las actividades simultáneamente. No entregues software en grandes porciones. Despliega incrementos más pequeños con más frecuencia.

Oportunidad #

Aprende a ver los problemas como oportunidades para aprender y mejorar.

Parte de ser extremo es elegir conscientemente transformar cada problema en una oportunidad: para el crecimiento personal, profundizar relaciones y mejorar el software.

Redundancia #

Los problemas difíciles deberían resolverse de múltiples maneras.

El costo de la redundancia se paga con creces por los ahorros de evitar un desastre.

Fracaso #

A veces no sabes qué camino tomar. Prueba las ideas que tienes, aunque fallen. El fracaso no es desperdicio, sino aprendizaje.

Cuidado con la trampa de discutir o pensar eternamente sin hacer nada.

Cuando no sabes qué hacer, arriesgarte al fracaso puede ser el camino más corto hacia el éxito.

Calidad #

Los proyectos no van más rápido bajando la calidad. Suele ser al revés. Resulta en entregas más tardías y menos predecibles por el tiempo dedicado a corregir bugs.

Aumentar la calidad suele resultar en entregas más rápidas.

La preocupación por la calidad no es excusa para la inacción. Si no conoces una forma limpia de hacer algo que hay que hacer, hazlo lo mejor que puedas. Si conoces una forma limpia pero tomaría demasiado tiempo, haz el trabajo tan bien como el tiempo te permita. Resuélvelo de forma limpia después.

Pasos Pequeños #

Da pasos pequeños. Hacer grandes cambios de golpe es peligroso. Las personas y equipos pueden dar muchos pasos pequeños y parecer que avanzan rápido.

Los pasos pequeños reconocen que su sobrecarga es mucho menor que cuando un equipo retrocede desperdiciando cambios grandes abortados.

Responsabilidad Aceptada #

La responsabilidad no puede asignarse; solo puede aceptarse. Si alguien intenta darte responsabilidad, solo tú puedes decidir si la aceptas o no.

Prácticas #

Se pueden hacer de forma aislada, pero muchos equipos han descubierto que algunas prácticas refuerzan a otras. Hacerlas juntas elimina los riesgos típicos del desarrollo de software.

Sentarse Juntos #

La comunicación es uno de los cinco valores de XP. Haz que tu equipo se siente junto en el mismo espacio sin barreras como paredes de cubículos.

Equipo Completo #

Incluye personas con todas las habilidades y perspectivas necesarias para que el proyecto tenga éxito.

Espacio de Trabajo Informativo #

Configura el espacio para facilitar la comunicación cara a cara, permite algo de privacidad cuando la necesiten, y haz el trabajo transparente para el equipo y las partes interesadas.

Trabajo Energizado #

Eres más efectivo en el desarrollo de software cuando estás enfocado y libre de distracciones.

Programación en Parejas #

Todo el software de producción lo desarrollan dos personas en la misma máquina. Dos cerebros y cuatro ojos son mejores que un cerebro y dos ojos. Obtienes revisión de código continua y respuestas más rápidas a problemas que podrían bloquear a una persona sola.

Los equipos que usan programación en parejas descubren que mejora la calidad sin tomar el doble de tiempo. Resuelven problemas más rápido y se mantienen más enfocados, escribiendo menos código para lograr lo mismo.

Los programadores en pareja:

Se mantienen mutuamente en la tarea.
Hacen lluvia de ideas sobre mejoras al sistema.
Clarifican ideas.
Toman la iniciativa cuando el compañero está atascado, reduciendo la frustración.
Se hacen mutuamente responsables de las prácticas del equipo.

La programación en parejas es un diálogo entre dos personas programando simultáneamente (analizando, diseñando y probando) e intentando programar mejor.

Si necesitas privacidad y tiempo para trabajar en una idea, adelante. Necesitamos tanto compañía como privacidad. Rota parejas frecuentemente y toma descansos: el pairing puede ser agotador, pero es gratificante.

Historias #

Describe lo que el producto debería hacer en términos significativos para clientes y usuarios. Son descripciones cortas de cosas que los usuarios quieren hacer. Sirven para planificar y como recordatorios para conversaciones más detalladas.

Dale a las historias un título corto y una descripción. Escríbelas en tarjetas y ponlas en una pared visible.

En XP las historias se estiman muy temprano. Esto hace que el equipo piense en cómo obtener el mayor retorno de la pequeña inversión.

Ciclo Semanal #

El Ciclo Semanal es una iteración. El equipo se reúne el primer día de la semana para reflexionar sobre el progreso. El cliente elige las historias que quiere entregar esa semana, y el equipo determina cómo abordarlas.

La idea es producir algo para mostrar al cliente y obtener feedback.

Build de Diez Minutos #

El objetivo es construir automáticamente todo el sistema y ejecutar todos los tests en diez minutos.

Integración Continua #

Los cambios de código se prueban inmediatamente al añadirse al código base. El beneficio: detectas y corriges problemas de integración antes.

Requiere disciplina extra y depende mucho del Build de Diez Minutos y el Desarrollo Test-First.

Programación Test-First #

Escribe un test automatizado que falle antes de cambiar cualquier código.

El libro menciona 4 problemas que aborda:

Expansión del alcance: Es fácil dejarse llevar y poner código “por si acaso”. Al declarar explícitamente lo que el programa debe hacer, te das un foco. Si quieres ese otro código, escribe otro test después.
Acoplamiento y cohesión: Si es difícil escribir un test, tienes un problema de diseño, no de testing. El código débilmente acoplado y altamente cohesivo es fácil de probar.
Confianza: Es difícil confiar en el autor de código que no funciona. Al escribir código limpio que funciona y demostrar tus intenciones con tests, das a tus compañeros razones para confiar en ti.
Ritmo: Es fácil perderse horas programando. Con test-first, siempre sabes qué hacer: escribir otro test o hacer que el test roto funcione. Se desarrolla un ritmo natural: test, código, refactorizar, test, código, refactorizar.

Diseño Incremental #

Invierte en el diseño del sistema todos los días.

Haces un poco de trabajo inicial para entender el diseño general, y luego profundizas en los detalles cuando entregas características específicas.

Este enfoque reduce el costo de los cambios y te permite tomar decisiones de diseño basándote en la información más actual.

Roles #

XP especifica prácticas, pero no establece roles específicos. Según la fuente, o no hay orientación, o hay descripciones de cómo los roles tradicionales se comportan en proyectos XP.

El Cliente #

Responsable de tomar todas las decisiones de negocio del proyecto.

Se asume que es una sola persona, pero la experiencia muestra que una persona no puede proporcionar toda la información de negocio de un proyecto.

El Desarrollador #

Como XP no necesita definición de roles, todos (excepto el cliente y un par de roles secundarios) se llaman desarrolladores. Son responsables de realizar las historias identificadas por el Cliente.

El Rastreador #

Su propósito es llevar el seguimiento de métricas relevantes para rastrear el progreso e identificar áreas de mejora.

El Coach #

Usualmente un consultor externo (o alguien de otra parte de la organización) que ha usado XP antes. Ayuda a mentorear al equipo en las prácticas XP y a mantener la autodisciplina.