Chemaclass - agile

Ship, Show, Ask

2025-04-12T00:00:00+00:00

En equipos que se mueven rápido, una de las mayores tensiones que enfrentamos es esta: ¿Cómo seguimos entregando sin comprometer la calidad o la colaboración?

El enfoque tradicional de pull requests a menudo ralentiza las cosas. Esperamos horas, o días, por aprobaciones, incluso para cambios triviales. Pero la alternativa, mergear directamente, puede sentirse imprudente o invisible para el resto del equipo.

Ahí es donde entra la estrategia Ship-Show-Ask. Originalmente descrita por Rouan Wilsenach, este modelo ofrece una forma más flexible y reflexiva de manejar cambios de código. No es solo una estrategia de branching, es un cambio en cómo los equipos colaboran, confían y toman propiedad.

¿Qué es Ship, Show, Ask? #

Es un modelo que clasifica los cambios basándose en cuánta revisión requieren:

Ship: Mergear directamente a main (sin PR)
Show: Abrir un pull request, pero mergearlo inmediatamente
Ask: Abrir un pull request y esperar revisión

La idea clave es usar Ask como el default para la mayoría del trabajo, recurrir a Show cuando el contexto lo hace seguro, y evitar Ship (o reservarlo para casos extremadamente triviales, si se usa).

Por qué prefiero Ask y Show #

Trata cada cambio, incluso los pequeños, como algo que vale la pena compartir. Siempre creo una rama y abro un PR. Proporciona visibilidad, construye un historial compartido, y crea un espacio para opiniones opcionales o asíncronas. Es trabajar con la puerta del garaje abierta, aplicado al código.

Pero no todos los PRs necesitan seguir el mismo proceso de revisión.

Por defecto uso Ask #

Prefiero esperar una revisión de un compañero cuando:

El cambio involucra lógica arriesgada o compleja
Podría impactar a otros desarrolladores o equipos
Introduce decisiones arquitectónicas o estructurales que no se han acordado aún
Se beneficia de input compartido o un segundo par de ojos

Dicho esto, Ask no significa sobre-ingeniar el proceso. A menudo, un revisor reflexivo es suficiente, especialmente si está familiarizado con el dominio. Si el cambio toca un área específica, pediré la opinión de la persona que posee (o mejor entiende) esa parte del código. No necesita involucrar a todos.

En equipos pequeños, requerir dos aprobaciones en cada PR puede convertirse rápidamente en un cuello de botella y ralentizar la entrega de valor. El objetivo es alineamiento y calidad, no ceremonia por sí misma.

Uso Show para cambios seguros y de bajo impacto #

Podría mergear inmediatamente cuando:

Practico pair programming (la revisión ya ocurrió en vivo)
Corrijo erratas o enlaces rotos
Actualizo documentación o changelogs
Refactorizo dentro de un módulo que poseo
Añado tests para comportamiento existente
Hago ajustes no funcionales (formato, logs, comentarios)
Aplico ajustes de UI o estilo sin cambio de lógica

El principio clave: Show es opcional, nunca obligatorio. Elijo Show solo si el cambio es de bajo riesgo y encaja con las expectativas del equipo. Cuando uso Show, me hago responsable del resultado. La responsabilidad es mía.

Por qué este enfoque funciona para mí #

Este modelo me ayuda a:

Entregar más rápido sin comprometer la calidad
Trabajar con mayor autonomía y propiedad
Evitar cuellos de botella, especialmente en equipos pequeños o async
Fomentar una mentalidad de confianza, responsabilidad y toma de decisiones reflexiva

Cambia el objetivo de obtener aprobación a compartir intención y ser dueño del resultado.

¿Qué hace un buen “Show”? #

Un PR Show podría ser la elección correcta cuando:

El cambio es trivial y dentro de mi área de responsabilidad
Nadie está disponible para revisar, y esperar bloquearía el progreso
El PR incluye contexto y razonamiento claro
Estoy abierto a comentarios post-merge
Estoy listo para hacer ajustes de seguimiento si es necesario

Consejos para que funcione #

Algunos consejos prácticos de la experiencia:

Clarifica las expectativas del equipo sobre cuándo usar Show vs Ask
Siempre proporciona contexto en tu PR, incluso si mergeas inmediatamente
Escribe tests para cualquier lógica o comportamiento nuevo
Da la bienvenida a los comentarios post-merge, la revisión no termina en el merge
Reflexiona regularmente como equipo y ajusta el enfoque según sea necesario

Ship, Show, Ask es más que higiene de branching. Construye una cultura de claridad, responsabilidad y confianza, donde los desarrolladores se mueven rápido sin dejar de ser reflexivos.

Si estás cansado de colas lentas de PR y aprobaciones sobre-ingeniadas, pruébalo en tu próximo cambio. ¿Quieres profundizar? Lee el post original de Rouan Wilsenach.

