Chemaclass - xp

¿Qué Mata la Agilidad?

2024-05-30T00:00:00+00:00

Docenas de documentos y hojas de cálculo, reuniones tras reuniones, y sin embargo sin mucho impacto, resultan en desalineaciones del equipo, descubiertas demasiado tarde.

Cómo gestionamos una organización define su calidad. Una excelente gestión es crucial para evitar la trampa del Waterfall si buscamos construir un entorno Agile. Pero ¿por qué querríamos eso? ¿Qué hay de malo en la forma en que ya trabajamos?

Si ya estás feliz con cómo tú y tu equipo trabajan juntos, está bien. Sin embargo, ¿qué hay de reevaluar cómo trabajas para buscar mejoras potenciales?

Me refiero a evaluar tu sistema y cómo tú y las personas a tu alrededor actúan dentro de él. Lo que funcionó hace meses o años podría diferir de lo que podríamos descubrir hoy, como parte de la mejora continua.

No me gusta la política en el lugar de trabajo, donde cada equipo va a lo suyo en lugar de tener una dirección compartida más grande. Esto resulta en trabajo diario lleno de miedo desde arriba, pasado a las personas de abajo, manteniendo un ambiente de trabajo no saludable. Game of Thrones es genial como serie de ficción, pero no algo con lo que lidiar en el negocio diario.

Agile nació precisamente como respuesta al desperdicio excesivo generado por la política y la microgestión organizacional.

Controlar y el “rendimiento lento” necesitaba un enfoque más flexible. Cuando las personas adoptan una mentalidad fija, resisten el cambio, temen al fracaso y priorizan procesos rígidos y jerarquías. Esto entra en conflicto con las ideas centrales de Agile de abrazar el cambio, entrega continua con desarrollo iterativo, planificación flexible y fomentar la colaboración e innovación.

Una mentalidad fija lleva al miedo a la experimentación y una reticencia a desafiar el statu quo, reduciendo el progreso y el potencial de aprendizaje y crecimiento.

¿Qué mata la agilidad? #

Mentalidad fija: Resistencia al cambio, miedo al fracaso y priorizar procesos rígidos sobre aprendizaje y adaptación estrangula la innovación y flexibilidad.
Burocracia excesiva: Procesos complejos y documentación excesiva ralentizan la toma de decisiones y la capacidad de respuesta.
Microgestión: Liderazgo demasiado controlador socava la autonomía del equipo.
Falta de colaboración: Mala comunicación y trabajo en equipo dificultan el progreso.
Bucles de retroalimentación inefectivos: Impiden ajustes y mejora continua.
Miedo a la experimentación: Una cultura que castiga el fracaso desalienta la experimentación y el aprendizaje de errores.
Procesos inflexibles: Adherencia estricta sin adaptarse a las necesidades del proyecto.
Objetivos desalineados: Prioridades conflictivas reducen la eficiencia.
Falta de apoyo del liderazgo: Sin respaldo de la alta dirección, las iniciativas Agile pueden tener dificultades para obtener los recursos y el compromiso necesarios.
Malas prácticas técnicas: Descuidar la excelencia técnica y el buen diseño puede llevar a una base de código frágil que es difícil de adaptar y extender.

¿Qué puedes hacer al respecto? #

Aprende los básicos de Extreme Programming (XP) y Lean Software Development.

XP: Enfocado en prácticas de desarrollo de software y excelencia técnica, con prácticas específicas como pair programming y Test-Driven Development (TDD).
Lean: Toma un enfoque más amplio, enfocándose en eliminar desperdicio, optimizar flujo y mejorar procesos en toda la organización.

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.

Despliegues los Viernes

2024-02-25T00:00:00+00:00

He escuchado múltiples veces, de varias personas, la idea de pánico hacia desplegar los viernes. ¿Qué tan buena es esa idea de prohibir el día antes del fin de semana entregar nuevo valor a nuestros clientes?

El argumento principal a favor de NO desplegar el viernes se basa en la idea de que “deberíamos ser paranoicos” con nuestro software y que podría fallar cuando lo tocamos. Entonces, “deberíamos asumir” lo peor cada vez que desplegamos una nueva versión de nuestro sistema.

