Agile Retrospectives: cómo mejorar

En una pequeña serie de artículos resumiré lo que encontré recientemente en el libro que abajo se referencia referente a cómo mejorar las reuniones retrospectivas (qué mal suena; no, no estoy hablando de Retrospector ni nada relacionado con La Hora Chanante).

¿Qué es un ‘retrospective’?

Una retrospección en la vida es pararse por un momento, mirar hacia atrás y reflexionar sobre el camino trazado hasta la fecha, evaluando las cosas buenas y las malas, y aprendiendo de todo ello para ser mejor persona.

Esto, que muchos seres humanos que andan sueltos por ahí deberían hacer a menudo, en las metodologías de desarrollo ágil de software se llama “retrospective” y en un modelo de desarrollo iterativo viene muy bien para evaluar cada una de esas iteraciones que se realizan. En nuestro caso particular orientaremos el discurso hacia SCRUM, quizá la metodología ágil más conocida y extendida, junto con eXtreme Programming.

Fases de un ‘retrospective’

Una buena reunión retrospectiva debería constar de las siguientes fases:

  1. Establecer el escenario.
  2. Recoger datos y métricas.
  3. Generar reflexiones y opiniones.
  4. Decidir qué hacer.
  5. Cerrar el retrospective.

Estas fases, no parecen nada del otro mundo y muchos equipos las llevan a cabo, en mayor o menor medida. ¿Por qué aun así no hacen buenos retrospectives? Bueno, quizá el problema está en el cómo y no en el qué.

¿Quién dirige un ‘retrospective’?

Un retrospective puede estar dirigido por el gestor del equipo o por cualquier miembro del mismo, o incluso ir variando en cada ocasión. Quien dirige la reunión deberá mantenerse lo más al margen posible, porque el poder subyacente que posee quien dirige la reunión puede coartar a los demás miembros a participar. Esto es especialmente apblicable al gestor, que en cualquier caso se mantendrá lo más al margen posible de la discusión, debido a que su estátus puede influir en las opiniones del equipo y romper la dinámica del grupo.

Es importante identificar qué parámetros se han de analizar en un retrospective. Algunos buenos ejemplos:

  • Buscar modos de mejorar las prácticas.
  • Descubrir qué se hizo bien.
  • Entender las razones subyacentes por las que no se cumplieron los objetivos.
  • Buscar modos de mejorar la responsabilidad de cara a los clientes.
  • Reconstruir relaciones maltrechas.

Y para terminar esta sección, dos máximas que deben cumplirse durante una reunión retrospectiva:

  1. Evitar culpabilizar a sujetos por el incumplimiento de un objetivo.
  2. Facilitar el que todo el mundo hable.

¿Cuánto debe durar un retrospective?

Depende.

De la duración del sprint, de la complejidad de la tecnología que se maneja en dicho sprint, del tamaño del equipo y del nivel de conflictos y controversias en las opiniones de los miembros. Como guía: cada semana de sprint, una hora de reunión retrospectiva.

Acortar el tiempo de la reunión es hacer trampa y engañarse uno mismo; sin embargo, si los objetivos se cumplieron se puede acortar la reunión.

Por otro lado, los retrospectives deben prepararse previamente. El equipo debe entrar en la sala de reuniones con algo mínimamente preparado, un adelanto de lo que se va a hablar.

¿Cómo preparar retrospectives?

El responsable debe responder a las siguientes preguntas:

  • ¿Cuál es el objetivo de la reunión?
  • ¿Quién atenderá?
  • ¿Cuánto durará?
  • ¿Dónde se celebrará?
  • ¿Cómo se organizará la sala?

¿Como hacer que el equipo prepare la reunión?

Puede enviarse un pequeño cuestionario por correo electrónico a todas las personas que van a asistir a la reunión antes de hacer el retrospective. De este modo se forzará a que el equipo se tome unos minutos en reflexionar sobre el sprint. Tras recibir las respuestas, que se tratarán anónimamente, pueden leerse los resultados en voz alta durante el retrospective, de manera que sirva como resumen de las impresiones generales del grupo.

Otra opción es solicitar un breve resumen de las impresiones del sprint.

¿Y después de la reunión?

Asigna cada acción a realizar en el siguiente sprint a un responsable. Muchos retrospectives fracasan porque, a pesar de que se aportan buenas ideas, éstas quedan en el aire y se olvidan para el siguiente sprint. Asigna responsables y haz que el equipo colabore en el cumplimiento de dichas acciones.

Y en la próxima entrega…

He dado un rodeo a propósito para no explicar detalladamente las fases de una reunión retrospectiva. Mi objetivo aquí ha sido el de sentar las bases, dar unos primeros consejos y establecer algunas ideas. En la próxima entrega explicaré detalladamente en qué consiste cada fase.