Ajusta la revisión al riesgo. Sé dueño de lo que mergeas.

¿Qué Es Waterfall?

2024-08-01T00:00:00+00:00

Waterfall es como seguir un camino recto donde te mueves de un paso al siguiente en un orden definido, como el agua fluyendo por una cascada a través de diferentes etapas.

El problema es que cada paso puede llevar mucho tiempo y recursos para completarse. Además, no recibes retroalimentación hasta que toda la etapa está terminada, lo que puede llevar a mucho tiempo desperdiciado. Esto es especialmente complicado en el desarrollo de software, donde las cosas siempre están cambiando y evolucionando.

Usualmente sigue una secuencia directa como esta:

La realidad de Waterfall #

Waterfall puede ser como el comunismo en teoría, parece perfecto en papel pero no funciona en el mundo real.

Los clientes a menudo no saben exactamente lo que quieren.
Los requisitos están constantemente cambiando.
Los negocios necesitan adaptarse rápidamente a los cambios del mercado y las necesidades de los clientes.
El software necesita ser flexible para mantenerse al día con estos cambios.

Entonces, en un mundo en constante cambio, Waterfall puede realmente perjudicar a un negocio. Tiende a frustrar a los desarrolladores y equipos, y también puede molestar a los clientes y a los negocios que pagan por el software. Esto usualmente lleva a retrasos y costos adicionales.

Por qué las empresas aún usan Waterfall #

Incluso con sus problemas, muchas empresas aún usan Waterfall porque parece directo y lógico. Esto les hace reacios a tomarse el tiempo de aprender Agile. Además, conseguir que la dirección acepte cambiar a Agile puede ser difícil de vender, especialmente ya que requiere una inversión en tiempo y aprendizaje.

El gran problema es cuando los superiores dictan exactamente cómo deben trabajar los equipos, llevando a la microgestión. Esto arruina la flexibilidad que Agile aporta. Por lo que he visto, esto es un problema común.

Mirando hacia atrás, cambiar a Agile podría haber solucionado muchos problemas.

Por qué se creó Agile #

Agile fue creado para superar las limitaciones del método Waterfall. Se enfoca en la interacción constante con clientes y equipos.

Agile construye equipos autónomos y responsables que manejan tareas de principio a fin, reduciendo tiempo y recursos desperdiciados. Enfatiza la flexibilidad, la colaboración y la retroalimentación del cliente.

A diferencia de Waterfall, Agile usa desarrollo iterativo, dividiendo proyectos en pequeños sprints o iteraciones manejables que duran de 1 a 4 semanas. Cada ciclo incluye planificación, desarrollo, pruebas y revisión, con el objetivo de entregar valor rápidamente y recopilar retroalimentación para mejorar.

Aspectos clave de Agile #

Desarrollo iterativo: Trabaja en pequeños fragmentos y ajusta sobre la marcha.
Colaboración con el cliente: Mantén la comunicación con los clientes para asegurar que están satisfechos.
Equipos multifuncionales: Equipos con diferentes habilidades trabajando juntos.
Planificación adaptativa: Mantente flexible y ajusta los planes basándote en la retroalimentación.
Mejora continua: Siempre busca formas de mejorar.

Lee el Manifiesto Agile original.

¿Por dónde puedes empezar? #

Como desarrollador, puedes impulsar tu agilidad sumergiéndote en pair programming y TDD.

Con pair programming, dos desarrolladores trabajan lado a lado, lo que significa que obtienes retroalimentación instantánea y resolución de problemas compartida, llevando a mejor código.
TDD, por otro lado, implica escribir tests antes del código, lo que ayuda a especificar lo que quieres hacer, enfocándote en pequeños pasos.

Juntas, estas prácticas hacen tu proceso de desarrollo más flexible, colaborativo y de alta calidad, encajando perfectamente con el enfoque de Agile en ajustes rápidos y mejora continua. Ve más prácticas aquí.

La clave es colaboración, pequeños pasos y retroalimentación rápida en todo lo que trabajas.

Mi experiencia con Agile #

He hablado sobre Agile en varios eventos tecnológicos y lo he explorado en profundidad porque me apasiona cómo puede potenciar a los equipos de software. Cuando se hace bien, Agile puede cambiar completamente cómo trabajan los equipos, haciéndolos más rápidos, más eficientes y mejores en entregar lo que los clientes y negocios realmente necesitan.

2022-06-26 | International PHP Conference [Berlín, Alemania] (EN)
2022-09-16 | Code Talks [Hamburgo, Alemania] (EN)
2022-10-26 | International PHP Conference [Múnich, Alemania] (EN)
2022-12-21 | IES Ginés Pérez Chirinos [Murcia, España] (ES)
2023-01-19 | devm.io [Remoto] (EN)
2023-07-28 | WeAreDeveloper World Congress [Berlín, Alemania] (EN)

WeAreDevelopers World Congress en Berlín #

