En enero comencé con un experimento, desarrollar una aplicación real (para un cliente mio) en sesiones online, abiertas y de 15 minutos. Como de costumbre, el desarrollo lo hice aplicando prácticas de Extreme Programming como ser Specification by Example, Test-Driven Development, Continuous Integration, Entrega Incremental, Story Slicing, etc., y utilizando algunas técnicas de diseño/programación como ser arquitectura hexagonal, mocks, etc.
Fueron en total 20 sesiones (unas 5 horas) en las que completé 2 mini-releases de la aplicación en cuestión. Luego, edité los videos de las sesiones, los complementé con algunos videos más y con ello le di forma un video-curso en la plataforma Udemy. La versión actual del curso tiene más de 7 horas de video y durante marzo repetiré la experiencia para agregar más funcionalidades y con ello sumar al menos otras 10 horas de video.
Los interesados en el curso lo pueden en la plataforma Udemy (aquí).
Hace un par de días salió publicado un episodio del podcast La Revolución Ágil en el que estuve participando. El episodio fue grabado hace un par de meses y es básicamente una charla uno a uno con Camilo Velasquez, host del del podcast.
Previo a esta publicación tuvimos cierto desencuentro respecto del título con el que saldría publicado el episodio. El título original que había puesto Camilo me generaba cierta incomodidad pues a mi parecer transmitia una idea de «rivalidad» entre técnicos y agilistas. El título final, «Agilidad Técnica», me parece mas apropiado pero igualmente a mi parecer tiene cierta redundancia ya la verdadera agilidad implica el uso de ciertas prácticas técnicas (test-automation, CI/CD, etc).
Más allá de la cuestión del título, creo que la charla estuvo muy buena y creo que trae muchas cuestiones interesantes para aquellos agilistas que trabajan con equipos de entrega de software y que no tienen formación técnica.
Agradezco a Camilo por invitación y lo felicito por iniciativa ya que al margen de este episodio hay otros episodios super interesantes. En lo personal me gustaron mucho los episodios 7 y 13 con Hiroshi y Alistair respectivamente.
En Scrum que existe una guía oficial que los autores mantienen actualizada. También existe una organización (en realidad creo que más de una pero la que conozco yo es la Scrum Alliance) que ofrece certificaciones de Scrum. En este sentido es razonable pensar que quien se acercó a Agile con Scrum, luego quiera acercarse a Extreme Programming (XP) y busque la guia oficial de XP.
Pero en XP no hay guía oficial, perdón si llegaron a este post buscando esa guía oficial. Al menos ahora saben que no existe :-). Tampoco existe una certificación oficial de XP, ni una XP Alliance.
En términos de publicaciones creo que los más cercano a una guía oficial es la serie de libros «XP Series» de la editorial Addison-Wesley publicada entre 1999 y 2005. En dicha serie se incluye el libro fundacional de XP escrito por Beck: «Extreme Programming Explained, Embrace chance» que a mi parece no es el mejor libro de la serie. No leí todos los libros de la serie en parte porque no pude conseguirlos, varios de ellos están discontinuados, de hecho algunos los conseguí usados. Dos libros que me parecieron excelentes fueron «Planning Extreme Programming» de Beck y Fowler y «Extreme Programming Installed» de Jeffries, Anderson y Hendrickson.
Por otro lado, un libro que a simple vista no parece de XP pero que definitivamente lo es, es el libro de James Shore «The Art of Agile Development«. La segunda edición, publicada en 2021, creo que es una descripción muy acertada de lo que podría considerarse un «XP Moderno».
En lo personal, creo que cada vez tiene menos sentido hablar de «métodos/marcos/metodologías» de desarrollo de software. Podemos debatir valores, principios, mindsets y luego bajar a prácticas concretas en las que materialicemos esos valores pero no necesitamos un rótulo para eso. Creo que las combinaciones pre-armadas de «valores + principios + prácticas» empaquetadas bajo un rótulo pueden agregar valor para un equipo/organización que recién empieza, pero a medida que conformamos grupos de trabajo más estables los «combos» agregan cada vez menos valor por el simple hecho de que el grupo de trabajo se convierte en un equipo y empieza a generar sus propias prácticas.
Hay muchas descripciones teóricas en libros, artículos y conferencias sobre cómo trabajar con la metodología Extreme Programming, pero muy pocos dando detalles. En este sentido un recurso excelente es el libro de Henrik Kniberg, Scrum and XP from Trenches. Al margen de ello, quiero compartir aquí algunos detalles de implementación de la forma en la que trabaja el equipo del cual soy parte actualmente.
Equipo (la gente está en todas las dailies):
5 Devs (skills de front, back, ci/cd, infra)
1 Tester
1 UX
1 facilitador
2 personas de negocio
Proceso:
Duración de iteración: 2 semanas calendario, time-boxed
Daily Stand-up: todos los días 9.15
Revisión de iteración & Demo: Jueves de 10:00 a 10:30 (cada 2 semanas)
Retrospectiva: Jueves de 10:30 a 11:30 (cada 2 semanas)
Planificación estratégica: Jueves de 11:45 a 13:00 (cada 2 semanas)
Planificación táctica: Jueves de 14:00 a 16:00 (cada 2 semanas)
Refinamiento: por el no tiene un horario ni cadencia fija, viene variando de iteración en iteración
Invision (el nombre aún no me cierra): martes de 11:00 a 12:00 tenemos esta reunión semanal donde coordinamos con otro equipo que desarrolla una API con la cual tenemos un importante dependencia
Prácticas de desarrollo:
Trunk-based Development, todo el equipo, todo el tiempo trabajando en la misma rama
Pair-Programming, todo el tiempo
TDD todo el tiempo en el código server-side (C#)
Test-Last en el código de client-side (angular)
Despliegue automatizado a todos los ambiente
Feature Toggling
Stack tecnológico:
Net Core 3.1
Angular 9
Gitlab (versionado de fuentes & pipeline)
Artifactory (versionado de binarios)
RunDeck (deploy automation)
Specflow, NUnit, Postman/Newman y Jess (test automation)
Visual Studio Code, Visual Studio, WebStorm & Rider (IDEs para todos los gustos pues tenemos gustos muy distintos)
Herramientas de gestión / colaboración
Microsoft Teams (chat & calls)
Miro & Zeplin (diseño & mockups)
Jira (backlog)
Confluence (wiki)
Algunas de estas cuestiones de esta forma de trabajo no me terminan de convencer (por ejemplo yo preferiría hacer iteraciones de 1 semana) pero por el momento nos viene funcionando bien, el negocio está contento y ningún miembro del equipo ha planteado desconformidades relevantes.
Comenzamos el proyecto con un equipo completamente nuevo. Según pasaron las iteraciones nos fuimos consolidando como equipo a la vez que sumamos nuevos miembros. De esta forma llegamos a completar la iteración 12 siendo 14 personas. Suficiente, hora de separarnos.
Previamente, allá por la iteración 7, había contado de la previsibilidad de este equipo, un propiedad que el equipo logró mantener a pesar de seguir creciendo. En términos generales, analizando las 12 iteraciones, vemos que la diferencia de trabajo planificado vs trabajo completado no supera el 18%. Esto significado que si este equipo planifica entregar 10 ítems, hay altas probabilidades que al final de la iteración haya completado al menos 8 ítems. El siguiente gráfico muestra el trabajo planificado vs. el trabajo completado para las últimas 3 iteraciones.
Creo que esta característica de previsibilidad es en gran medida consecuencia de un trabajo disciplinado y un crecimiento orgánico.
Algunas métricas de lo realizado hasta aquí:
45 releases a producción
6 meses de trabajo iterativo
382 casos de prueba automatizados que incluyen pruebas unitarias, de integración y aceptación
Una cobertura de código superior al 80%
De aquí en más…
Separamos el equipo y separamos el código para permitir que cada equipo sea lo más autónomo posible, pudiendo regular su velocidad delivery sin dependencias. Cada equipo trabajará enfocado en su (sub)producto con sus propios repositorios, infraestructura, microservicio y microfrontend.
Ahora el gran desafío es ver si podemos lograr que ambos equipos mantengan el nivel de efectividad y desempeño logrado hasta el momento.
Es domingo por la tarde, está anocheciendo. Estoy sentado en un sillón releyendo un libro para mi taller de TDD. El libro lleva en mi biblioteca un buen tiempo pero no el suficiente, debería haberlo comprado antes.
Leo un par capítulos seguidos y me resuena lo que dice, pero al mismo tiempo me llama la atención. Lo que estoy leyendo me parece muy actual pero sospecho que el libro fue publicado hace unos 15 años. Entonces detengo mi lectura y reviso las primera páginas donde figura la información editorial. Efectivamente, el libro fue publicado en Diciembre del año 2000.
Se trata de «Extreme Programming Installed», el libro de tapa rosa de la colección XP Series. Un libro escrito por Ron Jeffries, Ann Anderson y Chet Hendrickson. El libro es como un reporte de experiencia, los autores cuentan a lo largo del libro como aplican XP. Curiosamente los ejemplos de código están en Smalltalk, lo cual me resulta muy agradable :-).
Blog de NicoPaez 