Y en siguientes entregas explicaremos una serie de actividades que pueden realizarse durante la reunión retrospectiva y cuyo objetivo primordial es fomentar la participación. Fuera aparte de las ideas que surjan, de las decisiones tomadas y todo lo demás. Lo principal es hacer que todo el mundo participe. Lo demás vendrá sólo.


Referencias:

Agile Retrospectives – Making good teams great

Esther Derby, Diana Larsen

Serie:

Agile Retrospectives: cómo mejorar

Agile Retrospectives (II): Fases

Agile Retrospectives (III): Actividades (I)

Inventos de hoy y de mañana

En esta sociedad del futuro, de la innovación, de la tecnología y las comunicaciones, de los viajes espaciales y la biología molecular, de los truños de realities y de los programas del corazón, nadie se atreve a hablar de aquellos nichos de la vida en los cuales poco o nada hemos avanzado en los últimos años. ¿Miedo?, ¿conspiración de los gobiernos poderosos? ¿manipulación de los medios? ¿a qué huelen las nubes? ¿qué hace un funcionario en vacaciones? ¿trabajar?

Bien, pues a pesar de todas estas preguntas, para las que lógicamente no tengo respuesta, faltaría más, trataré de ahondar en aquellos aspectos en los que creo que no hemos avanzado mucho, o para que me entiendan mejor: hemos progresado más bien poco.

Podríamos comenzar por los inventos inútiles, como por ejemplo el bidé. El bidé, como todo el mundo sabe, sirve para dejar la ropa sucia y para que las putas te laven la polla antes de chuparla. Porque serán putas pero la higiene es la higiene. Si tienes en casa un bidé y no lo usas con estos fines es que no tienes ni idea de para qué sirve un bidé. Pregunta al fabricante.

Otro invento inútil son los juegos que vienen con la TDT. Ya jode que te tengas que comprar una puta mierda de telar para ver la tele como para que encima incluyan juegos cutres, con intensos colores que dañan la retina y que encima son más viejos que Anita Obregón. ¿Realmente alguien ha encendido la tele alguna vez y se ha puesto a jugar al tetris o al bricks con la TDT? ¿En serio?

Uno más: los pañitos de punto de cruz. Tela con éstos (jo, si no hago un chiste fácil reviento). Son decorativos, son bonitos, dan un toque de personalidad… acumulan polvo y recuerdan a las cutre-pelis de Almodóvar. Que luego vas a quitar el pañito para limpiar y ves el dibujo perfectamente impreso debajo, con el polvo que se ha colado por los huecos. Qué bonito.

Entre los inventos que directamente son timos están los crecepelos y tratamientos anticaída. Vamos a ver: si se trata de un asunto genético y que te dicen que no se puede evitar, aunque sí ralentizar a base de dejarte los dineros y echarte ridículos potingues en el pelo, si los dermatólogos dicen que todo eso es un timo, ¿cómo va a funcionar? Vamos a explicarlo con un sencillo ejemplo que todo el mundo entenderá: si Zidane está calvo con la de pasta que ha ganado durante su proceso de caída del cabello, ¿cómo coño va a existir un invento para evitar la calvicie?

Más inventos chorras: los post-it. Esa maravilla de papel que sirve para escribir cosas, pegarlas en un sitio visible y de este modo no se te olvide recoger los niños del colegio. Hasta aquí todo bien salvo por un pequeño detalle. No pegan. Simplemente no pegan. Tú lo dejas en el monitor, te das la vuelta y el puto papelito ya no está ahí; está caído sobre la mesa. Y boca abajo, además, el muy cabrón, para que se te olvide el detalle. Y claro que se te olvida, porque llenas todo de post-it y no tienes forma de ver qué era importante y qué no. Lo metes en la cartera, lo dejas sobre la mesa y ahí se queda. Olvidado de la mano de Dios.

Finalmente están los abrefáciles de los tetra-brick. Qué invento el tetra-brick, oigan. Una maravilla de la ciencia y la tecnología. Un puto poliedro de cartón. Para meter cosas. Idealmente líquidos. Lo malo es sacarlas. Y ahí viene la fiesta: empezó siendo una línea de puntos, pintada sobre un fondo azul. Vale. Todos, de niños, cuando cogíamos un cartón de leche, buscábamos el dichoso rectangulito azul para levantar la solapa y cortar por la línea de puntos. ¿Somos idiotas o qué? ¿Qué pasa, que por el otro extremo del cartón era imposible cortar? No, es que la tijera se traba, es un extremo mágico y los fabricantes han hecho que por ahí no se pueda romper jamás… ¡Joder, que es un puto extremo pintado! Y encima con línea de puntos, para que sepas  por dónde hay que cortar, no vayas a ser imbécil y te salgas de la línea!