El proyecto Fénix

2024-05-31T00:00:00+00:00

Una historia sobre un proyecto imposible donde todos juegan a la política, arreglan bugs críticos sin parar y desperdician esfuerzos en parches rápidos en vez de ayudar al negocio a prosperar.

Si IT falla, el negocio falla.

Principios DevOps: Flujo, Feedback, Aprendizaje Continuo y Experimentación. Estos conceptos impulsan mejoras en capacidad de respuesta, fiabilidad y trabajo en equipo.

Resumen #

El libro empieza con la promoción de Bill a VP de IT y la responsabilidad de entregar un proyecto imposible (Phoenix). El CEO le advierte: si no se entrega a tiempo, externalizarán todo IT y despedirán a todos.

Bill intenta entender la situación y descubre que todos apagan fuegos sin parar, con demasiadas responsabilidades y poco personal. Todo es urgente, todo para ayer. La fecha límite viene de arriba, sin planificación ni conversaciones con otros departamentos. En resumen: caos corporativo, política y reuniones infernales.

Bill conoce a alguien en la empresa que le ayuda a mejorar las cosas. No le dice qué hacer, sino que le hace preguntas para que encuentre la solución por sí mismo.

Por ejemplo, la primera pregunta: “¿Cuáles son los cuatro tipos de trabajo en IT?” La respuesta no llega de golpe, sino a lo largo de la historia:

Proyectos de negocio: afectan directamente los objetivos del negocio. Generan ingresos y dan valor a los clientes.
Proyectos internos: tareas regulares que mantienen el sistema funcionando (actualizaciones, parches de seguridad…). Suelen ser invisibles y pueden convertirse en cuello de botella.
Cambios: resultado de los proyectos anteriores. Hay que saber qué cambiar y dentro de qué.
Trabajo no planificado: el verdadero asesino de la productividad. Son todos los problemas operacionales que surgen de los otros tres tipos de trabajo.

¿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.

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.

El método Lean Startup

2024-01-26T00:00:00+00:00

La mayoría de las startups fracasan, pero muchos de esos fracasos se pueden evitar. El método Lean Startup es un enfoque que está cambiando cómo se crean empresas y se lanzan productos en todo el mundo.

Eric Ries define una startup como una organización que crea algo nuevo bajo condiciones de extrema incertidumbre. Da igual si es una persona en un garaje o un grupo de profesionales en una sala de juntas de una empresa Fortune 500. Lo que comparten es la misión de atravesar esa niebla de incertidumbre para encontrar un camino hacia un negocio sostenible.

Puntos Clave #

Prueba a menudo y aprende rápido
Observa y mide el comportamiento real del cliente
Enfócate solo en métricas accionables
Aprende a pivotar según lo que descubras
Adopta nuevos métodos de contabilidad
Detecta qué no funciona y cambia de inmediato: mantente lean

Resumen #

Gestión Ágil de Proyectos

2023-05-31T00:00:00+00:00

Una visión general básica y directa de lo que es Agile, presentando algunos ejemplos de frameworks bien conocidos hoy, como Scrum o Kanban, todo condensado en un libro de unas 100 páginas que puedes leer en un par de horas.

Capítulos #

El manifiesto fluido
Siendo ágil
Proceso ágil
Planificando para el éxito
Comunicación ágil
Fundamentos de Scrum
Introducción a Kanban
Construyendo un equipo adaptativo
Liderazgo y gestión colaborativa
Errores comunes detrás del fracaso ágil
Palabras finales: ágil es adaptación

“Los beneficios de los proyectos Ágiles se extienden no solo al equipo que lo usa, sino también al cliente que recibe el producto final.”

“Hay una métrica crítica subyacente que consistentemente lleva al éxito de un proyecto Ágil: la comunicación. La mala comunicación, la poca comunicación, o la comunicación deficiente de cualquier tipo lleva al colapso y fracaso de dicho proyecto.”

Puntos clave #

Los proyectos que seguían una metodología Waterfall tendían a exceder sus gastos con el tiempo, mientras que el producto entregado estaba por debajo del estándar y era difícil de usar.

Esa situación originó que un grupo de desarrolladores firmara un breve manifiesto de 68 palabras en 2001.

Un breve trasfondo #

Durante los años 1960, el software entró en una gran crisis; crear software era complejo pero cambiarlo después se convirtió en puro caos. Waterfall al rescate.

Waterfall delineó un conjunto simple y lógico de procesos que una empresa necesitaría seguir para que un proyecto fuera exitoso. Su nombre viene de la metáfora del agua cayendo suavemente en una corriente predecible, constante e incremental. Su ciclo de vida de desarrollo de software estaría en seis pasos simples.

Requisitos
Análisis
Diseño
Código
Testing
Operaciones

