Hace casi 4 semanas que no escribo sobre el #proyectodelamuerte. No es que nos haya fagocitado a todos sino que he estado tan descentrado que hasta la retrospectiva de este viernes no he vuelto en mí mismo.
El ir a Barcelona para el Agile Open Spain 201o y luego a Donosti para un nuevo coderetreat con Enrique Comba ha ayudado, sin duda, a que en lo personal y lo profesional estuviera descentrado. Para colmo, en medio, más actividad social con el grupo de Agile-Spain en Madrid (#madriagil) y una interesantísima cena en casa de Enrique Comba, que prácticamente sirvió de despedida informal al tímido @plagelao, que algún día será conocido como Alberto Peña. 😉 Alberto es la persona que más envidio ahora mismo sobre la faz de la tierra: se va a hacer lo que más le gusta, hacer software, con gente que también le encanta hacer lo mismo y que, por si fuera poco, lo hacen muy, pero que muy bien. No hace falta decirle que lo disfrute porque seguro que lo hará. Así que sólo me queda envidiarlo. 🙂
Aprendizaje: No se puede tener una vida social tan ajetreada con un #proyectodelamuerte entre manos. No es profesional.
Pero durante estas cuatro semanas han pasado muuuchas cosas en el proyecto. No todas malas. Algunas buenas. Por ejemplo, el nuevo analista para el backend se ha puesto las pilas y ha empezado a conocer la aplicación rellenando las paredes con pantallazos y flechas que explican la navegación. Poco a poco comienzan a darse discusiones frente a esos pantallazos y, lo mejor de todo, comenzamos a identificar defectos antes que los usuarios. También, poco a poco, vamos teniendo el modelo de datos en las paredes. Pero, como suele suceder en estos casos, las malas noticias se comen a las buenas. Es lo típico: basta que dejes un día el coche mal aparcado para que te pongan la multa. (Bueno, en nuestro caso es que dejamos el coche mal aparcado casi todos los días, ¡ya nos vale!)
Durante este mes hemos tenido sólo una retrospectiva (llegamos al convencimiento de que una retrospectiva por iteración era demasiado, porque nuestras iteraciones son -pretenden ser- de una semana). Y la que hemos hecho este viernes en realidad llevaba retrasada una semana porque no pude estar la semana anterior y luego la he ido aplazando hasta que ya me dolió demasiado. Eso sí, salí escaldado de la retrospectiva: me lo merecía.
Bueno, es evidente que el equipo sabe que la cosa no va bien, que el “Jefe de Proyecto” no está haciendo bien su trabajo y por eso la cosa va a peor. Echan de menos lo que se había ganado al principio. Analicemos un poco todo lo que el equipo señaló como cosas con las que se encuentra incómodo y quiere eliminar.
Lo que más nos preocupa es que no tenemos un tablón. Ahora tenemos varios tablones abandonados. Al principio improvisé un tablón en un papel de embalaje pegado en la pared y nos sirvió para ir adquiriendo foco en nuestras actividades diarias. Ahora tenemos unos “lujosos” tablones de cartón-pluma que me costaron un dineral y que aún no he pasado como nota de gastos a Kotasoft (que amablemente se ofrecieron a pagarlo). Pero estos están abandonados. Así que… #FAIL (y de los grandes). Quería que tuvieramos un tablón para la iteración en curso, otro para ir preparando la iteración siguiente, otro para el product backlog y otro para tener todas las tareas que se deben hacer periódicamente (todos los días, todas las semanas, todos los días 20, etc). Pero he cedido al día a día y no he cuidado el tablón (ninguno de ellos). Ya lo sé, no tenemos dueño de producto, pero eso no es óbice para que yo no haya puesto la energía necesaria para tener, al menos, el tablón de cada iteración actualizado. Es una herramienta fundamental para enfocar al equipo (a todo el equipo).
Durante estas últimas semanas habíamos conseguido ya un cierto ritmo sostenible, donde habíamos empezado a encontrarnos cómodos poniendo en producción de manera controlada todas las semanas, para ello tuvimos incluso que forzar a que fallara una puesta en producción. Pero no sé bien en qué momento nos dejamos ir (especialmente yo) y el ritmo sincopado de este proyecto nos ha ido absorbiendo. Y como consecuencia hemos empezado a no tener clara la gestión de la configuración. Incluso hemos tenido un despiste que nos ha llevado a poner un war viejo en producción. Vaya cagada. #FAIL. (Otro más). ¿Cómo mejorar esto? ¿Más concentración? Bueno, seguramente ayudaría, pero no creo que ésa sea la solución a la mayoría de los problemas. Es evidente que tenemos que automatizar mucho más. El paso a producción es aún demasiado manual y no tenemos muy claro cómo probar que todo está correcto. El amigo @kinisoftware (compañero de Kotasoft) se está currando un screencast (o una serie, ya veremos) sobre cómo incorporar Selenium a nuestra integración continua con Hudson. Ya uno de los “javeros” del equipo ha estado jugando con Selenium, así que calculo que será fácil incorporar un par de “smoke tests”, lo que nos ayudará a asegurarnos diariamente de que no estamos rompiendo cosas evidentes y, poco a poco, a que vayamos teniendo una batería de pruebas y automatismos que nos vayan dando más seguridad. Sabemos que esto no es una solución definitiva, pero es un paliativo necesario.
Otro frente donde tenemos que hacer más hincapié es una de las anotaciones en rojo (las que hemos señalado como acciones a tomar tras la retrospectiva): un calendario de tareas semanales en torno a la gestión de la configuración. Algo como: “¿cuándo arrancamos una iteración?”, “¿cuándo congelamos el código y abrimos la rama correspondiente?”, etc. Eso y un radiador de información claro donde se indique cuáles son los entornos y las versiones desplegadas en cada momento serán muy útiles. Esto es fácil de hacer y nos puede ayudar mucho a reducir los errores.
El jueves y el viernes estuve programando. (Cosa que me ha reprochado abiertamente Víctor: “sé que te apetece mucho programar pero ahora necesitamos que priorices”. ¡Vaya! Es la primera vez que en una retrospectiva en España alguien del equipo es tan honestamente sincero. ¡Bravo!)
El caso, y vaya en mi descargo, tenemos un proceso de negocio que consiste en la generación de unos PDFs que terminan llegando a manos de los clientes finales y en el que tenemos a un miembro del equipo involucrado hasta tal punto que si él no está el proceso de negocio falla y no se envían esas comunicaciones. Este proceso, antes de yo llegar pasaba por las manos del jefe de proyecto anterior, que con buena voluntad se había involucrado, pero que sinceramente creo que era un error porque ponía en manos de un equipo de desarrollo la responsabilidad de controlar un proceso de negocio, cosa que NO es de nuestro negociado. Así que, desde el principio he dejado claro que el control de ese proceso (mientras fuera una actividad manual) quedaba fuera del equipo de desarrollo porque somos desarrolladores, no gerentes ni administrativos ni nada por el estilo. Por fin parece que el “management” se ha decidido a hacerse cargo de él y, como era de esperar, se ha provocado un pequeño caos. Bueno, en realidad ha sido algo peor de lo que yo esperaba. Nos ha provocado más revuelo interno y no hemos podido digerirlo bien. Por eso me centré el jueves y el viernes en rediseñar la parte de la aplicación que se encarga de esto, para ser capaces de tener piezas bien desacopladas y configurables y así poder quitarnos de enmedio. Pero no pude terminarlo (de hecho lo he dejado incluso sin compilar en el PC de mi compañero… ejem, otro #FAIL más en mi debe) y eso me va a obligar a ponerme las pilas el lunes por la mañana y llevar tareas “de gestión” hechas desde casa. Pero esta tarea es MUY IMPORTANTE y tenemos que dejarla lista cuanto antes si no queremos tener más problemas.
Las anotaciones sobre DESORGANIZACIÓN y el RETROPLANNING (poner fechas y contar hacia atrás para hacer el plan) son muy interesantes. Por una parte, tengo la sensación de que la autoorganización comienza a funcionar, aunque en general el equipo siente la necesidad de que se les diga lo que deben hacer. En este asunto siempre he tenido una duda muy fuerte: debo forzar la situación y dejar que el equipo se autoorganice sin más, o debo ejercer de Jefe de Proyecto que dirige y reparte tareas para, poco a poco, ir dejando que el equipo se vaya autoorganizando. No sé. Sé que este tipo de cosas hace salir de su zona de confort a más de uno y provoca mucha incomodidad y se añade a otros cambios que se están provocando que contribuyen a la sensación de caos. Pero bueno, tampoco es que estemos desorganizados porque yo esté provocando un cierto caos controlado. No es eso. Es cierto que estamos desorganizados porque no estoy (como “coach”) manejando bien la transición desde el modelo tradicional al ágil y eso hace que el resto de dinámicas que deberían estar más controladas se hayan salido un poco de madre. Afortunadamente, nuestra Directora ha conseguido reducir la presión y priorizar el aseguramiento de lo que está en producción. Bueno, inmodestamente he de decir que en parte fue después de una reunión muy tensa con el malhumorado (y maleducado) Presidente, donde me salió el James Cagney que llevo dentro, pero que al final creo que fue bien porque hemos conseguido dejar claro que el proyecto está en una situación muy delicada y que requiere la implicación de toda la compañía si quieren salvarlo. Es un proyecto crítico, donde hay muchos intereses en juego y fracasar no es una opción para nadie. Y parece que esto es algo que, poco a poco, se va asumiendo y se están priorizando sólo tareas con fechas legales con el objetivo de que podamos consolidar la aplicación y los procesos que actualmente están en producción. Esperemos que sea suficiente. En cualquier caso, en la retrospectiva el equipo ha indicado esto como algo positivo, aunque también están preocupados porque parece que las fechas que se han establecido son demasiado justas. Cierto, son fechas que realmente no se han podido negociar porque casi todas son obligaciones legales o de marketing establecidas desde hace tiempo.
Por último, que ya veo que me ha salido un ladrillo como los que acostumbra Enrique Amodeo, resumir que, a pesar del rapapolvo que el equipo me ha dado en la retrospectiva, he de decir que estoy muy pero que muy orgulloso del resultado de esa retrospectiva porque es un ejemplo de honestidad por parte de todos. Han dicho abiertamente lo que piensan, por el bien del proyecto, sin más. Y eso, para mi, es muy importante, porque quiere decir que tenemos un equipo. Sólo hay que conseguir recuperar el ritmo sostenible y lo demás (la autoexigencia y la autodisciplina) vendrá por sí mismo. 🙂
P.S.
@jerolba ya ha comenzado a retomar el contacto con su hijo deforme (el #proyectodelamuerte). Se va a ir incorporando poco a poco y no hemos tenido tiempo de arrancar ese kanban del que hemos hablado para tener una lista de tareas que podemos ir abordando con su ayuda. Me ha encantado el cariño con el que todo el mundo lo ha recibido, yo diría que incluso la gente que no lo conocía. 🙂
A ver si podemos consolidar esta semana que viene el fichaje de @reemplazable y con esto tendríamos un equipo listo para recuperar al paciente en la parte Java.