Lo malo es que la cosa no ha mejorado desde entonces. Ahora están los tapones con una fantástica anilla debajo. Lo más normal que te puede pasar es que tires de la anilla y te salpique unas gotitas, ¡uy, qué cosa más simpática!, en las zonas más inesperadas: el mantel, la mano, la camisa recién planchada, los pantalones recién traídos de la tintorería…

En el peor de los casos te pueden ocurrir tres cosas, a saber:

  1. Que la anilla se rompa y el puto cacho de papel Albal siga ahí, inmutable ante tu desesperación. Te toca recurrir a un cuchillo y cortar el cacho como buenamente puedas. Después quedarán restos de papel de plata ahí, asquerosos, y corres el riesgo de cortarte, claro. La vida es emoción, amigos.
  2. Que la anilla se estire, se estire… y nunca corte la tira de papel Albal. Esto te deja un poco perplejo, porque no sabes si seguir tirando y exponerte a decorar las paredes de la cocina de leche o recurrir nuevamente al cuchillo (véase punto 1).
  3. Que salga todo. Y cuando digo todo… es todo: anilla, papelito, soporte de plástico… todo. Esto normalmente acaba muy mal: con medio litro de leche en el mantel, en tu mano, por tu ropa… acaba con tu paciencia, te supera… y encima ahora no hay forma de verter la leche, porque el cartón está plano y se derramaría por todas partes… aquí tienes que recurrir a una jarra o algo…

Por otra parte están esos inventos que se echan de menos y que uno no se explica qué cojones ha hecho el ser humano hasta ahora para no haberlos inventado ya; como por ejemplo el aspirador silencioso. Se ha inventado el aspirador con agua, el que tiene un cable extralargo, el que aspira mogollón, incluso el que no lleva cables sino una batería de litio con autonomía de tres horas. De puta madre, oiga, pero: ¿y el silencioso? ¡Porque yo estoy hasta las narices de que los vecinos me despierten los fines de semana porque están pasando el aspirador! Un apaño (o workaround, que decimos los informáticos, para dejar perpleja a la peña) sería inventar un dispositivo que hiciera que el cacharrín no arranque los fines de semana. Y todos tan contentos. Una solución muy española, además: en vez de atajar directamente el problema y solucionarlo, poner un cacho de esparadrapo y todos tan contentos.

Otro invento que estaría muy bien sería el desodorante repelente de pelmazos. Por este pagaría yo dinero, porque a todos nos ha pasado que estás un sábado de fiesta medio borracho, con la media sonrisa en la boca, la copa en una mano, el cigarro en la otra… y te viene el típico colega pesao a contarte lo que le ha pasado el miércoles en el trabajo, o te filosofa al oído, te filosofa escupiendo saliva además, o te cuenta lo graciosa que es una peli que ha visto o un libro que ha leído… y como no es plan de utilizar un desodorante normal para apuntarle directamente a los ojos y salir corriendo mientras él se returce de dolor pues digo yo que estaría bien algo que simplemente le quitara las ganas de dar el coñazo.

Algún día dejaré todo lo que hago en la vida e inventaré alguna de estas maravillosas cosas que nos harían la vida un poco más fácil, y me forraré, y especularé, robaré y seré corrupto, cual político del PP. Y entonces, veremos quién se ríe.

Test Driven Development: Patrones (I)

Después de estudiar las generalidades de Test Driven Development, explicaremos brevemente en una serie de artículos los patrones incluídos por Kent Beck relacionados con TDD:

Patrones generales

Test n

No es lo mismo probar algo a mano que ejecutar tests automáticos. Éstos últimos son una garantía de que lo que se ha cambiado no ha roto nada. Cuando hay estrés y el tiempo apremia, más razón hay para ejecutar los tests más a menudo en cada pequeño cambio.

Test aislado

Los tests tienen que ejecutarse lo más rápidamente posible, para no perder tiempo y para poder ejecutarlos con la frecuencia adecuada. Además, es muy importante que el estado de cada test debe ser totalmente independiente y no afectar a los demás.

Lista de tests

Antes de empezar a escribir tests, haz una lista (dinámica) de las cosas que se te ocurran que hay que probar. A medida que escribas cada uno de dichos tests pueden aparecer nuevos casos a probar que se añadirán a la lista. Recuerda que cada test debe probar una cosa y ser lo suficientemente pequeño como para dar un pequeño paso seguro adelante, que te permita avanzar hacia el estado final que deseas. Puesto que lo primero a lograr es un test que funcione, añade a la lista las refactorizaciones que se van a necesitar una vez se ha conseguido escribir un test que pasa.

