Sobre la Guia Oficial de eXtreme Programming

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.

Sobre mi experiencia en Ingeniería de Software Continua @ UBA-Exactas

Ayer terminé la materia Ingeniería de Software Continua que dicté en calidad de Profesor Invitado en la Facultad de Ciencias Exactas y Naturales de la UBA. La materia estuvo en el contexto de la carrera de Ciencias de la Computación, una carrera con un foco muy científico/algoritmico y bastante distinta a las carreras de FIUBA.

Tal como lo había adelantado, la materia fue en gran medida un recorte de MeMo2.

Inicialmente tuve unos 12 inscriptos, pero solo asistieron 9 a la primera clase y finalmente fueron 8 los que cursaron la materia entera. Solo 7 aprobaron la materia (el octavo asistió a todas las clases pero desaprobó varias tareas). Fueron 8 clases (una por semana) de 3 horas cada una , más una fecha de final. El final fue en parte un oral tradicional y en parte una dinámica colectiva en línea con mi idea de la evaluación como espacio de aprendizaje.

Al igual que en MeMo2, utilicé una estrategia de aula invertida y extendida, con soporte de Canvas, GitLab y GoogleGroups.

Durante la cursada tuvimos 31 tareas que incluyeron principalmente lecturas, videos y desarrollo. Fueron tareas 28 individuales, 2 en parejas y 1 en equipos de 4. Respecto de la dedicación extra clase y según lo reportado por los propios alumnos en sus tableros personales (cada alumno tenia un tablero de tareas al estilo Trello), representó en promedio unas ~49 horas repartidas a lo largo de 8 semanas. Un total de ~6 horas semanales.

Como de costumbre en mis cursos, hice una encuesta anónima al finalizar, comparto algunos números de dicha encuesta:

  • Evaluación general de la materia: 9 / 10
  • Claridad del docente: 4,8 / 5
  • Dinámica de clases: 5 / 5
  • Materiales de estudio: 4,8 / 5
  • Net Promoter Score: 83 (esta es una métrica que puede tomar valores en el rango -100 +100, con lo cual un 83 es muy bueno)

Mención aparte para la infraestructura. El pabellón «0+infinito» es fantástico. Además de ser moderno es super luminoso (lo cual es un contraste fuerte para los que venimos de FIUBA donde nuestros edificios tienen tanta luz como una baticueva). Hay aulas de distinto tipo, algunas tipo auditorio, otras con pupitres individuales y otras con mesas y sillas móviles. Precisamente una de estas últimas pedí explícitamente para dictar la materia de forma de poder facilitar las actividades de trabajo en grupo durante la clase.

Todas las aulas tienen proyector incorporado con pantallas retráctiles para proyección. Pero curiosamente la conexión a los proyectores no es vía cable sino vía wifi. Esto me resultó un poco incómodo.

Finalmente los pizarrones son los clásicos de madera para escribir con tiza, esto me resultó incomodo pues venia acostumbrado a las pizzaras blancas para escribir con marcador.

De todas formas mis incomodidades fueron mínimas, el aula luminosa, amplia y con mesas móviles que enamoraron.

Personalmente quedé muy contento con la experiencia, fue interesante tener contacto con una audiencia distinta y «vivir un poquito» en otra institución.

Quiero cerrar este post con agradecimientos:

  • A Ricardo Rodríguez, profesor de Exactas, que me ayudo con todas las cuestiones administrativas/operativas.
  • A Juan Pablo Galeotti, Director del departamento de Computación quien me hizo la invitación formal para postularme como Profesor Invitado
  • A Sebastián Uchitel, profesor de Exactas, que fue quien tuvo la idea inicial de que diera clases allí.
  • A los alumnos que se «arriesgaron» a anotarse en una materia desconocida con un profesor externo a la institución.

Meetup: Recorrida de Prácticas Técnicas para Gente no Técnica

