El Scrum Master, la planificación y la gestión

En el contexto de un proyecto de desarrollo/entrega de software gestionado «a lo Scrum», las actividades de planificación y gestión de proyecto son repartidas entre el equipo de desarrollo y el Product Owner. A su vez la planificación tiene un aspecto estratégico y otro táctico.

La planificación estratégica tiene que ver con la priorización, definir qué vamos a construir y cuándo vamos a construirlo, una responsabilidad típica del Product Owner. La planificación táctica tiene que ver con definir cómo a construirlo, o sea, tomar cada ítem y hacer su descomposición en tareas. Una responsabilidad típica del equipo de desarrollo.Y al margen de táctica o estratégica, la planificación requiere de tener alguna idea de «costo/dimensionamiento», o sea: «hacer esto ¿nos llevará alrededor 2 días o alrededor de 2 meses?. Entonces debemos estimar.

Conceptualmente el Scrum Master no se encarga de la gestión, ni de la planificación y mucho menos de estimar, pero definitivamente son cuestiones en las que podría llegar a aportar mucho valor no porque vaya a ejecutar ninguna de esas tareas, pero sí por facilitar la realización de las mismas. Pero en ocasiones las personas en el rol de Scrum Master no tienen conocimiento formal en estos temas, sobre todo si no han tenido una formación de base en IT. En algunos casos, hay Scrum Masters con algún conocimiento informal de gestión o tal vez incluso cierta experiencia de gestión de proyectos pero no necesariamente en proyectos de software. Los proyectos de desarrollo/entrega de software tienen algunos condimentos interesantes en términos de gestión y particularmente en temas de planificación y estimación.

Un libro clásico sobre estas cuestiones es «Agile Estimating and Planning» de Mike Cohn. Es un libro que tiene más de 15 años y algunas de las cuestiones que propone ya no suelen utilizarse pero al margen de esos detalles, el libro explica muy bien algunas cuestiones fundamentales.

Otro libro que personalmente me resultó mucho más interesante y útil es «Planning Extreme Programming» de Kent Beck y Martin Fowler. Este libro tiene más de 20 años pero no ha perdido vigencia y sin embargo es mucho menos conocido que el libro de Cohn.

Estas cuestiones de gestión, planificación y estimación son parte de mi Taller de Prácticas Técnicas para Scrum Masters y Agile Coaches que comienza a mediados de marzo y que está especialmente dirigido a gente trabajando en estos roles pero que no ha tenido formación de base en IT.

MeMo2: clases por la mañana

Desde un inicio las clases de MeMo2 las veníamos dictando en el horario de 19:00 a 22:00, pero este primer cuatrimestre de 2023 vamos a cambiar de horario de las clases, serán de 8:00 a 11:00 de la mañana.

Hace ya un tiempo que yo venía pensando en dar las clases por la mañana a modo de experimento para ver si lográbamos una mejor dinámica, ocurre que muchas veces a las 19:00 los alumnos (y también los docentes) llegan cansados, después de trabajar o de haber realizado otras actividades, lo cual impacta negativamente en el nivel de atención y participación en clase. Tengo la creencia que dando la clase por la mañana, todos estaremos más fresco y la clases tendrán un mejor flujo.

A esta idea que yo ya venía barajando se sumo una situación de fuerza mayor nos impide seguir con el horario habitual en este primer cuatrimestre de 2023 y eso resultó en el empujoncito que necesitábamos para finalmente concretar el experimento de las clases matutinas.

Para despejar las dudas que puedan tener potenciales, este viernes 24 a las 8:30 haremos un Meet explicando la dinámica de cursada (presencialidad, asistencia, dedicación, etc, etc).

Los interesados en participar, deben completar este formulario, para que les enviemos el link de acceso al Meet.

Alternativa a Heroku: Render

