Specification-Driven Development: un nuevo orden en el desarrollo de nuevo software con IA

 Specification-Driven Development: un nuevo orden en el desarrollo de nuevo software con IA

Dime de dónde vienes y te diré para dónde vas

En el pasado “soñábamos” con pasar de los diseños de software modelados en alguna herramienta de “cuarta generación” al código sin tener que escribirlo. Mis primeros intentos de generar software datan de 1987 cuando trabajé con mi profesor de algoritmos y luego de sistemas expertos Fabián Ríos y mi amigo Fabio Ruíz en un compilador para el lenguaje LEXICO (creado por Fabián) para el cual también hicimos algunos traductores a los lenguajes populares de la época: C, Pascal, C++ y BASIC, entre otros, y creamos un entorno de programación que permitía a los nuevos estudiantes de Ingeniería de Sistemas correr y probar sus programas escritos en  LEXICO.

Con Fabián y Fabio y otros amigos fundamos el entonces Equipo de Ambientes de Programación, dedicado a estos menesteres, en los que también hicimos nuestros primeros pinitos en inteligencia artificial con el lenguaje PROLOG y con Lisp. De hecho, Fabián escribió el primer intérprete de LEXICO en PROLOG y nosotros lo probamos, mucho antes de construir el compilador.

En los 90 pasamos por las herramientas generadoras de código a partir de diagramas, en los 2000 estos diagramas eran descritos usando lenguaje UML, incluyendo los casos de uso, una técnica de especificación de requisitos funcionales y no funcionales que usábamos con la metodología RUP. Fueron intentos incipientes. Normalmente teníamos que escribir el 99,9 % del código fuente, o todo.

Escribí miles de líneas de código en más de una docena de lenguajes de programación de todo tipo. Pero dejé de programar hace 2 décadas, aunque he seguido acompañando equipos de desarrollo de software, incluso de vez en cuando todavía me llaman para resolver algún problema de rendimiento en bases de datos relacionales.

Hoy las cosas han cambiado con la inteligencia artificial. Es evidente que la tarea principal del programador cambió. De hecho, ya hemos sido advertidos de que algunas herramientas de IA podrán reemplazar a los programadores puros y duros en muy poco tiempo. Por ejemplo, y a propósito de compiladores, en Anthropic acaban de construir un compilador C con Opus 4.6 usando equipos de agentes IA en solo dos semanas, algo que dice mucho sobre el futuro del desarrollo autónomo de software. Nuestros amigos de Anthropic dicen que hasta el 90 % de su código será escrito por sus nuevas herramientas en los próximos tres a seis meses. Es solo cuestión de “cuando” el resto de nosotros lo hará. Pero llegaré a esto un poco más tarde.

El caso de los requisitos de software, los casos de uso y las historias de usuario

Cuando de desarrollar software se trata, mi mayor interés siempre fue la comunicación. Primero entre personas y luego entre personas y las máquinas. Por eso este asunto de los requisitos en todos sus colores, tamaños y sabores siempre ha estado en la palestra de mis prácticas favoritas. Y durante las tres últimas décadas he estudiado el asunto a fondo, he realizado miles de experimentos, pero también he ayudado a implementar cientos de productos de software en algunas de las más grandes empresas de Colombia y algunas de Latinoamérica.

En los 90 con requisitos a la usanza tradicional, grandes documentos de texto en “lenguaje natural”. Hice lo mejor que pude. Pero desde finales de esa década y toda la siguiente usé casos de uso. Escribí, revisé, corregí y ayudé a escribir miles de casos de uso y también diseñé, planteé arquitecturas de software, programé y probé a partir de ellos. Escribí mucho sobre el tema en mi blog Gazafatonario. Finalmente, toda esta experiencia quedó consignada en mi libro Asuntos de la Ingeniería de Software, Volumen II, aunque todos los artículos originales siguen en mi blog.

Los casos de uso eran una buena práctica, aunque bastante exigente para todos los involucrados, incluyendo el mismo usuario. Así que entré en la era “ágil” y empecé a trabajar con historias de usuario. Fui a la fuente. Extreme Programming. Lo primero que supe fue que se plantearon originalmente de manera escueta, diciendo que “son como casos de uso”, en la primera edición del libro de Kent Beck. Me pareció natural y rápidamente adopté e implementé el concepto en los equipos que acompañaba.

También, casi todo esto quedó registrado en los libros que publicara con mi gran amigo Jorge Abad, Historias de usuario: una visión pragmática, Volumen I y Volumen II. Y también, casi todo el material de estos libros pueden leerlo en nuestros blogs. El de Jorge es Lecciones Aprendidas.

Distintas técnicas, mismo objetivo: lograr que todos los involucrados entiendan lo que quiere el usuario y conseguir que todos entiendan exactamente lo mismo. Siempre fue difícil. Aunque con el enfoque ágil abreviamos los tiempos de desarrollo y entrega, en el proceso la información transmitida igual se corrompía. Lo solucionábamos más rápido, pero el retrabajo siempre estaba a la orden del día.