La semana próxima, miércoles 19 a las 8:15 AM, estaré dando esta charla gratuita orientada a aquellas personas que trabajan con equipos de desarrollo de software pero que no tienen un perfil técnico. En la charla repasaremos la terminología y prácticas técnicas de uso habitual en equipos de desarrollo en la actualidad al mismo tiempo que haré una demostración en vivo del desarrollo y despliegue en la nube de una funcionalidad.

Los interesadxs en participar pueden registrase en el Meetup de Agiles Argentina para recibir el link de acceso.

Esta charla es la versión en castellano de la que estaré dando a fin de mes en la conferencia Agile 2023.

Cierre de cuatrimestre 2023-1 en MeMo2 @ FIUBA

Cerramos un cuatrimestre más con algunas particularidades. Una de las más destacadas fue el horario de cursada: dimos la materia en horario matutino de 8 a 11 hs. Otra de las particularidades fue la relación entre la cantidad de alumnos y la cantidad de docentes que nos permitió dar feedback bastante detallado en las entregas de los alumnos.

El feedback de los alumnos en la encuesta de cierre la cual nos arrojó los siguientes números:

  • La encuesta fue contestada por la totalidad de los alumnos que completaron el curso (10)
  • La evaluación general de la materia (en promedio) dio: 8,8 lo cual es menor que el cuatrimestre anterior (9,1) pero es mayor al promedio histórico (8,4). Adicionalmente el desvío fue mínimo: nadie calificó la materia con menos de 8.
  • Respecto del porcentaje de clases presenciales/virtuales, 9 alumnos lo consideraron apropiado mientras que solo 1 hubiera preferido más virtualidad.
  • Las otras dimensiones de evaluación de la materia también resultaron muy positivas (algunas incluso con valores record): claridad de los docentes: 4,6/5; Conocimientos de los docentes: 5 /5; Dinámica de las clase: 4,4/5; Materiales de estudio: 4/5.
  • El NPS nos dio 60 (esta es una métrica que puede tomar valores en el rango -100 +100, con lo cual un 60 es muy bueno)

De la restrospectiva de cierre nos quedamos con los siguientes accionables:

  • Agregar un ejercicio individual con el bot para familiarizarse antes del TP2
  • Dar un video o clase mostrando el flow de desarrollo guiado por pruebas desde el bot hasta la api
  • Dar la opción de usar infra gratuita o paga (por los propios alumnos) y considerar también que los propios alumnos gestionen su infra

Algunos otros números:

  • Respecto a la dedicación, tuvimos 28 clases de entre 2 y 3 horas cada una. Por otro lado la dedicación extra clase, en promedio por alumno, fue de un total de 116 horas (51 horas de tareas individuales, 12 horas de tp1 y 53 horas de tp2) repartidas en 16 semanas. Esto nos da unas 7,25 horas de dedicación semanal extra clase por alumno a lo largo de todo el cuatrimestre. Claro está que en este promedio hay semanas de 2 horas de dedicación extra clase y hay otras de 15 horas.
  • Tuvimos 42 tareas individuales, 1 en parejas y 2 TPs.
  • Tuvimos 14 inscriptos, solo 11 que asistieron alguna clase y finalmente 10 que aprobaron la cursada.
  • La nota promedio de aprobación de cursada fue 8.

Guía Oficial de Scrum, ¡chau!

En mis materias vengo utilizando la Guía Oficial de Scrum pero a partir de dos charlas distintas que tuve con colegas en la última semana he decidido dejar de usarla.

Resulta que una de las modificaciones «recientes» de la guía oficial de Scrum es que elimina los roles. En realidad no elimina los roles conceptualmente, sino que elimina el término «rol» y en su lugar habla de responsabilidades (accountabilities), o sea: «Scrum Master» es un conjunto de responsabilidades, «Product Owner» es un conjunto de responsabilidades, etc. Según me comentaban mis colegas expertos en Scrum (cosa que yo no soy) es para evitar la usual creencia de que las responsabilidades de Scrum Master deben ser tomadas por una única persona y que esa persona debe dedicarse de forma exclusiva a ello. Pero precisamente eso es un rol, «un conjunto de responsabilidades». Entonces si conceptualmente hablamos de roles pero no queremos usar el término roles, creo que lo que se está haciendo es una «precarización» del vocabulario y al mismo tiempo se genera ruido y confusión para aquellos que sabemos lo que es un rol.

