Etiqueta: xp

Radiografía de un equipo trabajando a lo Extreme Programming

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)
  • Sonar (quality check)
  • Docker, Docker Compose & Kubernetes (packaging & runtime)
  • 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.

Y un día no separamos (una historia de crecimiento orgánico)

Hasta aquí…

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.

En un par de meses les cuento.

Libro recomendado: XP installed

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 :-).