Sin embargo, el factor crítico aquí es ¿Por qué? ¿Por qué no deberíamos desplegar los viernes? ¿Está bien tener miedo de nuestro propio sistema de software, que vivimos en un pánico constante de romperlo el día después de haber hecho un despliegue? ¿Cuánto impacto deberían tener nuestras releases? ¿Cómo podemos asegurar que el despliegue no romperá el sistema en vivo?

Tus pipelines de Integración Continua/Entrega Continua, pruebas end-to-end y otros tipos de tests implementados, políticas de escalado automático, un sandbox de staging previo para realizar incluso pruebas manuales si es necesario, etc., determinarán la seguridad y confianza para cualquiera de tus releases. Sin embargo, la calidad de estos temas es un factor decisivo para tener suficiente confianza sobre cómo, cuándo y por qué tendría sentido hacer release a producción.

El objetivo es construir un sistema donde los despliegues a producción sean tan frecuentes, suaves y fáciles como sea posible; en cualquier momento, cualquier día. Tener miedo de tu sistema no debería ser el objetivo. Por el contrario, debería ser algo hacia lo que trabajar para solucionarlo.

Las dinámicas del equipo también son un factor esencial aquí. Si establecemos miedo a los despliegues los viernes, y miedo a nuestro sistema, eso terminará en falta de responsabilidad por defecto. Esto me recuerda a The Five Dysfunctions of a Team.

Si despliegas cambios pequeños y frecuentes tan pronto como pueden garantizar 100% de calidad y éxito de valor, ¿por qué retrasar tal mejora incremental a tu sistema?

Volviendo a “¿Por qué no deberíamos desplegar los viernes?” La única razón que se me ocurre es tener miedo de que tengamos que trabajar el sábado en la cosa rota que entregamos el viernes. Sin embargo, me pregunto si había alguna opción disponible, para que pudiéramos haber identificado tal cosa rota durante el propio viernes laborable.

Monitorear tu sistema en vivo es crucial para garantizar la salud después de cada despliegue. Esto es esencial para asegurar que todo funciona bien y sin problemas. Para construir un sistema resistente, esto debería activar alarmas para notificar a alguien responsable de abordar el problema, deshabilitar o revertir la última característica “rota”… hay muchas técnicas para crear conciencia y actuar sobre ellas.

En caso de duda, podrías usar feature flags para deshabilitar la característica que desplegarás. Aún así, prefieres no habilitarla durante el fin de semana mientras mantienes la opción de agregar valor y desplegar en cualquier momento siempre abierta.

Creo que las releases frecuentes y pequeñas a producción son clave; en cualquier momento, cualquier fecha, mientras tenga sentido, y haya un camino claro para traer valor pronto al cliente para obtener retroalimentación lo antes posible.

Entrega valor de calidad en pequeños incrementos, tan frecuentemente como sea posible.

Poder desplegar los viernes (si es necesario o deseado) impacta la confianza del equipo. De manera similar, prohibir los despliegues los viernes impacta la autoestima del equipo también.

¿Cómo Consigues que Todos se Sumen?

2023-08-02T00:00:00+00:00

Fui invitado al WeAreDevelopers World Congress para dar una charla técnica sobre mi experiencia con XP y los profundos beneficios de abrazar el cambio en tu trabajo y vida.

Con más de 12k asistentes, 300 speakers y ~10 tracks en paralelo, fui invitado a dar no una sino dos charlas. Una es sobre mi experiencia con Extreme Programming y los profundos beneficios de abrazar el cambio en tu trabajo y vida.

Disfruté especialmente la participación de la audiencia y las opiniones que me dieron después de cada charla. En particular, una pregunta que había enfrentado muchas veces durante mi carrera: “¿Cómo tratas con personas reacias al cambio?”

Este es uno de los temas más complejos que afecta a cualquier equipo, independientemente de su profesión. Pero, especialmente en nuestra industria del software en constante cambio, si eres reacio a abrazar el cambio, harás más daño que bien a tu equipo, carrera y a ti mismo.

Como se indica en Peopleware, “nuestra profesión del software es menos sobre computadoras y más sobre humanos y sus interacciones”. Este es usualmente el problema raíz para las personas; es un problema humano primero.

