Sobre la formación de un Scrum Master

El trabajo de Scrum Master es uno de los que ha experimentando una gran demanda de parte de la industria en los últimos y también un gran interés de parte de los profesionales. Los cursos certificados de Scrum Master ofrecidos por la Scrum Alliance son muy requeridos, tengo varios colegas que se dedican a dictar estos cursos y desde hace años llenan cada uno de los cursos que dictan e incluso tienen gente en lista de espera.

Sin embargo, al margen de la popularidad y lo bien que puedan dictarse los cursos de Scrum Master, no resulta factible formar un Scrum Master con un curso de 2 días. De hecho los varios trainers que dictan estos cursos están de acuerdo con esto. El curso es un punto de partida ¿y luego qué? ¿otro curso? No lo sé. Yo no hice el curso y no me considero un especialista en Scrum. Estudié Scrum por mi cuenta y lo he utilizado muchas veces durante años. Incluso he llegado alguna vez a ocupar el rol de Scrum Master (si si, con mi estilo particular, pero Scrum Master al fin, !ja!).

Para alguien que viene trabajando en desarrollo de software, imagino que su formación como Scrum Master comienza siendo parte de un equipo que utiliza Scrum y que cuenta con un Scrum Master. Entonces uno va aprendiendo de la mano de su Scrum Master, tomando gradualmente algunas tareas y haciendo una transición gradual de su rol.

Para alguien que no viene trabajando en desarrollo de software imagino que el camino debería comenzar sumándose a un equipo que utiliza Scrum y que ya tiene un Scrum Master. Entonces el aspirante a Scrum Master (¿Scrum apprentice?) trabaja junto al del equipo Scrum Master inicialmente como observador y gradualmente tomando tareas que le delega el Scrum Master. Esto es básicamente el modelo tradicional/medieval de formación de oficios. Me consta de varias empresas que utilizan este modelo para la formación de desarrolladores y testers pero ¿habrá alguna que lo use para la formación de Scrum Masters?

Un modelo de branching con «condimentos»

Desde hace años en mis desarrollos hago Trunk-Based Development (TBD) y también «evangelizo» en esta técnica. Pero lamentablemente me suelo encontrar que en muchos casos los equipos no se encuentran en condiciones para trabajar de esta forma. TBD requiere del uso simultáneo de un conjunto de técnicas complementarias sin las cuales su utilización resulta impracticable (o demasiado riesgosa). Obviamente que también están los «detractores» que creen que TBD «no funciona» o que «no es bueno», resulta curioso que muchos de estos detractores nunca probaron TBD seriamente.

En fin, el tema es que si no utilizamos TBD hay que buscar otra alternativa. Dos técnicas bastante populares en la actualidad son Gitflow y GitHub flow. Adicionalmente hay una práctica que he visto bastante difundida de asociar branches a ambientes la cual está bien para proyectos chicos/triviales pero que personalmente me parece inconveniente para proyectos más grandes/complejos.

Actualmente estoy colaborando con un equipo que digamos no está en condiciones de hacer TBD (o dicho de otra forma: al cual aún no logré convencer de hacer TBD). Sin embargo el modelo de branching que hemos acordado me resulta bastante convincente. La cuestiones es así:

  1. Para desarrollar cada funcionalidad se crear un branch (feature branch) a partir de la rama principal(main).
  2. En cada commit+push se ejecuta el linter y un conjunto de pruebas «unitarias/de componentes» automatizadas.
  3. Una vez el developer completa la funcionalidad (code complete), se genera un tag, una imagen docker y la misma es desplegada a un ambiente de prueba (existen varios ambientes de prueba) donde se realizan pruebas manuales.
  4. Al mismo tiempo se instancia un arnés de prueba armado con docker, donde se ejecutan un conjunto de pruebas de aceptación automatizadas.
  5. Si la prueba manual y las pruebas de aceptación automatizadas resultan exitosas, la rama es integrada en la rama principal, la imagen docker es promovida (no se la vuelve a buildear) y es desplegada a un ambiente de staging.
  6. En staging se realizan otro conjunto de pruebas (con datos más parecidos a los productivos) y todo está ok, la imagen se vuelve a promover y queda lista para ir a producción.