Durante 10 años, Waterfall fue la metodología estándar en el universo del software. Y durante 10 años más, el caos persistió. Aunque la intención era buena, la realidad es que el conjunto siempre cambiante de restricciones no se lleva muy bien con esta metodología porque cada paso depende del anterior.

El 86% del tiempo que una empresa usa el método Waterfall para gestión de proyectos, el cliente recibe software inadecuado o inútil. Muchos proyectos de software no se usaron o nunca se terminaron.

Durante los años 70 y 80, Desarrollo Iterativo e Incremental (IID) probó ser una opción viable. En los 90 surge la Entrega Evolutiva (ED), que cambia la situación. El desarrollador es responsable de escuchar las reacciones del usuario temprana y frecuentemente. El usuario comienza a jugar un rol directo en el proceso de desarrollo.

Unos años después, surgió un nuevo método Prototipado de Producción Iterativa Rápida (RIPP), más tarde llamado Desarrollo Rápido de Aplicaciones (RAD), que afirmaba “Software funcionando en 90 días… o te devolvemos tu dinero.”

Por último, durante los 90 se definieron en detalle Extreme Programming (XP), Scrum y Crystal.

Estas soluciones distintas pero similares estaban descentralizadas, trabajando independientemente unas de otras. Esta realización llevó a esa noche en Utah la unificación de estas ideas bajo una bandera, en un documento.

Agile se convirtió en el estándar definitivo para el desarrollo de software.

El Manifiesto Ágil #

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación comprehensiva
Colaboración con el cliente sobre negociación de contratos
Responder al cambio sobre seguir un plan

Es decir, aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

¿Equipos de QA Dedicados en Software?

2023-05-17T00:00:00+00:00

Esto será controvertido, pero hablemos de la posición de QA. La verdad oculta detrás de la falta de calidad del software y por qué esto debería preocuparte si escribes software.

QA es un rol, no una posición #

Como desarrollador de software, cuando escribes software, eres responsable de la calidad de lo que sea que estés escribiendo. Una tercera persona actuando como QA podría encontrar que tu solución no funciona como se esperaba, pero ¿cómo es posible? Podrías argumentar que podrían encontrar casos límite, pero ¿cómo podría ser posible si el software ya fue testeado previamente?

El objetivo final de un equipo de software es hacer la posición de QA inútil porque no deberían encontrar nada más que software bien funcionando. Pero ¿cómo llegas a ese punto? ¿Cómo podemos asegurar que el software que escribimos funciona como se espera y no hay necesidad de una persona QA en nuestro equipo?

La verdad oculta detrás de la falta de calidad del software #

Desafortunadamente, en nuestra industria del software, la demanda de proyectos “rápidos, rápidos y sucios” terminó en MVPs pobremente desarrollados simplemente aplicando parches y código sobre código con solo testing manual comprobando caminos felices, a veces incluso ignorando casos límite.

“La fecha límite es en una semana, ¡así que mejor termínalo a tiempo!”

No aprendemos la importancia de lo que el testing automatizado puede aportar a nuestro trabajo diario, así que no lo tomamos en serio, y por lo tanto, no lo practicamos lo suficiente. Y, por esa misma razón, porque no lo practicamos, no sabemos cómo realizarlo correctamente. ¡Sí, estoy hablando de escribir tests automatizados que prueban el comportamiento de tu software!

Nuestra incapacidad para escribir código testeable resulta en software que es difícil de testear, y por lo tanto delegamos el testing a terceros trasladando la responsabilidad de la calidad final general del producto o servicio que escribimos.

La práctica hace al maestro #

Debes aprender y aplicar técnicas de testing apropiadas cuando tengan sentido. ¿Cómo y cuándo usar efectivamente dobles de test, preparar tests solitarios o sociables, qué compromisos y razones respaldan tu mente al elegir uno u otro camino hacia tus estrategias de testing?

Eres la última y principal persona responsable de tu conocimiento, así que mejor invierte en ti mismo porque nadie más lo hará por ti.

Mira todo lo que haces como una oportunidad de aprendizaje. Practica y mejora por defecto en todo lo que haces.

Si no sabes cómo empezar, aquí está mi consejo favorito: siempre puedes practicar y mejorar tus habilidades de testing usando katas de código. Lee más sobre este tema aquí.

Buena teoría, pero… ¿para qué molestarse? #

El testing manual es, por supuesto, necesario. Es otra estrategia de testing que no estoy culpando o atacando. Aún podríamos necesitar una persona dedicada a cargo de descubrir qué nuevas funcionalidades queremos construir para satisfacer a nuestros clientes. Pero este post no es sobre esa posición.

Se trata de acortar el bucle de retroalimentación. Si puedes escribir software para que funcione de maneras específicas, ¿no puedes escribir tests automatizados para probar que el software que escribiste se comporta de la manera que esperas?

Si has cubierto con tests automatizados el comportamiento de tu software a cualquier nivel que tenga sentido, ¿qué queda para una persona QA dedicada?