A fines de 2022 Heroku cambió su modelo de suscripciones y descontinuó su oferta gratuita que muchos veníamos utilizando. Yo tenia alguna que otra aplicación de juguete pero principalmente venia utilizando Heroku en mis materias para que los alumnos puedan desplegar las aplicaciones que construyen durante la cursada. Si bien es cierto que con estos planes Heroku incluye una oferta para estudiantes la misma no se ajusta a nuestras restricciones pues exige una tarjeta de crédito para poder acceder a la oferta.

Este cambio de Heroku nos obligó a buscar alternativas considerando nuestras restricciones:

  • La plataforma/servicio debe ser gratuito y adicionalmente no debe pedir tarjeta de crédito (hay varias plataformas que a pesar de ofrecer opciones gratuitas piden igualmente una tarjeta de crédito para hacer una validación del usuario)
  • Debe soportar nuestro stack tecnológico, básicamente necesitamos poder correr una aplicación web construida en Ruby y con una base de datos PostgreSQL.

Estas restricciones nos obligaron a descartar algunas opciones interesantes como Vercel (no soporta nuestro stack).

Finalmente hemos decido utilizar Render que cumple con nuestras restricciones y que de acuerdo a la pruebas que hicimos parece que se ajusta bien a nuestras necesidades funcionales.

Mi colega Hérnan hizo un video orientativo para nuestros alumnos mostrando como desplegar en Render una aplicación web Ruby+PostgreSQL.

Nueva materia: Ingeniería de Software Continua

Durante el primer cuatrimestre de este 2023 estaré dictando esta materia en calidad de Profesor Invitado en la carrera de Ciencias de la Computación en la Facultad de Ciencias Exactas y Naturales de la UBA.

La materia será una variante reducida MeMo2 con algunos agregados. Será reducida porque las materias dictadas en esta modalidad tiene una duración de medio cuatrimestre (8 semanas).

El temario tentativo es:

  • Ingeniería de Software Continua: fundamentos.
  • Principios Lean & El movimiento DevOps.
  • Flujos de valor en el proceso de entrega de software.
  • Tipos y Estrategias de testing.
  • Software Configuration Management de segunda generación.
  • Desarrollo guiado por pruebas de aceptación.
  • Integración, Entrega y Despliegue continuos.
  • Delivery Pipelines & Estrategias de despliegue.
  • Gestión de Ambientes.
  • Modelos de infraestructura & Infraestructura como Código.
  • Roles y Modelo de Equipo.
  • Técnicas de trabajo colaborativo.
  • Gestión del proyectos vs. Gestión de Producto.
  • Operaciones y el enfoque SRE.

Digo tentativo porque aún me falta terminar de bajarlo a detalle de implementación y es posible que no llegue a cubrir la totalidad. de los puntos.

En términos de dinámica de cursada mi idea es utilizar la misma que en MeMo2 lo cual implica:

  • cursada híbrida (algunas clases presenciales y otras clases virtuales).
  • un enfoque muy «hands-on»
  • una carga de trabajo extra-clase de unas 6 horas semanales a lo largo de todo el curso.
  • stack tecnológico basado en Ruby, GitLab y Kubernetes
  • herramientas colaborativas para soporte de la cursada: GoogleGroups, CanvasLms, Discord y Google Meet

Dado el alto grado de interacción con los estudiantes, la materia está planteada con un cupo de 16 vacantes.

A comienzos de marzo tengo una reunión con personal de la facultad donde espero tener más «detalles de implementación».

Pensamiento final: mientras escribo estas línea se me ocurre que esta materia podría dictarla como materia optativa en otra institución o incluso como un curso privado, si llega a haber algún interesado no dude en contactarme.

Cursos y Materias 2023

Este año 2023 viene con algunas novedades que se suman a mis actividades recurrentes.

En el ámbito académico, seguiré con mis materias de grado en UBA Ingeniería (memo2) y UNTreF (Ing. de Software) y también volveré a dictar (por cuarta vez) el Seminario de Postgrado en Software Delivery. Una novedad es que durante el primer cuatrimestre de 2023 estaré dictando una nueva materia en UBA Exactas: Ingeniería de Software Continua (más detalle próximamente). Finalmente, si bien aún no está confirmado, es posible que durante la segunda mitad de año también esté participando del dictado de otro Seminario de Postgrado en UNTreF sobre Arquitectura de Software.