No me malentiendan. Yo sí puedo decir que tanto aquellas técnicas como estas son muy buenas y funcionan, con los equipos donde participé pusimos en producción muchos sistemas de información que hoy se continúan usando. De hecho, incluso los casos de uso, ni hablar de las historias de usuario, hoy reciben un nuevo aire con esto de la Spec-Driven Development con IA, que es el asunto que nos convoca.

Entra la inteligencia artificial generativa

Sé que me extendí en la historia, pero para mí era muy importante contarles de dónde vengo, ahora sí, para decirles hacia dónde voy.

Así que me voy a saltar toda la perorata de los últimos tres años, la IA no viene a reemplazarte y todo ese blablablá ampliamente difundido, comentado y embutido hasta la saciedad en nuestras mentes, e iré directo al punto: allí estaba la herramienta con la que había soñado hace cuatro décadas para generar código, pero los primeros intentos no funcionaron. Por muy buenos que eran los “prompts”, no salía nada más allá de lo que yo mismo podía hacer con otras herramientas.

Y empecé a iterar, a refinar, a usar la IA como colaboradora de primera categoría. A descargar en ella todo lo que creía que era útil para que pudiera construir mejores productos, al menos, mejores MVP. Y entonces hace por allá un año escuché o leí de SDD y las cosas tomaron su curso natural, en el fondo, era lo que había estado haciendo en los dos últimos años, alimentar o instruir a la IA con especificaciones más precisas, no ambiguas… ¡Hey, esperen! Esto me recuerda algo:

·       Instrucciones legibles

·       Otra información relevante que posea alguna influencia sobre esas instrucciones

·       Identificación unívoca de cada instrucción

·       Instrucciones correctas

·       No ambiguas

·       Completas

·       Consistentes

·       Verificables

·       Modificables

·       Trazables

Es difícil lograr todo eso de una buena vez, alguna vez, pero hay que hacer el mejor trabajo posible. Recordé aquel modelo de la IEEE 830 de 1998, el estándar de requisitos según el prestigioso Instituto de Ingeniería Eléctrica y Electrónica, bajo el cual escribí y modelé requisitos con distintas técnicas y en diferentes formatos durante muchos años.

Pero también empecé a hablarle a la IA de usabilidad, de confiabilidad, de desempeño, de capacidad de soporte e, incluso, de restricciones de diseño y requisitos de implementación. Y entonces también recordé ese otro modelo FURPS+ que complementó aquel estándar. ¡Ah, y la arquitectura! Ya llegaremos a ese nivel.

De todo esto ya escribí y publiqué. Por eso era necesario contar toda aquella historia previa. Lo de ahora es “empaquetar” todo eso en una especificación estructurada, práctica y sistemática y entregársela a una IA para que genere el código que queremos, el producto que necesitamos. Eso es, más o menos, Specification-Driven Development o SDD y no me voy a desgastar nombrándola en español como hice antes muchas veces con incontables conceptos que nacieron en inglés.

“Hola, mundo” con SDD

Un ejemplo para terminar. Así empecé hace tres décadas escribiendo sobre requisitos y casos de uso, y hace década y media sobre historias de usuario. Vendrá mucho más sobre esto, pero los dejaré con un ejemplo breve. La gran diferencia ahora es que podemos tener el resultado de esa especificación en minutos, cuando no en segundos. Y podemos iterar, ajustar, repetir, y en medio de todo ello, verificar, en muy muy muy corto lapso de tiempo. Veamos el ejemplo.

Hoy por hoy, escribir un mensaje en WhatsApp o un correo electrónico se ha convertido en algo común, pero nunca estás seguro de si suenas demasiado agresivo, muy tímido o poco profesional. La solución: una caja de texto donde escribes o pegas tu mensaje y la IA te ofrece 3 versiones instantáneas: una "Directa y Ejecutiva", otra "Empática y Amigable" y una más "Mínima (estilo Gen-Z)". ¿Te gusta la idea? A mí sí. Es un “Sintonizador de Tono Comunicacional”. Les dije que este asunto de la comunicación entre personas está en mi ADN. Aquí vamos entonces.

Una Specification para IA incluye (o debe incluir) la visión de lo que quieres:

Una herramienta de productividad diseñada para eliminar la ansiedad en la comunicación digital. Permite a los usuarios transformar mensajes crudos o mal estructurados en versiones optimizadas según el contexto social, asegurando que el mensaje sea efectivo y el tono sea el adecuado.

Incluso puedes probar eso como un prompt directo a tu IA favorita. Las posibilidades son infinitas. Pero con eso no vas a obtener lo que quieres, al menos no de inmediato. Ni siquiera en las mejores herramientas IA que existen hoy para crear productos digitales.

Una Spec también incluye la Estructura de la Interfaz (UI). Vamos con una parte de esta:

A. Panel de Entrada

Área de Texto: Un `textarea` sin bordes pesados, con una tipografía Serif o Sans-serif elegante.

