Kanban, Scrum, CMMI light.

“La vida te da sorpresas” decía Rubén Blades en su canción Pedro Navaja. Y llevando casi un mes mirando las paredes en mi antigua empresa, me llegó una oferta de trabajo tan interesante como crítica en su plazo de decisión. Como “las oportunidades solo se dan una vez” y “camarón que se duerme se lo lleva la corriente”, he cerrado una etapa de casi tres años en Alten, donde he realizado de todo tipo de labores. Y empiezo en mi nueva empresa –Quadramqs- como Jefe de Proyecto . NET. Bueno, más bien líder de equipo. Es decir, sigo picando código y además hago la documentación.

Lo bueno es que al ser una empresa joven tengo capacidad de decisión sobre la metodología a utilizar y un equipo de nóveles que me acompañan en el “hambre” por probar cosas nuevas.

En el primer aterrizaje, lo primero es “levantar” el servidor de base de datos y el servidor del repositorio de código/documentación. Es decir instalar un SQL2005 y un servidor TFS. Mientras espero que entre Sistemas y yo montemos el tinglado y quede accesible a todo el dominio – revienta todo cuando a la máquina de un tfs la metes en dominio – tengo que probar el conocimiento y velocidad del equipo que, además, está habituado a la metodología ASM (A Salto de Mata @Rodrigo del Corral)  y más bien llegan justos de conocimientos.

Para ello ataco dos vertientes diferentes de modo simultáneo:

1. Técnica:  Les pongo un ejercicio de construcción de una pequeña aplicación en donde, aumentando la complejidad poquito a poco, veo cuales son sus límites y sus conocimientos. Arquitectura de dos capas, datos y representación. Acceso a los datos por Linq to Entities. Pruebas unitarias para cada método. Cargas de datos con SqlAdapter. Y construcción manual de GridView.

2. Metodología: Con el objetivo final de utilizar SCRUM en el desarrollo del proyecto real, tengo que empezar con un tablero Kanban de tres columnas: ToDo, Doing(2), Done. Y, además, este tablero será virtual en Scrumy ya que aún no tenemos el tablero físico.

Insistiendo un poquito y revisando desde internet en casa o en la calle el tablero y comentándolo al llegar a la oficina, motivo para que lo mantengan actualizado, pero observo cierta tendencia a tenerlo en segundo plano. Más como un reporte qué como seguimiento del flujo de trabajo.

A los pocos días llega nuestra flamante pizarra y plasmamos el tablero con rotulador. Y entonces si que se convierte en un punto en donde sin tener que preguntarme, el propio equipo decide qué tarea hacer y cuando. Ha llegado el momento de darle una vuelta de tuerca a la metodología y les pido estimaciones.

Esto provoca en los noveles incomodidad ya que lo entienden como fiscalización. Pero después de dos o tres previsiones fallidas, pero cada vez más cercanas, se convierte en una motivación más y se les ve como empiezan a sentirse responsables de sus actuaciones. Se implican… :)

La próxima semana empezamos a trabajar en el proyecto real. Las tareas realizadas ahora, sin que ellos lo supieran, son exactamente las mismas que vamos a realizar para construir el primer módulo que nos va a llevar el primer sprint. Y el lunes conocerán que es un planning meeting, e intentaré ser disciplinado con las daily meeting.

Mientras, en mi lado de Gestor del proyecto. Tengo mil reuniones de toma de requisitos en donde lo de las “historias de usuario” es pura ciencia ficción. De todo lo leído he puesto en práctica el recorrerme todos los puestos de los usuarios reales de la aplicación y estar con ellos horas hablando, recabando sensaciones, mejoras y problemas. También realizo actas de reuniones tipo CMMI level2, y quiero realizar análisis funcionales de cada módulo a realizar ANTES de llegar al inicio del sprint, tanto como documentación para el cliente como para el Backlog Product.

Para dar una vuelta de tuerca a la visibilidad del proyecto, además de las entregas de cada iteración, pondremos el servidor de desarrollo accesible al cliente para que nos indique las desviaciones lo antes posible.

Jo!! Que gusto volver a estar en la brecha.