La próxima vez que pienses “Necesitamos una persona QA para testear esto”, intenta el ejercicio de pensar en cambio, “¿Cómo puedo escribir un test automatizado que verifique lo que esperaría si una persona QA estuviera comprobando esto?”

Y así es como cambias la “posición de QA a tiempo completo” en una “mentalidad de rol para todos los que escriben software.”

El código nunca miente y nunca olvida; una vez que está escrito y automatizado en tu pipeline, puedes ejecutarlo en cualquier momento sin coste.

Accelerate

2023-03-19T00:00:00+00:00

Accelerate explora cómo los equipos que usan Lean Software y DevOps pueden medir su rendimiento. También muestra cómo el rendimiento de ingeniería impacta a toda la organización.

Nota: DevOps integra y automatiza el desarrollo de software (Dev) con las operaciones de TI (Ops). El foco: mejorar y acortar el ciclo de vida de desarrollo.

Capacidades Clave #

Entrega Continua #

Usar Control de Versiones para todos los Artefactos de Producción
Automatizar tu Proceso de Despliegue
Implementar Integración Continua
Usar Métodos de Desarrollo Basado en Trunk
Implementar Automatización de Tests
Entrega Continua (CD)

Arquitectura #

Usar una Arquitectura Débilmente Acoplada

Producto y Proceso #

Recopilar e Implementar Feedback del Cliente
Hacer Visible el Flujo de Trabajo a través del Value Stream
Trabajar en Lotes Pequeños
Fomentar y Habilitar la Experimentación del Equipo

Gestión Lean y Monitoreo #

Tener Procesos Ligeros de Aprobación de Cambios
Monitorear la Aplicación e Infraestructura para Informar Decisiones de Negocio
Verificar la Salud del Sistema Proactivamente
Mejorar Procesos y Gestionar el Trabajo con Límites WIP (Work-In-Process)
Visualizar el Trabajo para Monitorear la Calidad y Comunicar a través del Equipo

Cultural #

Apoyar una Cultura Generativa
Fomentar y Apoyar el Aprendizaje
Apoyar y Facilitar la Colaboración entre Equipos
Proporcionar Recursos y Herramientas que Hacen el Trabajo Significativo
Apoyar o Encarnar el Liderazgo Transformacional

Cuatro Métricas Clave #

Lead Time de Cambio
- Tiempo para implementar, probar y entregar código para una funcionalidad
Frecuencia de Despliegue
- Número de despliegues en un período de tiempo dado
Tasa de Fallo de Cambios
- Porcentaje de cambios fallidos sobre todos los cambios (independientemente del éxito)
Tiempo Medio de Recuperación
- Tiempo que toma restaurar el servicio después de un fallo en producción

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.

¿Ignorar Scrum para ser más Agile?

2022-12-06T00:00:00+00:00

Hablando con un amigo sobre agile, me hizo una pregunta interesante: a veces Agile y Scrum encajan mal, especialmente con las reuniones. Aquí van mis reflexiones.

“¿Crees que tendría sentido simplemente usar agile e ignorar scrum (sprints) completamente en una empresa basada en producto? Siento que es difícil ser agile cuando tienes 10 horas de reuniones por semana.” Filip G.

Esto conecta con la esencia de Extreme Programming: el primer valor es la Comunicación Efectiva.

“Probablemente algunas empresas no saben usar bien las reuniones y las hacen por costumbre.” Filip G.

No diría ignorar Scrum del todo. Scrum (bien hecho) es un gran “Framework de Gestión de Producto”. Para entenderlo mejor recomiendo: Scrum: The Art of Doing Twice the Work in Half the Time.

El problema principal con Scrum hoy es que la gestión tomó el control y los desarrolladores no saben practicarlo de forma realmente Agile. Ahí empieza el problema. Recomiendo Zombie Scrum Survival Guide, un libro divertido y fácil de leer que aborda los problemas típicos de equipos Scrum.

No es “Agile sí, Scrum no”. Son compatibles. El reto es enfocar los procesos del equipo desde una perspectiva agile.

Agile en pocas palabras #

Recientemente escribí un post sobre fundamentos agile, que te recomiendo leer para entrar en los detalles: Trabajando agile con equipos no agile. Pero, el tl;dr: Agile es sobre retroalimentación rápida. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.

Agile es sobre mantener estos valores siempre presentes:

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

Aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Scrum en pocas palabras #

Scrum es un framework de gestión de proyectos orientado al desarrollo de software, aunque se usa en ventas, marketing y más. Está pensado para equipos de 5-9 personas (ver número de Dunbar) autónomos y responsables de dividir su trabajo en partes pequeñas para completar en iteraciones llamadas sprints (1, 2 o 4 semanas).

Las ceremonias/reuniones típicas son:

Stand-up: 15 min (o menos) para sincronizar al equipo y actuar si alguien está bloqueado o necesita ayuda.
Refinement: ~2h para asegurar que los tickets están listos antes de planificarlos.
Planning: ~2h para planificar el trabajo del siguiente sprint.
Demo/Review: ~2h para mostrar el trabajo hecho al equipo, stakeholders e interesados.
Retrospectiva: ~2h para que el equipo reflexione y mejore.

La pregunta clave es cómo organiza tu equipo estas reuniones y, sobre todo, si son efectivas. Estas son solo algunas de las reuniones de cualquier “Equipo Scrum”.

Pero además de estas, se acumulan muchas otras reuniones. De pronto el día entero se ha ido y sientes que no has producido el valor esperado. Si tu trabajo no consiste en estar en reuniones constantemente, algo está mal.

Reuniones aburridas #

¿Has estado alguna vez en una reunión pensando “Esto es aburrido, qué pérdida de tiempo…”? Yo lo he vivido más de una vez. ¿A quién culpar? Esa suele ser la primera pregunta. Seguida de: “Mi jefe, obviamente. Él organizó esta reunión, me invitó, estoy obligado a asistir, y esta pérdida de tiempo es su culpa.”

No creo que sea una respuesta honesta. Culpar a otros y alejar responsabilidades es mucho más fácil que mirarse a uno mismo.

“Estoy obligado a asistir, y esta pérdida de tiempo es su culpa” puede ser cierto. Quizás estabas obligado y estás perdiendo el tiempo. Pero, ¿de verdad no hay forma de actuar al respecto?

Cuando algo no funciona como espero (no me gusta el resultado, creo que algo está mal), antes de culpar a otros prefiero reflexionar: ¿cuál es la raíz del problema? ¿Qué puedo hacer para mejorar la situación?

¿Qué puedes hacer al respecto? #

Volviendo al tema de “muchas reuniones”: si estás en una que se siente mal o aburrida, pregúntate:

¿Me aburro? ¿Por qué? ¿Quizás no participo en el resultado de la reunión? Si es así, ¿mi presencia es realmente necesaria? ¿Podría pedir un resumen después y salir para hacer algo más productivo?

O al revés: ¿está bien aburrirse en esta reunión? ¿Debería participar más y contribuir al resultado?

Veo este patrón:

Si la reunión no aburre, es productiva y dará buenos resultados para todos.
Si aburre, hay dos opciones: A) está bien que aburra, pide salir educadamente y pide el resumen después; o B) no está bien que aburra porque tu participación es necesaria. Involúcrate más con tus compañeros y la reunión dejará de ser aburrida.

Hay muchas estrategias. Depende de ti actuar cuando veas algo mejorable.

Está bien señalar el “elefante en la habitación” y pedir ayuda para mejorar cualquier situación que sientas que no funciona como debería.

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.

Continuous Discovery Habits

2022-08-21T00:00:00+00:00

Este libro te enseña cómo product managers y diseñadores pueden crear productos que realmente impacten la vida de sus clientes. Propone un proceso claro de toma de decisiones para equipos de producto que quieran mejorar continuamente.

Parte 1: ¿Qué es el descubrimiento continuo? #

El Qué y Por Qué del Descubrimiento Continuo
Un Framework Común para el Descubrimiento Continuo

Parte 2: Los hábitos de descubrimiento continuo #

Enfocarse en Resultados Sobre Outputs
Visualizar Lo Que Sabes
Entrevistas Continuas
Mapear el Espacio de Oportunidades
Priorizar Oportunidades, No Soluciones
Ideación Potenciada
Identificar Suposiciones Ocultas
Probar Suposiciones, No Ideas
Medir el Impacto
Gestionar los Ciclos
Muestra Tu Trabajo

Parte 3: Desarrollando tus hábitos de descubrimiento continuo #

Empieza Pequeño e Itera
¿Qué Sigue?

Enfocarse en resultados sobre outputs te ayudará a crear los productos correctos para tus clientes.

El Qué y Por Qué del Descubrimiento Continuo #

El Triángulo de Gestión de Proyectos

2022-07-25T00:00:00+00:00

Un triángulo de tiempo, calidad y coste. Es un indicador de que estos tres parámetros están interconectados. Puedes fijar uno o dos de ellos, pero no los tres.

La triple restricción #

Barato y rápido: la calidad sufrirá.
Barato y bueno: llevará más tiempo.
Rápido y bueno: subirá el precio.

Waterfall vs Agile #

En metodologías de software, puedes adaptar esta idea cambiando calidad por alcance:

Waterfall #

En proyectos waterfall, el alcance está fijado, mientras que el tiempo y el dinero serán más variables. Dependiendo de si es más importante terminar a tiempo o dentro del presupuesto.

Agile #

Por otro lado, en un entorno agile normalmente trabajamos en iteraciones de pocas semanas, así que esta es la parte fija: el tiempo, para entregar valor lo antes posible, y así obtener retroalimentación y recalibrar una y otra vez.