Para convertirte en verdaderamente agile, debes tener una buena base de confianza entre tus compañeros. Sin confianza, no hay equipo, y la responsabilidad principal de un buen líder es ayudar a crear un ambiente de confianza sin miedo a conflictos saludables. Todos sienten que pueden hablar y expresarse libremente en un ambiente seguro.

Un ambiente seguro significa que no necesitas llevar una armadura todo el día para protegerte de otros, así que tendrás más energía para impulsar la excelencia en tu lugar de trabajo.

Pero aún así, a pesar de tu esfuerzo por crear un ambiente de confianza y seguro, podrías encontrar personas reacias al cambio. Para esas, podrías necesitar probar diferentes enfoques. ¿Cómo puedes ayudar a crear confianza entre todos?

No tengas miedo al fracaso; en cambio, piensa que todo lo que haces es un experimento del que aprenderás algo. Y cualquier cosa que te acerque a un mejor estado es mejor que nada.

La clave aquí es encontrar una manera de conectar con las personas entendiendo cómo entienden su potencial para que puedas empoderarlas y ayudarlas a crecer.

Concede tiempo para leer #

Las reuniones 1:1 son ideales para establecer conexiones personales con tus compañeros. Sin embargo, podrías sentir que la situación requiere un empujón adicional, especialmente si tienes a alguien a quien no le gusta hablar de sí mismo, y es difícil saber qué piensan sobre lo que está pasando.

Aquí hay una idea que podrías probar:

Dales un libro que contenga ideas o conocimiento que podría beneficiar a todos.
Permite leer este libro durante el tiempo de trabajo, ej: los viernes después del almuerzo. Esta es una inversión de la empresa para el desarrollo de tu equipo.
El libro debería leerse en 3-4 horas, o un par de viernes, dependiendo del número de páginas.
No esperes hasta que el libro esté terminado para hablar sobre él. Sigue el progreso.
Tendrás grandes temas para discutir durante tu próximo 1:1.

Podrías usar cualquier libro para este ejercicio #

Cualquier libro estaría bien. Aún así, si estás buscando grandes ejemplos, estos son mis tres favoritos para empezar a impulsar una conversación:

Who moved my cheese? es una metáfora de las diferentes actitudes que las personas adoptan como parte de su identidad en la vida cuando tienen que confrontar cualquier cambio.
Extreme Programming Explained contiene una compilación de valores, principios y prácticas altamente relacionados con el toque humano en nuestra industria del software. Enfocándose en el aspecto del equipo, colaboración con tus compañeros y creando un sentido de maestría y propósito en nuestro oficio.
Start with Why aborda la importancia de empezar con “¿Por qué?” para definir un propósito para todo lo que hacemos.

Experimenta con cualquier libro, marco de tiempo, persona o grupo para crear un entendimiento compartido de los valores y motivaciones fundamentales del equipo. El objetivo es participar en el intercambio activo de conocimiento mientras cultivas un equipo que siente que pertenece, fomentando la pasión en el trabajo. Esto ayudará a crear confianza, y puedes empezar a construir sobre ella.

Si estás buscando libros para ayudar a escalar tus habilidades de liderazgo, aquí tienes: “Gran Liderazgo”.

No puedes forzar a las personas a cambiar. Por el contrario, cuanto más intentes forzarlo, más difícil te lo pondrán. En cambio, enfócate en entenderlas reconociendo lo que sienten y pensando sobre lo que hacen para crear un terreno común de entendimiento mutuo.

Fotos mías en WeAreDevelopers World Congress, Berlín 2023.

Entrevista sobre XP y Agile

2023-01-09T00:00:00+00:00

Mi entrevista con devm.io sobre Agile y Extreme Programming.

devm.io: Hablamos con Chema, un desarrollador de software y experto en Extreme Programming, sobre su tema favorito y su próximo evento en vivo Update Your Team To Be More Extreme.

¿Podrías contarnos un poco sobre ti, quién eres y qué haces? #

