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>
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
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.