Last Thursday afternoon I delivered my talk «Technical Practices Walkthrough for non-technical People» at Agile 2023 Conference.
The session was attended by an enthusiastic audience of over 100 participants, and I was delighted to see that nearly everyone stayed engaged until the very end. From the positive atmosphere in the room, I believe it was a successful and impactful session. I am glad to share that I accomplished all the objectives I had planned for the talk.
Overall, I feel gratified by the experience and want to express my gratitude to the Agile 2023 Conference organizers for letting me share my knowledge and insights.
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.
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.
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.
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.
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.
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
Blog de NicoPaez 