Si, es un clásico esquema de feature branch pero con «condimentos» que en muchos equipos no están presentes. Destaco aquí las pruebas automatizadas, el arnés de prueba «portable» creado con docker y el hecho de que la imagen docker se crea una única vez y es promovida a medida que pasa de un ambiente a otro.

Enseñando prácticas DevOps

La semana pasada presenté en la conferencia ARGENCON 2022, IEEE Biennial Congress of Argentina un artículo formal (experience report) que describe la forma en que abordamos las cuestiones relacionadas a DevOps en el contexto de MeMo2

Este artículo junto con los publicados por Sergio Villagra (Teaching software engineering: an active learning experience) y Carlos Fontela (Learning Communication Skills in Software Development Management Courses: An Active Learning Experience), resume de forma bastante acabada el núcleo de Ingeniería de Software de la carrera de Licenciatura en Análisis de Sistemas de Universidad de Buenos Aires. En un par de semanas el artículo estará disponible en IEEE Explore.

Aproximaciones a la ingeniería de software

La ingeniería de software es una «actividad práctica» y en la cual hay ciertos fundamentos conceptuales sobre los cuales están construidas las prácticas y herramientas que utilizamos. Ejemplo: utilizamos la herramienta Jenkins para implementar la práctica de Integración Continua que, entre otras cuestiones, nos da feedback, uno de los pilares en el ejercicio de la ingeniería de software. Un esquema similar es planteado por Kent Beck en el marco de Extreme Programming. Kent Beck nos habla de Valores, Principios y Prácticas.

Curiosamente (o no tanto) la industria y la academia se aproximan de forma distinta a esta tríada (fundamentos-prácticas-herramientas). La academia suele enfocarse en los fundamentos y las prácticas dejando muchas veces bastante marginadas a las herramientas, lo cual en ocasiones suele generar la queja de la industria al ver que los egresados de la universidad no dominan ciertos lenguajes/frameworks /tecnologías de moda.

Por su parte la industria suele enfocarse en las herramientas (de ahí su queja) y algunas prácticas dejando muchas veces de lado los fundamentos. Esto se ve claramente en muchas búsquedas donde directamente se enumeran herramientas casi sin hacer mención a la formación: «Programador React». La falta de programadores es un condimento a toda esta situación y ha potenciado la aparición de cursos informales que muchas veces se venden como alternativas a las carreras universitarias.

En mi constante tránsito entre industria y academia siempre intento recorrer esta tríada de punta a punta. En mis materias estudiamos fundamentos y prácticas utilizando herramientas de uso habitual en la industria. Al mismo tiempo al trabajar en la industria, cuando trabajo con una determinada herramienta me ocupo de entender y difundir las prácticas y fundamentos detrás de la misma. Claro que es un desafió pues las herramientas están en constante evolución y eso requiere un esfuerzo sostenido de mantener actualizado el material de estudio y a própsito de esto, dejó aquí porque tengo que actualizar los videos de GitLab con el release de la version 15.1 🙂

Clases virtuales condicionadas

Luego de 2 años de clases obligadas en modalidad virtual, la mayoría de los alumnos siguen prefiriendo esa modalidad. De mi lado docente, si bien la virtualidad me resulta en cierto modo más cómoda (no tengo que trasladarme hasta la universidad) hay ciertas cuestiones que me resultan mucho más incómodas y que en el balance me llevan a elegir la presencialidad en varias casos.

Concretamente me genera una gran incomodidad dar clases virtuales para una audiencia «ausente»: gente con cámara apagada (o sin cámara) y con nula participación durante la clase. La participación «verbal» puede que no cambie en un esquema virtual o presencial (hay gente que incluso estando en el aula física, no aporta ni una palabra durante toda la clase), pero a pesar de eso, el poder ver las caras ofrece al menos cierto grado de feedback infinitamente más rico que una foto de perfil.

Es por eso que para este segundo cuatrimestre 2022 de MeMo2 vamos a regular la virtualidad acorde a la participación de los alumnos. Si los alumnos quieren clases virtuales entonces deben tener sus cámaras encendidas. En la medida que la mayoría de las cámaras permanezcan apagadas vamos a optar por más clases presenciales. Según la planificación que hicimos tenemos 6 clases que si o si serán presenciales y otras 2 que si o si serán virtuales. El resto de las clases, tenemos la flexibilidad de poder darlas en cualquiera de las dos modalidades.