En el ámbito no-académico, ya tengo confirmada una nueva edición del Taller de Prácticas Técnicas para Scrum Masters y Agile Coaches que comenzará a mediados de marzo. También tengo la intención de estrenar dos nuevos talleres: uno sobre «Artesanía de Software» (sobre esto escribí algo el año pasado) y otro sobre «Especificación con ejemplos, BDD y TDD» (sobre esto tengo varias ideas pero nada escrito aún). Respecto de estos dos talleres, estoy considerando hacer un experimento de crowdfunding para cubrir los costos de preparación y dictado, en breve compartiré más información al respecto.

Como siempre, dudas, consultas y sugerencias las pueden poner en los comentarios o bien contactarme en privado por aquí.

Libro: Formulation (The BDD Books)

Terminé de leer este libro hace un par de días. Me gustó y me alegró ver que varias de las cuestiones que menciona coinciden con lo que vengo aplicando en mis proyectos y enseñando en MeMo2.

Al margen de que ya sabía, descubrí algunos conceptos y capacidades de Gherkin de las que nos estaba al tanto como ser los «journey escenarios» y la diferencia entre las «data tables» y «example tables».

El texto está escrito de forma tal que intercala explicaciones conceptuales con fragmentos de diálogos de un equipo de desarrollo que aplica esos conceptos. En cierto modo esto hace que la explicación de cómo formular buenos ejemplos contenga muchos ejemplos.

Creo que es fundamental para todo equipo pretenda aplicar BDD que al menos una persona del equipo de desarrollo maneje fluidamente las cuestiones descriptas en este libro (¿el facilitador/Scrum Master? ¿un tester?).

Balance 2022

Hace varias semanas tenia pendiente la publicación de este post. Creo que para muchos el 2022 fue «el año de la vuelta»: volvimos a las aulas, volvimos a la oficinas, volvimos a encontrarnos, volvimos… ¿mejores? Mmmm, no sé, pero sin duda volvimos distintos. De hecho algunos no volvimos completamente, algunas casas de estudio (y empresas) tomaron consciencia de que hay ciertas cuestiones de la educación (y del trabajo) que pueden verse beneficiadas de un esquema híbrido online/onsite. En mi caso particular, no volví a pisar las oficinas de un cliente en parte porque he estado trabajando con clientes del exterior. Y en el ámbito académico, adoptamos un esquema híbrido que consideramos lo más apropiado didácticamente para nuestra materia.

Al igual que el año pasado tuve una dedicación muy similar en academia e industria.

En el ámbito académico:

En el ámbito industrial, la primera mitad del año estuve trabajando como parte del staff de RadioCut, una aventura que inicié en 2021 con la intención de ser parte de un producto pero que lamentablemente no resultó como esperaba. Ya en la segunda mitad del año volví a mi trabajo de consultoría/freelance. Finalmente por otro lado dicté en reiteradas ediciones mi Taller de Introducción a Kubernetes y realicé la primera edición del Taller de Prácticas Técnicas para Scrum Masters.

Sobre el uso de Gherkin/Cucumber y esa costumbre de dormir en la mesa

Toda herramienta es creada con un fin y luego usada como a cada uno le parece. El ejemplo que siempre pongo es el de la mesa: podríamos pensar que la mesa fue pensada para sentarse a comer o a trabajar, pero sin embargo alguien podría usarla para acostarse a dormir. Esto puede traer dos riesgos: 

  1. que no resulte muy cómodo/conveniente o incluso que tenga limitaciones, «¡que incómodo dormir en la mesa! => es razonable ya que no fue pensada para eso»
  2. que posiblemente haya una herramienta más apropiada => ¿qué tal si probas dormir en la cama?

(tengo la sensación de que esta situación de «dormir» en la mesa se repite frecuentemente en la industria del software con distintas herramientas)

