Este año me he propuesto completar mi tesis de maestría. Ya tengo el proyecto planteado y aprobado. La temática del mismo tiene que ver con desarrollar una propuesta para la enseñanza del desarrollo guiado por pruebas. Y si bien en el título de este post menciono TDD, Test-Driven Development, mi planteo es bastante más amplio que el clásico ciclo Red-Green-Refactor, mi idea es centrarme en el desarrollo guiado por pruebas pero desde una perspectiva más «holística» similar la que plantean Freeman y & Pryce en GOOS, viendo el desarrollo guiado por pruebas como un proceso de construcción de software que va más allá del diseño, la codificación y la prueba y que abarca también cuestiones de análisis, requerimientos, deployment y delivery.
La tesis en sí, es la forma de comunicar el trabajo de investigación que uno realiza. Dicho trabajo de investigación puede extenderse por meses o incluso años. Típicamente los trabajos de tesis de maestrías académicas son planteados para ser completados en un año calendario, pero eso no siempre se cumple. En mi caso armé un calendario de trabajo de apróximadamente un un año, pero dado que un año me parece un marco de tiempo demasiado extenso, plantee algunos hitos intermedios representados por publicaciones de las distintas cuestiones que vaya resolviendo.
Más allá de las publicaciones formales que realice, mi idea es ir compartiendo en este espacio algunos de mis avances. En este sentido va este primer post.
Dicho esto, si están interesados en la enseñanza, la prácticas y el aprendizaje de la técnica de desarrollo guiado por pruebas, les recomiendo estén atentos a este espacio.
Se considera Millennials a aquellos nacidos entre comienzos de los 80 y mediados de los 90. Los millennials y pre-millennials que se dedicaron a la programación trabajaron en una web distinta. Muchos vivimos en la web 1.0.
No había programadores de front. Yo creo que no había una «división» tan marcada de programadores. Recuedo los «duelos» Java vs. Net, pero al margen de eso creo que había «programadores web» y «programadores a secas».
No había estándares web, cada navegador se comportaba distinto al interpretar el código js/css/html.
Tal vez como consecuencia de lo anterior, había «engendros» (como Applets y ActiveX) que corrían dentro del navegador pero que estaban programados server-side y no es que uno escribiera código Java que luego era traducido a js/css/html, sino que los navegadores tenían complementos que les permitían ejecutar binarios (jar, dlls, etc). Pero igualmente era raro, porque estos complementos tampoco corrían en todos los navegadores. Yo hablo de esto en pasado pero sin duda hay soluciones de este tipo que aún hoy están en funcionamiento.
Tampoco había la variedad de navegadores que tenemos hoy en día.
Y finalmente, nadie tomaba JavaScript muy seriamente, nadie se dedicaba a JavaScript. Un programador que hacía web trabajaba con Php, Asp, Perl, Java o incluso C++ (haciendo los denominados CGIs) y si por alguna razón necesitaba utilizar JavaScript lo googleable en el momento que lo necesitaba. Como el soporte de JavaScript ofrecido por los navegadores no era estándar, tampoco se podía hacer demasiado en JavaScript (técnicamente se podía pero era muy costoso y terminaba siendo insano).
Creo que muchos de esta generación intentamos por un tiempo escaparle a JavaScript. De hecho algunos aún siguen intentando escapar. Más aún, algunos vendors insistieron mucho tiempo en proveer soluciones para que el programador no tenga que tocar JavaScript. Soluciones como las provistas por Microsoft con las primeras versiones de ASP.NET iban aún más allá, posibilitaban al programador trabajar exclusivamente con C# sin tener que meterse con las tecnologías web y dejar en manos de la plataforma la generación del código (js/css/html) que finalmente se ejecutaba en el navegador. Menciono a Microsoft porque ahí está el grueso de mi experiencia, pero otros vendors siguieron estrategias análogas. Y menciono explícitamente «las primeras versiones de ASP.NET» porque creo que en un punto el propio Microsoft tomó conciencia de las limitaciones de ese enfoque y cambió el rumbo. Ya desde hace años Microsoft viene apostando al desarrollo client-side dándole un gran impulso a TypeScript.
Personalmente me rendí a JavaScript hace varios años pero los proyectos en los que estuve involucrado me mantuvieron lejos del navegador. Profundicé mi conocimiento de JavaScript a partir de algunas cosillas que hice con Node y alguna otra cosilla que hice principalmente con Angular.
Como ya mencioné en algún post anterior, hoy por hoy estoy metiéndome muy de lleno en el mundo de desarrollo JavaScript client-side y es por ello que en los próximos días/meses iré compartiendo recursos de lo que vaya aprendiendo. En general estarán enfocados desde la perspectiva pre-millennials ya que esa es mi procedencia.
Creo que hay mucho material de JavaScript/Frontend dando vueltas por la web pero mi sensación es que la gran mayoría es material introductorio y enfocado en programadores que están dando sus primeros pasos en la profesión. Al mismo tiempo la mayoría del material que veo es para el escenario de creación de aplicaciones desde cero, lo cual tiene mucho sentido pero hay también una parte de la población que tenemos que lidiar con aplicaciones existentes y para esos escenarios creo que no abunda el material. Esta percepción motiva en gran medida mi intención de compartir lo que vaya descubriendo.
Nuestra aplicación Django de 2014 tiene un componente de código JavaScript (client-side) construido a la vieja usanza, con pruebas y modularizado, pero a la viaja usanza. Las pruebas estan escritas en Jasmine/Karma y la modularización está hecha en base «namespaces«. El bundle productivo es generado por Django.
A partir de ciertas necesidades de evolución funcional y de mejorar la experiencia de usuario decidimos llevar la parte visual de nuestro componente a React. Alguien podría preguntarse porqué React y no algún otro como Vue o Angular. La elección está basada en dos cuestiones. En primer lugar no queremos hacer una SPA, sino simplemente reemplazar componente dentro de un sitio existente. Este es uno de los escenarios explícitamente atacados por React a punto tal que ya en el tutorial inicial nos muestra como hacerlo. El otro tema es que en breve tendremos que rehacer nuestra aplicación mobile para lo cual apuntamos a React Native así que encarar este componente con React nos resultó una conveniente primera aproximación al mundo React.
A la pasada, aprovechamos y, decidimos actualizar el stack del proyecto. En primer lugar decidimos quedarnos en JavaScript (en lugar de pasar TypeScript) al mismo tiempo elegimos NPM + WebPack + Babel. También pasamos de Jasmine a Jest para los tests.
Uuuufffff. Durísimo. Si bien yo ya estaba familiarizado con lenguaje JavaScript (sintáxis, características del lenguaje, etc) estaba bastante ajeno a las cuestiones de tooling (frameworks, gestor de paquetes, bundlers, transpilers, linters, etc, etc) y meterme con estas cuestiones me ha resultado bastante desgastante. Al mismo tiempo si bien había hecho algún proyectito menor con JavaScript «moderno», en esos casos había comenzado desde cero utilizando un stack preconfigurado donde ya de entrada tenemos todo el tooling cableado. Pero en este caso teníamos una base de código existente y tuvimos que ir haciendo nosotros mismos la elección y cableado de todo el tooling. La parte positiva de esto es que nos permitió entender ciertas cuestiones con un nivel de detalle tal que al usar el stack prearmado uno ni se entera.
La cantidad de opciones existente y el vértigo de evolución de las herramientas JavaScript creo que no tiene igual en otros lenguajes. Esto lleva a que las posibilidades combinación de herramientas sea realmente muy grande y a la hora de tener que buscar información de un stack específico, todo sea más trabajoso. Esto queda muy en evidencia cuando lo comparamos con otros lenguajes donde las opciones son mucho más acotadas. Personalmente vengo muy acostumbrado del mundo .Net/C# donde en general hay una forma de hacer las cosas, si bien en ocasiones existen alternativas la comunidad ha decantado claramente hacía ciertas opciones que se han convertido en un estándar de facto. En el medio de toda esta movida fui a dar con la página stateofjs.com que realizada una encuesta y provee un interesante informe sobre la evolución del uso de las herramientas en el mundo JavaScript que confirma en cierto modo mi sensación de vértigo.
En fin, el proyecto ya está encaminado y en siguientes post iré compartiendo como hemos resulto distintas cuestiones particulares.
Hace ya tiempo venía dando vueltas en mi cabeza la idea de una materia para estudiar ciertas cuestiones «avanzadas» y en un punto hasta filosóficas de nuestra profesión. Dada la gran mezcolanza de temas no lograba darle nombre. Se me ocurrieron nombres como «Desarrollo Profesional de Software», «Programación Avanzada» y «Ejercicio profesional del desarrollo de software» pero ninguno me convencía. Finalmente, el pasado fin de semana me puse a escribir una descripción de los temas a abordar y mientras escribía la bibliografía de referencia me resultó evidente que el título debería ser «Artesanía de Software».
La idea de esta materia es estudiar ciertas cuestiones del ejercicio profesional del desarrollo de software. Es una materia avanzada, no por la complejidad de los temas a abordar sino por el hecho de que para poder abordarlos con profundidad y con una visión crítica es necesario tener algunos años de experiencia en el ejercicio de la profesión y más específicamente en programación. O sea, esta no es una materia para gerentes, analistas o maquetadores, es una materia para programadores.
Si tuviera que ubicar esta materia en el plan de estudio, sería una materia optativa del último año de la carrera.
Sobre los temas
Si miramos los planes de estudio de las carreras de sistemas vemos varias materias de programación: Algoritmos y Programación, Paradigmas de Programación, Programación Concurrente, Programación Orientada a Objetos, Taller de Programación, etc. Cada una de estas materias aborda alguna técnica o aspecto de la programación, pero hay ciertas cuestiones que son en cierto modo transversales a todas estas materias.
Entre estas cuestiones transversales hay temas tan básicos como la elección de los nombres de variables que uno podría pensar que deberían abordarse en las primeras materias de programación pero que en ocasiones no se abordan en profundidad o que incluso cuando sí se abordan, son cuestiones que resulta interesante replanteantearse luego de un par de años programando.
También tenemos algunos otros temas relacionados al versionado que es algo que utilizamos a diario pero que muchas veces lo hacemos en modo automático y sin considerar qué estamos metiendo en cada commit, que mensaje de commit ponemos, con que criterio creamos branches, etc.
Uno de los temas más polémicos y filosóficos que trata la materia es la discusión del desarrollo de software como ingeniería, ciencia u oficio.
Algunos otros temas a cubrir:
Profesionalismo, ética y contratos
Freelancing
Work-life balance
Aprender, enseñar, aprender a aprender y aprender a enseñar
Estimación, No-estimación, presupuestos y planificación
Lenguajes y paradigmas
Tipado estático vs. tipado dinámico vs. no tipado
Código de aplicación y código de pruebas
Las pruebas como documentación
Java, el nuevo cobol
El ascenso de JavaScript
Smalltalk…..
Mantenimiento y evolución
Trabajo con código legado
Código de infraestructura
Versionado y trazabilidad
Revisiones, Pairing y Mobbing
No-code / Low-code
Modalidad de cursada
La materia se dicta en una modalidad de aula invertida durante 16 semanas con un encuentro online de 3 horas por semana y con una dedicación estimada extra clase de unas 4 horas semanales.
La materia incluye lecturas (varias), videos (no tantos), código (tanto para leer y como para escribir) y debate (espero que mucho).
Participantes
Los candidatos a cursar la materia deberían:
Estar a menos de 4 materias para recibirse de una carrera de grado de sistemas/computación.
Tener al menos 3 años de experiencia programando profesionalmente en la industria.
Sentirse cómodos trabajando con al menos dos lenguajes de programación y tener alguna experiencia en al menos otros dos lenguajes (no cuenta HTML, CSS, ni bash).
Bibliografía
Estos son algunas de la fuentes y materiales en los que está basada la materia:
The Pragmatic Programmer, de Hunt & Thomas
Software Craftsmanship: The New Imperative, de Pete McBreen
Code Complete, de Steve McConnell
The Software Craftsman, de Sandro Mancuso
Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, de Oshineye & Hoover
The Design of the Design, de Brooks
Atomic Habits, de James Clear
Implementation Patterns, de Beck
Refactoring to Patterns, de Kerievsky
xUnit Test Patterns, de Meszaros
A esto se suman varios artículos (algunos formales y otros no tanto) y algunos videos.
Pre-Inscripción
Si el lector llegó hasta este punto, posiblemente se esté preguntando donde se dicta esta materia. La respuesta es que no lo sé. Por el momento tengo armada la estructura de la materia, algunos materiales, muchas ideas pero no tengo institución para dictarla. Claro que podría hacer un curso «no académico» y dictar esto por mi cuenta, pero precisamente lo pensé como materia porque me parece que es un contenido faltante en las carreras de grado de sistemas/computación. Creo que estos temas deben ser parte de la formación académica de los profesionales de esta disciplina.
En fin, por lo pronto y mientras veo como meter esto en una institución, si estás interesado en tomar este curso te invito a que completes este formulario y en cuanto tenga más definiciones me contactaré contigo.
Hace unos 6 meses comencé a trabajar en un proyecto Python/Django. Si bien yo ya tenía cierta familiaridad con Python, nunca había trabajando con Django, la mayoría de las cosas que había hecho a nivel profesional tenían que ver con scripts para automatizar tareas de deployment.
Para ser justo, me parece que antes de compartir mis reflexiones debo explicar algunas cuestiones de contexto que pueden tener cierta influencia en mis percepciones.
El primer punto es importante: no estuve trabajando en un proyecto nuevo, sino en una aplicación existente. Más concretamente una aplicación creada hace ya varios años con Python 2.7 y Django 1.4.
La aplicación tiene una cantidad no despreciable de código JavaScript, no React, no Angular, JavaScript puro, «vanilla JavaScript» condimentado apenas con jQuery. Esto es un punto no menor, porque parte del tiempo lo he pasado trabajando con código JavaScript en lugar de Python.
La aplicación cuenta con unos 1000 test automatizados del código python y también tiene tests automatizadas de parte del código JavaScript.
Esta aplicación Django es la parte central de un ecosistemas de aplicaciones, la mayoría de ellas también construidas con Python pero no necesariamente con Django.
Finalmente el último detalle contextual es que las funcionalidades en las que estuve trabajando tuvieron que ver con cuestiones «algorítmicas/lógica de negocio», o sea, no tuve que modificar el modelo de datos.
Aclarado el contexto ahora sí mis percepciones. Definitivamente Django es a Python lo que Rails es Ruby con todo lo bueno y lo malo que eso pueda implicar. Django es un framework orientado a la creación de sistemas de información (CRUD) y como tal ofrece muchas facilidades para con relativamente poco código resolver muchas de las cuestiones planteadas por este tipo de aplicaciones: validaciones, persistencia de datos, envío de mails, autenticación, manejo de usuarios, sistema de backoffice/admin, etc. Todo esto complementado con una funcionalidad de scaffolding que genera una porción importante de nuestro código.
Todas estas facilidades que provee Django no son «gratis», tienen un costo asociado el cual implica que la aplicación tiene cierta estructura que en ocasiones puede ser un dolor de cabeza. En este sentido un punto que me resulta particularmente molesto es el grado de acoplamiento con la base de datos que dificulta la escritura de pruebas unitarias ya que al momento de escribir pruebas que utilicen las entidades de negocio (lo que Django llama models) es necesario tener una conexión con la base de datos. Otra cuestión que me resulta muy molesta es la convención de utilizar «pocos archivos pero muy grandes», ejemplo: en vez de tener un archivo por cada clase, un archivo por cada controller, etc, la propuesta es tener un archivo models con todas las clases de entidades, un archivo views con todos los controllers, etc, etc.
Por otro lado hay dos cuestiones que me resultan fantásticas: el debugger de línea de comando (que en realidad es un funcionalidad de Python, no de Django) y el Django shell, que al igual que el Rails console, nos permite manipular de forma interactiva los objetos de nuestra aplicación.
Otra cuestión, en este tipo de frameworks, es el manejo de la persistencia. Al igual que Rails, la persistencia está implementada al estilo ActiveRecord. Esto es que cada entidad/model hereda de una clase base provista por el framework la cual nos provee todo un conjunto de métodos para «llevar y traer» objetos de la base de datos y de esta forma no tenemos que lidiar con la escritura de SQL.
Finalmente el último punto que quiero mencionar es la sensación (y resalto que es una sensación) de que Django «nos lleva a hacer aplicaciones grandes» en contraposición con las tendencias actuales de micro-servicios. Ojo, no digo que el frameworks nos obligue a hacer aplicaciones grandes, sino que algunas de las funcionalidades que provee (como la posibilidad de tener varias aplicaciones dentro de un mismo proyecto) resulta muy tentador para seguir trabajando dentro del mismo proyecto/artefacto en lugar de crear un nuevo proyecto independiente.
En fin, si bien hay cuestiones que no me gustan nada, hay algunas otras que están muy bien.
En esta ocasión voy a referirme a un conjunto de libros que en algún momento (y por puro prejuicio) los habria categorizado como libros de «autoayuda» sin siquiera tener en claro que implica «autoayuda». El punto es que más allá de la categoría son libros que me han resultado muy útiles e interesantes.
El primero de estos libros que quiero mencionar lo leí allá por 2008: Los 7 hábitos de la gente altamente efectiva. Ya en aquel momento este libro era un best seller. Tanto es así que a pesar de que originalmente está en inglés, también ha sido traducido a varios idiomas. De hecho, yo lo leí en castellano. Su autor, Stephen Covey, ha escrito varios libros más en relación a esta misma temática. A partir de este libro fue que empecé a trabajar la formación de ciertos hábitos en mi materia de Ingeniería de Software.
Otro libro que también leí por aquella época es el ya clásico de Francesco Cirillo: «The Pomodoro Technique«. Esta técnica ha cobrado tal popularidad que se han generado una importante cantidad de recursos relacionados entre los que se incluyen varios videos, apps y cursos. Personalmente esta técnica me ha ayudado mucho a enfocar mi trabajo y suelo recomendarla a mis alumnos y colegas. De hecho recuerdo que en la época que dictaba Ingeniería de Software en UNQ, esta era una de las lecturas obligatorias de la materia (mientras escribo estas líneas creo que debería incluir esta lectura en mi materia de UBA).
Finalmente esta semana terminé de leer el libro «Atomic Habits» de James Clear. Este lo compré a comienzos de 2020 a partir de una mención que hizo en Twitter mi colega @hhiroshi. El libro me gustó mucho por varias cuestiones. Encontré justificación «teórica» para varias cuestiones que suelo hacer. También encontré muchas cuestiones para experimentar. Muchos de los capítulos comienzan con anécdotas/historias que hacen muy llevadera la lectura. Un tema no menor en relación con la lectura es la extensión de los capítulos, tienen una extensión tal que permite completar un capítulo en unos 15 minutos (al menos a mi ritmo de lectura). El tema de la generación de hábitos me parece fundamental para trabajar de forma más efectiva. El tener incorporadas ciertas tareas como hábitos hace que uno pueda ejecutar esas tareas de forma «automática» sin necesidad de poner energía/atención extra y de esa forma poder ahorrar esa energía/atención para dedicarla a otras cuestiones de mayor prioridad/valor. Este libro ofrece todo un marco teórico junto con técnicas concretas para generar hábitos y también para eliminar hábitos.
Se fue el segundo año de pandemia, pero a diferencia del anterior, este año ya estaba planeado para trabajar en forma remota. Y así fue, solo fui a la universidad para la clase de cierre de Ingeniería de Software @UNTreF y solo fui a la oficina 2 días para una reunión de planificación estratégica y para el almuerzo de fin de año.
Mi tiempo total de trabajo (en términos de horas facturables) este año fue radicalmente menor que el año anterior. A su vez, este año por primera vez en mi carrera tuve una dedicación pareja de trabajo en industria y trabajo en academia.
Dedicación Industria vs. Academia
Dentro de mi trabajo en la industria gran parte fue dedicada a cuestiones de capacitación. Lo referente al trabajo de consultoría fue principalmente relacionado a cuestiones de DevOps/Automatización de Pruebas/Infra/Deployment.
Dedicación de actividades de industria
En lo que respecta a las actividades de academia lo principal fue el dictado de mis materias pero adicionalmente a eso hice otra actividades como:
Dirección / Evaluación de trabajos finales de carrera
En lo que respecta a participación en conferencias este año participé en muy pocas. Sinceramente las conferencias en formato virtual no me resultan atractivas. Presenté sesiones en XP, Agiles Latam, Agile Brazil y Agiles en Español.
En lo que respecta a publicaciones apenas hice dos publicaciones pero ambas resultaron muy interesantes. Publiqué un reporte de experiencia en la conferencia XP y publiqué mi primer artículo en un journal: nuestro artículo final del proyecto Helena «What Makes Agile Software Development Agile» fue publicado en el journal IEEE Transactions on Software Engineering.
Un detalle importante a mencionar es que se trata de un workshop académico, o sea: no es típico de taller que podemos encontrar en el contexto de una conferencia de industria como podría ser Nerdearla o la RubyConf. Sino que se trata de un workshop en el contexto de una conferencia académica, en este caso particular la conferencia es ICSE (International Conference on Software Engineering). En este tipo de workshops se presentan artículos que son previamente evaluados por pares (los miembros del comité del programa) y luego se trabaja colaborativamente sobre las temáticas planteadas en los artículos.
Esta es la cuarta edición del edición del workshop, yo participé como autor en 2017 y personalmente creo que es un espacio interesante para participar y publicar:
Al ser un espacio en formato workshop, además de la exposición de los artículos, hay un espacio interactivo de intercambio, colaboración, debate y hasta co-creación de contenido/materiales
La convocatoria (CFP) incluye obviamente trabajos de investigación pero también reportes de experiencia y artículos de posicionamiento (position papers).
Es parte de ICSE, lo cual le da una gran exposición, pero al mismo tiempo, al ser un workshop «la vara de entrada» no es tan exigente como en el track de educación de ICSE.
Debido a las condiciones de pandemia, esta edición se realizará en formato virtual, con lo cual no hace falta viajar para participar.
El deadline para el envió de artículos es el 14 de enero, se que es poco tiempo para escribir algo desde cero, pero tal vez quien algo escrito a medias y esta pueda ser una buena opción para redondear y publicar.
Apenas Bob Martin publicó su libro Clean Architecture allá por 2017, leí el índice y me pareció que ya conocía todos los temas tratados. Sin embargo, hace un par de meses, sin haber cambiado de opinión decidí igualmente leerlo. Ayer lo terminé.
Efectivamente considero que el libro no me trajo nada nuevo a mi. O sea, he leído mucho sobre arquitectura de software y tal vez por eso no encontré nada revelador. Sin embargo creo que el libro puede resultar muy valioso para muchos lectores porque de hecho creo que es un muy buen resumen de temas con un enfoque muy concreto y pragmático. Spoiler: la idea central de Clean Architecture es lo que hace unos 20 años Alistair Cockburn bautizó inicialmente como Ports & Adapters y más tarde como Hexagonal Architecture.
Si bien los temas los conocía, algo que encontré muy valioso son algunas explicaciones y argumentos.
Me gustó mucho el capítulo «Clean Embedded Architecture» en el cual trata sobre arquitectura de sistemas embebidos.
También me gustó la «desmitificación» sobre «los micro-servicios».
Una perlita interesante son los capítulos «The Database is a Detail», «The Web is a detail» y «Frameworks are details». Me parece que la posición del autor es demasiado extrema pero igualmente vale la pena leerlos.
Una cuestión que parece importante y que no he visto de forma tan explícita en otros libros es que los principios de diseño «son universales», si bien muchos de ellos han sido popularizados en relación con la programación orientada a objetos, los mismos pueden aplicarse tanto a programas desarrollados en C (que no tiene objetos) como a APIs y Servicios.
En fin, el libro me gusto y lo recomiendo sobre todos para aquellos que no esten muy familiarizados con cuestiones de diseño de software.
Y se nos fue un cuatrimestre más en modalidad virtual. Ya el cuarto. Personalmente estoy muy contento debido principalmente a 3 cuestiones, paso a enumerar en orden aleatorio.
Una de las cuestiones destacadas es que me parece que logramos transmitir de forma efectiva la propuesta de Desarrollo Guiado por Pruebas (TDD ourside-in). Este es un tema que venimos dando desde que comenzamos a dictar la materia pero que creo que este cuatrimestre en particular logramos transmitir esta técnica de forma efectiva. Digo esto basado en ciertas charlas que se dieron con los alumnos, en los trabajos realizados y en el resultado de una actividad de relevamiento que hicimos en clase que se puede apreciar en la figura 1.
Figura 1. Resultado de la actividad de relevamiento de TDD
Otra cuestión destacada son ciertos ajustes internos en la dinámica del TP2. La forma en que presentamos el problema, el mecanismo de seguimiento y tutoría que implementamos para guiar a los alumnos y un conjunto de checklist que implementamos como herramientas de soporte para los docentes. Creo que esto nos permitió mejorar la experiencia de docentes y alumnos en el desarrollo del TP2.
Finalmente, un objetivo que nos habíamos propuesto a partir del feedback del cuatrimestre anterior, fue disminuir la carga de trabajo del TP2. Este objetivo lo logramos con éxito aun cuando esa carga de trabajo es importante, este cuatrimestre fue menor que el cuatrimestre anterior.
Creo que directa o indirectamente todas estas mejoras se reflejan en los resultados de la encuesta final del curso:
Evaluación general de la materia: 9.1 / 10
Dedicación semanal extra-clase: 9.1 horas
Materiales de estudio: 4.1 / 5
Claridad de los docentes: 4.5 / 5
Conocimientos de los docentes: 4.6 / 5
Dinámica de las clases 4.5 / 5
Nota promedio de aprobación: 8
Conformidad con nota de aprobación: 4.7 / 5
Net Promoter Score: 79 (métrica que puede oscilar entre -100 y +100)
De estas 10 métricas, 9 tienen mejores valores que el cuatrimestre anterior. Al mismo tiempo la Evaluación general de la materia tiene un máximo histórico (9.1 vs. el máximo anterior de 8.9). El otro valor record es el NPS que marca 79 vs. el máximo anterior de 42. Un punto a mencionar es que no todos los alumnos contestaron la encuesta (tenemos 19 respuestas sobre un total de 26 alumnos), este es un tema recurrente, como la encuesta es anónima y como la hacemos una vez terminada la materia no hemos encontrado un mecanismo para asegurar que todos los alumnos la completen. Pero dado que este es tema recurrente de todos los cuatrimestres creemos que la igualmente la encuesta sigue siendo un elemento válido para medir el curso.
Finalmente, para dar un poco más de contexto comparto algunos otros números del curso:
Blog de NicoPaez 