Kit docente 2022 para clases presenciales

Hubo una época en que ir a dar clases implicaba llevar solamente la notas de la clase. El docente tomaba el centro de la escena, hablaba y posiblemente escribía algo en el pizarrón. En el aula siempre había borrador y algunas tizas.

Luego llegaron las notebooks y los proyectores, entonces en pizarrón dejó de estar solo y empezamos a llevar las notebooks y a usar los proyectores provistos por la universidad.

Gradualmente los pizarrones «de madera para tiza» fueron reemplazados (o complementados) por pizarras «de plástico para fibra» y obviamente empezamos a llevar fibras y borradores para estos nuevos pizarrones. Creo que en la actualidad esta es la situación para muchos docentes universitarios en el área de tecnología/ingeniería (posiblemente en otras áreas ocurra lo mismo).

Pero quienes optamos por una modalidad distinta a la clase magistral, solemos necesitar algunos elementos adicionales. A esto debemos sumarle cierta escasez de recursos en la universidad pública y mi intención de mitigar riesgos. Es por estas cuestiones que suelo asistir a mis clases presenciales con conjunto extra de elementos.

En la foto precedente se pueden observar los siguientes elementos:

  • Parlante: lo utilizo para poner música al llegar al aula (suelo llegar unos 10 minutos antes del comienzo de clase y entonces pongo música mientras van llegando los alumnos). También suelo poner música mientras los alumnos trabajan en las consignas de la clase.
  • Post-it: las suelo utilizar para distintas cuestiones, por ejemplo para pegar en el pizarrón el plan de clase o para hacer un «parking lot» de la dudas que van surgieron durante la clase.
  • Control remoto y puntero láser: en ocasiones me gusta sentarme junto a los alumnos y este dispositivo me permite pasar las diapositivas a distancia y apuntar a los elementos que quiero destacar.
  • Papeles de colores: son como los post-it pero sin el pegamento.
  • Cable HDMI: para conectar la notebook al proyector. Me ha pasado que el que me provee la universidad no funciona óptimamente.
  • Hojas de papel A4: más papel para actividades
  • Borrador y varios marcadores para pizarra: si bien la universidad provee estos materiales prefiero utilizar los míos.
  • Zapatilla: en ocasiones me toca dar clases en aulas donde los toma corriente se encuentran demasiado lejos o incluso tal vez hay un único toma.

Y para llevar todo esto, utilizo mi «maletin» de la Smalltalks 2009.

Se viene Nerdearla 2022

Este año Nerdearla tiene dos ediciones. Nerdearla 101, enfocada en aquellos que están comenzando en el mundo IT, que tendrá lugar esta semana: 5 y 6 de Agosto, gratis y en modalidad híbrida. Registración aquí. Estuve viendo la agenda y hay algunas sesiones muy interesantes incluso para gente ya experimentada. Aquí está publicada la agenda completa.

Por otro el Nerdearla «clásico» (novena edición) se realizará del 19 al 22 de Octubre también en modalidad híbrida. En este momento no hay mucha información al respecto pues el foco está en el evento 101 que es esta semana. Se sabe que la parte presencial será en el Konex (en Ciudad de Buenos Aires). Si están interesados en enviar una propuesta, pueden hacerlo aquí. El llamado está abierto hasta el 8 de agosto. Yo ya mandé mi propuesta, no se duerman.

Preparando Ingeniería de Software 2022 @ UNTreF

Luego de dos ediciones 100% virtuales volvemos a la presencialidad. Si bien la universidad habilitó la presencialidad plena, nuestra idea es tener un esquema híbrido. En principio estamos planificando al menos 4 clases presenciales y las restantes online.

En términos de contenido, no planeamos novedades.

En términos de la dinámica de las clases esperamos hacer un mix de lo que eran nuestras clases presenciales pre-pandemia y nuestras clases online de la pandemia.

Un cambio que estamos evaluando es respecto del trabajo grupal de la materia. Personalmente tengo la idea de que el trabajo tenga un complejidad funcional y técnica un poco mayor que lo que veníamos haciendo, de forma tal que nos habilite a poner en práctica algunas cuestiones que hasta el momento solo estudiábamos de forma más superficial.