Por otro lado tengo la sensación que la guía cada vez tiene menos cuestiones relacionadas al desarrollo de software, posiblemente consecuencia del uso de Agile/Scrum fuera de contexto de IT. Pero dado que lo que estudiamos en mi materias es desarrollo de software, estas nuevas versiones de la Guía de Scrum, me resultan cada vez menos útiles.

Es por esto que de ahora en más ya no usaré la guía oficial de Scrum como material de estudio sino (algunos de) los siguientes materiales:

  • El artículo «Scrum Development Process» de Ken Schwaber de los años 90
  • El libro «Scrum and XP from the treches» de Henrik Kniberg
  • El resumen de Scrum de mi libro «Construcción de Software»

De Chicago a Londres, artículo aceptado

En línea con la estrategia de enseñanza de TDD que seguimos en FIUBA y UNTreF, escribí este artículo que fue aceptado en el Simposio Argentino de Educación en Informática de las Jornadas Argentinas de Informática, JAIIO 52. Al margen de la presentación del artículo que haré en el contexto del Simposio, tengo planeado hacer un charla abierta (meet-up online) para compartir esta experiencia. Si están interesados esten atentos a este canal.

La paradoja de los Ingenieros de Software

Es habitual hoy en día encontrar gente «autodenominándose» Software Engineer sin tener un título formal de ingeniero o disciplina universitaria aledaña. Personalmente no creo que sea una cuestión relevante pues a diferencia de lo que ocurre con otras ingenierías, la ingenieria de software no es una disciplina regulada, o sea: para construir un puente es necesario el aval legal de un ingeniero civil pero para construir un software no es necesario el aval legal de un ingeniero de software.

Por otro lado, algunos de los que somos Software Engineer «con título», dudamos de la denominación «ingeniero» o mejor dicho dudamos de que el Desarrollo de Software deba ser considerado formalmente una ingeniería. He aquí la paradoja:

No ingenieros que quieren ser ingenieros e ingenieros que dudan de serlo

Varios referentes de la disciplina se han pronunciado respecto de este dilema, uno de ellos es David Parnas en su artículo «Software Engineering – Missing in Action: A Personal Perspective«. Otro autor que trata la cuestión es Pete McBreen en su libro Software Craftsmanship.

Esta visión «ingenieril» del desarrollo de software llevó a que las carreras de Ingeniería Informática/Sistemas en Argentina tengan varias materias de ciencia básica (física y química entre otras) compartidas las demás ingenierías. En lo personal y viendo la carrera que yo cursé me hubiera gustando tener menos contenido ciencia básica y más contenido de específico de informática.

En fin, los años pasan y la polémica se renueva.

Role Smell: Test Automation Engineer

Este es un rol viene ganando cada vez más popularidad desde el auge de DevOps. Ocurre que en muchas organizaciones el testing lo realiza gente que no sabe programar y por ende no puede automatizar los tests que realizan (en realidad es posible utilizar herramientas del tipo record & play, pero en general esa estrategia tiene muchas limitaciones).

En un par ocasiones trabajé con equipos donde había gente en este rol y sinceramente no me pareció una buena idea. En todos los casos la dinámica de trabajo era:

  • en primera instancia un tester (o varios) definía los casos de prueba y los ejecutaba manualmente
  • luego, generalmente en la siguiente iteración, un automatizador (test automation engineer) se encargaba de automatizar algunos de los casos de prueba previamente definidos

De entrada esto me hizo recordar a la época en que una persona hablaba con el usuario (analista), escribía un documento de casos de uso y luego otra persona (desarrollador) leía el documento y programaba la funcionalidad. Si bien aún hoy hay equipos trabajando de esta forma creo que son minoría. Por algo será.

Otra cuestión que me resultaba poderosamente llamativa era la desconexión total entre estos automatizadores y los desarrolladores.