Contador de caracteres: Discreto en la esquina inferior.

Botón de Acción: "Sintonizar Mensaje" (Efecto de brillo suave al pasar el mouse).

 

B. Panel de Resultados

Un grid de 3 columnas (o 1 columna en móvil) que muestra tres variantes:

1. Variante: Directa & Ejecutiva

Color: Azul Cobalto (Focus en eficiencia y claridad).

Badge: "Profesional".

Como esta App usa IA necesitamos un “system prompt” mínimo viable. Es otra parte de la Spec. Les dejaré esta sección aquí completa:

3. Lógica de Inteligencia Artificial (Prompt de Sistema)

Para generar los resultados, la aplicación debe enviar este contexto al LLM:

> "Actúa como un experto en comunicación asertiva y psicología organizacional. Tu tarea es reescribir el mensaje del usuario en 3 versiones estrictamente diferenciadas.

> Reglas:

> 1. Directo & Ejecutivo: Elimina rellenos, ve al grano, usa lenguaje formal pero activo. Ideal para correos a superiores o clientes.

> 2. Empático & Amigable: Usa lenguaje cálido, validación de sentimientos y suaviza peticiones. Ideal para equipos cercanos o situaciones delicadas.

> 3. Minimalista: Reduce el mensaje a su esencia absoluta (máximo 15 palabras). Ideal para Slack, WhatsApp o equipos rápidos.

>

> Output: Devuelve un JSON con las llaves: `profesional`, `amistosa`, `minimalista`."

Sí, por supuesto puedes probar el prompt directamente en la IA de turno.

Pero la Spec también puede incluir requisitos técnicos e interacciones, como “Cada tarjeta de resultado debe tener un botón de ‘Copiar’”, ¿lo recuerdan? Precisión, cero ambigüedad, completitud, etcétera, etcétera; también pueden tener historias de usuario o hasta casos de uso, pero eso será motivo de próximos artículos; incluso puede tener y es bueno que tengan instrucciones para la IA que se va a usar. Y mucho más.

Todo esto lo almacenan en un documento Markdown (.md) y se lo pasan a la IA. Esta vez usé Lovable, es apenas el “Hola, mundo” de SDD. Les dejo el documento completo para su descarga.

[Enlace a la especificación]

El resultado, en modo oscuro y colores vibrantes, dos de los requisitos precisos, consistentes y verificables que encontrarán en la Spec completa:

Me cuentan cómo les va corriendo la Spec que les dejé. En el próximo artículo les hablaré más en detalle de la anatomía de una Spec y avanzaremos en esto.

Hace poco, mi también gran amigo Daniel Ramírez decía en un artículo que “La vibra no escala, la arquitectura sí” y preguntaba al final: “¿En qué punto una automatización deja de ser una PoC y se convierte en un sistema que requiere una arquitectura de verdad?” Bueno mi estimado Daniel, SDD es un paso, uno grande, en esa dirección.

Déjenme saber en el foro qué se les ocurre que hagamos con esto.

 

Lucho Salazar

Villa de Nuestra Señora de La Candelaria de Medellín, 5 de febrero de 2026

39 años después.

Video generado con Grok

El poder de la experimentación: una travesía a través de Scrum e historias de usuarios

 

Luego de muchos desafíos he observado una constante: la transformación ágil es una travesía de descubrimiento. Es un camino cargado de preguntas, dudas y esa ansiedad que genera la experimentación. He recorrido este camino con personas, equipos y organizaciones, y una de esas revelaciones es que Scrum, combinado con Historias de Usuario y Desarrollo Conducido por Hipótesis (HDD), puede ser la brújula que nos guíe a través de los paisajes corporativos actuales.

La esencia de la experimentación

Hecho: la experimentación no se trata de fracaso o éxito. Se trata de aprender, adaptarse y mejorar, en el sentido de crecer. Se trata de desafiar las suposiciones y aceptar una realidad en constante cambio. En el corazón de Scrum, el proceso iterativo de inspección y adaptación es en sí mismo un experimento. Es una búsqueda de la verdad, pero también de la belleza y la excelencia.

La experimentación es un arte, pero, sobre todo, una ciencia. Es una filosofía que ha estado en el centro de mi trabajo durante más de una década. Pero ¿qué significa exactamente y por qué resuena tan profundamente en el mundo Ágil?

El proceso de descubrimiento. En el ámbito de Scrum, la experimentación no es simplemente una herramienta o un método; es una forma de pensar que impregna cada acción, decisión e interacción. Permite a los equipos navegar por esos horizontes complejos y en constante cambio de los negocios modernos.

Para experimentar, ten la voluntad de explorar. La experimentación comienza con la curiosidad. Se trata de preguntar, "¿Y si…?" ¿Y por qué no…?" Se trata de tener el valor de adentrarse en lo desconocido, desafiar el statu quo y sondear posibilidades sin un destino predeterminado.