Chema: Mi nombre es Jose Maria Valera Reales, pero todos me llaman Chema. Soy originalmente de España pero vivo en Berlín desde 2015. He estado trabajando como desarrollador de software desde 2013. En los últimos años, me he enfocado en alcanzar la excelencia y descubrir cómo ayudar a mis compañeros y, con ellos, a toda la comunidad de software a mejorar en nuestra profesión.

Actualmente soy Tech Lead en Lautsprecher Teufel GmbH, donde trabajo con el equipo del webshop de e-commerce. También disfruto del software de código abierto, así que me gusta crear pull requests para otros repositorios, y también me encanta cuando recibo pull requests de otros.

¿Cómo describirías Extreme Programming? ¿Qué lo hace tan “extremo”? #

Extreme Programming es el enfoque más directo y pragmático para abrazar Agile en tu equipo de software. Incorpora soluciones basadas en valores, principios y prácticas. No tienes que usar o hacer todo, sino lo que se ajuste a ti y a tu equipo en tu contexto. Sin embargo, estas son soluciones generales útiles que funcionan mejor cuando se combinan.

Desde mi experiencia, la palabra “extremo” puede ser engañosa, pero la veo como una oportunidad para enfatizar la dificultad de los fundamentos detrás de ella. El punto crítico es darse cuenta de que nuestro “sentido común” no es tan “común” como tendemos a pensar, ni las mejores prácticas para el trabajo en equipo efectivo. Por lo tanto, esto se trata de llevarnos a la efectividad extrema, colaboración y satisfacción mientras trabajamos con otros.

Organizarás un evento en vivo en devm.io sobre el tema el 19 de enero. ¿Podrías darnos un adelanto de lo que tu audiencia puede esperar? #

Exploraremos cómo funciona un equipo de software hoy en día, los problemas comunes que encontramos y qué soluciones podríamos aplicar para mejorar las rutinas de nuestro equipo. Buscaremos el verdadero significado de Agile, enfocándonos en las ideas de Extreme Programming.

Además, compartiré algunas ideas para ayudar a tu equipo a crear oportunidades de aprendizaje con ejemplos concretos que cualquier equipo puede incorporar en su trabajo actual.

Durante el evento, también nos contarás algo sobre Katas. ¿Qué son exactamente las Katas? #

El término “kata” proviene de los movimientos repetitivos hechos en karate que te ayudan a mejorar tus habilidades de combate.

¿Por qué “katas de código”? Porque como grupo, necesitamos practicar más. La mayor parte de nuestro aprendizaje ocurre en el trabajo, por lo que la mayoría de nuestros errores también se cometen allí. Y porque queremos mantener PROD, somos reacios a probar cosas nuevas.

Las katas existen para ayudar a los desarrolladores a obtener los mismos beneficios que obtendrías de la práctica en cualquier otra profesión. Estos ejercicios simples de simulación te permiten experimentar y aprender sin la presión de PROD. No hay respuestas correctas o incorrectas en ninguna kata de software: el beneficio viene del proceso, no del resultado.

Hay katas para ayudarte a mejorar tus habilidades de refactoring (como Gilded Rose Refactoring Kata de Emily Bache) o tus habilidades de testing (fáciles como Fizz Buzz o Roman Numerals, o más avanzadas como Bank Kata de Sandro Mancuso). También son geniales para construir confianza al programar con otros, observar y practicar diferentes roles colaborativamente, fomentar la cohesión del equipo, etc.

¿Qué papel juegan los métodos Agile en el desarrollo de software para ti? #

La primera pregunta aquí es definir qué son los métodos Agile. Al final, todos se comunican de alguna manera, dan retroalimentación a otros y simplifican hasta cierto nivel. A veces las personas tienen el coraje de decir lo que piensan y a veces no, y usualmente intentan respetar a sus compañeros. Así que, para mí, Agile es más sobre “cómo” haces ciertas cosas en lugar de “qué” cosas haces.

Agile es un proceso de trabajo altamente colaborativo a cualquier nivel, que podría tener una curva de aprendizaje desafiante al principio, pero vale la pena antes de lo que podrías esperar.

¿Qué tema en el área de agile debería recibir más atención? #

La construcción de equipos y abrazar la agilidad, empezando por preguntar “¿por qué?” Necesitamos desafiar el statu quo más a menudo y preguntarnos por qué trabajamos de la manera en que lo hacemos y cómo y qué podríamos hacer diferente para seguir mejorando y nunca dejar de aprender.

