Me tomo una licencia de los temas habituales de este espacio para compartir una experiencia fantástica que viví recientemente.
El pasado domingo 3 de Abril estuve en el estadio de Vélez Sarsfield para ver el show de Fito Páez en el contexto de su tour «El amor 30 años después del amor», justamente conmemorando los 30 años de lanzamiento del disco «El amor después del amor». Fue un show plagado del hits, tal como el disco en cuestión. Por algo sigue siendo, 30 años después, el disco más vendido del rock nacional.
El show fue excelente, Fito mezcló en el repertorio los temas del disco conmemorado con otros clásicos de su carrera. Me gustaron mucho las versiones de Dar es dar, Tumbas de la gloria y Ciudad de pobres corazones. Esta última comenzó un arreglo sinfónico mientras detrás del escenario se veían los relámpagos de la tormenta que se avecinaba, increíble, parecía que la naturaleza se hubiera acoplado para participar del espectáculo.
Cada historia de usuario tiene típicamente varias reglas asociadas que deben cumplirse simultáneamente. Sin embargo la técnica de mapeo de ejemplos propone que cada ejemplo esté centrado en una regla en particular, «ignorando» el resto de las reglas. La idea de esto es enfocarnos en entender cada una de las reglas y tener ejemplos bien concretos. En lo personal, me ha pasado de trabajar en aplicaciones con cierto grado de complejidad donde puede resultar muy útil generar ejemplos adicionales para ejemplificar la combinación de reglas. No siempre genero estos «escenarios de combinación» pero cuando lo hago procuro hacerlo en segunda instancia, o sea: comienzo trabajando en escenarios «de una regla» y luego recién después de terminar con ellos, trabajo los escenarios «multi-regla».
Escenarios encubiertos
Si al identificar los escenarios tenemos uno con un «o», puede ser un indicio de que en realidad tenemos 2 escenarios distintos. Por ejemplo si en una funcionalidad de pago con tarjeta de crédito tengo un escenario «aquel donde mi tarjeta está bloqueada o sin saldo», es posible que resulte más conveniente tener un escenario para tarjeta bloqueado y otro aparte para tarjeta sin saldo.
Plantilla online
Si bien ante la posibilidad de elegir prefiero que las sesiones de mapeo de ejemplos sean presenciales, en muchas ocasiones me encuentro haciéndolas online y para esos casos suelo usar esta planilla de Google Docs.
Alternativas a la tarjetas de colores
Al hacer las sesiones presenciales en ocasiones he tenido dificultades para conseguir tarjetas bibliográficas de colores y he tenido que buscar alternativas.
Una alternativa es hacer la sesión en forma presencial pero digital, o sea, tomamos la una computadora, la conectamos a un proyector y trabajamos con la plantilla que mencioné previamente. Pero en lo personal, si estamos físicamente juntos prefiero utilizar papel.
Una alternativa obvia es usar post-its, pero me he encontrado que el pegamento me genera cierta incomodidad pues me gusta poder ir reacomodando los escenarios a medida que los vamos trabajando. Por esto es que prefiero utilizar simplemente papeles de colores, tipo post-its pero sin pegamento. Esto va muy bien pues los puedo mover con total libertar, aunque al ser más livianos que las tarjetas y no tener pegamento, son mucho más volátiles y cualquier brisa leve los hace volar.
Hace un tiempo comenté de esta materia que voy a estar dictando en carácter de Profesor Invitado. Pues bien, estoy empezando a ultimar detalles.
En primer lugar la materia la estaré dictando los días miércoles en el horario de 15 a 18. Será en principalmente en modalidad presencial pero con un esquema de aula extendida y algunas clases en modalidad online.En segundo lugar, Francia (perdón, sé que esto me quita seriedad pero no pude contenerme, jajajaja).
El próximo miércoles 19 de Abril a las 16:00 hs. estaré haciendo una charla de presentación de la materia para potenciales estudiantes interesad@s en cursarla. El objetivo de esta charla es básicamente setear expectativas tanto de quienes vayan a cursar la materia como también del equipo docente. O sea, me parece importante que los alumnos sepan antes de anotarse los temas que vamos a estudiar, la propuesta didáctica, mecanismo de evaluación y dedicación requerida. si bien toda esta información podría compartirla en texto, me parece importante poder la dar la chance de hablarlo en vivo y atender inquietudes de los interesados. Al mismo tiempo, como docente, quiero saber la cantidad aproximada de estudiantes que cursarán la materia pues ello podría llevarme a cambiar algunas cuestiones (no es lo mismo un curso para 6 estudiantes que uno para 20). De hecho, si hubiera muy pocos inscriptos (menos de 5) debido al horario de cursada, podría ver de analizar alguna alternativa horaria.
De cualquier forma que llames a esta conversación, muchos equipos la encuentran difícil, al no ser una conversación estructurada suele llevar mucho tiempo y se torna aburrida. Como consecuencia de ello, algunos no la hacen de forma regular o consistente, o tal vez directamente dejan de hacerla.
He descubierto un método simple y poco tecnológico para hacer que esta conversación sea corta y poderosamente productiva. Lo llamo Example Mapping.
Cómo funciona
Los ejemplos concretos son una excelente manera de ayudarnos a explorar el dominio del problema y constituyen una excelente base para nuestras pruebas de aceptación.
Pero a medida que discutimos estos ejemplos, hay otras cosas que surgen en la conversación que también merecen ser capturadas:
reglas que resumen un conjunto de ejemplos o expresan restricciones acordadas acerca del alcance de una historia.
preguntas acerca de escenarios en los que nadie en las conversaciones sabe cuál es el resultado correcto. O suposiciones que estamos haciendo para poder avanzar.
nuevas historias que descubrimos o slicieamos y diferimos fuera del alcance.
La técnica de mapeo de ejemplos utiliza un paquete de fichas bibliográficas o tarjetas de 4 colores y algunos bolígrafos para capturar estos diferentes tipos de información a medida que se desarrolla la conversación. Mientras hablamos, los capturamos en las tarjetas y los organizamos en un mapa.
Comenzamos escribiendo la historia en discusión en una tarjeta amarilla y colocándola en la parte superior de la mesa.
A continuación, escribimos cada uno de los criterios de aceptación, o reglas que ya conocemos, en una tarjeta azul y los colocamos en la mesa debajo de la tarjeta de historia amarilla.
Para cada regla, es posible que necesitemos uno o más ejemplos para ilustrarla. Los escribimos en una tarjeta verde y los colocamos bajo la regla correspondiente.
Mientras discutimos estos ejemplos, podemos descubrir preguntas que nadie en la sala puede responder. Entonces los capturamos en una tarjeta roja y seguimos con la conversación.
Seguimos adelante hasta que el grupo esté satisfecho de que el alcance de la historia está claro, o nos quedamos sin tiempo.
Y eso es todo. Te lo dije ¡es simple!.
Feedback Instantáneo
A medida que fluye la conversación, creamos rápidamente una representación visual en la mesa frente a nosotros que refleja nuestra comprensión actual de la historia:
Una mesa cubierta con tarjetas rojas (preguntas) nos dice que todavía tenemos mucho que aprender sobre esta historia.
Una mesa cubierta de tarjetas azules (reglas) nos dice que esta historia es grande y complicada. ¿Quizás podamos particionarla? Tomamos otra tarjeta amarilla (historia), escribimos la nueva historia y la colocamos en el backlog.
Una regla con muchos ejemplos podría ser demasiado compleja. ¿Hay múltiples reglas en juego que deben ser objeto de otras historias?
Descubrirás que algunas reglas son tan obvias que no necesitan ejemplos en absoluto. Está claro a partir de la conversación que todos entienden la regla. ¡Excelente! Todos pueden seguir adelante con sus vidas sin obligarse a sí mismos a obtener ejemplos como autómatas con lavado de cerebro BDD.
Pensando dentro de la caja del tiempo (time-box)
Un pequeño grupo de amigos debería ser capaz de procesar una historia bien entendida y de buen tamaño en unos 25 minutos.
Si no puede, o todavía está dominando esto (lo cual está bien), la historia es demasiado grande (definitivamente no está bien) o todavía tiene demasiada incertidumbre. Escuche eso e intente dividir la historia, o deje que la persona de producto se vaya y haga un poco de tarea antes de volver a poner la historia en otra sesión de mapeo de ejemplos en una fecha posterior.
En Cucumber, usamos un voto rápido con la mano después de 25 minutos para determinar si creemos que la historia está lista para comenzar a desarrollarse. Incluso si quedan algunas preguntas pendientes, puede pensar que son lo suficientemente menores como para poder resolverlas sobre la marcha. Deja que el grupo decida.
Beneficios
El mapeo de ejemplos ayuda a acercar y enfocarse en las partes más pequeñas de comportamiento dentro de la historia. Al mapearlo, puede separar las reglas, encontrar el núcleo del comportamiento que se desea y posponer el resto hasta más tarde. Con este nivel de detalle, el mapeo de ejemplos actúa como un filtro, evitando que las grandes historias entren en el sprint y exploten con sorpresas de último minuto tres días antes del día de la demostración.
También ahorra tiempo y, por lo tanto, ayuda a mantener el interés de las personas ocupadas en el proceso.
Muchos equipos asumen que los tres amigos deben escribir pruebas de aceptación (por ejemplo escenarios de Cucumber) durante esta sesión, sentados alrededor de un proyector mientras alguien escribe escenarios formales de Cucumber en un IDE. Hay ocasiones en las que esto es valioso, pero en general creo que es una mala idea. De hecho, puede distraerte del verdadero propósito de la conversación.
Es fácil ver por qué la gente comete este error: el propósito aparente es tomar una historia de usuario, que ya tiene algunos criterios de aceptación predefinidos, y generar ejemplos que puedan convertirse en pruebas de aceptación.
Creo que el verdadero propósito, sin embargo, es llegar a un entendimiento compartido de lo que se necesitará para hacer la historia. Puede moverse mucho más rápido hacia este objetivo si se mantiene bajo en tecnología.
Episodios de Friends
Entonces, en lugar de optar por escenarios formales de Gherkin en toda regla, solo intente capturar una lista de ejemplos aproximados, utilizando la convención de nomenclatura de episodios de Friends.
Por ejemplo:
Aquel en el que el cliente olvidó su recibo
Aquel en el que el producto está dañado
Aquel en el que se compró el producto hace 15 días
A veces, cuando acecha la incertidumbre, instintivamente querrás ser más concreto que esto. Todavía no necesitas recurrir a la estructura rígida de Dado-Cuando-Entonces:
Cuando el resultado (el entonces) no está claro, no tienes un ejemplo, tienes una pregunta.
Incógnitas conocidas
Cada vez que una conversación como esta da vueltas en círculos, es porque no tienes suficiente información. Probablemente falte alguien en la conversación, o tal vez necesites hacer una investigación de usuario, o un spike.
En lugar de dejar que todos compartan su opinión sobre cuál creen que debería ser el resultado, simplemente captura la pregunta y continua. ¡Felicidades! Acabas de convertir una incógnita desconocida en una incógnita conocida. Eso es un gran progreso.
¿Quién debería venir?
Lo mínimo son los tres amigos: un desarrollador, un tester y una persona de producto. Sin embargo, eso es solo un mínimo. Por todos los medios invita a gente de operaciones, personas de experiencia del usuario o cualquier otra persona que sea relevante para la historia que se está discutiendo. Cualquier persona que pueda ayudar a descubrir nuevas preguntas o convertir las preguntas en decisiones durante la conversación será útil.
Mientras aprende esta técnica, puede ser útil tener a alguien en el papel formal de facilitador, cuyo trabajo sea asegurarse de que todo lo que se dice se capture en una tarjeta. Los ejemplos y las preguntas vuelan rápidamente por la sala, y se necesita disciplina para capturarlos en la mesa para que pueda verse de lo que se está hablando.
Entonces ¿cuándo escribimos el Gherkin?
No dejes que esta publicación te confunda: también es de gran valor escribir Gherkin juntos, especialmente durante los primeros días de un proyecto. Ahí es donde desarrollas tu lenguaje ubicuo, y es vital tener esos escenarios expresados de una manera en la que todos en el equipo crean.
Pero expresar ejemplos de esa manera requiere un modo de pensar diferente al de decidir qué ejemplos están en el alcance y aclarar las reglas subyacentes.
Para un equipo que está funcionando, con un lenguaje de dominio bastante maduro, mi preferencia es que la persona del producto dedique su tiempo y energía a la sesión de mapeo de ejemplos y deje la escritura real de Gherkin a sus otros dos amigos. Una vez que han redactado una especificación de Cucumber, la persona del producto puede darles su opinión.
¿Es así como lo habría escrito?
Esto le brinda la oportunidad de probar qué tan efectiva fue la conversación de mapeo de ejemplos para transferir el conocimiento de la persona del producto a sus amigos.
¿Con qué frecuencia debemos hacer esto?
La gente de producto suele estar ocupada. Respeta su tiempo programando estas sesiones de manera que puedan prestarte toda su atención.
Mi recomendación, basada en lo que he visto funcionar para varios equipos en la práctica, es ejecutarlos con frecuencia: cada dos días suele ser un buen ritmo. Solo elige una historia y dale 25 minutos de atención, luego vuelve al trabajo. Tratar de hacer más en un lote grande solo agotará su energía.
¡Pero mi equipo está distribuído!
Ya he visto trucos innovadores en esto: algunas personas usan listas con viñetas en un documento de Google, he visto personas que usan una hoja de cálculo con celdas de colores para representar las tarjetas. También puedes usar un mapa mental. La clave es mantenerlo rápido y fácil de usar, para que puedan concentrarse en la conversación.
Algunas consejos finales
Es importante comprender claramente la distinción entre reglas y ejemplos antes de poder utilizar el mapeo de ejemplos. Tengo un ejercicio divertido para enseñar esto que compartiré en una publicación futura.
Recuerda que todo el propósito de esta conversación es descubrir las cosas que aún no sabes. Así que no hay preguntas tontas. Diviértete y explora realmente el problema.
Descubrirás que las reglas crean fallas naturales para dividir una historia. Trata de sentirte cómodo aplazando tanto como sea posible, para que puedas concentrarte en resolver el núcleo del problema. Puedes agregar más sofisticación (y complejidad) más adelante.
Gracias a Janet Gregory, Aslak Hellesøy y Seb Rose por sus comentarios sobre esta publicación, a Theo England por su paciencia mientras la perfeccionaba y a Tom Stuart por sacarme el dedo.
Aula espaciosa, luminosa, con ventanas que pueden abrirse. Mesas altas y bancos que pueden acomodarse a gusto. Pizarra blanca con marcadores de 4 colores en perfecto estado y borrador. Sin aire acondicionado pero con ventilador. Proyector modelo 2019 con entrada HDMI y muy buena definición. Conexión WIFI de buena velocidad y bastante estable. Y posiblemente lo más importante: 11 alumnos y dos docentes nombrados (y algunos otros colaboradores informales/sin nombramiento).
No todo es perfecto, por supuesto: paredes con pintadas y con manchas de humedad, un edificio que literalmente se está cayendo a pedazos, un sueldo demasiado discreto (para los que tenemos sueldo) y una burocracia infinita e ineficiente.
Así es la situación de contexto para las clases de MeMo2 que estoy dando este cuatrimestre los lunes por la mañana (8:00 am) en la Facultad de Ingeniería de UBA. Si, la UBA, esa institución tan grande, tan politizada y con espacios tan distintos. A mi mismo me cuesta creerlo y el único cambio que hicimos fue el horario. Esto me hace pensar muy seriamente el mantener este horario matutino de forma permanente.
Ayer estuve participando en el ciclo de Tech Talks facilitado por Arcadio Abad. Estuve hablando sobre un conjunto de prácticas que he dado en llamar Testing 3.0.
La charla fue efectivamente una charla de ida y vuelta con Arcadio quien a su vez transmitía las preguntas de la audiencia. Me sentí muy cómodo con el formato y creo que pude dar respuesta a todas las preguntas que Arcadio me transmitió(aunque creo que por el chat pasaron algunas otras que pueden haber quedado sin respuesta por cuestiones de tiempo).
Durante la charla hablé de varias cuestiones pero la gran mayoría relacionadas a la idea de usar los tests como especificación de requerimientos y guía del desarrollo (lo que usualmente se conoce como BDD). Comparto aquí algunos recursos al respecto:
Los libros de BDD de Rose y Nagy son simplemente excelentes.
El libro «Specification by Example» de Goyco también es excelente, es bastante más extenso porque cubre muchas cuestiones.
Unos videos que muestran la técnica de BDD/TDD en acción: parte 1 y parte 2
Y si quieren aprender más de BDD y no tienen un perfil muy técnico, los invito a que se sumen a mi Taller de Prácticas Técnicas para Scrum Masters (al margen del nombre, vemos cuestiones que son relevantes incluso para gente que no es Scrum Master)
Ya tenemos confirmada la cuarta edición de este seminario. Para quienes nunca escucharon al respecto de este seminario les cuento que está basado en el libro Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (IT Revolution, 2018) y tiene como objetivos:
Entender el impacto de las capacidades de Software Delivery en la performance del negocio
Entender las prácticas técnicas y de gestión que mejoran la performance de delivery
Conocer posibles estrategias para la adopción de las mencionadas prácticas
En términos de dinámica de cursada mantendremos el mismo formato que el año pasado:
100% online
6 encuentros de 2,5 horas cada uno
Los encuentros serán semana por medio, haciendo una duración calendario total de 11 semanas
Estimamos una dedicación semanal de 3 horas todas las semanas (al margen del tiempo de los encuentros)
Al igual que la edición 2022, tendremos un primer encuentro informativo, online y de participación abierta, el mismo será el miércoles 22 de marzo a las 9.30, los interesados en participar de este encuentro informativo pueden inscribirse aquí.
Las fechas de los encuentros son:
2023-03-22, encuentro 0, presentación del seminario (previo a la inscripción)
2023-04-12, encuentro 1
2023-04-26, encuentro 2
2023-05-10, encuentro 3
2023-05-24, encuentro 4
2023-06-07, encuentro 5
2023-06-21, encuentro 6, presentación de trabajos finales y cierre
Este jueves 9 de marzo estaré participando del ciclo de charlas técnicas organizado por la gente de Abstracta. En dicho espacio hablaré sobre mi visión actual del testing en general y del rol de tester en particular. La charla está pensada como una continuidad/profundización de la charla que dí en la QualitySense Conf en diciembre 2022 (video disponible aquí) y resume lo que actualmente enseño en la universidad.
Algunos puntos centrales de la charla:
Parte del testing lo deben hacer los desarrolladores.
Los testers deben trabajar muy cerca de la gente de negocio.
Los casos de pruebas deben generarse temprano en la iteración, incluso algunos casos de prueba deberían estar claros al finalizar la reunión de planificación de la iteración.
La gran mayoría del testing debe estar automatizado.
La ejecución de la mayoría de los test debe poder ejecutarse sin necesidad de utilizar un ambiente particular.
Testear algunas cuestiones en producción es válido, pero ello requiere planificación de cara a poder contemplarlo a nivel de desarrollo e infraestructura.
Varios de los puntos anteriores impactan directamente en las tareas y habilidades del tester y sé también que algunos pueden resultar polémicos. Esto es una buena excusa para sumarse la charla, es gratuita pero require registració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.
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.
Blog de NicoPaez 