Para experimentar, no le temas a la incertidumbre. Uno de los aspectos más viscerales y emocionales de la experimentación es su incertidumbre inherente. Hay un miedo y una sensación de asombro al no saber qué sucederá a continuación. Es esta incertidumbre la que alimenta la creatividad, la innovación y el crecimiento. Es por ello por lo que causa tanto temor hablar en voz alta de experimentos en los entornos organizacionales de hoy. Sigue siendo un tabú. Antes, era una herejía.

Experimentando, aprendes a través del fracaso. No voy a usar palabras bonitas. Que falla, que negación, que infortunio. No.  En mis años como coach, he visto equipos tropezar, flaquear y frustrarse. Pero también los he visto crecer, aprender y transformarse. La experimentación reconoce que el fracaso no es un callejón sin salida sino una encrucijada, un punto de reflexión, una lección que se debe acoger, que se debe dejar entrar en nuestra cultura organizacional. Es en estos momentos de fracaso cuando a menudo se produce el aprendizaje más profundo.

Experimentando continuamente, cimientas resiliencia. Es de esta manera que las personas y los equipos se vuelven más adaptables, más receptivos y más alineados con la naturaleza dinámica de su trabajo. Es un proceso que fomenta una cultura de confianza, colaboración y empoderamiento.

Frecuentemente me preguntan cómo fomento, cómo cultivo la experimentación. Aquí les dejo algunas notas:

1. Colabora: involucra a todos. La diversidad de pensamiento es el caldo de cultivo de la innovación.
2. Acepta el fracaso: este es una oportunidad de aprendizaje. Celébralo, analízalo, crece a partir de él.
3. Haz preguntas: fomenta la curiosidad. Aviva una cultura en la que se celebre hacer preguntas.
4. Itera: los experimentos pequeños y frecuentes permiten un aprendizaje y una adaptación rápidos.
5. Reflexiona: Tómate el tiempo para reflexionar sobre los resultados. ¿Qué aprendiste? ¿Cómo lo aplicarás?
6. Crea espacios seguros: permite errores. Crea un entorno en el que el fracaso se vea como una oportunidad, no como una amenaza.
7. Celebra el aprendizaje: concéntrate en el viaje de aprendizaje, no solo en los resultados. Reconoce y recompensa el crecimiento y la comprensión.
8. Comparte ideas: la transparencia fomenta la colaboración. Comparte hallazgos, ideas y reflexiones abiertamente dentro del equipo y la organización.

La esencia de la experimentación es algo rico y complejo que ha moldeado mi trabajo y la vida de aquellos a los que he acompañado. Es más que una técnica o un proceso; es una forma de ser, un camino que conduce a una comprensión más profunda de nosotros mismos, nuestro trabajo y nuestro mundo. Es el latido del corazón Ágil, y es lo que hace que nuestro trabajo no sea solo un trabajo, sino una pasión, una aventura y una celebración del potencial humano.

Puedes leer algo más sobre esto en:

http://www.gazafatonarioit.com/2022/01/no-cometas-los-mismos-errores.html

O en mi libro Cultura Ágil: ese oscuro objeto del deseo.

La técnica de desarrollo conducido por hipótesis (HDD)

Esta técnica es el núcleo de la experimentación. Con HDD, planteamos preguntas, diseñamos experimentos, analizamos resultados y tomamos decisiones.

Por ejemplo, considera un equipo que lucha con su compromiso de sprint. La hipótesis podría ser: "Al reducir la cantidad de Historias de Usuario en un 25 % en el próximo Sprint, mejoraremos la tasa de finalización en un 20 %". ¿El resultado? A veces funciona, y a veces no. Pero siempre, aprendemos. Incluso ya sabemos que, si aplicas patrones como El Clima de Ayer o Los Equipos que terminan más temprano aceleran más rápido, vas a aumentar tus probabilidades de tener éxito. Entonces dejará de ser un experimento y se convertirá en una práctica común a tu alrededor. Para saber más de estos patrones, puedes consultar el libro Scrum: epítome de experiencias o en mis blogs en:

http://www.gazafatonarioit.com/

O en:

https://luchosalazar.com/category/agilidad/

La técnica HDD no es simplemente un método, sino un enfoque filosófico para el desarrollo de productos y la resolución de problemas. He aquí un breve vistazo a sus elementos centrales y cómo ha llegado a influir en la forma en que trabajo con equipos y organizaciones.

Un enfoque científico. El corazón de HDD radica en tratar cada nueva idea, característica o cambio como un experimento. Adopta un enfoque científico en el que se formula una hipótesis y luego se diseña un experimento estructurado para probar esa hipótesis.

La hipótesis. Una hipótesis es una declaración bien elaborada que expresa una suposición que se va a probar. Por ejemplo, "Implementar la función Pagar Contra Entrega mejorará la participación del usuario en un 20 %". La belleza de este enfoque es su claridad y enfoque, que establece una meta y una métrica precisas para el éxito o el fracaso.