El test lo primero

Primero escribe el test y después escribe el código probado por el test.

Los asertos, primero

Antes de escribir el código del test escribe los asertos; así sabrás de antemano las condiciones que se deben dar durante el desarrollo del test; de modo que el modelo a seguir es: test guiados por asertos. Cuando te dispongas a escribir el test, hazte las siguientes preguntas:

  • ¿De qué tipo de código se trata? ¿Es una modificación / nuevo método / nueva clase / refactor / … ?
  • ¿Cómo deberían ser los nombres de clases, variables y métodos?
  • ¿Cómo vas a comprobar el resultado correcto?
  • ¿Cuál es el resultado correcto?
  • ¿Qué otros tests nuevos sugiere este test?

Probar los datos

Utiliza datos lo más simples posible para tus test; recuerda que los leerán personas, así que si ‘1’ y ‘3’ valen igual para probar el caso, usa ‘1’. No reutilices la misma constante o variable para significados diferentes. Esto es válido salvo que se trata de tests de rendimiento o de sistemas en tiempo real. En estos casos deben utilizarse datos realistas.

Datos evidentes

Representa claramente los resultados esperados y reales y haz que la comparación entre ellos sea explícita.

Patrones de barra roja

Los siguientes patrones se refieren al desarrollo de tests en la fase en la cual el test falla.

Test de un sólo paso

Elige un test de la lista de tests pendientes que te vaya a enseñar algo del sistema y que estés convencido de poderlo implementar. Cada test debe representar un paso adelante hacia el objetivo global. Si no encuentras en la lista ningún test que represente un paso adelante, añade nuevos tests que representen un acercamiento a los elementos que ya tienes en la lista.

Al final no se sigue un desarrollo top-down o bottom-up, sino más bien de lo conocido a lo desconocido: tomando piezas de las que tenemos conocimiento, vamos avanzando hacia lo desconocido del sistema, aprendiendo cosas de éste en el camino.

Test de comienzo

¿Con qué test comenzar? Con una variante de una operación que no haga nada.

Tests de explicación

¿Cómo se propaga el uso de testing automático? Pide y provee explicaciones en forma de tests. De este modo, el equipo adoptará TDD más fácilmente. Convierte, por ejemplo, diagramas de secuencia en tests.

Test de aprendizaje

Escribe tests para comprender el funcionamiento de un nuevo API, COTS, librería, etc. que vayas a utilizar. Puede crearse, así, un modo de trabajar que es: si los tests pasan, ejecuto la aplicación; si no, no; porque sé que no va a funcionar de ninguna manera.

Otro test

¿Cómo mantener una discusión técnica sin salirse del tema? Cuando surja una idea que toque de algún modo la discusión principal, añade un test a la lista, y vuelve al tema de discusión. Mantente centrado en los objetivos, pero receptivo a nuevas ideas; anótalas y vuelve a tus objetivos.

Test de regresión

En cuanto se detecta un error, se escribe un test que lo cubra y después se soluciona el problema. Los tests de regresión son tests que, de haber tenido un conocimiento más profundo del sistema, cuando la funcionalidad que ha fallado se estaba desarrollando, debería haberse escrito en tal momento. Cada vez que escribas un test de regresión, piensa qué hubieras necesitado saber para haber escrito dicho test en primer lugar, cuando desarrollaste esa funcionalidad.

Descanso

¿Qué haces cuando estás cansado o te encuentras atascado? Tómate un descanso. Tómate un refresco, date un paseo. Si llega la idea, termina tu descanso, la idea no se va a ir. Si no surje la idea, plantéate si el objetivo que te has propuesto es correcto, realista y adecuado. Utiliza una botella de agua para descansar al cabo de unas horas; utiliza el sueño tras cumplir tus objetivos al cabo del día; utiliza los fines de semana para verificar el progreso y utiliza las vacaciones (tres o cuatro semanas es lo recomendable) para recargar las pilas para el resto del año.

Comienza de nuevo

¿Qué haces cuando te encuentras perdido? Tira todo el código y vuelve a empezar. A veces conviene que le cuentes lo que estás haciendo (y sobre todo, cómo) a un compañero; si él no lo ve claro, quizá sea buena idea comenzar de nuevo. Utiliza Pair Programming en estos casos también.

Escritorio barato, silla fantástica

Invierte en escritorios baratos, simples, feos y sobre todo espaciosos. Invierte también en las mejores sillas posibles, lo más cómodas posibles. Cuando se hace Pair Programming, cuida el que ambos programadores queden enfrente del monitor y que el teclado se pueda desplazar fácilmente.


Referencias:

“Test-Driven Development by Example
Kent Beck