Mes: enero 2025

Curso online de TDD

Hace ya un par de años que decidí no dictar más cursos de TDD, sin embargo desde ese momento me encontré con varias situaciones en las que necesité de un material introductorio a TDD, a modo de nivelación, para poder explicar luego el uso de TDD en escenarios más avanzados/reales. Busqué pero no encontré ninguno que me resultara convincente, entonces decidí generar mi propio material.

Es por esto que estas últimas semana estuve trabajando en un curso en video de «Introducción a TDD» que ya está disponible en la plataforma Udemy.

Si bien el curso está armando con C# y Nunit, la tecnología termina siendo anecdótica pues todo lo explicado es completamente aplicable en otros stacks de tecnología y todo el código es fácilmente traducible.

La idea de este curso es explicar los fundamentos de esta técnica de desarrollo ¿Vas a podes con este curso utilizar TDD inmediatamente en tu trabajo de desarrollo cotidiano? Depende, sin duda te va servir para entender la técnica y aplicarla en ciertas partes de tu código, pero de ahí a poder utilizarla al 100% en escenarios «reales», hay un largo trecho, hace falta mucha práctica y también utilizar algunas técnicas que intencionalmente no están cubiertas en este curso. Justamente la idea es: 1) comenzar tomando este curso, 2) practicar e incluso intentar aplicar la técnica en algunas partes/momentos de tu trabajo, 3) tomar una curso/taller más avanzado que tengo planeado publicar para mediados de 2025 y que incluirá muchas de las cosas que habitualmente doy en mis cursos de ingeniería de software.

Si sos estudiante de FIUBA y tenés pensado tomar mi curso de Ingeniería de Software 2, te recomiendo hacer este curso a modo de nivelación/repaso, escribime desde tu cuenta @fi.uba.ar y te tramito un pase gratuito.

Los seguidores habituales de este blog, también pueden escribirme y les tramito un pase.

Revisión y ajustes de «Construcción de Software: una mirada ágil»

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.

Sobre la movida de la Agile Alliance y el PMI

El pasado 3 de enero se anunció «la unión» de la Agile Alliance (AA) al Project Management Institute (PMI) y por todos lados saltaron opiniones, muchas de ellas bastante críticas.

En lo personal el hecho en sí mismo no me resulta demasiado relevante. Al mismo tiempo lo que me llama la atención es la reacción «de la comunidad», muchos de los denominados agilistas.

En lo personal, he estudiado el PMBoK pero nunca me certifiqué como PMP ni fui parte del PMI. Por otro lado sí he tenido membresía de la Agile Alliance, ya que al ser speaker de su conferencia anual (Agile XX) solían otorgar una membresía como parte de los beneficios de speaker. Tampoco tengo ninguna certificación del universo Agile. En términos generales no soy partidario de las certificaciones, no les veo gran valor, pero eso es tema de otro post.

Respecto de la noticia en cuestión solo quiero compartir algunas preguntas para que el lector pueda reflexionar y sacar sus propias conclusiones:

¿Hasta qué punto estas organizaciones representan a los practicantes y a la práctica en sí misma? La misma pregunta podríamos hacerla para «la comunidad» ¿hasta qué punto la comunidad (la gente que organiza y participa activamente de eventos y del debate público) representa a los practicantes?

Aquellos que critican a la AA, ¿cuán involucrados están (o han estado) con la AA?

Cuando hacemos proyectos: gestionamos los proyectos o los proyectos nos gestionan a nosotros ¿qué preferimos?. Sin duda hay distintos enfoques para la gestión pero en lo personal me parece que algunos agilistas reniegan exageradamente de la gestión y en este sentido muchos han demonizado al PMI y su enfoque de gestión.

Sin duda que dentro de estos dos movimientos hay posiciones extremas. Podríamos pensar en los tradicionales gerentes de proyectos del mundo PMI y los fundamentalistas abrazadores de árboles dentro del mundo ágil. ¿Cuán representativos son estos estereotipos del grueso de los practicantes?

Una cuestión que sería importante tener presente es que el PMI como organización ha propuesto un enfoque de gestión que en cierto modo muchos ven como lejano, distante o incluso hasta contrario al enfoque de gestión de Agile. Debemos decir también que Agile surgió del mundo IT mientras que el PMI es mucho más amplio y por supuesto que no es lo mismo gestionar proyectos de IT que proyectos de Ingeniería Nuclear, Civil o Naval.

Finalmente, creo si leemos el comunicado dejando de lado cualquier prejuicio, el anuncio resulta interesante e incluso hasta prometedor. Veremos.

Una mirada ágil, 10 años después

Mi libro «Construcción de Software: una mirada ágil», que escribí con colegas de FIUBA, ya tiene más de 10 años. Lo publicamos en 2014 y desde ese momento algunas cuestiones han cambiado. Sin embargo creo que todo el contenido del libro es aún válido y por ello lo sigo usando en mis cursos. De hecho el libro está disponible gratuitamente en forma digital desde el año pasado, solo hay que completar este formulario y una copia registrada llega por correo en el transcurso de un par de horas.

Si bien el libro sige siendo actual, hay algunas cuestiones que en la actualidad suelo manejar de una forma distintas a la que quedó descripta en el libro. El auge de DevOps, las transformaciones digitales y la pandemia dispararon y/o aceleraron varios cambios haciendo algunas partes del libro cobren mayor relevancia y tal vez alguna otra ya no tengo tanto valor.

Cabe destacar que cuando escribimos el libro lo pensamos para un lector que posiblemente ya estaba familiarizado con el desarrollo de software tradicional y por ello en el libro apuntamos a destacar aquellos puntos en los que los métodos ágiles tenían una propuesta innovadora. Hoy en día los métodos ágiles son el estándar de facto (al menos desde la intención ya que en la práctica no todos los logran). Más aún, muchos de lo que empezaron en la profesión en los últimos años bien podrían ser denominados «nativos ágiles».

Esta semana empecé a releer todo el libro tomando algunas notas para una potencial segunda edición que incluya actualizaciones a algunos capítulos e incluso tal vez algún nuevo capítulo. En las próximas semanas, a medida que avance en la revisión, iré publicando mis notas «de actualización».

[off-topic] Políticos en la oposición

Hace un par de semanas me encontré con una compañera de la secundaria que fue diputada por el «Frente de Todos (contra todos)» y cuyo mandato terminó en el 2023. Hablando con ella sobre las medidas tomadas por el gobierno actual y sobre la inacción [1] de su espacio político, ella me dice «la gente votó a Milei, ahora que se lo banquen«. Esta respuesta me generó una mezcla muy variada de sensaciones: risa, bronca, impotencia y finalmente resignación.

No todo el mundo votó a Milei, más del 40% votó al Frente de Todos (contra todos) y con una expectativa que va más allá de ganar o no la elección. De una u otra forma, esa expectativa puede resumirse en que hagan algo para mejorar nuestra sociedad en línea con los valores y principios de su movimiento. De hecho, el puesto de presidente lo ganó Milei, pero hay varios legisladores que obtivieron una banca. Ojo, esto que digo no es solo para el Frente de Todos (contra todos) sino para todo movimiento: si te presentas a elecciones y alguien te vota entonces tenés una obligación con esos votantes. «No vale» que te quedes cruzado de brazos hasta la próxima elección y menos aún si ganaste una banca legislativa.

Y no me vengas con «estamos votando en contra», no alcanza, espero que traigas ideas, que te muevas, que hables con la gente, que acompañes, que traigas ideas porque con solo votar en contra no se construye nada.