Como mencioné hace unas semanas, estuve releyendo el libro. Bueno, lo terminé y encontré varias cuestiones. Aquí voy.

Contexto

Antes que nada me parece importante mencionar que el objetivo del libro era dar una idea general de agile incluso cuando algunos capítulos ofrecen bastante detalles de técnicas.

Sin duda que en estos últimos 10 años surgieron muchas cuestiones que podrían/deberían mencionarse en un libro de introducción a agile, algunos temas en este sentido podrían ser: escalamiento, #noEstimates y dual-track agile. Pero también es cierto que varias de las cuestiones que aparecieron no están necesariamente relacionadas a agile, por ejemplo «observabilidad» y «testear en producción» son prácticas que uno podría utilizar sin trabajar en un contexto agile del mismo modo que uno podría trabajar en un contexto agile sin usar estas prácticas.

Al margen de las prácticas yo creo que el mayor cambio que hemos presenciado es que hace 10 años agile era mainstream mientras que hoy en día ya ha supero eso y ahora es el enfoque por default (incluso cuando haya personas/organizaciones que no lo dominan).

Generalidades

La primer cuestión que detecté es que tendríamos que haber numerado explícitamente los capítulos, o sea, en la edición actual los capítulos solo tienen un nombre pero no tienen un número lo cual resulta incómodo cuando uno quiere referirse a un capítulo en particular :-(.

Como era de esperar (o no tanto) detecté algunos errores menores de tipeo (typos).

Creo que en ningún lado explicamos como es el flujo completo de un proyecto ágil, tenemos capítulos que tratan sobre cada una de las partes y tenemos también un capítulo que, a modo novela, cuenta un relato de un proyecto pero no tenemos un capítulo que explique la secuencia de eventos, ceremonias, etc. de un proyecto de punta a punta.

Me parece que falta más énfasis en la entrega continua, es una cuestión que está mencionada pero de forma muy tímida, discreta. Tal vez sea que la entrega continua es mi foco de trabajo actual (y desde hace unos años) pero si tuviera la posibilidad de hacer un ajuste en el libro, definitivamente sería poner más énfasis en la práctica de la entrega continua.

Muy relacionado con lo anterior, falta también más énfasis en stories pequeñas, de hecho creo que debería haber una sección (o incluso un capítulo) de slicing.

La práctica de Pair-Programming, que tiene más de 20 años y es core en XP, está apenas mencionada, creo que deberíamos haber escrito un capítulo al respecto (admito que cuando escribimos el libro, yo mismo no le daba la importancia que le doy en la actualidad a esta práctica).

En todo el libro hablamos constantemente de cliente pero en algunos casos creo que hubiera sido más conveniente hablar de usuario y obviamente hacer la diferenciación explícita entre usuario y cliente.

Finalmente, en lo personal, creo que cambiaría el orden de algunos capítulos.

Sobre cada capítulo

Nota previa: creo que la mayoría de los capítulos puede calificarse en uno de dos grupos: de mindset o de práctica. Los capítulos de mindset buscan explicar cuestiones de valores, principios, el espíritu de alguna cuestión casi sin entrar en cuestiones de prácticas o técnicas, aquí claramente están los dos primeros capítulos. Al mismo tiempo hay otros que se meten más concretamente en prácticas y técnicas, en cómo hacer concretamente alguna cuestión como es el caso del los capítulos de estimación (4) y retrospectivas (11). Dicho esto, los capítulos de mindset siguen siendo completamente válidos y casi que no requieren actualización. Por su parte los capítulos de prácticas, en su mayoría, requieren actualización ya sea por variaciones de las prácticas o por cambios en las herramientas.

Capítulo 1, «¿Por qué cambiar?»: es bastante filosófico/conceptual y si bien se podrían agregar algunas párrafos/secciones, creo que todo lo que dice sigue siendo válido.

Capítulo 2, «Iterativo por naturaleza»: también tiene un tinte bastante conceptual y apunta a explicar la necesidad de trabajar en forma iterativa. Me parece que hoy en día esta es una cuestión ampliamente aceptada aunque no en todos los casos correctamente implementada. Al igual que el capítulo 1, creo que se podría ampliar pero me parece que el contenido actual sigue siendo válido.

Capítulo 3, «Delineando el alcance»: explica las generalidades de las User Stories y la técnica de descubrimiento conocida como Visual Story Mapping(VSM). El contenido sigue siendo completamente válido y actual, aunque creo que amerita algunos ajustes relevantes. En primer lugar, cuando escribimos el libro no había una publicación formal de la técnica Visual Story Mapping, las fuentes disponibles eran algunos posts del blog del Jeff Patton (creador de la técnica) y de algunas otras personas que habían participado de alguna capacitación con el propio Patton. Al poco tiempo de la publicación de nuestro libro, finalmente Patton publicó un libro sobre esta técnica: User Story Mapping, Discover the Whole Story, build the right product. A partir de esto, nuestra descripción de la técnica difiere un poco de la descripción que hace Patton en su libro, lo cual no lo veo como un problema, nuestra descripción sigue siendo una herramienta válida y útil de comunicación/relevamiento. En este sentido creo que lo que sí le falta a nuestro libro (y en particular a este capítulo) es mostrar un ejemplo concreto del uso de la técnica. Finalmente algo que me suele ayudar mucho a entender el alcance de una funcionalidad es la técnica Example Mapping y por ello creo que agregaría una sección sobre la misma.

Capítulo 4, «Estimar no es predecir»: el contenido sigue siendo válido aunque mi práctica de estimación ha variado un poco. Creo que también que faltaría agregar algunos ejemplos concretos de las técnicas explicadas. Finalmente, si hubiera una nueva versión, sin duda agregaría alguna mención al movimiento #NoEstimates.

Capítulo 5, «Planificación constante»: aquí me parece que hay espacio para varios ajustes en línea con la idea de trabajar en un esquema de entrega continua. Planificamos el trabajo para toda la iteración pero esperando entregar los ítems apenas los vamos terminando sin esperar necesariamente al final de la iteración. Al mismo tiempo haría más énfasis en iteraciones cortas: una semana o a lo sumo dos. Creo que también es necesario ajustar la definición del slack pues me parece que no es precisa ni clara. Definitivamente agregaría algún apartado sobre técnicas slicing.

Capítulo 6, «Empezando por la aceptación»: este capítulo está muy bien y seguramente sea este el lugar para explicar con cierto detalle la técnica de Example Mapping. Este es uno de los capítulos que cambiaría de orden (lo pondría antes).

Capítulo 7, «Arquitectura y Diseño en emergencia»: gran parte de este capítulo habla de cuestiones que van más allá de agile, pero al margen de eso, su contenido sigue siendo actual.

Capítulo 8, «Probar, Probar, Probar»: trata de testing y dado que hace mención a varias herramientas requiere una actualización de las mismas. Al mismo tiempo creo que un punto para revisar es la taxonomía de pruebas, en lo personal, hoy en día no me convence del todo la taxonomía que escribimos.

Capítulo 9, «Esto está listo»: es más conceptual que práctico y ha envejecido bien. Nada que ajustar.

Capítulo 10, «Integrando el producto al instante»: al igual que el capítulo de arquitectura, tiene algunas cuestiones que van más allá de agile y al igual que el capítulo de pruebas hay cuestiones de herramientas a actualizar. Al mismo tiempo creo que falta mencionar más explícita y enfáticamente que hacer integración continua implica que todo el equipo trabaja simultáneamente sobre el mismo branch (o que si se crean branches, no deben vivir más de 1 día). Finalmente me resulta curioso que hablamos de feature flags sin utilizar el término feature flag.

Capítulo 11, «En retrospectiva»: es el más largo y si bien sigue siendo completamente válido, dista un poco de lo que es mi práctica actual de retrospectivas, principalmente la parte de preparación.

Capítulo 12, «Reuniendo al equipo»: creo que está muy bien, tal vez profundizaría sobre Pair-Programming (si no agregara un capítulo exclusivo para esta técnica).

Capítulo 13, «Irradiando Información»: muy bien, no creo que necesite cambios, tal vez un agregado para escenarios remotos.

Capítulo 14, «¿Quién manda a quién?»: es muy de mindset y sigue aplicando completamente.

Capítulo 15, «No hay como un buen ambiente»: me gusta mucho, sigue aplicando completamente tal como está aunque creo que faltaría agregar algo de operaciones y/o ambiente productivo.

Capítulo 16, «La fantasía de evitar los cambios»: completamente actual, nada que ajustar.

Capítulo 17, «Formalizando compromisos»: completamente actual, nada que ajustar.

Capítulo 18, «Construyendo con calidad día tras día»: completamente actual, nada que ajustar.

Capítulo 19, «Un día de desarrollo ágil»: creo que fue una muy buena idea para ejemplificar como fluye el día de un equipo trabajando con agile, sin embargo hoy en día creo que faltaría agregar alguna mención/situación relacionada a la operación/producción.

Capítulo 20, «Todo muy lindo pero…»: completamente actual, nada que ajustar.

Capítulo 21, «La riqueza de la diversidad»: completamente actual, nada que ajustar.

No sé si algún día escribiremos una segunda edición, pero en lo personal voy a escribir algunas línea relacionadas a los capítulos marcados en rojo y tal vez también para los naranjas.