Diseña el Experimento. Dibujar el experimento implica planificar cómo se probará la hipótesis. Esto incluye definir las métricas, el público objetivo, las condiciones y los criterios de evaluación. Es una etapa crítica donde entran en juego la precisión, la previsión y la colaboración.

Ejecuta el experimento y aprende. Una vez que el experimento está diseñado, es hora de ejecutarlo. Esta etapa puede estar llena de anticipación, conmoción y, a veces, desasosiego. Los resultados pueden confirmar la hipótesis, refutarla o revelar ideas inesperadas. Independientemente del resultado, la atención se centra en el aprendizaje y la adaptación. Si no aprendes nada del experimento, quizás no era un experimento del todo.

Itera y adáptate. HDD no es un evento único sino un ciclo continuo. Cada experimento conduce a nuevos conocimientos, nuevas preguntas y nuevas hipótesis. Es un proceso dinámico y en evolución que se alinea perfectamente con la naturaleza iterativa y adaptativa de Ágil y Scrum.

Ahora bien, ¿por qué debería importarte HDD? Esta técnica ha sido transformadora en mi práctica. Aporta disciplina, claridad y un enfoque implacable en el aprendizaje. Alienta a las personas a pensar de manera crítica y sistémica, desafiar los supuestos y aceptar la naturaleza cambiante de su trabajo.

Historias de usuarios y la conexión humana

¡El poder de las historias de usuario!

Las historias de usuarios dan vida a nuestro trabajo. Son la voz de nuestros usuarios, el latido de nuestro producto. Pero también pueden ser un campo de juego para la experimentación. Recuerdo a un equipo que una vez tuvo el desafío de comprender las necesidades de sus clientes. Decidimos experimentar involucrando a los clientes directamente en la creación de Historias de Usuario. El compromiso, la empatía, los conocimientos que obtuvimos fueron transformadores. El producto prosperó, al igual que el equipo. De hecho, usamos Historias de Usuario Conducidas por Hipótesis para que cada nueva característica del producto, y el producto mismo, fueran considerados una hipótesis, un experimento en sí. Es de esta manera que empiezas a promover, aún sin mencionarlo, una cultura de experimentación en tu ámbito empresarial.

La belleza de las historias de usuario radica en su sencillez y humanidad. Sirven como puente entre los requisitos técnicos y las necesidades humanas reales, creando una conexión que impulsa el desarrollo significativo de productos.

El elemento humano. Las historias de usuario ponen al usuario en el foco del proceso de desarrollo de productos. No se trata de código, algoritmos o bases de datos; se trata de personas, emociones, experiencias. Infunden empatía en el desarrollo del producto, convirtiéndolo en un esfuerzo colaborativo y compasivo. Son una parte viva y palpitante del desarrollo ágil. Les ponen cara a las funciones, voz al código y corazón al producto. Al utilizar Historias de Usuario como base para los experimentos, no solo humanizamos el proceso, sino que también aportamos claridad, enfoque y empatía a nuestra búsqueda de innovación y excelencia.

En mi trabajo con diversos equipos y empresas, estas historias simples pero profundas a menudo han sido el catalizador de la creatividad, la colaboración y la conexión. Nos recuerdan que, en el centro de toda nuestra tecnología, procesos y métodos, siempre hay una persona, con necesidades, deseos y sueños. Conectar con ese elemento humano es lo que hace que nuestro trabajo no solo sea efectivo sino también significativo y satisfactorio.

No quiero extenderme más en este sentido. En mi blog puedes encontrar docenas de publicaciones sobre ello, incluyendo presentaciones, artículos y, por supuesto, el libro de la portada negra y naranja.

Pensamientos finales

Mi periplo ha sido uno de continua experimentación. Con cada fracaso, éxito y sorpresa, he aprendido, evolucionado y prosperado. Al menos, lo he intentado. Es una experiencia profundamente personal, llena de pasión, temor, alegría y resiliencia. Lo que he compartido no es solo un método o una técnica, sino una forma de vivir y trabajar. Se trata de ser humano y humanizante en un mundo de complejidad. Se trata de coraje, curiosidad y compasión. Y, sobre todo, se trata de la voluntad de experimentar, cuestionar y crecer.

Aquí tienes el próximo experimento y el siguiente paso en tu propio viaje. Auguro que será tan emocionante, esclarecedor y gratificante como todo lo anterior.

El poder de las historias de usuario: sembrando narrativas para cosechar productos disruptivos

 

Esta es algo así como la transcripción de mi charla relámpago en Ágiles Colombia 2023 en Barranquilla. Y al final, está la charla para su descarga.

El poder de las historias de usuario:
sembrando narrativas para cosechar productos disruptivos

Las historias de usuario son un instrumento muy muy poderoso. Escuchen esto, queremos hacer las cosas “the Agile way”, y muchas veces nos preguntamos “¿eso cómo se hace?” “¿Eso con qué se come?”. Pues bien, las historias de usuario son ese utensilio que necesitamos para ello.