Los costes en un equipo de software también están fijados por las personas que pertenecen a él.

El tiempo está fijado, el coste está fijado, así que por la regla del triángulo de hierro, el alcance debe ser variable.

Un equipo agile no puede predecir el alcance de su trabajo en un proyecto de un año, sin embargo, no necesitan hacerlo. Su enfoque debería estar en entregar constantemente valor tanto como sea posible, o al menos al final de cada iteración, reflejando sus aprendizajes y recalibrando sus prioridades una y otra vez.

Como puedes ver, un dato curioso es que waterfall y agile comparten un triángulo invertido con sus parámetros fijos y variables. Realmente interesante.

Referencia #

Ingeniería de Software Moderna

2022-06-29T00:00:00+00:00

El libro presenta el desarrollo de software como una práctica de ingeniería real. Para dominarlo hay que ser experto en aprender y gestionar la complejidad.

Optimizar para aprender #

El libro presenta cinco comportamientos clave para aprender mejor:

Trabajar de forma iterativa
Buscar feedback
Incrementalismo
Empirismo
Ser experimental

La idea central: trabajar en pasos pequeños, recoger feedback y ajustar.

Optimizar para gestionar la complejidad #

Cinco ideas para manejar la complejidad:

Modularidad
Cohesión
Separación de responsabilidades
Ocultación de información y abstracción
Gestión del acoplamiento

Gestionar la complejidad de nuestros sistemas es fundamental.

Herramientas para apoyar la ingeniería #

El libro profundiza en ideas como:

Testeabilidad
Desplegabilidad
Control de variables
Entrega continua

Un vídeo donde el autor explica las ideas principales del libro:

Topologías de Equipos

2022-03-31T00:00:00+00:00

El libro explica cómo estructurar equipos dinámicos y sus interacciones para adaptarse rápido a nuevas condiciones y entregar software de forma ágil y segura.

Estructura de equipo #

Alta cohesión: agrupa las cosas relacionadas.
Bajo acoplamiento: límites claros entre equipos.
Carga cognitiva: es como la RAM del equipo. Si lo sobrecargas, se quema.

Para evitar cuellos de botella, asegúrate de que la carga cognitiva del equipo no sea excesiva.

Ley de Conway #

La estructura organizacional influye en la arquitectura del software.
Las organizaciones diseñan sistemas que copian su estructura de comunicación.
Resultado: nadie se enfoca en la arquitectura óptima para el proyecto.
Primero define la arquitectura, luego forma los equipos.

El equipo primero #

Quién está en el equipo importa menos que su dinámica.
Al medir rendimiento, el equipo importa más que las personas individuales.
Equipo = grupo de 5-9 personas trabajando hacia metas compartidas.
- Ver el número de Dunbar.
Formar un equipo toma de 2 semanas a 3 meses.
La carga cognitiva es el esfuerzo mental total usado en la memoria de trabajo.
3 tipos de carga cognitiva:
- Intrínseca: fundamentos del problema. Ej: lenguaje de programación.
- Extrínseca: relacionada con el entorno. Ej: cómo desplegar.
- Germane: requiere atención especial. Ej: dominio de negocio.
Heurísticas:
- 3 tipos de dominio: simple, complicado, complejo.
- Si el dominio es muy grande, divídelo en subdominios.
- Un equipo puede manejar:
  - 2-3 dominios simples.
  - 1 dominio complejo.
  - Evita 2 dominios complicados; mejor divide el equipo.
Define una API de equipo:
- Código: endpoints, librerías, clientes…
- Versionado.
- Documentación.
- Prácticas y principios.
- Herramientas de comunicación.

Topologías de equipo #

Organiza equipos por áreas de dominio de negocio, no por conocimiento técnico o actividades.

El éxito depende tanto de los miembros como del entorno, otros equipos e interacciones.
Divide responsabilidades para romper silos.
Tipos de dependencias: conocimiento, tarea y recurso.
Cuatro tipos de equipos:
- Stream-aligned: entregar funcionalidades y productos al mercado cuanto antes.
- Enabling: desarrollar capacidades para los equipos stream-aligned.
- Complicated-subsystem: reducir la carga cognitiva de los equipos stream-aligned.
- Platform: dar autonomía a los equipos stream-aligned.

Interacciones de equipo #

Colaboración: trabajo cercano entre equipos con distintas habilidades.
X-as-a-Service: propiedad clara, baja carga cognitiva.
Facilitación: eliminar impedimentos y mejorar la calidad de las interacciones entre equipos.

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.

Red Work vs Blue Work

2021-10-21T00:00:00+00:00

“Blue Work” y “Red Work” son conceptos que David Marquet describe en su libro Leadership is Language. Ambos requieren mentalidades diferentes y tienen lenguajes distintos.

“Hacer” en nuestro estilo de liderazgo tradicional no nos llevará a donde necesitamos estar en el futuro.

