«User story»: una explicación sencilla, o cómo dividir un producto en etapas

Puede que te hayan dicho que tu proyecto se dividiría en «user stories». La expresión viene del sector, no es tuya, y esconde una idea que ya aplicas cuando encargas un trabajo: una etapa se describe por lo que podrá comprobarse al final.

Una user story, explicada de forma sencilla, es una etapa de construcción descrita desde el punto de vista de la persona que usará el software, con la lista de lo que podrá comprobarse cuando termine. En el resto de este artículo, y también en nuestro producto, decimos «etapa», porque la expresión inglesa no aporta nada a quien encarga un software.

Una etapa es una frase y una prueba

Pensemos en una herramienta de gestión de taller. «El cliente recibe un mensaje cuando su reparación está lista» es una etapa. Cabe en una frase, identifica a la persona afectada y, sobre todo, incluye lo que demuestra que está terminada: el mensaje sale en el momento adecuado, contiene el número de expediente correcto, no se envía dos veces y no se envía en absoluto si el cliente ha pedido no recibir nada. Esa lista de pruebas es lo que cuenta. Sin ella, la etapa es un deseo, y el final del trabajo se convierte en una negociación en la que cada uno defiende su interpretación de la frase inicial.

Por qué dividir cambia lo que ves

Un proyecto entregado de una sola vez te deja sin noticias hasta el día en que te lo enseñan todo. Entonces corregir resulta caro, porque el resto se ha construido encima. Un proyecto dividido te entrega algo verificable a intervalos cortos. No miras código, sino un comportamiento: si sale el mensaje, si la factura se imprime con las menciones correctas, si el descuento por fidelidad se aplica al importe adecuado. Dividir es tu única forma de mantener el control sin leer una línea técnica, y también hace comprensible un documento de requisitos para quien no pertenece al sector.

Quién divide, quién construye, quién verifica

En nuestro caso, tres agentes se reparten este trabajo sin pisarse. Marcel divide: toma el documento de requisitos que has validado y obtiene una secuencia de etapas, cada una con su lista de pruebas. Amélie construye la etapa. Félix la verifica y tiene la última palabra: mientras las pruebas no se superen, la etapa no cuenta como terminada. La separación tiene un motivo: quien escribe y quien controla no pueden ser la misma persona, porque entonces el control se adapta al trabajo. Hemos visto qué ocurre en el caso contrario, cuando todo está en verde y, aun así, está mal.

El orden es nuestra regla más estricta: las pruebas se escriben antes que el código. Félix establece primero la lista de lo que la etapa deberá demostrar, y esa lista falla porque todavía no existe nada. Después, Amélie construye hasta que se supera. Escrita en ese orden, una prueba describe lo que querías; escrita después, describe lo que ha producido la máquina y no te protege de nada. Detallamos esa decisión y sus costos en primero las pruebas: TDD impuesto a los agentes.

La trampa de la etapa demasiado grande

«Gestionar los clientes» es un capítulo del tamaño de un trimestre. Nadie sabe cuándo acaba, así que nadie sabe si ha acabado. La señal es fácil de detectar: si no puedes escribir en tres líneas qué vas a comprobar en pantalla, la etapa es demasiado grande y hay que dividirla. A la inversa, una etapa que no produce nada observable para una persona no debe figurar sola en una lista que validas. Entre ambos extremos, el tamaño adecuado es el que te permite decir «me parece bien» o «no, falta esto» al mirar el resultado, sin que nadie tenga que traducirte nada.

La palabra que sigue siendo tuya

Cada etapa construida vuelve a ti como una propuesta, no como un hecho consumado. Dices «Me parece bien» y empieza la siguiente. Dices que no y vuelve a corrección. Esa puerta existe en cada documento y en cada etapa, lo que ralentiza un poco y evita mucho, por las razones que expusimos en «Me parece bien»: la validación humana.

Dividir tu proyecto esta noche

Toma una hoja y escribe diez frases que empiecen por el nombre de una persona: el cliente, la secretaria, el contable, tú. Cada frase dice qué hace o recibe esa persona en tu futuro software. Debajo de cada una, escribe dos líneas de prueba: qué vas a mirar para afirmar que está bien. Si una frase se resiste, acabas de encontrar la parte de tu trabajo que nadie ha escrito todavía, y es la que habría descarrilado el proyecto más adelante.