Veamos cómo en esta sesión relámpago…

Ninguna charla, mucho menos relámpago, sobre historias de usuario estaría completa si no comenzamos por aquí.

“Con historias y contando historias es como las culturas se hacen más fuertes y sobreviven”.

Con historias es como hemos llegado a este momento del tiempo, algunos científicos ya dicen que estamos en la era del Antropoceno, la nuestra. Imagen así el poder que tienen las historias si son ellas las que nos han permitido evolucionar durante los últimos 2 millones de años.

¡Y las historias de usuario son eso: historias!

Las historias de usuario son un protocolo de comunicación social, y la comunicación es condición requerida, indispensable, sine qua non dicen los intelectuales, para que haya verdadero trabajo colaborativo que, a su vez, es esencial para que la hagamos las cosas de la manera ágil.

Así es que lo más, con énfasis en “más”, importante de las historias de usuario son las conversaciones que se gestan alrededor de ellas. En su entorno.

Son conversaciones que se dan entre las personas involucradas, pero sobre todo comprometidas con el desarrollo de productos o la ejecución de actividades con enfoque Ágil y Lean.

Vamos a ver más en detalle esto porque es el mensaje principal de esta sesión.

Miren. Muchos todavía ven las historias de usuario, en el mejor de los casos, en este ámbito. Alguien tipo Product Manager/Product Owner “escribe” las historias de usuario y se las entrega a un equipo. En ocasiones hay una charla breve, muchas veces más relámpago que esta y ¡zas, ya está! Ahí les dejo sus historias.

Pero no, así no es. Es más bien de esta otra forma.

Esas conversaciones poderosas se dan, de un lado, entre esta persona tipo PM/PO y su entorno, incluyendo no solo a los usuarios o clientes finales, sino también a los interesados y más allá, gente del Mercado, de la Competencia, del Gobierno, de la Sociedad y del Medio Ambiente. Importantísimo estos dos últimos, volveremos a ello sobre el final de la charla.

Y de otro lado, entre esta PM/PO y el equipo de desarrollo de productos. Conversaciones abiertas, francas, en confianza, con transparencia.

Este es el ámbito donde las historias de usuario tienen mucho poder.

Pero eso no es todo… Las historias de usuario son poderosas si su práctica y el comportamiento que exhibimos quienes las usamos tiene como soporte la esencia de la agilidad. HU para colaborar, ya lo dijimos, pero también, HU para entregar en pequeño y frecuentemente, y una vez entregadas, para reflexionar con datos, no con supuestos. Y en el proceso, siempre siempre, mejora implacable.

Esto es absolutamente necesario, si no, son cualquier otra cosa menos historias de usuario a la usanza ágil.

Así que es definitivo. Si por lo menos ya las estamos usando, cambiemos nuestra forma de pensar acerca de las HU. Vamos de un mindset “especificacional” a uno conversacional. Las HU no son para escribir documentos repletos con características del producto. Para nada.

Dicho esto, empecemos también a pensar en las HU como experimentos. Como hipótesis que son realmente. Una HU siempre será una hipótesis hasta tanto el producto o el incremento de producto del que hace parte no está en manos del usuario final, del consumidor.

Así que empecemos a tratarlas como tal desde el principio.

Esto además ayuda a cambiar el mindset que necesitamos para tener éxito con ellas.

Y miren esto: ese apellido “de usuario” no está allí gratuitamente, por su linda cara como decimos. Las HU, o la práctica de estas, deben permitirnos conocer al usuario más que cualquier otra persona en nuestro entorno. ¿Quién es el usuario? ¿Qué hace?

¿Con quién lo hace? ¿Qué información intercambia? ¿Como lo hace? ¿Cuáles son sus dolencias y quejas? ¿Qué lo hará exitoso?

Responder a todas estas cuestiones solo se logra si el enfoque que usamos con HU está centrado en el usuario final y nadie más. En la persona.

De la misma manera, las historias de usuario deben permitirnos conocer más el producto, sus características esenciales, las que hacen feliz al consumidor, las importantes, las que lo dejan satisfecho, y las buenas bonitas, pero no baratas, las que lo dejan presuntuoso, más que cualquier otra persona a nuestro alrededor.

Ahora bien, Las HU poderosas, las que nos permiten crear productos disruptivos que nuestros clientes amen y que causen en ellos impactos a tal grado de modificar su modus vivendi, son pequeñas y aun así proporcionan valor a esos usuarios.

Pequeña es un término relativo, pero en general significa que se pueda construir en una iteración corta junto a otras HU.

También, las HU poderosas tienen unos criterios de aceptación bien definidos: tamaños, colores, matices, sabores, ángulos, vistas. Gozan de precisión, son colaborativos también. Quizás en una sesión hoy hablemos de mi modelo de las 7 C de los criterios de aceptación.

Y en el fondo, las HU poderosas se enfocan en el objetivo del usuario final. Son pequeños peldaños hacia el logro de una meta aún mayor: el objetivo del producto.

