Scrum, Sprints, Estimaciones y Fanfarrones

¡Al tema! ¡Y vaya tema!

Cada año, en una extraña herencia de las dietas milagro, aparecen en el ámbito empresarial, y adoptado especialmente por el sector tecnológico, fórmulas mágicas que prometen ser una revolución. Unido a esto, hay quien; por asistencia a una conferencia, descubrimiento fortuito o conversación de café (con o sin misterio) con un compañero de puesto similar en una empresa mayor; se "empapa" o se lo mira por encima o se crea un concepto en su cabeza, llega a la oficina y dice: ¡Eureka!

Seguramente habrás oído hablar de, o sufrido, el método Scrum o similar. Son métodos de trabajo, realmente aplicado a cualquier sector, orientado a grupos, en principio, con un proyecto común cuyas tareas son dependientes.

En muchos casos asistirás, o habrás asistido, a reuniones dónde realmente cada profesional se ocupa de un sprint (el tiempo estimado para ese grupo de tareas), aunque por alguna razón el "especialista" de turno ha mezclado en un sprint tareas no dependientes, de ahí que diga que cada profesional se ocupa de un sprint. La reunión se hace eterna, pues realmente se está haciendo una reunión con los presentes sin estar todos involucrados en el mismo proyecto o que no tienen tareas dependientes. 

La empresa acaba de ser víctima de un fanfarrón, y tú acabas de sufrir las consecuencias. Pues esa palabra que el "especialista" escuchó y que le llevó a decir "Eureka!", se ha convertido en un absurdo método de control y de examen estresante de aptitudes.

Si en este punto has entendido algo, es que lo has sufrido. Bienvenido a la era de la fanfarria tecnológica.

En caso de que se aplique de forma correcta una metodología ágil como Scrum, entramos en un terreno pantanoso si hablamos de servicios, especialmente si hablamos de desarrollo informático.

Una de las bases de este tipo de metodologías es la estimación de tiempos. Y eso, en desarrollo informático, es un problema.

Veamos cómo sería la estimación de tiempos en un carpintero.

A un carpintero le piden hacer una silla. Con una madera, barniz y forma concretas. El carpintero no ha realizado nunca esa especificidad. Al carpintero le hacen la pregunta: ¿para cuándo estará?. El carpintero tiene esa madera. Si no la tuviese tendría que buscarla y hablar con proveedores conllevando un tiempo indeterminado. Pero afortunadamente para nuestro implicado, tiene la madera que se ha solicitado. 

¿Cuánto tardará? Él ha trabajado esa madera, y en hacer una silla tarda 3 días. Pero el diseño lo desconoce, por lo que responde: "6 días". 

El carpintero se encuentra con que ciertos aspectos del diseño, con esa madera concreta, no son viables. Ha tenido que hacer algunas pruebas que le han retrasado un día. Al final comprueba que para algunos elementos necesita cambiar la madera. Escribe un email (es un artesano moderno) al cliente que le responde un día después, aceptando el cambio de madera en esos elementos. 

El carpintero, al barnizar con el líquido especificado, descubre que éste, que también lo tenía, se comporta de forma diferente en cada tipo de madera. Por lo que necesita cambiar el tipo de barniz, escribiendo nuevamente al cliente. El cliente responde en dos días admitiendo el cambio. 

El carpintero entrega el trabajo a los 8 días. En este caso ha tenido suerte y el cliente (o jefe de proyecto) entiende la circunstancia. 

Al mes siguiente, llega otro cliente que pide un diseño muy parecido al anterior, con la misma madera y el mismo barniz. El carpintero le informa de los cambios que serán necesarios, y ante la pregunta de "¿cuándo estará?", el carpintero responde 5 días, entregando el trabajo en 3 días. 

¿Se entiende? Bien. Normalmente un desarrollador informático no repite una tarea. Es más; un buen programador/analista informático reutilizará hilos de código (clases, rasgos, etc.), cuya preparación inicial conllevará un tiempo indeterminado en pro de un ahorro de tiempo posterior. Y teniendo en cuenta esto, ¿cuál crees que debería de ser la respuesta a la pregunta de cuándo estará?.

Este es el gran problema que se encuentra un programador, analista o cualquier puesto que necesite hacer un estudio previo ante una tarea desconocida ante la estimación de tiempos. Cualquier desarrollador sabe que, excepto las tareas de mantenimiento con error localizado, algo que estimas en cinco días puede estar en dos horas o en un mes.

Algo que, sin duda, jamás entenderá el fanfarrón de metodologías ágiles que utiliza como control de personal y que le hace sentirse útil con la convicción de que, si no fuese por él, la empresa no saldría adelante. 

Hay muchos tipos de trabajadores en todas las empresas y sectores. Unos aportan rapidez, otros excelencia y otros creatividad. Un jefe de proyecto que no sabe sacar partido de su equipo no está haciendo su trabajo correctamente. Por muy al día que esté en dietas milagro.