En este sentido Gherkin fue pensado como una herramienta de colaboración/comunicación/especificación para ser utilizada de programar la solución y que nos trae el beneficio adicional de poder automatizar utilizando alguna herramienta Gherkin-compatible como Cucumber, Cucumber-jvm, Behat, etc, etc.

Sin embargo vemos en la industria un uso alternativo de Gherkin/Cucumber: la automatización de pruebas una vez que la solución ya está programada. Si bien este escenario esalgo perfectamente válido a mi no me resulta conveniente. O sea: si no vamos a tener el involucramiento del usuario y no vamos a trabajar colaborativamente en entender el negocio antes de empezar a programar y solo buscamos automatizar pruebas, me resulta entonces más práctico programar las pruebas con alguna herramienta de la familia xUnit o Rspec. Un escenario en el que automatizar con Gherkin/Cucumber «a posteriori de la programación» es cuando tenemos una persona describiendo la prueba (erscribiendo Gherkin) y otra persona escribiendo el código de automatización por detrás del Gherkin. En lo personal sigue sin convencerme.

Pero al margen de mis gustos y convicciones, hay una diferencia importante en el uso de Gherkin dependiendo de la intención con la que lo estamos usando. Más concretamente la forma en la que vamos a escribir los escenarios con Gherkin va a ser distinta. Veamos un ejemplo, tomemos una funcionalidad de login, si estamos usando Gherkin como herramienta de colaboración/comunicación/especificación y seguimos las recomendaciones de los creadores, podríamos tener lo siguiente:

Antecedentes:
  Dado que existe un usuario "juan" con clave "claveFuerte123"

Escenario: Login exitoso
  Cuando un usuario ingresa credenciales "juan" y "claveFuerte123"
  Entonces el login exitoso

Escenario: Login fallido por clave incorrecta
  Cuando un usuario ingresa credenciales "juan" y "claveIncorrecta"
  Entonces el login es fallido

Algunos puntos para destacar:

  • El foco está en el comportamiento omitiendo todo detalle de implementación
  • No hay ninguna mención a elemento de presentación/pantallas/html
  • Los escenarios son muy cortos

Veamos ahora una versión alternativa que típicamente podría ser creada «post-programación» con el fin de automatizar una prueba de regresión.

Antecedentes:
  Dado que existe un usuario "juan" con clave "claveFuerte123"

Escenario: Login exitoso
  Dado que en el campo "usuario" pongo "juan"
  Y que en el campo "clave" pongo "claveFuerte123"
  Cuando hago click en el "Login"
  Entonces veo el mensaje "Bienvenido"

Escenario: Login fallido por clave incorrecta
  Dado que en el campo "usuario" pongo "juan"
  Y que en el campo "clave" pongo "claveIncorrecta"
  Cuando hago click en el "Login"
  Entonces veo el mensaje "Credenciales incorrectas"

A diferencia del otro caso aquí vemos mención a los elementos de presentación/pantalla y un detalle «del cómo», esto se debe a que el escribir el Gherkin de esta segunda forma permite reutilizar código de automatización. O sea, el paso «Dado que en el campo <x> pongo <v>» es completamente genérico y lo puedo utilizar tanto en el escenario de login como en cualquier otro. Por otro lado el paso «Cuando un usuario se logueo con credenciales «juan» y «unaClaveIncorrecta» es muy específico del login.

Entonces:

  • En un contexto donde el objetivo central es la automatización, será mucho más probable encontrarnos con Gherkin del segundo estilo.
  • En un contexto donde el objetivo es entender/comunicar será más probable (y conveniente) el uso de Gherkin del primer estilo.

Estos dos estilos de Gherkin que menciono aquí son en cierto modo dos extremos. Asimismo, si bien la sintáxis de Gherkin no viene sufriendo grandes cambios, la forma de uso ha ido variando dado pie a distintos estilos. Lo importante para mi es que cada equipo establezca explícitamente un conjunto de convenciones sobre su uso que estén en sintonía con el uso que le vayan a dar.

Para aquellos que apuesten a utilizar Gherkin como herramienta de colaboración/especificación les recomiendo la serie de libros de Rose y Nagy «The BDD Books«.