“No vamos a recoger requerimientos, sino ‘user stories’”, me dice un joven compañero del equipo de proyecto con una larga sonrisa que le cruza de oreja a oreja. Me da la impresión de que me están llamando a la cara viejo, trasnochado, anticuado; todo viene a raíz del uso (o desuso) de palabra ‘requerimiento’ y de la confusión que podemos tener en el entendimiento de qué es una metodología ágil.
El “palabro” de moda a la hora de definir lo que toda la vida ha sido un requerimiento es “user story”. Sí, es tope “cool”, no lo niego; mola mazo, y hasta a mí se me han empezado a quitar algunas arruguitas de la cara a medida que voy usando el “palabro” en cuestión, pero si leemos algunas de sus definiciones veremos que seguimos hablando de los mismo: requerimientos.
a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function Wikipedia
are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system Mike Cohn
“¿Cómo que no estamos recogiendo requerimientos?”, respondo. Mi compañero contesta que las ‘user stories’ exhiben características que las distinguen -y suponen una ventaja- de técnicas anteriores para la especificación de las necesidades… “¿Anteriores?”, pregunto “Sí, requerimientos al estilo IEEE 830”, me responde (¡Ya me han vuelto a llamar viejo!) “Vale, a ver, ¿qué ventajas son esas?”:
- Eliminan la imprecisión del lenguaje escrito
- Son útiles para la planificación, al otorgar a cada una de ellas un grado de dificultad o una estimación de tiempo
- Alientan al equipo a aplazar la recogida de detalles, permitiendo que se recojan todas esas historias rápidamente para tener una “sensación” general del sistema a construir y haciendo que esos detalles se obtengan, inicialmente, sólo de algunas historias para poder empezar cuanto antes su construcción
- No se generan miles de enunciados para especificar el producto final
¡Uf! Ahora sí que me han dejado planchado, porque me temo que las 2 primeras son ventajas compartidas y las 2 últimas son concernientes al ciclo de vida y no a un problema intrínseco a los requerimientos.
Razonemos. El patrón que siguen los enunciados de las necesidades según estos dos distintos estilos o corrientes es:
- Sentencia Agile – User Story: PERSONA + ACCIÓN + RESULTADO ESPERADO -> Como vendedor quiero que se creen facturas automáticamente para poder evitar perder tiempo creándolas manualmente
- Sentencia estilo IEEE 830: ACTOR + CAPACIDAD + [CONDICIÓN] + [RESTRICCIÓN] -> El sistema de facturación deberá crear una factura cuando un pedido sea enviado a menos que la forma de pago del pedido sea “prepago”
A la luz de los patrones expuestos, ¿podemos decir que el estilo IEEE 830 es poco preciso, más cuando la precisión es uno de los baluartes de IEEE 830? ¿Podemos decir que la ‘user story’ sea más útil para la estimación y planificación del proyecto? ¿Podemos decir que las estilo IEEE 830 empujan al equipo a obtener detalles ‘hasta el infinito y más allá’ generando miles de líneas enunciativas de especificación? No, no y no.
“Bueno, es que las ‘user stories’ son un punto de partida para establecer una conversación con los usuarios al respecto de esa historia, son narraciones livianas y no una declaración de una necesidad en sí misma” ¡Ahora sí que flipo! ¿No es una declaración de una necesidad?, entonces, ¿de qué son una declaración? Son livianas… ponme en la báscula tu narración a ver si pesa menos que una al estilo IEEE 830. Así pues, ¿no puede ser igual de válido declarar esa necesidad al estilo IEEE 830?
Deberíamos recordar que existe la denominada pirámide de requerimientos (descomposición en sucesivos niveles de detalle o refinamiento) en la que muchas de estas estas ‘user stories’, que provienen de ‘epics’, derivarán en ‘sub-stories’ -con nuevas y más detalladas condiciones de satisfacción- o bien en ‘use cases’ y ‘test cases’, de manera que acabas currando un montón y obteniendo igualmente algo parecido al tan “temido” SRS (Software Requirements Specifications) del IEEE 830. El problema radica en pretender tener el SRS completo antes de iniciar cualquier otra fase; por tanto no es un problema de qué hago, sino de cuándo lo hago.
“Pues léete ‘The Agile Samurai’”. Sí, reconozco que es un gran libro, pero si te has leído éste y algunos otros ves que lo que realmente te dicen es que debes descartar malas praxis. De hecho, y ya que a mi joven compañero de proyecto le gusta leer, le recomendaría leer más en detalle al estándar IEEE 830-1998. En ningún momento dice cuándo generar el SRS; muy al contrario, remite al estándar IEEE 1074-1997 que dice claramente ‘Select the SLCM that will best satisfy the project attributes and constraints’ (SLCM = Software Life Cycle Model)
¿Entonces? Entonces ocurre que más sabe el diablo por viejo que por diablo, y que el error radica en pensar que ser ágil es, necesariamente, ser ‘Agile’ aplicando técnicas ‘Agile’, cambiándole el nombre a las cosas o creando nuevos términos (‘theme’, ‘epic, ‘story’, condición de satisfacción, …). Ser ágil en la producción del software es ser lógico: no tener una parte del equipo jugando al solitario mientras espera a que otra parte haga un trabajo previo al suyo; no lanzar un producto con unos requerimientos desfasados (por la naturaleza dinámica del negocio) y sin abrir las puertas a los cambios; no dar la posibilidad de utilizar cuanto antes las características más importantes del producto para cumplir con los objetivos de negocio.
Por todo ello, llámame pureta, pero yo seguiré con mis requerimientos al vetusto estilo IEEE 830, simplemente aplicando modelos de ciclo de vida que no sean en cascada y refinando, como he hecho siempre, dichos requerimientos; al fin y al cabo, una chancla es una chancla, sea del pie que sea, y te vale para ir a la playa, pero no para correr por la montaña.
Nota: IEEE 830-1998 ha sido reemplazado por IEEE 29148:2011
Cuan cierto todo lo que dices en el artículo! Es más, a mi me da la sensación que lo único que hacen es ponerle nombres chorra a cosas que ya existen para luego poder vender cursillos y certificados a precio de caviar por aprenderte todos esos términos.
Si sabes llevar un proyecto no necesitas retorcer las cosas y puedes llamarle a las cosas por su nombre: por ejemplo «requerimientos». Porque es lo que se requiere del sistema, coñe!