Finalmente cierro con algunos datos relevantes para quienes tengan pensado cursar la materia este 2022:

  • La materia se dictará en modalidad híbrida y que la asistencia es obligatoria.
  • Semanalmente son 4 horas de clase y adicionalmente hay que dedicar como mínimo otras 4 horas de estudio (según reportan los alumnos suelen dedicar unas ~7 horas extra clase)
  • Utilizamos Git pero no enseñamos Git
  • Programamos con Ruby pero que no enseñamos Ruby
  • Damos por sabido todo lo visto en la materias anteriores, pero definitivamente lo más relevante es lo visto en las materias «Algoritmos y Programación (1,2 y 3)» y «Diseño y Arquitectura de Sistemas«

Testing automatizado en React-Native

Luego de 6 meses trabajando a diario con React-Native he logrado hacerme una idea bastante clara sobre esta temática que me parece no está suficientemente bien documentada.

En primer lugar tengamos presente que con React-Native vamos a generar aplicaciones móviles para Android y/o iPhone con lo cual un tipo de prueba automatizada que podremos realizar es directamente sobre el binario nativo que se instala en el dispositivo, serían las denominadas pruebas end-to-end que muchas veces se hacen en forma manual. Su ejecución requiere por un lado del uso de un emulador (o incluso se puede usar un dispositivo físico) y por otro, el uso de algún driver/conector que nos permita interactuar con la aplicación desde la perspectiva del usuario. Como estas pruebas van directamente contra el binario/ejecutable, tenemos independencia para codearlas en un lenguaje distinto al que utilizamos para codear la aplicación. La pieza central en este tipo de pruebas es el driver/componente que nos va a permitir manipular la aplicación emulando la interacción del usuario. En este sentido una de las herramientas más populares es Appium y otra es Detox.

Sacando las pruebas end2end, tenemos distintos tipos de pruebas de índole más técnico, de componentes/unitarios. Estas pruebas sí las estaremos codeando con la misma tecnología que codeamos la aplicación. En el caso de estar trabajando con React Native estas pruebas las vamos a codear con JavaScript. Aquí también entran en juego distintas herramientas. La primera de ellas es el framework de testing que utilizaremos para escribir los casos de prueba y agruparlos en suites. Aquí tenemos varias alternativas (como suele ocurrir habitualmente en JavaScript) pero al trabajar con React se suele utilizar Jest que es la herramienta recomendada en la documentación oficial de React. Jest nos va a permitir escribir casos de prueba sobre objetos/funciones JavaScript, sean estos componentes React o simples objetos planos «vanilla JavaScript». Una «bondad» que tiene Jest es que trae nativamente funcionalidades de mocking/stubbing con lo cual nos ahorramos de tener que incluir en nuestro proyecto otro framework/herramienta para mocking.

Si en nuestras pruebas queremos testear componentes React-Native, en particular el rendering, en primera instancia podemos utilizar el Test Renderer que es parte del core de React. También como parte del core de React tenemos las Test Utils que ofrecen un conjunto muy útil de funciones utilitarias.

También tenemos la posibilidad de utilizar React-Native Testing Library que debemos instalar por separado (yarn add –dev @testing-library/react-native). Esta librería construída sobre la base del Test Renderer y agrega un conjunto de funciones utilitarias de gran utilidad.

Docker: experiencia clone & run

Durante mucho tiempo al comienzo de mi carrera profesional como desarrollador (hace +20 años) era habitual que cuando uno comenzaba en un nuevo proyecto/trabajo, tenía que invertir varias horas instalando herramientas y ajustando configuración antes de poder tirar una línea de código. Esta situación sigue ocurriendo en muchas organizaciones/contextos. Sin embargo existe en la actualidad un conjunto de herramientas que pueden ayudarnos a tener experiencia mucho más fluida. Una de esas herramientas es Docker. Personalmente suelo hablar de una experiencia Clone & Run. Llegas a un proyecto, tomas tu host, instalas Git y Docker, ejecutas git clone y docker-compose up, buscas un café y al rato ya estas listo para empezar a codear. Explicar como lograr esto con texto puede resultar muy largo e inconveniente, por ello hice un video explicando y mostrando esta experiencia. Espero les resulte util.