¿Qué es “Red Work”? #

Red Work trata de hacer y reducir la variabilidad. Se enfoca en demostrar y en el rendimiento.

En Red Work, buscas completar una tarea sin tener que decidir mucho sobre el qué o el cómo. Es estar en control y tomar el control:

Procesar trabajo y evitar errores.
Tener previsibilidad y controlabilidad.

Hace falta un mecanismo para parar el Red Work y preguntar: ¿estamos haciendo lo correcto?

¿Qué es “Blue Work”? #

Blue Work trata de decidir, pensar, planificar. Se enfoca en mejorar con una mentalidad humilde.

El lugar correcto para hacer Blue Work es al principio y al final de un punto de decisión.

Blue Work es crucial para empezar bien. Nos permite decidir la mejor manera de hacer algo con la información que tenemos ahora mismo.

Conviene establecer iteraciones cortas entre las diferentes actividades que queremos completar. Así tenemos “tiempo de Blue Work” para reflexionar. Es perfecto para hacer retrospectivas y ver qué podemos mejorar.

Es el momento de parar, “controlar el reloj”, colaborar y comprometerse para la siguiente iteración. Blue Work también incluye:

Trabajo de pensamiento.
Toma de decisiones.
Buscar alcanzar la excelencia.
Lograr que más personas piensen de forma independiente.
Abrazar la variabilidad y buscar diferentes aportes.

Blue Work aislado es inútil. Su función es hacer mejor el Red Work. Blue Work interminable, planificar sin resultados, no trae beneficios reales.

En nuestra industria del software no hay lugar para la vieja escuela de “Red-Workers” y “Blue-Workers”. Hay “Red Work” y “Blue Work”, y todos debemos participar en ambos.

Por eso todos debemos ser conscientes de estos tipos de trabajo y encontrar un buen equilibrio. Los buenos líderes involucran a todos en Red Work y Blue Work.

Referencias #

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.

Guía de supervivencia Zombie Scrum

2021-03-01T00:00:00+00:00

Disfruté mucho las ideas y experimentos del libro. Pone el dedo en la llaga sobre muchos equipos que dicen hacer Scrum o Agile de forma cuestionable. A eso lo llaman Zombie Scrum.

Resumen #

El libro explica por qué Scrum se estanca y cómo mejorar tus resultados divirtiéndote en el proceso. Con humor y ejemplos muy reconocibles, ofrece enfoques prácticos, ejercicios y herramientas para escapar del Zombie Scrum.

Aunque estés rodeado de escépticos, este libro te ayudará a construir lo que los usuarios realmente necesitan, entregar más rápido, mejorar continuamente y sentirte mejor con tu trabajo. Un día recordarás: para esto adoptamos Scrum.

Cómo te infecta el Zombie Scrum, por qué se propaga y cómo prevenirlo
Acércate a tus stakeholders y hazles entender el valor
Por qué los equipos Zombie no aprenden y qué hacer al respecto
Elimina los obstáculos para la mejora continua
Logra equipos autogestionados donde la gente actúe como humanos, no como zombies

Un buen webinar donde comparten ideas clave del libro y discuten sus hallazgos más recientes.

Gestión ágil de productos con Scrum

2021-02-22T00:00:00+00:00

Temas principales #

El rol del product owner
Cómo visualizar el producto
Refinamiento del product backlog
Planificación de releases
Colaboración en las reuniones de sprint
La transición hacia el product ownership

Scrum

2020-06-10T00:00:00+00:00

Toda organización tiene que lidiar con entregar productos a tiempo y dentro del presupuesto. Da igual el tamaño.

Scrum te muestra cómo hacerlo. Te explica cómo definir lo que quieres lograr, cómo armar el equipo adecuado y cómo seguir el progreso hasta completar el proyecto con éxito.

Agile Limpio

2020-03-12T00:00:00+00:00

Clean Agile viene de Uncle Bob, uno de los padres fundadores de Agile. Fue una de las diecisiete personas que escribieron el Manifiesto Ágil en 2001.

El libro trata sobre Agile: lo que fue, lo que es y lo que será. Es un regreso a lo básico que cubre la historia de Agile, qué lo motivó y qué ha pasado desde entonces. Cubre las prácticas básicas y las compara con la variedad actual de procesos ágiles.

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.

¿Qué es XP? (en 2 min) #

Tech Talk de Kent Beck: XP 20 años después #

Sprint

2016-09-01T00:00:00+00:00

“Sprint ofrece una fórmula para probar ideas que funciona en startups y grandes empresas. En cinco días pasas de idea a prototipo y decisión, ahorrando horas y dinero. Lectura obligada para emprendedores.” - Eric Ries, autor de El método Lean Startup

Tres socios de Google Ventures comparten un proceso de cinco días para resolver problemas difíciles, probado en más de cien empresas.