También puedes leer la entrevista desde el enlace original: https://devm.io/agile/extreme-programming-agile.

Trabajando Agile con Equipos No Agile

2022-11-11T00:00:00+00:00

Asumamos que ya sabes qué es el manifiesto agile. Consideremos que aplicas la mayoría de los valores, principios y prácticas de “extreme programming”. ¿Cómo puedes trabajar con otros equipos que no son agile?

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación de contratos

Responder ante el cambio sobre seguir un plan

Estás usando bucles de retroalimentación cortos, donde las cosas cambian constantemente. Puedes sentir que el equipo está vivo y cada uno es esencial.

Abrazas el cambio hasta el punto de que disfrutas saliendo de tu zona de confort cuando es necesario. Buscando crear valor para tu equipo y sus dinámicas, y siempre considerando el crecimiento personal.

Pero claro, asumamos todo eso, y todo lo demás que pueda haber olvidado respecto a la “agilidad”, ¿cómo podrías trabajar con un equipo externo que no es agile? ¿Cómo podría tu “equipo perfectamente agile” trabajar con otro grupo de personas que no tiene nada que ver con software? Por ejemplo, un médico.

Un médico no tiene tiempo para aprender sobre tus “valores y principios agile para desarrollo de software”. Un médico no tiene tiempo para aprender sobre “extreme programming”. De manera similar, no tienen tiempo para aprender sobre testing, diseño, arquitectura y buenas prácticas relacionadas con el software en general.

¿Cómo podrías crear un puente entre ese médico y tu equipo de software?

¿Cómo podrías trabajar agile con ese médico? #

Si necesitas trabajar con ese médico es porque él/ella debería ser un experto de dominio. Sugiero que uno o dos miembros de tu equipo se reúnan con ese experto durante 30/60 min, para que puedan hablar y compartir sus impresiones. Y luego repetir esto tanto como sea posible para acortar el bucle de retroalimentación. Por ejemplo, una vez a la semana.

Recopilar esos requisitos e impresiones de los expertos y luego dirigir el diseño de tu software de acuerdo con eso es Domain-Driven Design. Puedes encontrar mucha documentación sobre DDD en libros (como Domain-Driven Design Distilled) o en muchos blogs en Internet.

Sin embargo, el aspecto crítico aquí no es qué requisitos o impresiones se están resolviendo sino cómo. ¿Cómo podrías trabajar agile con ese médico?

Agile es sobre retroalimentación rápida. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.

Al aplicar verdaderamente estos cinco valores, ya estás actuando de forma agile #

Comunicación
Retroalimentación
Simplicidad
Coraje
Respeto

Estos objetivos abstractos aplican a cualquier profesión, e incluso a la vida, no solo al software.

La comunicación continua ayuda a acortar el bucle de retroalimentación, lo que simplifica las tareas. Siempre con el coraje de abordar la verdad y respeto mutuo.

Las prácticas son las cosas que haces #

Sentarse Juntos
Pair Programming
Test First
Diseño Incremental
y muchas más

Y a pesar de tener un nombre técnico, podrían aplicar a cualquier profesión:

Sentarse Juntos & Pair Programming: pensar y hacer con otros compañeros

Test First: verifica tus suposiciones primero, luego resuelve el problema

Diseño Incremental: lo que sea que hagas, hazlo mejor incrementalmente

Los principios guían y motivan las prácticas hacia los valores #

Beneficio Mutuo
Diversidad
Fracaso
Oportunidad
Pasos Pequeños
Calidad
y muchos más

El beneficio mutuo es el más importante porque se trata de encontrar prácticas que nos beneficien ahora, a nosotros después, y también al cliente.

Otros principios incluyen la diversidad de ideas. No tengas miedo del fracaso. Mira todo lo que haces como una oportunidad de aprendizaje. Evita pasos gigantes porque tienen mayor riesgo de fallar. Apunta a un sistema de alta calidad porque son más predecibles y más fáciles de cambiar.

La pregunta permanece: ¿eres agile? #