También ocurría que si en una determinada iteración no había trabajo de automatización, esos automatizadores, a pesar de saber programar, no se ponían a programar la aplicación.

Finalmente lo que para mí resultaba más perjudicial: toda la automatización de pruebas quedaba en manos de estos automatizadores, o sea: los desarrolladores no escribían ningún tipo de prueba automatizada, ni siquiera unitarias. Es bien sabido que para tener un buen flujo de entrega continua es necesario tener pruebas automatizadas, pero también es necesario que parte de ese trabajo de automatización lo hagan los propios desarrolladores comenzando por las pruebas unitarias.

En fin, no digo que tener un rol de Test Automation Engineering sea algo malo ni incorrecto. Solo digo que las dinámicas de trabajo que he visto en equipos que tienen personas en dicho rol, no generan un buen flujo de entrega continua. No digo que siempre sea así, pero sí lo fue en los casos que vi de cerca. Dicho esto, mi recomendación es que si tienes en tu equipo una persona en este rol o estás pensando en incorporarla, tal vez deberías detenerte un momento a pensar en la dinámica de trabajo del equipo.

De feature-branches y Pull-Request a Continuous Delivery

El uso de feature branches en conjunto con pull-request es una práctica muy habitual en la actualidad, a pesar de que en general termina siendo un impedimento para implementar Continuous Delivery. Esto resulta en gran medida curioso porque mucha gente que utiliza feature branches y pull-request cree que hace Continuous Delivery.

Por definición Continuous Delivery implica Continuous Integración lo cual a su vez implica Trunk-Based Development, o sea: no hacer branches que duren más de un día. Siendo conceptualmente estrictos uno podría hacer feature-branches & pull-request y aún así hacer Continuous Delivery, pero entonces los branches y pull-request no deberían extenderse más de un 1 día, situación que no condice con lo que suele verse en la industria mayoritariamente en la actualidad.

Desde hace varios par de meses vengo trabajando con un equipo muy maduro en un sistema que ya está productivo hace años. Trabajan con una dinámica de feature-branches, pull-requests bloqueantes y puesta en producción al final de la iteración. Dado que la iteración dura 2 semanas, esta dinámica implica que todo ítem, por simple que sea, tardar 2 semanas en llegar a producción. A su vez esto provoca que cada release a producción sea bastante grande pues contiene todo el trabajo acumulado durante 2 semanas. Y obviamente, cuanto más grande, más riesgoso. En parte como consecuencia de esto cada release a producción implica un downtime del sistema lo que obliga notificar a los usuarios sobre el tiempo de downtime y al mismo tiempo obliga que el release se realice fuera del horario de oficina para así afectar lo menos posible a los usuarios.

Dado que a mi parecer el equipo está bien consolidado, cuenta con un interesante set de pruebas automatizadas, el producto está estable, hay un proceso formal de testing y release, considero que están en condiciones de transicionar a un esquema de Continuous Delivery y por ello la semana pasada le propuse hacer un experimento. La propuesta es identificar un par de items de backlog, de bajo riesgo, para liberarlos (ponerlos en producción) tan pronto estén listos. De esta forma se entrega valor al negocio más rápidamente y al mismo tiempo el release de fin de iteración es más pequeño y menos riesgoso.

Debut en la era del podcast y de los vivos

El formato «vivo» creo que se popularizó con Twitch y digo creo porque sinceramente no es un formato que suela consumir. El formato «podcast» por su parte, ya lleva un buen tiempo en la red y si bien suelo consumir algunos podcast recién ahora pasé del otro lado para tomar el micrófono y ser protagonista.

Es que ayer salió publicado el episodio #30 del podcast Agile Latam en el cual tuve una interesante conversación sobre testing con Ettiane Salamanca de Inspirit. Pueden encontrarlo en Spotify.

Por otro lado, la semana pasada participé de mi primer vivo junto a Martin Alaimo con quien estuvimos hablando en LinkedIn sobre «Definition of Done«, lo pueden ver aquí.

Mi próxima intervención será durante julio en el podcast de otra empresa amiga.