Metodologías. Agile. Scrum. Extreme programming. Muchas metodologías. « User stories » me parece muy de moda actualmente. Está bien.

Cuando era un desarrollador, yo no pensaba en las metodologías. O eres un buen desarrollador o no lo eres. Y si no lo eres, no existe ni una metodología que podría cambiar eso.

Requisitos

Un día, un jefe de proyecto me explicó que yo tenía que escribir las especificaciones para los requisitos de los usuarios, antes de empezar a programar. ¿Por qué tengo que perder 2 o 3 días para escribir especificaciones y esperar una semana para que no sé quién las accepta, cuando podría haber hecho el trabajo de inmediato?

Bueno, puedo entenderlo. Demasiadas veces empecé a tocar el teclado antes incluso de pensar a lo que tenía de hacer y al final del día, demasiadas líneas de código que ni siquiera yo podía entender, y peor aún, que no hacían nada. Bugs, bugs, bugs. Así que aprendí a tomar por lo menos 10 minutos a reflexionar, dibujar algo, pensar en un algoritmo.

Era un tiempo cuando metodología significaba diseñar un algoritmo. Después de eso, fue “entidad-relación”. Estructurar los datos como entidades y definir las relaciones entre ellos. Una metodología llamada Merise, muy famosa en los años 80. Por lo menos me ha gustado mucho, porque era como un ejercicio mental, un juego y era muy útil para diseñar la capa de datos.

El único problema es que tienes un montón de reuniones y por favor, tomate papel porque vamos a pasar unas horas hablando de si esta relación es bidireccional y de cardinalidad. Y sabes que la eficacia de una reunión es inversamente proporcional a cuanta más gente hay alrededor de la mesa. Y si se trata de una reunión de «user stories», incluso si sólo tienes a dos personas alrededor de la mesa, pero que uno es un desarrollador y el otro usuario, olvídate de la metodología y mejor recordarse de una reglas sencillas.

Los desarrolladores son de Marte y los usuarios de Venus

Los desarrolladores y los usuarios no hablan el mismo idioma, ¿por qué perder el tiempo contándose «historias»?

El proyecto está de retraso. El jefe del proyecto tiene una reunión con los usuarios y escucha sus últimas «historias». Luego el se pone con su hoja de cálculo o su software de gestión de proyectos para actualizar la planificación del proyecto. Luego tiene otra reunión para vender a los usuarios el nuevo calendario. Y luego una reunión con su jefe para hablar del calendario final. Aún más presión. Por último, se va a ver al programador que deja todo lo que está haciendo y rápidamente desarrolla un prototipo de modo que hay algo que mostrar en la próxima reunión y que los usuarios pueden ver que todo el equipo comenzó a trabajar en sus «historias». Tal vez los usuarios serán felices. Muy a menudo, van a empezar una otra «historia». O decir que el jefe de proyecto no entiende nada, que es tonto.

La única metodología que conozco es «garbage in, garbage out». Y como director de proyecto, mi primera prioridad siempre ha sido que todos entiendan bien que yo no sería responsable de la basura en la entrada. Por lo tanto:

1. El desarrollador no empieza nada hasta que el usuario tenga la «historia».

2. El usuario redacta su «historia» y firma su «historia». Con su propia sangre, si es posible.

Todo es crítico

Los usuarios quieren todo y su contrario. Una vez tuve una reunión con cerca de 20 vendedores para establecer una lista de requisitos. Después de un par de horas bastante productivas, teníamos definido lo que estaban esperando para su aplicación comercial y les pedí elegir lo que era crítico para ellos, lo que era importante y lo que era «nice to have». Me miraron como si yo les pedía un descuento, y respondieron que «todo es crítico». Entonces les expliqué:

«Un cliente llama por teléfono y vosotros deseáis lo más ante posible la pantalla con la ficha del cliente, los órdenes de venta, los datos contractuales y las informaciones personales, y todo lo que quieras y en menos de un segundo ¿no? Y queréis poder actualizar esta información tan pronto como sea posible mientras el cliente está en el teléfono?»

«Sí. El cliente no espera »

«También queréis hacer todo tipo de consultas en todos los datos posibles para identificar conjuntos de clientes potenciales y generar correos para enviar ¿no?»

«Sí».