Creo verdaderamente que un equipo agile es el que puede lidiar con el cambio a nivel de equipo. Por lo tanto, primero debes dominar agile dentro de tu equipo, y luego puedes colaborar con otros equipos de “manera agile”.

Una vez que hayas interiorizado estos puntos anteriores, puedes aplicarlos mientras trabajas con cualquier persona de cualquier equipo.

Aunque estas ideas aisladas son buenas, son aún más poderosas cuando se combinan. Crean una atmósfera de curiosidad y aprendizaje activo. Incluso podría despertar alguna pasión por tu profesión que construye un aura de cohesión de equipo, y así sin más, el equipo respira por sí mismo.

Todos se preocupan y asumen plena responsabilidad de mantener al equipo saludable construyendo confianza. No hay miedo a conflictos saludables. Se sienten empoderados y responsables de sus compromisos. El equipo celebra sus resultados y aprende de sus errores; ya no hay necesidad de máscaras.

Es entonces cuando la magia empieza a suceder, y de repente puedes trabajar agile con cualquier equipo, especialmente el tuyo.

Diferentes Creencias sobre la Calidad del Software

2022-10-08T00:00:00+00:00

Hace poco recibí una pregunta en Twitter que me hizo pensar bastante. Decidí compartir mis reflexiones al respecto.

El tweet que empezó esto #

Primero, algo de contexto: me siento muy bien porque el código base donde trabajo mejora cada vez más, así que tuiteé esto:

“A medida que el software mejora con el tiempo, puedes sentir que lo estás haciendo bien.”

Y entonces recibí una pregunta pidiendo sugerencias:

Así que aquí vamos…

Mi respuesta #

Crear acuerdos #

Lo primero es crear acuerdos sobre qué significa software de calidad para tu equipo y para ti. Esto aclara qué cultura de software quieres construir. Dejar tu empresa debería ser el último recurso.

Antes de pensar en irte, pregúntate:

¿Por qué crees que no puedes mejorar el código base de tu empresa?
¿Qué puedes hacer para reducir la fricción entre tus diferentes creencias sobre calidad?

No existe un código base perfecto. El software es una entidad viva que cambia constantemente. Para mí, software de calidad es el que puede adaptarse al cambio con facilidad.

Una vez que acordéis ese objetivo, hay muchas formas de lograrlo. Mi favorita es mantener una mentalidad agile con dosis de valores, principios y prácticas de Extreme Programming.

El software es sobre personas #

El software no es solo escribir código limpio y sólido. Eso es deseable, claro, pero primero hay que entender por qué lo queremos. El “por qué” se basa en los valores del equipo.

Si no compartís el mismo propósito, el mismo “por qué”, no disfrutaréis trabajando juntos. En ese caso, buscar otra empresa que comparta tus valores es una opción. Pero antes, intenta arreglar el problema de raíz y ayuda a tu equipo a mejorar.

Entendiendo tu por qué #

Primero necesitas entender tu “por qué” a fondo para transmitirlo a tus compañeros. ¿Has hecho todo lo posible para comunicar tu “por qué”?

Algunas ideas: fomentar la programación colaborativa (pair/mob), dar charlas técnicas internas, crear una cultura de compartir conocimiento a diario, cuestionar el statu quo y buscar oportunidades de mejora en todas partes.

Tu trayectoria profesional #

Si después de varios meses intentando estas ideas de verdad ninguna funciona, busca una empresa que comparta tus creencias. Al fin y al cabo, tú eres el principal responsable de tu carrera profesional.

Hilo de twitter original.

Pensamientos adicionales #

Si quieres que algo sea diferente, no esperes a que cambie solo. Intenta cambiarlo; si no funciona, déjalo. Quizás no es tu sitio.

Eso sí, reflexiona si ves este patrón repetirse a menudo (cambiar de empresa demasiado rápido). Si es así, quizás el problema no son las empresas sino tú.

El desarrollo de software no es solo código, es negocio. Hay que encontrar un equilibrio justo entre velocidad, costes y calidad según la situación. A veces conviene asumir algo de deuda técnica para llegar antes al mercado.

Ningún equipo debería tener “baja calidad” como parte de su identidad. Cada equipo tiene expectativas de calidad. La clave está en acordar qué es buena calidad.