Aquí tenemos un ejemplo de una HU que no está basada en el objetivo, sino en la solución, un botón para exportar datos a un plano, ni más faltaba, se le tiene, pero esto no es del contexto de las HU, es algo de la solución.

En cambio, en este otro ejemplo, vemos con claridad una HU enfocada en el objetivo de un usuario final: elegir un método de envío, sin ninguna preferencia en particular ni ningún detalle que restrinja la solución final. Esta será un asunto del equipo de desarrollo del producto.

Y no podemos cerrar tampoco sin hablar de priorización por valor. Las HU poderosas se priorizan por algún aspecto de valor.

Técnicas como MoSCoW, WSJF, modelo de Kano, El costo de la demora y la Matriz de Impacto Motivado, conocida también como el modelo de Lucho.

Entre otras que se pueden usar para ordenar y reordenar un backlog constantemente.

¿Y todo esto para qué? Para hacer que germinen productos asombrosos. Aquí les dejamos un modelo simple pero efectivo para ello.

Ojo al paso 5: No es posible que construyamos productos asombrosos, que impacten a nuestros clientes, es una sociedad y en un planeta enfermos. Perentorio. Así que siempre pensemos en estos 2 factores además del financiero que es absolutamente necesario.

Esto era todo, mis amigos. Aquí 5 ideas claves de esta sesión relampagueante:

1.    Mindset conversacional para las HU,

2.    Colabora,

3.    Enfoque centrado en el usuario,

4.    Priorización eficaz con diferentes métodos, y

5.    desarrollo iterativo e incremental. ¡Lo nuestro!

Muchas gracias. Les dejo información de donde pueden conseguir muchísima más información, por si apenas llegan a nuestra sintonía. En bit.ly/lashistoriasdelucho y, por supuesto, el libro que se originó en esa página precisamente.

Puedes descargar la presentación aquí: 👇

[Learning Lab] El poder de las historias de usuario: cómo crear productos que agreguen valor

Esta es la presentación “El poder de las historias de usuario: cómo crear productos que agreguen valor” que hice para el Learning Lab con Certiprof el 19 de abril de 2023.

Algunos aspectos de la presentación:

Las historias de usuario son una herramienta poderosa en el desarrollo ágil de productos porque ayudan a los equipos a centrarse en las necesidades y los deseos de los usuarios finales. Al crear historias de usuario, los equipos pueden identificar cómo su producto agregará valor a la vida de los clientes y asegurarse de que están construyendo algo útil y relevante.

El poder de las historias de usuario radica, entre otros, en los siguientes aspectos:

1. Centrarse en el cliente: las historias de usuario ponen al cliente en el centro del proceso de desarrollo del producto, asegurando que sus necesidades y preferencias impulsen las características y mejoras del producto.

2. Simplicidad: las historias de usuario son concisas y directas, lo que ayuda a los equipos a comunicarse de manera efectiva sobre los requisitos y objetivos del producto.

3. Colaboración: las historias de usuario fomentan la colaboración entre los miembros del equipo, fomentando una comprensión compartida del propósito y la visión del producto.

4. Adaptabilidad: las historias de los usuarios se pueden ordenar fácilmente, lo que permite a los equipos responder a las condiciones cambiantes del mercado o a los comentarios de los clientes.

Ahora bien, para crear productos que agreguen valor en todas las industrias, considera los siguientes pasos:

1. Identifica a tus usuarios objetivo: ¿Quiénes son las personas que se beneficiarán más de tu producto? Entiende sus necesidades y deseos.

2. Crea historias de usuario: haz narraciones concisas y centradas en el cliente que describan cómo tu producto abordará las necesidades y los deseos de los usuarios objetivo.

3. Ordena las historias de usuario: clasifica las historias de usuario en función de su impacto potencial, viabilidad y alineación con los objetivos estratégicos de tu empresa.

4. Itera y valida: prueba continuamente tu producto con usuarios reales para recopilar retroalimentación y refinar tus historias de usuario. Adapta su plan de desarrollo del producto según sea necesario para asegurarte de que estás entregando valor.

5. Considera los beneficios sociales y ambientales: Esfuérzate por crear productos que no solo generen ganancias financieras, sino que también contribuyan positivamente a la sociedad y el medio ambiente. Esto puede incluir la reducción de residuos, el apoyo a las comunidades locales o la promoción de la sostenibilidad.

Puedes descargar la presentación aquí:

Las 5 disfunciones de un equipo Scrum durante la Sprint Planning

En su libro The Five Dysfunctions of a Team: A Leadership Fable, Patrick Lencioni enfatiza que es difícil “responsabilizar a algunas personas porque son muy útiles. A otras porque se ponen a la defensiva. A otras porque son intimidantes”. Y remata diciendo que no cree que sea fácil responsabilizar a nadie, ni siquiera a nuestros propios hijos.

