Uf… ¿Te acuerdas de los requisitos? El requisito y sus “equipamientos extra”, requisitos no funcionales, especificaciones de requisitos, matriz de requisitos, trazabilidad de requisitos, completitud de requisitos, elevalunas eléctricos, cierre centralizado, etc.
Que tiempos. Bueno, como todo, pues las cosas evolucionan, cambian, se prueban nuevas ideas, unos nacen, otros se reproducen, otros mueren, etc.
He estado haciendo un poco de reflexión y te he dejado en este post la evolución del concepto requisito, o de su sustitución, ya que llamarle a las historias de usuario, o a las hipótesis, “requisito evolucionado” es retorcer mucho las cosas.
Y de entre las propuestas sucesoras, me he quedado con 3, las historias de usuario, las Feature Injection y las Hipótesis, vamos a ello…
El antiguo requisito y las antiguas especificaciones de Requisitos Software
Que antiguo suena. La idea más antigua y usada, el “requisito”, aquí, si uno se pone a recordar y le vienen a la cabeza cosas ya totalmente olvidadas como la “830-1998 — IEEE Recommended Practice for Software Requirements Specifications”, o esos pdfs de “Métrica v3”, que obsoleto se ve todo eso ahora.
Esta primera época era la del papel, la de escribir mucho, la de detallar mucho con la idea de que no hubiera que cambiar nada durante mucho tiempo, que se firmase con sangre los papeles (por si acaso) y de que una vez tomado el requisito se quedará ahí, en ese pdf, hasta que meses, años, después se convirtiera en software.
La historia de usuario
Las primeras ideas sobre lo que hoy se conoce como historia de usuario vienen de eXtreme Programming, de finales de los 90. Luego Ron Jeffries aportó aquello de que la historia de usuario era realmente tres Cs, Card, Conversation y Confirmation. Desde luego, frente a la idea anterior, la del requerimiento, aquí el papeleo prácticamente desaparece, a favor de la interacción, y el cambio “es bienvenido”
En lo que refiere a formatos… Aunque el formato ha tenido sus críticas (no entro aquí, que nos perdemos), el más popular y bastante usado, el típico de una historia de usuario es…
As A…. <role>
I Want… <goal/desire>
So That… <receive benefit>
Feautre Injection
Desde el mundo BDD, apareció hace unos años el concepto del Feature Injection. La terminología y los conceptos han ido evolucionando con los años, incluso en algunos momentos han sido confusos, pero aparte de introducir (bueno, evolucionar y popularizar) en acompañar una necesidad (historia) de ejemplos de su comportamiento (el by example), en lo que refiere a formatos… hace unos años se popularizó usar el siguiente:
In Order To… <receive benefit>
As A… <role>
I Want… <goal/desire>
Hypothesis
Y ahora llegamos a una siguiente evolución, la que viene del Hypothesis Driven Development, al cual le dediqué un post el lunes pasado, Hypothesis-Based Development, desarrollo basado en Hipótesis, que enfatiza que aquello que quiero hacer es… simplemente una hipótesis a validar que puede que no sirva para nada.
Sobre el formato, el más común, con adaptaciones es el siguiente…
Creemos que <hipótesis>
Y que esto obtendrá como resultado <lo que esperamos>
Y tendremos confirmación de ello cuando <métrica>
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Truco (con IA o sin ella) para espiar (legalmente) a tu competencia - 6 marzo, 2025
- Lo que NO te aconsejo hacer si quieres que SI se valore tu conocimiento - 27 febrero, 2025
- Como una PIZZA te puede dar una clase magistral de IA - 20 febrero, 2025
Hola Javier,
te sigo desde hace tiempo y te tengo un respeto enorme por tu experiencia, implicación y sentido de la innovación, aunque no por eso debo estar siempre de acuerdo contigo 😉
Hablas de los «viejos requisitos» como algo obsoleto, de otra generación. Sí que es cierto, y comparto contigo, que SCRUM o la agilidad y todo lo que conlleva es efectivo y válido en ciertos entornos, pero te puedo garantizar que los modelos tradicionales son efectivos en otros entornos. Aquellos muy críticos, en los que hay una aproximación más sistemista y en los que el SW juega un papel muy importante en términos de safety.
Donde yo trabajo utilizamos «el viejo requisito» a veces, y utilizamos «el nuevo requisito» p.e. historia también a veces. Y ambos conviven con sus pros y sus contras dignamente.
Puede ser que no sea la persona apropiada para opinar, ya que me cuesta atarme y admirar cualquier modelo de desarrollo porque los entiendo como herramientas que utilizas en quirofano dependiendo de la intervención.
Un cordial saludo y te animo a seguir como hasta ahora.
Juan
Hola Juan,
Gracias por pasar por aquí.
Si,puedo estar desacuerdo que en ciertos casos puedan ser necesarios, pero es que es algo que no se ha evolucionado, o si se ha hecho ha sido con poca repercusión, desde hace años…
Saludos!
Saludos Javier!
me guiado mucho por tus artículos,y por tus sugerencias, estoy desarrollando una investigación y quería saber si respecto a este tema existen antecedentes, alguna tesis, algún trabajo predecesor, algún articulo científico? e revisado bastante y e encontrado muy pocos.