Artesanía Limpia

2022-07-11T00:00:00+00:00

El libro tiene tres partes: disciplinas, estándares y ética.

La primera es la más técnica. Te guía con ejemplos de TDD y muestra cómo el testing te ayuda a diseñar tu código.

La segunda trata sobre productividad, calidad y coraje.

La tercera explica cómo hemos llegado hasta aquí como profesionales del software y nuestra responsabilidad ética: no hacer daño, integridad y trabajo en equipo.

Una de mis partes favoritas del libro:

Nuestra industria es dinámica y cambia constantemente. Hay que aprender de forma continua y agresiva.

¿Cómo y cuándo aprendes? Si tu empresa te da tiempo para ello, aprovéchalo al máximo. Si no, tendrás que hacerlo por tu cuenta.

Prepárate para dedicar varias horas al mes. Reserva ese tiempo.

Sí, ya sé: familia, facturas, viajes, la vida. Pero también tienes una profesión. Y las profesiones requieren cuidado y mantenimiento. Aprendamos de forma continua y agresiva.

Capítulo 11. Coraje - Aprendizaje Agresivo Continuo

Índice #

Parte I: Las Disciplinas #

Capítulo 1. Artesanía #

Extreme Programming
Test-Driven Development
Refactoring
Diseño Simple
Programación Colaborativa
Tests de Aceptación

Capítulo 2. Test-Driven Development #

Visión General
Lo Básico

Capítulo 3. TDD Avanzado #

Quedarse Atascado
Arrange, Act, Assert
Test Doubles
Arquitectura

Capítulo 4. Diseño de Tests #

Testeando Bases de Datos
Testeando GUIs
Patrones de Test
Subclase Específica de Test
Humble Object
Diseño de Tests
Rompiendo la Correspondencia

Capítulo 5. Refactoring #

¿Qué es Refactoring?
El Kit Básico de Herramientas
Extract Method
Las Disciplinas

Capítulo 6. Diseño Simple #

YAGNI
Cubierto por Tests
Cobertura
¿Diseño?
Maximizar Expresión
La Abstracción Subyacente
Minimizar Duplicación
Minimizar Tamaño

Capítulo 7. Programación Colaborativa #

Capítulo 8. Tests de Aceptación #

La Disciplina
El Build Continuo

Parte II: Los Estándares #

Capítulo 9. Productividad #

Nunca Enviaremos M***da
Adaptabilidad Económica
Siempre Estaremos Listos
Productividad Estable

Capítulo 10. Calidad #

Mejora Continua
Competencia Sin Miedo
Calidad Extrema
No Volcaremos en QA
QA No Encontrará Nada
Automatización de Tests
Testing Automatizado e Interfaces de Usuario
Testeando la Interfaz de Usuario

Capítulo 11. Coraje #

Nos Cubrimos Mutuamente
Estimaciones Honestas
Debes Decir NO
Aprendizaje Agresivo Continuo
Mentoría

Parte III: La Ética #

El Primer Programador
Setenta y Cinco Años
Nerds y Salvadores
Modelos a Seguir y Villanos
Gobernamos el Mundo
Catástrofes
El Juramento

Capítulo 12. Daño #

Primero, No Hacer Daño
Mejor Trabajo
Prueba Repetible

Capítulo 13. Integridad #

Ciclos Pequeños
Mejora Implacable
Mantener Alta Productividad

Capítulo 14. Trabajo en Equipo #

Trabajar como Equipo
Estimar Honesta y Justamente
Respeto
Nunca Dejes de Aprender

Charla de Uncle Bob donde cubre la mayoría de los temas del libro.

Escucha sobre:
* Cita e Intro - [00:00:00]
* Trayectoria Profesional - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programador como Profesión - [00:15:31]
* Artesanía - [00:18:45]
* Disciplinas - [00:22:45]
* Disciplinas: Test-Driven Development - [00:28:49]
* Disciplinas: Refactoring - [00:34:31]
* Cobertura de Código - [00:39:02]
* Estándar: Nunca Enviar M***da - [00:42:35]
* Estándar: Siempre Estar Listo - [00:47:15]
* Ética: No Hacer Daño - [00:50:00]
* Ética: Estimar Honestamente - [00:53:56]
* 2 Sabiduría de Tech Lead - [00:57:50]