La planificación es acerca de responsabilizarse. Cuando lo hacemos a la usanza ágil, esa responsabilidad es compartida. Y nuestro modo de pensar insiste en que cuando la responsabilidad es compartida, en efecto, todo el equipo es responsable. Dado el carácter cíclico que tiene la planificación en Scrum, es común que los equipos empiecen a manifestar ciertos trastornos, sobre todo cuando están en etapas tempranas de su desarrollo como equipos.

En la práctica son muchas más de cinco, pero he seleccionado estas cuyas secuelas pueden echar al traste cualquier esfuerzo de desarrollo de productos. Estas son las 5 disfunciones de los equipos Scrum durante la Sprint Planning y cómo superarlas.

1.   No hay un objetivo de sprint claro o no lo hay del todo

Un objetivo de sprint claro es esencial para un sprint exitoso. Proporciona dirección y enfoque para el equipo y les ayuda a ordenar el trabajo. Sin un objetivo de sprint claro, el equipo puede trabajar en tareas que no están alineadas con los objetivos generales de la iniciativa. Para superar esta disfunción, el Product Owner debe trabajar con el equipo para definir un objetivo de sprint claro antes del inicio de cada sprint.

Como Scrum Máster, asegúrate de que todos los miembros del equipo conozcan el objetivo del sprint propuesto antes del inicio de la Sprint Planning. Esto les ayudará a comprender en qué deben concentrarse durante la sesión de planificación.

2.   No están todos los que son ni son todos los que están

La Sprint Planning es un evento colaborativo que requiere la participación de todo el equipo. Si faltan algunos miembros del equipo, puede ser difícil planificar con precisión el sprint y asegurarse de que todos estén en la misma página. Si hay personas que no son del equipo se puede perder el foco con facilidad debido a la falta de conocimiento de estas personas sobre lo que el equipo viene haciendo y hacía dónde va. Para superar esta disfunción, es importante programar la Sprint Planning en un momento en el que todos puedan asistir y asegurarse de que todos entiendan la importancia de asistir. No debe haber interrupciones redundantes durante la sesión.

3.   Muy poco tiempo para el evento o el tiempo es excesivo

La Sprint Planning debe tener suficiente tiempo para permitir una discusión exhaustiva y una planificación apropiada. Sin embargo, también es importante no dedicar demasiado tiempo al evento, ya que esto puede llevar al síndrome de la parálisis por análisis y retrasar el inicio del sprint innecesariamente. Para superar esta disfunción, es importante encontrar un equilibrio entre una planificación conveniente y un uso eficiente del tiempo.

4.   No hay historias de usuario refinadas

Las historias de usuario son la columna vertebral de cualquier sprint. Proporcionan al equipo una comprensión clara de lo que debe lograrse durante el sprint. Sin historias de usuario refinadas, el equipo puede tener dificultades para comprender lo que debe hacer y puede perder tiempo en tareas que no son necesarias. Para superar esta disfunción, el Product Owner debe colaborar con el equipo para refinar las historias de usuario antes del inicio de cada sprint.

5.   No se elabora un sprint backlog apropiado

El sprint backlog es una lista de tareas que deben completarse durante el sprint. Es esencial para hacer conocer el progreso del trabajo y garantizar que todo se haga. Sin un sprint backlog adecuado, puede ser difícil para el equipo saber qué deben hacer y cuándo deben hacerlo. Para superar esta disfunción, es importante que el equipo trabaje en conjunto durante la sesión para crear una Sprint Backlog para los primeros días del sprint y una hoja de ruta que permita al equipo el logro del objetivo del sprint.

Clic en la imagen para ampliar

Ahora bien, ¿cómo puedo mejorar la Sprint Planning de mi equipo?

En el libro Scrum: epítome de experiencias detallamos varias formas de mejorar la Sprint Planning de tu equipo. Aquí hay algunas otras:

• Asegúrate de que todos estén preparados, de que todos tengan la información y los materiales necesarios antes del inicio del evento. Esto incluye un objetivo de sprint claro, historias de usuario refinadas y cualquier otra información relevante.

• Fomenta la participación: la Sprint Planning es un evento colaborativo y todos deben participar activamente. Anima a todos a compartir sus ideas y opiniones y asegúrate de que se escuche la voz de todos.

• Mantén el foco en el objetivo del sprint, este debe ser la fuerza guía detrás de la Sprint Planning. Asegúrate de que todas las discusiones y decisiones estén alineadas con el objetivo del sprint.

• Usa el tiempo de manera efectiva durante la reunión. Evita que el equipo se atasque en largas discusiones y motiva la toma de decisiones de manera rápida y eficiente.

• Revisa y mejora: después de cada Sprint Planning, tómate un tiempo para revisar qué funcionó bien y qué podría mejorarse. Utiliza el feedback para realizar cambios y mejoras para futuras sesiones de planificación.

Y una recomendación adicional, parte de mi mantra: da un paso a la vez. Recuerda que “el trabajo en equipo comienza generando confianza. Y la única forma de hacerlo es superando nuestra necesidad de invulnerabilidad”.