El otro día, después de muchos años, coincidí con un viejo amigo, un camarada más del mundo del desarrollo software. Estaba con él y con su equipo, hablamos de Agilidad, hablamos de Historias de Usuario, alguien sacó en la conversación a los viejos casos de uso y hablamos de algo que todos aquellos tenían en común para entender todas esas aproximaciones: el actor.
El actor, ese ese viejo elemento que se usó desde siempre para diferenciar «la funcionalidad que había que hacer» de aquello externo al sistema y que interactúa, bien lanzando la funcionalidad, bien recibiendo información, con esa funcionalidad que pretendemos desarrollar, incorporar el incremento del producto.
La idea del actor, viejo como el solo, que vendría a ser, siendo muy genéricos, el «Cómo usuario quiero…» de las Historias de Usuario, o aquello que pintábamos como un monigote, con un circulo por cabeza y cuatro palos como cuerpo, cuando dibujábamos Casos de Uso en UML.
Por otro lado, días después, Pablo escribió un post muy chulo en Medium, contando como años después de haber leído en retro-vintage «Mítico Hombre Mes», de Brooks, del 75, había madurado la idea de comenzar a crear software partiendo de un «storytelling».
Cuando leí su post, me vino a la cabeza la técnica, más moderna, más «User Story» de los mapas de historias de usuario. Que, con otro formato, busca los mismo, que una historia contada a un futuro usuario, sobre la funcionalidad de lo que queremos desarrollar, sea la que arranque todo.
De nuevo, dos historias, contando algo «moderno» cuya base es muy muy muy viejuna.
Aparte de la reflexión de si ya estaba todo inventado y si desde hace años sólo hacemos «remasterizaciones» yo tengo un pensamiento más.
En ambos casos, y en otros tantos similares que podría citar, los veteranos del lugar hemos coincidido en lo siguiente: muchos de los que llevan menos tiempo en esto, y también muchos de los que llevan años, no terminan de entender los conceptos e ideas clave. La base.
Esa base que comparten, sin ser iguales, por supuesto, técnicas como los Casos de Uso y las Historias de Usuario. O que comparten los mapas de historias de usuario y la idea de «manual» de Brooks.
Y creo que el problema está ahí, en que hemos olvidado leernos las bases. Los clásicos. Esos que no están de moda. Esos muchos que se escribieron antes de que yo naciera y, otros tantos, que se escribieron mucho antes de que yo supera qué era una línea de código.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Estoy totalmente de acuerdo con este contigo. El aprenden e implementar metodologías que están siendo tendencia porque agilizan los desarrollos no implica que se olvide de donde comenzamos a formamos. Todo lo aprendido con los años y lo que otros nos regalan con la oportunidad de leer su experiencias sirve para ser mas eficiente.
La primera vez que estuve en una reunión de historias de usuario pegando postit en la pared, efectivamente lo primero que me vino a la cabeza fueron los casos de uso. Sí, todo estaba escrito ya.
Muy de acuerdo. Y creo que alguien más está de acuerdo con respecto a otros aspectos de la informática:
http://blog.cleancoder.com/uncle-bob/2012/12/19/Three-Paradigms.html
Y no es un cualquiera…
Muy de acuerdo, y parece que Robert C. Martin también estaba de acuerdo en esto, con respecto a otro aspecto relacionado, los lenguajes de programación:
http://blog.cleancoder.com/uncle-bob/2012/12/19/Three-Paradigms.html
Pues si te vas al mundo JS, ya flipas con las reinvenciones que encima venden como si fuera la cura del cáncer
Hola Javier,
Tienes toda la razón, hay que entender las bases ya que nos ayudan a tener una mejor visión.
Algún listado que tengas en un post de esos «clásicos» que son de lectura obligada?