Libro Recomendado: Getting Real

Hace un par de días que terminé de leer Getting Real. Me parece que no es un libro demasiado conocido a pesar de tener casi 20 años. Yo lo tenía en mi lista de pendientes desde hace un tiempo porque uno de sus autores es David Heinemeier Hansson (conocido como «DHH», creador de Ruby on Rails).

La lectura me resultó muy amena, en parte por sus capítulos cortos (1 o 2 páginas) y en parte por ser contenido muy práctico: en cierto modo cada capítulo es un consejo sobre algún tema concreto sobre el desarrollo de productos web.

Creo que este libro es una lectura obligatoria para todo aquel que pretenda crear productos online/digitales.

Debo admitir que no estoy de acuerdo con todo lo que dice pero sí estoy totalmente de acuerdo con la mayoría de las cuestiones que plantea.

Es importante destacar que varias de las cuestiones que proponen los autores son, a mi parecer», de aplicación «universal» pero algunas otras claramente aplican puntualmente a escenarios de «startups».

Sobre la cadencia de iteración

Sobre la cadencia de iteración

Personalmente me gusta trabajar con iteraciones de 1 semana. Pero en el proyecto que estoy trabajando actualmente acordamos trabajar en iteraciones de 2 semanas pues la mayoría del equipo así lo prefiere y no logré convencerlos. Y cuando digo la mayoría del equipo en este caso es todo el equipo salvo yo. Entre los argumentos de mis compañeros para no hacer iteraciones de 1 semanas se destacó: «si hacemos iteraciones de una semana vamos a invertir demasiado tiempo porcentual en planning, review y retro». Personalmente no coincido, al ser las iteraciones más cortas, la planning y la review deberían también ser más cortas. Pero es cierto que más allá del tiempo dedicado a planning y review hay un costo de logística/setup de cada reunión.

Mi preferencia por las iteraciones de una semana se remonta a unos 10 años atrás. Desde entonces siempre que puedo intento trabajar de esta forma. Otra de mis preferencias es hacer las iteraciones en continuado agrupado en un mismo día las reuniones de revisión y planificación. Respecto de las retrospectivas no considero mandatorio que tengan la misma cadencia que la planificación. En varios proyectos he trabajado con una cadencia de planning/review semanal y con retrospectivas cada 2 o 3 semanas dependiendo de la consolidación del equipo.

Cuando me toca trabajar en iteraciones de 2 semanas (como en mi proyecto actual) yo igualmente en iteraciones de 1. No es que yo haga planning y review en solitario ni en paralelo, sino que al inicio de la iteración yo mentalmente planifico que voy hacer durante la primera semana. Una vez completa la primera semana, hago un checkpoint de mitad de iteración, leo el burndown chart, analizo cuánto hemos completado y veo como enfocar la semana siguiente de cara a intentar asegurar cumplir con el plan de la iteración o de ajustarlo si es que el contexto así lo requiere.