«Bueno, se puede conseguir todos los datos de un cliente en un segundo, o se puede conseguir un dato de todos los clientes en un tiempo muy corto, pero no se puede tener todos los datos de todos los clientes en un segundo» .

Expliqué que para obtener una información tan pronto como sea posible, los desarrolladores ponen un índice en los datos, pero que lo más índices se usan, más lento todo el sistema. Yo pensé que el “query” de consulta del cliente era más importante, y me comprometí a proporcionar esta funcionalidad con el tiempo de respuesta lo más rápido posible. Luego les dije que si poder hacer todos tipos de consultas complejas en todos los datos era importante, no era algo que harían ellos todos los días, pero una vez al mes o al trimeste. Así que si este tratamiento es lento, una vez al mes, podían ir a tomar un café a la espera de los resultados. Y estuvieron de acuerdo.

Los vendedores a veces pueden ser usuarios exigentes, pero al menos entienden el concepto de negociación.

Así que cualquiera que sea la «historia» de los usuarios, lo importante es que:

3. El usuario define las prioridades.

4. Comprometete con lo critico, haz lo mejor que puedas de lo que es importante, y el «nice to have» es para la próxima versión.

Yo quiero la luna

Otro proyecto consistió en la creación de un sitio web de jardinería. Fue un proyecto difícil, con una planificación apretada, un equipo de proyecto no bastante numeroso, y un montón de presión. Y los usuarios no saben lo que querían, con los requisitos en constante evolución. Hasta que un día el director de la ‘startup’ del sitio web solicitó que se desarrolle una sección sobre «la luna y su influencia en las plantas.»

Pensé que era completamente irresponsable pedir tal cosa cuando teníamos mucho más importante que hacer, pero él era el gran jefe. Pedí al más joven en el equipo de desarrolladores para que crea un prototipo rápido sin perder demasiado tiempo en él. Él desarrolló una sección con dos o tres páginas que el usuario pueda actualizar, editar texto, añadir algunos enlaces, etc. y colocó la imagen de una luna en la parte superior de cada página.

Hice una presentación ante el gran jefe y sus ayudantes, en mi propio ordenador, y aunque no era todo lo que él había pedido, le gustaba. Pero en ese momento, él hizo algo estúpido: enseño la esquina superior derecha de la pantalla y dijo «Quiero la luna aquí.» Llamé al joven programador que estaba en el otro extremo de la sala así que todos podían ver, cuando se acercaba con pasos lentos a mi despacho, que estaba cansado de los caprichos de los usuarios.

El jefe reiteró su petición: «¿Es posible poner la luna aquí? »

El desarrollador joven miró con mucha atención en el lugar indicado en la pantalla como si estuviera pensando profundamente sobre el tema, y ​​simplemente respondió «No». Luego volvió tranquilamente a su ordenador pasando por una sala completamente aturdida. El jefe estaba tan sorprendido que solo miró la pantalla y dijo: «Bueno. Supongo que es bastante bueno, ya que está ahí”.

Después de eso, ya no tuvimos jamás ningún problema. No más evolución de las especificaciones. A veces yo invitaba el programador a una reunión de proyecto, y se sentaba a mi derecha, en silencio, para que todos puedan recordar que todo «era bastante bueno como estaba». A ese joven, yo le llamaba mi «Kill Bill».

La lección aquí es: lo que el usuario dice que necesita puede que no sea necesario. El problema no es entender las necesidades, sino producir una aplicación que satisface las necesidades de la empresa. El desarrollador puede modificar los requisitos hasta que el usuario demuestra que es absolutamente necesario. Esto implica, por supuesto, un buen conocimiento del negocio por parte del equipo del proyecto.

 

Tengo muchas historias acerca de los usuarios y probablemente también tienes algunas. Sea cual sea la metodología, hay algo fundamental que recordar: «Keep it simple».

El trabajo de un desarrollador es producir una aplicación de calidad, con herramientas de desarrollo que tienen bugs, base de datos con tiempo de respuesta impredecible, librerías no siempre operacionales y lenguajes de programación misteriosos y complejos.

Los desarrolladores tienen ya suficientes problemas sin pedirles que entiendan «historias».

Esta entrada está disponible también en Lire cet article en français y Read that post in english.