Actualiza tu Equipo para Ser Más Extreme

2022-02-26T00:00:00+00:00

Nuestra profesión del software está en constante evolución y exige aprendizaje continuo. El cambio no es opcional en nuestra industria.

Hay que crear espacios para salir de nuestra zona de confort. Nuestro cerebro necesita entrenarse para adaptarse a un entorno que cambia constantemente.

¿Por qué katas de código, charlas técnicas o viernes de investigación? #

El objetivo es crear un ambiente que fomente la mejora continua. Buscar aprender en todas partes, todo el tiempo, como actitud central para cada persona y para el equipo.

Crear oportunidades de aprendizaje #

Programa tiempo cada X semanas para practicar juntos.

Al final de cada iteración, o cada 2-4 semanas, trabajamos en katas en parejas o mob durante 2 horas. Ese espacio también sirve para preparar charlas técnicas internas y compartir conocimiento interesante que no sea del “negocio diario”.

El objetivo es salir de nuestra zona de confort. Mejorar nuestra capacidad de adaptación mientras aprendemos otros temas.

¿Qué es una kata de código? #

Los desarrolladores no practicamos lo suficiente. La mayor parte del aprendizaje ocurre en el trabajo, y ahí es donde cometemos la mayoría de errores.

El término “kata” viene del karate: movimientos repetitivos que mejoran tus habilidades de combate.

Las katas de código dan a los desarrolladores los mismos beneficios que practicar en cualquier profesión. Son ejercicios simples que permiten experimentar y aprender sin la presión de producción.

No hay respuestas correctas o incorrectas en una kata: el beneficio viene del proceso, no del resultado.

Motivación #

Practicar técnicas de refactoring.
Practicar TDD.
Aplicar principios SOLID.
Hacer sesiones de live coding.
Ejercitar el concepto driver-navigator.
Mejorar la cohesión del equipo.
Pasarlo bien mientras aprendes con otros.

Si te interesa mi visión sobre TDD y katas, escribí un post hace poco: Test-Driven Development.

¿Qué es una charla técnica? #

Las charlas técnicas nos permiten compartir conocimiento de nuestra industria con el equipo.

Puede ser sobre FrontEnd, BackEnd, DevOps. Pero también animo a compartir:

un nuevo lenguaje que estás aprendiendo,
un resumen de un libro que terminaste,
una tecnología que te da curiosidad,
un software que te gustaría presentar,
una herramienta que mejora tu productividad,
en realidad: cualquier cosa que aporte valor o conocimiento.

¿Cómo presento una charla técnica? #

Escribí un artículo con consejos sobre cómo mejorar tu charla técnica. Algunas preguntas que pueden ayudarte:

¿Qué has aprendido recientemente?
¿Qué conocimiento sería interesante compartir con tus compañeros?
¿Qué aspecto de ti te gustaría mejorar profesional o personalmente?

Una sola regla: sé curioso y “abraza el cambio.”

Viernes de investigación y aprendizaje #

Reserva el último viernes del mes para investigar y aprender. Todo el equipo tendrá un espacio dedicado al crecimiento y la experimentación.

Es clave construir confianza con tu equipo. Que todos sepan que cada uno usará este tiempo bien. No microgestiones forzando un registro detallado en una wiki.

Eso sí, estaría bien que el equipo comparta lo que hace. Crea transparencia. Un anuncio verbal el día antes con las intenciones, y el día después con los aprendizajes clave.

Resumen #

Puedes ayudar a tu equipo a ser más extreme creando un espacio dedicado al crecimiento y la experimentación.

Da flexibilidad para experimentar con estas ideas.
Es una oportunidad para crecer y aprender a la vez.
La responsabilidad es de cada persona y del equipo.

No microgestiones este tiempo. Enfócate en el resultado. Ayuda a tu equipo a crecer, y disfrutarán creciendo contigo.

Charla Técnica #

Tras escribir este post (originalmente en febrero de 2022), me invitaron a dar una charla técnica sobre este tema en varias conferencias.

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.