Mostrando las entradas con la etiqueta Product Owner. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Product Owner. Mostrar todas las entradas
martes, mayo 27, 2025
domingo, marzo 16, 2025
La necesidad del pensamiento Lean en la era de la GenAI: un enfoque hacia las historias de usuario
Hola a todos,
La inteligencia artificial generativa (GenAI) ha transformado significativamente el proceso de generación e identificación de historias de usuario (HU). Antes, construir una historia de usuario requería sesiones de descubrimiento, múltiples interacciones con los interesados y refinamiento iterativo con el equipo de desarrollo. Aunque estas sesiones siguen siendo esenciales para garantizar una alineación con las necesidades reales del usuario, la GenAI ha simplificado y acelerado el proceso al capturar múltiples puntos de vista clave, sintetizarlos y generar rápidamente una lista estructurada de épicas, características esenciales del producto e historias de usuario relevantes. Con un prompt bien diseñado, también puede proporcionar criterios de aceptación detallados e incluso generar el código base necesario para su implementación (1).
Automatización y eficiencia en la construcción de historias de usuario
Gracias a la GenAI, no solo podemos generar historias de usuario más rápido, sino que también podemos obtener el código que resuelve la funcionalidad requerida casi de inmediato. Esto significa que la velocidad de desarrollo ha aumentado drásticamente, pero al mismo tiempo, han surgido nuevos riesgos y desafíos que pueden comprometer la efectividad del producto final (2).
Sin embargo, la velocidad no es sinónimo de precisión., de nada sirve ir a 200 km/h en la dirección incorrecta, es preferible dirección y precisión sobre velocidad. La GenAI, aunque útil para agilizar procesos, no reemplaza la interacción humana ni la validación con usuarios reales. Es fácil caer en la trampa de creer que, porque la IA genera respuestas convincentes y completamente acertadas, recordemos que los modelos de GenAI tiene una precisión cercana (a hoy del 99%) (5). Pero la realidad es otra: un producto verdaderamente exitoso no solo debe ser funcional, sino que debe resonar con sus usuarios, ser intuitivo y sentirse como una extensión natural de su flujo de trabajo (3).
En Apple, el diseño se basa en una premisa clara: eliminar todo lo que no sea esencial. Un producto verdaderamente excepcional no es aquel que tiene más características, sino aquel que resuelve necesidades de la manera más elegante y precisa posible (4).
El peligro de la sobreconstrucción y la desconexión con el usuario
Uno de los mayores riesgos que enfrentamos en esta nueva era de automatización e inteligencia es la tendencia a construir más de lo que realmente se necesita. La facilidad con la que la GenAI genera código y funcionalidades puede llevarnos a desarrollar características que no son esenciales, simplemente porque es fácil hacerlo. Sin una adecuada priorización basada en las necesidades reales del usuario, podemos terminar creando productos saturados de opciones innecesarias, en lugar de soluciones minimalistas y funcionales que realmente resuelvan sus problemas (1).
Otro peligro latente es la falta de comunicación con el usuario. La GenAI puede simular el comportamiento de un usuario a través de perfiles de "Personas" creados mediante técnicas de Design Thinking (3). Un prompt como:
Contexto: Vamos a generar una app para los guardabosques, y vas a responder como si fueras un guardabosques de más de 10 años de experiencia. A continuación, te haré preguntas que me guiarán en el diseño de un producto que mejorará tu forma de gestionar el bosque que estás cuidando.
"Vamos a generar una app para guardabosques, y vas a responder como si fueras un guardabosques de más de 10 años de experiencia. A continuación, te haré preguntas que me guiarán en el diseño de producto que mejorará tu forma de gestionar el bosque que estás cuidando."
puede ayudar a capturar información valiosa, sin dudarlo. Sin embargo, aunque esto sirve, es indudable que tiene limitaciones. Nada sustituye las entrevistas reales, la observación en el campo y la empatía directa con quienes usarán el producto. Un diseño exitoso no es aquel que solo responde a suposiciones bien estructuradas, sino aquel que emerge de la interacción genuina con los usuarios reales (4).
La importancia del diseño centrado en el usuario y la medición del impacto
El éxito en esta nueva era dependerá de quién logre conectarse verdaderamente con los usuarios y utilice el potencial de la GenAI para construir productos alineados con sus expectativas reales (2). Empresas como Apple han demostrado que la simplicidad y la precisión en el diseño generan una experiencia de usuario superior (3). Los consumidores buscan productos que resuelvan sus necesidades de manera intuitiva, sin saturación ni funcionalidades innecesarias. En este sentido, herramientas como A/B Testing y el análisis de métricas de uso se vuelven indispensables para validar continuamente la utilidad de las funcionalidades implementadas (1).
Las empresas que no adopten este enfoque y se dediquen a saturar a los usuarios con opciones irrelevantes verán cómo el mercado elige la perfección sobre la sobrecarga. Sin una estrategia de medición y ajuste basada en el comportamiento real de los usuarios, muchas organizaciones podrían quedar desconcertadas al ver que sus productos no son elegidos, sin entender que la razón fundamental fue la falta de alineación con las necesidades del cliente (4).
¿Es esta historia de usuario necesaria o es desperdicio?
Para evitar la sobrecarga de funcionalidades innecesarias, los Product Owners y los equipos ágiles deben evaluar rigurosamente cada historia de usuario antes de desarrollarla. A continuación, algunas preguntas clave que pueden ayudar en esta validación:
-
¿Cuál es el problema real que esta historia resuelve?
- Si no puedes identificar claramente un problema que impacte negativamente al usuario, es posible que esta historia sea innecesaria.
-
¿Esta funcionalidad alinea con los objetivos del producto?
- Una historia de usuario debe contribuir a la visión del producto. Si no lo hace, podría ser un desperdicio de recursos.
-
¿Esta historia de usuario tiene métricas de éxito definidas?
- Si no hay una manera clara de medir su impacto, ¿cómo sabremos si fue útil?
-
¿Qué impacto tendría si no se desarrolla esta historia?
- Si el producto aún funciona perfectamente sin ella, probablemente no es prioritaria.
-
¿La funcionalidad generará fricción en la experiencia del usuario?
- Más opciones no siempre son mejores. A veces, menos es más.
-
¿Cuántos usuarios realmente la necesitan?
- Si la funcionalidad es relevante solo para un nicho muy reducido, podría ser mejor posponerla o encontrar una alternativa más general.
-
¿Es una funcionalidad que puede validarse con un experimento rápido?
- Antes de construirla completamente, ¿podemos hacer un test de baja fidelidad para ver si realmente se usa?
Un producto bien diseñado es aquel que parece haber leído la mente del usuario, eliminando lo innecesario y dejando solo lo esencial. Si cada historia de usuario se filtra a través de estas preguntas, el backlog estará compuesto solo por elementos que realmente aportan valor.
El rol del Product Owner en la era de la GenAI
A pesar de la automatización que permite la GenAI, el papel del Product Owner (PO) sigue siendo crucial. No basta con generar funcionalidades rápidamente; es necesario identificar qué sí y qué no hacer, qué agrega y qué no agrega valor (2). El PO es quien tiene la responsabilidad de ordenar y priorizar el backlog, asegurando que el producto final no solo cumpla con las necesidades funcionales, sino que logre la perfección oculta en el imaginario del usuario (3).
Cuando un usuario interactúa con un producto bien diseñado, experimenta una sensación de esbeltez y perfección. No se trata solo de que el producto funcione, sino de que se sienta preciso, exacto, como si hubiera sido diseñado específicamente para ellos (1). Esa sensación no se logra con cantidad, sino con calidad, atención al detalle (4) y a la eliminación de cualquier forma de desperdicio.
Cerrando
La GenAI es una herramienta poderosa que, bien utilizada, puede revolucionar la manera en que diseñamos y desarrollamos productos. Sin embargo, su éxito dependerá de nuestra capacidad para combinar la automatización con un enfoque genuinamente centrado en el usuario, evitando la trampa de construir más por el simple hecho de que podemos hacerlo. Aquellos que comprendan esto y logren equilibrar la velocidad con la precisión y la esbeltez serán quienes dominen esta nueva era digital+ai.
Saludos ágiles,
Jorge Abad
Notas, aclaraciones, referencias y comentarios
- Ries, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.
- Norman, Donald A. The Design of Everyday Things. Basic Books, 2013.
- Brown, Tim. Change by Design: How Design Thinking Creates New Alternatives for Business and Society. Harper Business, 2009.
- Blank, Steve. The Four Steps to the Epiphany: Successful Strategies for Startups That Win. K&S Ranch, 2013.
- Hughes Hallucination Evaluation Model (HHEM) leaderboard - https://huggingface.co/spaces/vectara/leaderboard
martes, marzo 04, 2025
Las Historias de Usuario en la Era de la GenAI
Hola a todos,
Las historias de usuario han sido el pilar de la gestión ágil de requisitos desde que fueron propuestas y popularizadas en Extreme Programming (XP) a finales de los noventas y usadas ampliamente con Scrum en las últimas dos décadas. Su sencillez y orientación al usuario las convirtieron en una herramienta fundamental para capturar necesidades y garantizar el alineamiento entre negocio y tecnología.
Sin embargo, la aparición de la inteligencia artificial generativa (GenAI) ha introducido nuevas dinámicas en la forma en que los equipos crean, refinan y priorizan estas historias. ¿Puede la IA escribir historias de usuario de manera efectiva? ¿Qué tan confiables son las historias generadas automáticamente? Y, lo más importante, ¿cómo cambia el papel del Product Owner (PO) en esta nueva realidad?
Este artículo explora cómo la GenAI está transformando la gestión de historias de usuario y qué desafíos y oportunidades representa para los equipos ágiles.
La esencia de las historias de usuario
A pesar de no tener un formato preestablecido(Abad, 2024), las historias de usuario siguen una estructura simple y poderosa:
Como [rol], quiero [acción], para que [beneficio].
Este formato fomenta la empatía con el usuario final y permite que los equipos se enfoquen en la entrega de valor. Sin embargo, escribir buenas historias de usuario que guíen el trabajo del equipo de desarrollo sigue siendo un desafío, ya que requiere claridad, alineación con los objetivos de negocio y criterios de aceptación bien definidos.
Las mejores prácticas en la redacción de historias de usuario incluyen:
- Mantenerlas independientes y negociables (INVEST) (Cohn, 2004).
- Garantizar las tres C: Card, Conversation, Confirmation (Jeffries, 2001).
- Incluir criterios de aceptación claros.(Abad, 2025)
- Enfocarse en el valor para el usuario, no en soluciones técnicas.
El impacto de la GenAI en las historias de usuario
Generación automática de historias de usuario
Las herramientas de IA generativa han revolucionado la manera en que se redactan historias de usuario en proyectos de desarrollo de software y productos digitales. Modelos avanzados como ChatGPT, GEMINI, Grok, Llama y Copilot tienen la capacidad de procesar grandes volúmenes de información, estructurar requisitos ambiguos y generar historias de usuario de manera rápida y precisa. Esto resulta particularmente útil en entornos ágiles, donde la velocidad y la adaptabilidad son fundamentales para mantener la cadencia de desarrollo y la alineación con las necesidades del negocio.
Los Large Language Models (LLM), entrenados en vastos conjuntos de datos que incluyen documentación técnica, metodologías ágiles y mejores prácticas en ingeniería de software, pueden generar historias de usuario a partir de simples descripciones proporcionadas por los equipos de desarrollo, producto o negocio. Con un solo prompt bien formulado, un LLM es capaz de analizar requerimientos previos, identificar patrones en historias de usuario existentes y producir nuevas historias en segundos, garantizando consistencia en el formato y alineación con los objetivos del proyecto.
Además de la generación rápida, estas herramientas permiten iteraciones y refinamientos en tiempo real, facilitando la incorporación de criterios de aceptación detallados, escenarios de prueba en Behavior-Driven Development (BDD) (North, 2009)e incluso recomendaciones para mejorar la claridad y el alcance de cada historia. Gracias a la integración con sistemas de gestión de productos y herramientas de colaboración como JIRA, Trello y Azure DevOps, las historias generadas pueden ser directamente revisadas, ajustadas y priorizadas dentro del backlog, reduciendo significativamente el tiempo y esfuerzo dedicados a esta tarea (Brown et al., 2020).
Veamos un ejemplo:
Requerimiento inicial:
"El sistema debe permitir a los usuarios descargar reportes en formato PDF y Excel con los datos de sus transacciones de los últimos seis meses."
Prompt:
Basado en el requerimiento: """El sistema debe permitir a los usuarios descargar reportes en formato PDF y Excel con los datos de sus transacciones de los últimos seis meses.""".
Elabora la historia de usuario correspondiente con criterios de aceptación en prosa, y luego presenta los criteros de aceptación usando el formato gherkin.
Respuesta:
Transformación en Historia de Usuario:
Como usuario del sistema financiero,
quiero descargar reportes de mis transacciones en formatos PDF y Excel,
para analizar mis gastos y movimientos bancarios con facilidad.
Criterios de Aceptación en Prosa:
- El usuario debe poder seleccionar un rango de fechas dentro de los últimos seis meses.
- El sistema debe generar el reporte en menos de 5 segundos.
- Los datos en el reporte deben coincidir con los movimientos visibles en la interfaz.
- El usuario debe poder elegir entre descargar el reporte en formato PDF o Excel.
- Si no hay transacciones en el período seleccionado, el sistema debe notificar al usuario sin generar un archivo vacío.
Criterios de Aceptación en BDD:
Escenario 1: Generación exitosa de reporte
- Dado un usuario autenticado con transacciones en los últimos seis meses
- Cuando selecciona un rango de fechas y el formato de descarga
- Entonces el sistema genera un archivo en el formato seleccionado
- Y el contenido del reporte coincide con las transacciones en pantalla
- Y el tiempo de generación no supera los 5 segundos
Escenario 2: Intento de generación sin transacciones
- Dado un usuario autenticado sin transacciones en el período seleccionado
- Cuando solicita la descarga del reporte
- Entonces el sistema muestra un mensaje indicando que no hay datos disponibles
- Y no genera un archivo vacío
De historia de usuario a casos de prueba
La IA permite automatizar la conversión de historias de usuario en casos de prueba estructurados, reduciendo errores y mejorando la trazabilidad (Murphy et al., 2022).
Continuando con el ejemplo:
Prompt:
Para lo anterior, genera los casos de prueba
Respuesta:
1. Casos de Prueba Funcionales
Caso de Prueba 1: Generación exitosa de reporte en PDF
- ID: CP_001
- Descripción: Verificar que el sistema permite generar y descargar un reporte en formato PDF con las transacciones del usuario.
-
Precondiciones:
- El usuario debe estar autenticado.
- Debe haber transacciones en el rango de fechas seleccionado.
-
Pasos:
- Iniciar sesión en la plataforma.
- Ir a la sección de reportes.
- Seleccionar un rango de fechas con transacciones.
- Elegir formato de descarga PDF.
- Hacer clic en el botón "Descargar".
-
Resultado Esperado:
- El sistema genera y descarga un archivo PDF con los datos de las transacciones seleccionadas en menos de 5 segundos.
- El contenido del PDF debe coincidir con la información mostrada en la interfaz.
Caso de Prueba 2: Generación exitosa de reporte en Excel
- ID: CP_002
- Descripción: Verificar que el sistema permite generar y descargar un reporte en formato Excel con las transacciones del usuario.
-
Precondiciones:
- El usuario debe estar autenticado.
- Debe haber transacciones en el rango de fechas seleccionado.
-
Pasos:
- Iniciar sesión en la plataforma.
- Ir a la sección de reportes.
- Seleccionar un rango de fechas con transacciones.
- Elegir formato de descarga Excel.
- Hacer clic en el botón "Descargar".
-
Resultado Esperado:
- El sistema genera y descarga un archivo Excel con los datos de las transacciones seleccionadas en menos de 5 segundos.
- El contenido del archivo debe coincidir con la información mostrada en la interfaz.
Caso de Prueba 3: Intento de descarga sin transacciones disponibles
- ID: CP_003
- Descripción: Validar que el sistema no genera un archivo vacío cuando no hay transacciones en el período seleccionado.
-
Precondiciones:
- El usuario debe estar autenticado.
- No debe haber transacciones en el rango de fechas seleccionado.
-
Pasos:
- Iniciar sesión en la plataforma.
- Ir a la sección de reportes.
- Seleccionar un rango de fechas sin transacciones.
- Elegir cualquier formato de descarga (PDF o Excel).
- Hacer clic en el botón "Descargar".
-
Resultado Esperado:
- El sistema muestra un mensaje: "No hay transacciones en el período seleccionado".
- No se genera ningún archivo de descarga.
Caso de Prueba 4: Verificación de tiempos de generación
- ID: CP_004
- Descripción: Asegurar que la generación del reporte no supere los 5 segundos.
-
Precondiciones:
- El usuario debe estar autenticado.
- Debe haber transacciones en el rango de fechas seleccionado.
-
Pasos:
- Iniciar sesión en la plataforma.
- Ir a la sección de reportes.
- Seleccionar un rango de fechas con transacciones.
- Elegir cualquier formato de descarga (PDF o Excel).
- Iniciar la medición del tiempo.
- Hacer clic en el botón "Descargar".
- Detener la medición cuando el archivo esté disponible.
-
Resultado Esperado:
- El tiempo total de generación y descarga no debe superar los 5 segundos.
2. Casos de Prueba de Seguridad
Caso de Prueba 5: Acceso no autorizado a reportes
- ID: CP_005
- Descripción: Asegurar que un usuario no autenticado no pueda descargar reportes.
-
Precondiciones:
- Usuario no autenticado en el sistema.
-
Pasos:
- Intentar acceder directamente a la URL de generación de reportes.
- Intentar descargar un reporte sin iniciar sesión.
-
Resultado Esperado:
- El sistema redirige al usuario a la página de inicio de sesión.
- No permite la descarga del reporte.
Caso de Prueba 6: Descarga de reportes de otro usuario
- ID: CP_006
- Descripción: Asegurar que un usuario no pueda descargar reportes de otro usuario.
-
Precondiciones:
- Usuario autenticado en el sistema con permisos limitados.
-
Pasos:
- Intentar modificar la URL de descarga para acceder al reporte de otro usuario.
- Intentar forzar la descarga cambiando parámetros en la solicitud.
-
Resultado Esperado:
- El sistema debe denegar la solicitud con un mensaje de error: "Acceso no autorizado".
3. Casos de Prueba de Integración
Caso de Prueba 7: Integración con sistema de almacenamiento en la nube
- ID: CP_007
- Descripción: Validar que los reportes puedan almacenarse automáticamente en la nube si el usuario lo selecciona.
-
Precondiciones:
- El usuario debe haber activado la opción "Guardar en la nube".
-
Pasos:
- Seleccionar rango de fechas y formato de descarga.
- Marcar la opción "Guardar en la nube".
- Hacer clic en "Descargar".
-
Resultado Esperado:
- El sistema genera el reporte y lo sube automáticamente al almacenamiento en la nube del usuario.
- Aparece un mensaje confirmando la acción.
4. Casos de Prueba de Usabilidad
Caso de Prueba 8: Verificación de claridad en los reportes
- ID: CP_008
- Descripción: Evaluar la facilidad de lectura y comprensión de los reportes generados.
-
Precondiciones:
- Usuario autenticado.
- Transacciones disponibles en el período seleccionado.
-
Pasos:
- Descargar el reporte en PDF y en Excel.
- Revisar la estructura, organización y claridad del contenido.
- Resultado Esperado:
- Los datos están organizados en tablas claras.
- Los encabezados y etiquetas son descriptivos.
El Papel de los Agentes de IA en la Automatización del Desarrollo de Software
Los agentes de IA están revolucionando la forma en que los equipos de desarrollo y UX trabajan juntos, automatizando tareas clave en la planificación, diseño, implementación y pruebas de software. Estos agentes pueden escribir o recibir historias de usuario y generar bocetos de interfaz, estructurando automáticamente la disposición de los elementos visuales según las mejores prácticas de usabilidad. Gracias a su capacidad para analizar patrones en grandes volúmenes de datos de diseño, pueden sugerir componentes reutilizables, mejorar la accesibilidad y garantizar estructuras coherentes con la identidad visual de la empresa.
Además de la planificación y el diseño, los agentes de IA han comenzado a generar software funcional preliminar, tomando como base historias de usuario bien definidas con criterios de aceptación claros. A partir de una descripción funcional, la IA puede producir código inicial estructurado, con implementación de lógica básica y validaciones esenciales. Si bien este proceso aún está en evolución, ya es posible que un agente de IA genere microservicios, funciones backend, interfaces frontend e integraciones simples con bases de datos en cuestión de minutos.
En la arquitectura de software, estos agentes pueden identificar tecnologías adecuadas según los requisitos funcionales y no funcionales de la aplicación. Sus propuestas incluyen diagramas preliminares de componentes, selección de patrones de diseño y recomendaciones sobre escalabilidad, seguridad y mantenimiento. Al integrarse con herramientas como PlantUML o Draw.io, la IA puede producir esquemas técnicos que sirven como base para la validación por parte del equipo de arquitectura antes de la implementación.
En el ámbito de la planificación funcional, los agentes de IA pueden generar documentos preliminares detallados con flujos de trabajo, validaciones de negocio y escenarios de uso basados en la historia de usuario original. Estos documentos incluyen descripciones de estados, reglas de validación de datos y excepciones que el sistema debe manejar, permitiendo que los equipos de producto visualicen el comportamiento esperado de la funcionalidad antes de escribir una sola línea de código.
Uno de los avances más prometedores es la capacidad de la IA para crear software funcional en tiempo real, complementado con casos de prueba automatizados. A partir de los criterios de aceptación definidos en la historia de usuario, el agente puede generar un conjunto completo de pruebas funcionales, de integración y de regresión. Si el equipo trabaja con frameworks como Selenium, Cypress o JUnit, la IA puede convertir automáticamente estos casos de prueba en scripts ejecutables, garantizando que el código generado cumpla con los requisitos antes de su integración en la solución final.
Hacia un Desarrollo Autónomo con Agentes de IA
El futuro cercano apunta hacia una automatización aún más profunda, donde un agente de IA podrá recibir una historia de usuario y, en cuestión de minutos, entregar un módulo funcional listo para ser validado y ajustado por un desarrollador. Este proceso incluirá no solo el desarrollo del código, sino también:
- Pruebas automatizadas generadas y ejecutadas de inmediato.
- Validación de calidad basada en métricas predefinidas.
- Despliegue en un ambiente seleccionado para pruebas o integración.
Este enfoque permitirá que los desarrolladores pasen de ser constructores manuales de código a supervisores y optimizadores de soluciones generadas por IA. Aunque actualmente estas capacidades están en evolución, ya existen modelos avanzados que generan código funcional con estructuras bien definidas y pruebas incluidas, reduciendo significativamente los tiempos de desarrollo.
Impacto en la Productividad y Colaboración
Al integrar estos agentes de IA en el ciclo de desarrollo, los equipos de UX y desarrollo pueden colaborar de manera más eficiente, reduciendo la ambigüedad en los requerimientos y minimizando el tiempo de iteración en la construcción del producto. Esto permite que los desarrolladores se concentren en optimizar la funcionalidad y corregir detalles específicos en lugar de escribir código desde cero.
En un futuro no muy lejano, podríamos estar ante un modelo de desarrollo donde una simple historia de usuario bien redactada desencadene, de manera automatizada, el diseño, el desarrollo, la generación de pruebas y el despliegue en el ambiente adecuado, acortando drásticamente los tiempos de entrega y permitiendo ciclos de retroalimentación más rápidos.
Entrega de historias a agentes de IA
Los agentes de IA están transformando la forma en que los equipos de desarrollo y UX trabajan juntos, automatizando tareas clave en la planificación, diseño y pruebas de software. Estos agentes pueden escribir o recibir historias de usuario, y generar bocetos de interfaz, estructurando automáticamente la disposición de los elementos visuales según las mejores prácticas de usabilidad. Gracias a su capacidad para analizar patrones en grandes volúmenes de datos de diseño, pueden sugerir componentes reutilizables, accesibilidad optimizada y estructuras coherentes con el branding de la empresa.
Además, los agentes de IA pueden generar propuestas de arquitectura de software, identificando las tecnologías más adecuadas en función de los requisitos funcionales y no funcionales de la aplicación. Estas propuestas incluyen diagramas preliminares de componentes, selección de patrones de diseño y recomendaciones sobre escalabilidad, seguridad y mantenimiento. Al integrarse con herramientas como PlantUML o Draw.io, la IA puede producir diagramas técnicos que sirven como punto de partida para la validación del equipo de arquitectura.
En el ámbito de la planificación funcional, los agentes pueden generar documentos preliminares detallados con flujos de trabajo, validaciones de negocio y escenarios de uso basados en la historia de usuario original. Estos documentos pueden incluir descripciones de estados, reglas de validación de datos y excepciones que el sistema debe manejar. Así, los equipos de producto pueden visualizar el comportamiento esperado de la funcionalidad antes de escribir una sola línea de código.
Otro aspecto clave es la capacidad de la IA para crear y automatizar casos de prueba. A partir de los criterios de aceptación definidos en la historia de usuario, el agente puede generar un conjunto completo de pruebas funcionales, de integración y de regresión. Además, si el equipo trabaja con frameworks como Selenium, Cypress o JUnit, la IA puede convertir automáticamente los casos de prueba manuales en scripts listos para ejecutarse, reduciendo el esfuerzo en la automatización de pruebas. Esto no solo acelera el ciclo de desarrollo, sino que también garantiza una mayor cobertura y calidad del software antes de su despliegue.
Al integrar agentes de IA en estos procesos, los equipos de UX y desarrollo pueden colaborar de manera más eficiente, evitando ambigüedades y reduciendo tiempos de iteración en la construcción del producto. Esto permite que los desarrolladores se concentren en la implementación de funcionalidades mientras la IA se encarga de optimizar el flujo de trabajo, mejorando así la velocidad y calidad del desarrollo.
La IA en la Partición y Priorización de Historias de Usuario
Uno de los mayores retos en la gestión de historias de usuario es dividirlas adecuadamente sin perder valor. Una historia de usuario demasiado grande puede ralentizar el flujo de trabajo y dificultar su entrega en iteraciones cortas, mientras que una historia demasiado pequeña puede generar fragmentación innecesaria. Aquí es donde la IA ofrece ventajas significativas, ayudando a equipos ágiles a optimizar la entrega de valor.
Descomposición Asistida por IA
La inteligencia artificial puede analizar historias de usuario grandes y sugerir particiones lógicas basadas en patrones previos y heurísticas ágiles (Fowler, 2019). Gracias a modelos de procesamiento de lenguaje natural (NLP), la IA puede:
- Identificar subtareas dentro de una historia grande.
- Recomendar divisiones siguiendo criterios de INVEST (Independiente, Negociable, Valiosa, Estimable, Pequeña y Testeable).
- Adaptar la descomposición en función de la capacidad del equipo y las dependencias entre historias.
- Sugerir fragmentos reutilizables para acelerar el desarrollo de funcionalidades similares en el futuro.
En la práctica, la IA puede recibir una historia de usuario compleja y generar automáticamente versiones más manejables sin perder la coherencia del valor de negocio.
Ejemplo de Partición de Historia de Usuario Usando GenAI
Historia de Usuario Original (Muy Grande)
Como usuario de una plataforma de e-commerce,
quiero realizar pagos con tarjeta de crédito y recibir confirmación automática,
para completar mis compras sin errores y con seguridad.
Sugerencias de Partición Generadas por GenAI
Historia 1: Integración con Pasarela de Pago
Como usuario,
quiero ingresar los datos de mi tarjeta y procesar el pago,
para completar mi compra de manera segura.
Criterios de Aceptación:
- El sistema debe validar los datos de la tarjeta antes de procesar el pago.
- El pago debe realizarse en menos de 3 segundos.
- Se deben manejar errores como tarjeta rechazada o fondos insuficientes.
Historia 2: Confirmación de Pago
Como usuario,
quiero recibir una notificación de confirmación tras completar el pago,
para saber que mi compra se ha realizado correctamente.
Criterios de Aceptación:
- El sistema debe enviar un correo y una notificación en la app tras la transacción.
- El mensaje debe incluir detalles como monto, productos comprados y número de orden.
- En caso de pago rechazado, la notificación debe indicar el motivo y posibles soluciones.
Historia 3: Historial de Pagos
Como usuario,
quiero consultar el historial de mis transacciones dentro de la plataforma,
para tener un registro de mis compras anteriores.
Criterios de Aceptación:
- El sistema debe mostrar una lista de transacciones con fecha, monto y estado.
- Debe permitir filtrar por rango de fechas y métodos de pago.
- La información debe actualizarse en tiempo real tras cada transacción.
- Se mantienen historias pequeñas y manejables, asegurando su entrega en iteraciones cortas.
- Se optimiza el flujo de trabajo, evitando bloqueos y dependencias innecesarias.
- Se asegura que cada historia agregue valor real al usuario, sin fragmentar la experiencia.
- Se mejora la predicción de tiempos de desarrollo, facilitando la planificación del sprint.
Priorización Inteligente
Los modelos de GenAI pueden analizar datos históricos de velocidad del equipo, dependencias entre historias y métricas de impacto para sugerir un backlog optimizado (Leffingwell, 2020). Algunos de los beneficios de este enfoque incluyen:
- Predicción de tiempos de entrega basados en historias similares completadas previamente.
- Priorización según impacto en los objetivos de negocio.
- Identificación de cuellos de botella y dependencias técnicas antes de iniciar el desarrollo.
- Sugerencias sobre cuáles historias deberían abordarse primero para reducir riesgos.
Este enfoque permite optimizar la gestión del flujo de trabajo, asegurando que los equipos trabajen en las historias más importantes en el momento adecuado.
El Product Owner Sigue al Mando
A pesar de estos avances, la IA no reemplaza la responsabilidad del Product Owner (PO). Este sigue siendo quien debe:
- Leer, entender y validar las historias de usuario.
- Ordenar el backlog en función de la estrategia del negocio.
- Asegurar que las historias descompuestas mantengan su valor e independencia.
- Trabajar en conjunto con el equipo para tomar decisiones finales sobre la implementación.
La IA funciona como un asistente inteligente, proporcionando información y recomendaciones, pero la última palabra sigue en manos del PO y el equipo de desarrollo.
Una mejora indiscutible en la eficiencia y unas advertencias
La GenAI puede hacer -actualmente - a los equipos hasta un 40% más efectivos en la gestión de historias de usuario (McKinsey, 2023). Sin embargo, esto no exime a los equipos de la responsabilidad de comprender qué se está pidiendo ni de evitar la generación de desperdicio.
Para maximizar el valor de la IA en este contexto, los equipos deben:
- Usar la IA como asistente, pero validar siempre sus resultados.
- Mantener la creatividad y el pensamiento crítico en la escritura de historias.
- Evitar la dependencia excesiva de la IA para evitar historias sin contexto o mal estructuradas.
Cerrando
La IA ha llegado para quedarse en la gestión de historias de usuario. Desde la generación automática hasta la conversión en casos de prueba y la priorización basada en datos, la GenAI es una herramienta poderosa. Sin embargo, su éxito depende de cómo los equipos la adopten y combinen sus capacidades con el juicio humano.
El futuro de las historias de usuario en la era de la GenAI es prometedor: una colaboración cada vez más estrecha entre humanos e inteligencia artificial, donde la automatización potencia la creatividad y la eficiencia, sin reemplazar el papel fundamental de los equipos ágiles.
Saludos ágiles,
Jorge Abad.
Referencias
- Abad, J (2024) De Colección: Ejemplos de Historias de Usuario de la Fuente: Los Libros de Extreme Programming (XP)
- Abad, J (2025). Guía para identificar mejores criterios de aceptación en historias de usuario
- Brown, T. et al. (2020). Language Models are Few-Shot Learners. OpenAI.
- Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
- Fowler, M. (2019). Refactoring: Improving the Design of Existing Code. Addison-Wesley.
- Jeffries, R (2001). Essential XP: Card, Conversation, Confirmation
- Leffingwell, D. (2020). SAFe 5.0 for Lean Enterprises. Scaled Agile Inc.
- McKinsey & Company (2023). The State of AI in Agile Development.
- Murphy, G. et al. (2022). AI-Driven Software Testing: Trends and Challenges. IEEE Software.
- North, D. (2009). Introducing BDD.
lunes, febrero 24, 2025
Transformando conversaciones en código funcionando: El rol de las Historias de Usuario
Hola a todos,
El software no es simplemente un conjunto de líneas de código que ejecutan instrucciones en un procesador. Es la representación digital del mundo real, un esfuerzo por modelar procesos, resolver problemas y crear experiencias significativas para los usuarios. Pero esta transformación del mundo físico al digital no ocurre de manera automática; se da a través de la conversación, el entendimiento compartido y la construcción colaborativa de soluciones.
Las historias de usuario (HU) no son especificaciones técnicas ni documentos cerrados; son el punto de partida de una conversación sobre lo que queremos construir. Son el vehículo que nos permite expresar necesidades, compartir expectativas y alinear criterios entre negocio, desarrollo y usuarios. Como lo señala Jeff Patton en User Story Mapping, las historias de usuario son “promesas de una conversación” más que requerimientos detallados (1). Es en estas conversaciones donde se define el valor del software y cómo este reflejará la realidad que buscamos modelar.
De la Conversación al Código: El Software como Modelo del Mundo Real
En esencia, desarrollar software es un proceso de traducción: convertimos problemas y oportunidades en soluciones digitales. Cada línea de código es el resultado de múltiples interacciones entre equipos de negocio, desarrollo y usuarios, quienes discuten qué se necesita, cómo debe funcionar y cuál es la mejor manera de representar una solución efectiva.
Martin Fowler, en Refactoring: Improving the Design of Existing Code, argumenta que el software evoluciona en ciclos de retroalimentación constante y que la claridad en la comunicación es esencial para evitar malentendidos que se traduzcan en código incorrecto o innecesario (2). Esto refuerza la idea de que el software no es solo código, sino la cristalización de un entendimiento compartido sobre cómo resolver un problema.
La conversación es el insumo fundamental del desarrollo de software. Sin una comunicación efectiva, los equipos corren el riesgo de construir soluciones que no reflejan la intención original. Como lo menciona Kent Beck en Extreme Programming Explained, la programación extrema (XP) enfatiza la comunicación continua entre todos los involucrados para garantizar que el software represente fielmente las necesidades del negocio y de los usuarios finales (3). En otras palabras, la calidad del software está directamente relacionada con la calidad de las conversaciones que lo preceden.
El Proceso de Creación de Software: De la Idea a la Validación
El desarrollo de software es un ciclo iterativo donde cada etapa está respaldada por conversaciones clave que permiten garantizar que lo que se construye es realmente lo que se necesita. El flujo típico sigue esta secuencia:
- Idea: Surge una necesidad o una oportunidad que se quiere materializar en software.
- Conversación inicial: Se llega a un acuerdo sobre lo que se quiere lograr y por qué.
- Historia de usuario: Se plasma el concepto en una HU que actúa como un recordatorio de la conversación.
- Conversación de refinamiento: Se profundiza en los detalles y se acuerda lo que realmente se va a construir.
- Codificación: Se implementa la funcionalidad en base a la conversación previa.
- Conversación durante la construcción: Se acuerdan partes difusas de la HU, se cierran detalles, se identifican oportunidades de ajuste. Los pasos 5 y 6 se pueden repetir varias veces.
- Conversación de validación: Se presenta y valida lo construido con el usuario para verificar que cumple con las expectativas.
Este proceso se repite de manera continua, asegurando que cada funcionalidad agregada tenga sentido, sea útil y cumpla con los objetivos del negocio. En un entorno ágil, las conversaciones no terminan con la entrega del software; más bien, se mantiene un diálogo constante que permite mejorar y adaptar la solución a las necesidades cambiantes del usuario y del mercado.
El Rol de la Inteligencia Artificial en la Conversación del Software
Con la evolución de la inteligencia artificial (IA), el ciclo de retroalimentación en el desarrollo de software se está reduciendo drásticamente. Herramientas como GitHub Copilot y modelos avanzados de procesamiento de lenguaje natural están acelerando la transformación de ideas en código. Sin embargo, esto no significa que la IA pueda reemplazar la conversación humana.
La IA puede asistir en la generación de código, la identificación de patrones y la optimización de soluciones, pero aún depende de instrucciones claras y precisas. Como lo menciona Google en su investigación sobre Software 2.0, los modelos de IA pueden generar código, pero requieren contexto, intención y guía humana para producir resultados valiosos (4). Esto refuerza la importancia de las historias de usuario como un puente entre el entendimiento humano y la ejecución automatizada.
Incluso en un mundo donde la IA nos permite validar ideas en tiempo récord, sigue siendo crucial plasmar nuestras necesidades en historias de usuario claras y concisas. No se trata de eliminar la conversación, sino de hacerla más eficiente. Las HU siguen siendo necesarias para estructurar y comunicar lo que queremos construir en pequeños fragmentos implementables en cuestión de horas, manteniendo el ciclo de entrega ágil y efectivo.
De las Historias de Usuario a la Conversación Continua
En metodologías ágiles, las historias de usuario no solo sirven como un punto de partida, sino que también facilitan la conversación continua a lo largo del desarrollo del software. Como señala el Agile Manifesto, la colaboración frecuente entre negocio y desarrollo es un principio clave para entregar software de calidad (5). Cuando los equipos adoptan este enfoque, logran reducir el riesgo de malinterpretaciones, mejorar la alineación estratégica y aumentar la satisfacción del usuario final.
El software no es solo código. Es la representación de acuerdos, decisiones y aprendizajes compartidos a lo largo de múltiples interacciones. Es un reflejo de cómo entendemos y resolvemos problemas en el mundo real. Por eso, la calidad del software no depende únicamente de la tecnología utilizada, sino de la capacidad de los equipos para conversar, comprender y traducir esas conversaciones en soluciones digitales efectivas.
Cerrando
El desarrollo de software es un proceso de diálogo estructurado, donde las historias de usuario actúan como catalizadores de la conversación. La inteligencia artificial está acelerando la implementación de soluciones, pero no reemplaza la necesidad de expresar, compartir y validar ideas. En este ecosistema, la clave no está en generar más documentación, sino en mejorar la forma en que conversamos, porque al final del día, el software es solo eso: una conversación convertida en ceros y unos.
Referencias:
- Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product (O'Reilly Media, 2014).
- Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley, 1999).
- Kent Beck, Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999).
- Google Research, "Software 2.0: AI-Driven Code Generation and Its Future", 2023.
- Agile Manifesto, “Principles Behind the Agile Manifesto”, 2001.
De Colección: Una buena definición de Historia de Usuario - continuación
Esta es la explicación del post: De Colección: Una buena definición de Historia de Usuario
Hola a todos
Uno de los retos más comunes en agilidad es definir claramente qué es una historia de usuario y, sobre todo, cuál es su tamaño adecuado. He encontrado útil compartir esta definición:
"Una Historia de usuario es una pequeña porción de valor cuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue, puede estar entre unas cuantas horas hasta máximo 36 aproximadamente."
Otra versión que enfatiza el impacto en el negocio es:
"Una Historia de usuario es una pequeña porción funcional de valor cuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue; puede estar entre unas cuantas horas hasta máximo 36 aproximadamente, que le permite al equipo de desarrollo de forma tangible y rápida mostrar progreso al negocio"
Justificación de esta definición
El propósito de estas definiciones es alinear expectativas sobre el tamaño y alcance de una historia de usuario. En la práctica, es común encontrar historias que son demasiado grandes o demasiado pequeñas, lo que afecta el flujo de trabajo y la entrega de valor real.
¿Qué significa una "pequeña porción de valor"?
Para que una historia de usuario tenga el tamaño adecuado, debe cumplir dos principios clave:
- Ser lo suficientemente pequeña para completarse en poco tiempo (idealmente en menos de dos días de trabajo acumulado). Esto permite que el equipo entregue de forma frecuente y fluida.
- Ser lo suficientemente grande para aportar valor tangible al usuario o negocio. Esto significa que debe entregar una funcionalidad completa y usable, no solo una parte técnica aislada.
Una historia demasiado pequeña puede caer en fragmentación innecesaria, por ejemplo:
- "Agregar un nuevo campo en un formulario" (sin que esto implique una funcionalidad completa para el usuario).
- "Implementar solo la lógica de frontend" sin que el usuario pueda interactuar con el sistema de manera funcional.
Por otro lado, una historia demasiado grande se convierte en un problema porque:
- No se logra entregar dentro del sprint, afectando la previsibilidad del equipo.
- Genera un esfuerzo desproporcionado que impide recibir retroalimentación temprana.
- Puede requerir múltiples iteraciones para completarse, lo que dificulta la entrega continua de valor.
¿Por qué definir un límite de hasta 36 horas?
Anteriormente, usaba la referencia en días, pero esto generaba confusión. Algunas personas asumían que se trataba del esfuerzo acumulado de varias personas en paralelo, cuando en realidad el enfoque está en el tiempo total requerido.
Este límite de tiempo permite que las historias de usuario sean manejables y estén listas para ser desplegadas dentro del sprint sin convertirse en un obstáculo para el equipo. Además, facilita:
- Un flujo de entrega continuo, evitando acumulaciones y bloqueos.
- Un progreso visible para el negocio, al recibir incrementos de valor en ciclos cortos.
- La detección temprana de problemas, reduciendo el riesgo de retrabajo.
¿Cómo lograr historias de usuario con el tamaño adecuado?
- Asegurar que cada historia entregue valor real. Si un usuario no puede interactuar con la funcionalidad o si no se resuelve un problema concreto, entonces la historia está mal definida.
- Evitar fragmentación innecesaria. Dividir en tareas técnicas (backend por un lado, frontend por otro) no es lo ideal, ni lo correcto. En su lugar, cada historia debe representar un incremento funcional, usable y comprobable del usuario.
- Reducir la complejidad sin perder el impacto. Si una historia es demasiado grande, dividirla de manera que cada parte siga teniendo sentido de negocio y sea usable por el usuario.
Definir historias de usuario en estos términos ayuda a los equipos a mejorar su agilidad y a entregar valor de forma consistente.
¿Tu equipo tiene una definición clara de historia de usuario? ¿Cómo manejan su tamaño? Comparte tu experiencia en los comentarios.
miércoles, febrero 19, 2025
Guía para identificar mejores criterios de aceptación en historias de usuario
Hola a todos,
Escribir criterios de aceptación, a pesar de ser un proceso de llegar a un acuerdo sobre lo que se quiere recibir, no deja de ser un reto. En este proceso surgen al menos tres preguntas:
- ¿Hasta cuándo es suficiente detalle?
- ¿Estoy dejando la descripción muy general?
- ¿Qué más debo incluir?
Ante esto, generalmente, a los Product Owners les digo:
- No te preocupes, que si falta detalle, los developers te lo recordarán.
- Si olvidaste algo, es porque aún no es importante.
Aún así, el pedido que constantemente recibo es:
"¿Podrías escribir una guía para hacer criterios de aceptación?"
Considerando que lo anterior lo he respondido de forma particular, voy a cambiar mi aproximación y hacerlo por medio de este artículo que, con seguridad, iré engrosando en la medida que la retroalimentación y la experiencia vayan llegando.
¿Qué son los criterios de aceptación?
Los criterios de aceptación son las condiciones que una historia de usuario debe cumplir para considerarse completada cuando es desarrollada y desplegada por el equipo. Funcionan como una guía para los desarrolladores y testers, asegurando que lo que se construye es realmente lo que el negocio necesita.
Es de considerar que el formato original de las historias de usuario no incluía los criterios de aceptación (1), y aunque no hay un acuerdo sobre quien los incluyó, Ron Jeffries hace referencia tácita a ellos en su artículo sobre las tres C (Card - Conversation- Confirmation) (2):
"Al comienzo de la iteración, el cliente comunica a los programadores lo que desea y les dice cómo confirmará que han hecho lo que se necesita. Define las pruebas de aceptación que se utilizarán para demostrar que la historia se ha implementado correctamente".(2)
No se habla de un formato específico, incluso se sugiere el uso de ejemplos para que estos sean más claros, algo que al final incluyó Behavior Driven Development (BDD) (3).
No confundir con la Definition of Done (DoD). Mientras que los criterios de aceptación son específicos para una historia de usuario, la Definición de Terminado es un estándar general del equipo para determinar cuándo una historia está terminada desde un punto de vista técnico y de calidad.
¿Por qué son clave en un desarrollo ágil? (4)
Los criterios de aceptación cumplen un papel fundamental en la comunicación entre los equipos de desarrollo y los stakeholders. Algunas razones por las que son esenciales incluyen:
- Evitan malentendidos: Reducen la ambigüedad y ayudan a alinear expectativas.
- Mejoran la calidad del producto: Definen el mínimo aceptable para el negocio.
- Facilitan la prueba y validación: Los testers pueden usarlos para diseñar pruebas.
- Permiten la automatización: Son la base para la creación de pruebas automatizadas.
- Pueden contener ejemplos que van a guiar a los desarrolladores: Basados en los ejemplos proporcionados, los desarrolladores encontrarán como cumplir con lo que se espera de la fucionalidad.
Cómo aceptar la funcionalidad con el usuario durante la escritura de historias de usuario
Para asegurarte de que la funcionalidad que estás definiendo en la historia de usuario es realmente lo que el usuario necesita, puedes involucrarlo en el proceso desde el inicio. Aquí hay una estrategia para lograrlo:
Validar la historia de usuario antes de escribir los criterios de aceptación
- Explicar la historia de usuario en términos simples y preguntar:
- “¿Esta historia realmente cubre tu necesidad?”
- Preguntar si falta algo en la descripción de la historia.
- Asegurar que la historia esté escrita en el lenguaje del usuario, no en lenguaje técnico. No incluyas llamado a bases de datos, nombres de tablas, etc.
Involucrar al usuario en la definición de criterios de aceptación
- Preguntar cómo espera que funcione la funcionalidad en su día a día.
- Plantear escenarios de uso y validar que cubran sus expectativas.
- Escribir los criterios de aceptación junto con el usuario o validarlos con él antes de finalizar la historia.
Revisar los criterios de aceptación con ejemplos
- Presentar ejemplos de cómo funcionará la funcionalidad basados en los criterios de aceptación y preguntar:
- Si esto se comporta así, ¿te parecería correcto?
- ¿Cuáles son los campos que van a viajar en el formulario? ¿Cuáles serán las validaciones asociadas a cada campo?
- ¿Cuáles son los campos que tendrá el reporte? ¿Tendrá filtros?
- ¿Cuáles son los mensajes de éxito y de fracaso, según el resultado?
- ¿La imagen o gráfico será interactivo? ¿Qué comportamientos tendrá?
- ¿Se enviarán notificaciones? ¿De qué forma? ¿A quiénes?
- Si usa formato Given-When-Then (más adelante cubriré este aspecto), leer los escenarios y validar con el usuario.
Usar prototipos o bocetos si es necesario
- Si la funcionalidad es visual, mostrar wireframes o pantallas para confirmar que la historia refleja lo que el usuario espera.
Obtener aprobación antes de llevarla a desarrollo
- Preguntar directamente: “Si construimos esto con base en estos criterios de aceptación, ¿estarías satisfecho?”
- Si hay dudas o cambios, refinarlos antes de que el equipo empiece a desarrollarla.
- Preguntas adicionales para descubrir criterios de aceptación
Si quieres mejorar la identificación de criterios de aceptación, aquí tienes más preguntas que puedes hacer al usuario o al equipo:
- Sobre el objetivo de la historia
- ¿Cuál es el problema exacto que queremos resolver con esta historia?
- ¿Cómo sabremos si la funcionalidad realmente cumple su propósito?
- ¿Hay métricas o indicadores que podrían ayudarnos a medir el éxito?
- Sobre los escenarios clave
- ¿En qué situaciones usarías esta funcionalidad?
- ¿Cuál es el flujo ideal desde tu perspectiva?
- ¿Existen variantes o excepciones que debamos considerar?
- Sobre las reglas de negocio
- ¿Existen restricciones específicas para esta funcionalidad?
- ¿Qué pasa si el usuario introduce datos incorrectos?
- ¿Hay algún comportamiento especial que deba seguir la funcionalidad en ciertos casos?
- Sobre la experiencia de usuario
- ¿Qué tan rápido esperas que responda el sistema?
- ¿Cómo te gustaría recibir la confirmación de que la acción se completó?
- ¿Prefieres una notificación visual, un correo, o algún otro mecanismo?
- Sobre seguridad y accesos
- ¿Todos los usuarios deberían poder acceder a esta funcionalidad?
- ¿Necesitamos permisos o restricciones especiales?
- Sobre el manejo de errores y excepciones
- ¿Qué pasa si el sistema no puede completar la acción?
- ¿Cómo debería informarse al usuario en caso de error?
- Sobre la integración con otros sistemas
- ¿Esta funcionalidad afecta o depende de otros módulos o sistemas?
- ¿Qué datos necesitamos capturar o enviar a otras áreas del sistema?
Elementos esenciales de un buen criterio de aceptación
Para que los criterios de aceptación sean efectivos, deben cumplir con estas características:
- Claridad y precisión: No deben dejar espacio a interpretaciones.
- Independencia de implementación: No describen cómo hacerlo, sino qué resultado se espera.
- Testabilidad: Deben ser verificables con pruebas manuales o automatizadas.
- Alineación con las necesidades del usuario: Siempre deben responder a lo que el usuario final necesita.
Nota importante: Quisiera compartirles algo sobre lo que soy reiterativo cuando explico este concepto: aunque tu historia de usuario, con sus criterios de aceptación, quede bien definida, lo más importante es la conversación alrededor de la historia, el entendimiento común con el equipo.
Formatos comunes para escribir criterios de aceptación
Formato tradicional
Es el más simple: una lista de condiciones que deben cumplirse.
Ejemplo:
Historia de usuario:
Yo como usuario quiero poder restablecer mi contraseña para acceder a mi cuenta en caso de olvido.
Criterios de aceptación:
- El usuario debe recibir un correo con un enlace de restablecimiento.
- El enlace debe expirar en 30 minutos.
- La nueva contraseña debe cumplir con requisitos de seguridad.
Formato Given-When-Then (Gherkin)
Este formato, popular en BDD (Behavior Driven Development), ayuda a describir escenarios de manera estructurada:
- Given: Estado inicial.
- When: Acción del usuario.
- Then: Resultado esperado.
Ejemplo:
Given que el usuario olvidó su contraseña,
When ingresa su correo en la opción “Olvidé mi contraseña” y presiona enviar,
Then debe recibir un correo con un enlace de restablecimiento.
Este enfoque facilita la automatización de pruebas con herramientas como Cucumber.
Errores comunes al redactar criterios de aceptación
- Ambigüedad: Si no es claro, cada persona lo interpretará de manera diferente. Aunque invitan a la conversación en fases tempranas, próximos al desarrollo pueden convertirse en una fuente de incertidumbre, ejemplo: si la transacción no es exitosa se deberá confirmar al usuario. Surgen varias preguntas con lo anterior ¿Cómo? ¿Qué mensaje? ¿A través de que medios? ¿Proporcionaremos al usuario alguna forma de hacer reclamos?
- Demasiado técnico: No deberían describir cómo implementarlo, sino qué resultado se espera.
- No validarlos con el equipo: Deben ser revisados en sesiones de refinamiento del backlog.
Mejores prácticas para escribir criterios de aceptación efectivos
- Involucrar a todas las partes interesadas: No es solo tarea del Product Owner, los desarrolladores y testers también deben participar.
- Refinarlos en sesiones de backlog refinamiento con el equipo: Asegurar que sean claros antes de iniciar el desarrollo.
- Hacerlos testables: Si no se pueden probar, probablemente no están bien escritos.
- Utilizar el lenguaje del usuario final: Evitar tecnicismos innecesarios.
Cómo automatizar pruebas basadas en criterios de aceptación
Los criterios de aceptación bien definidos pueden traducirse directamente en pruebas automatizadas. Algunas herramientas que permiten hacer esto incluyen:
- Cucumber (BDD, Given-When-Then).
- Selenium (Pruebas UI basadas en escenarios).
- JUnit / TestNG (Pruebas unitarias automatizadas).
Esto permite que el equipo valide rápidamente si una historia cumple con los requerimientos sin depender exclusivamente de pruebas manuales.
Checklist final para validar criterios de aceptación
- Historia de usuario validada con el usuario o stakeholder.
- Criterios de aceptación basados en necesidades reales. Evita el desperdicio, es decir, poner criterios que no serán usados.
- Ejemplos o escenarios de uso confirmados.
- Información que se capturará o que retornará la funcionalidad, y el nombre de sus campos.
- Reglas de negocio y restricciones documentadas.
- Casos de error y manejo de excepciones definidos.
- Aprobación del usuario antes de pasar a desarrollo.
Nota importante: Un buen criterio de aceptación se puede convertir en un caso de prueba, directamente. Si el tester puede escribir una prueba automatizada o manual a partir de él, es una señal de que está bien definido.
Y si quedas con muchos criterios de aceptación
Si al final de todo este ejercicio, tu historia de usuario queda con entre seis y ocho criterios de aceptación (es mi actual heurística, puede que cambie con la IA), está perfecta de tamaño, pero si supera con creces este rango, pues. ¡Divide la historia y listo! Puedes tener más historias de usuario que ayuden con tu propósito de generar valor, la verdad, no hay lío con eso.
El mejor criterio de división es: que la historia requiera del trabajo suficiente para ser completado en alrededor de 36 horas, por desarrolladores y testers.
Cerrando
Escribir buenos criterios de aceptación es clave en el desarrollo ágil. Mejoran la comunicación, reducen malentendidos y permiten entregar software de mejor calidad.
Si en tu equipo todavía no los documentan formalmente, este es un buen momento para comenzar.
Notas. Aclaraciones Comentarios
- De Colección: Ejemplos de Historias de Usuario de la Fuente: Los Libros de Extreme Programming (XP) - Clic aquí.
- XP esencial: Tarjeta, Conversación, Confirmación - Clic aquí.
- What's in a Story? - Clic aquí.
- En este momento de la historia existe un boom sobre la Inteligencia Artificial y lo que puede proporcionarnos el uso de agentes; es posible que en el futuro cercano muchas o todas las tareas de desarollo y testing sean ejecutadas por Agentes de IA. Amanecerá y veremos.
- La historia de las historias de usuario - Clic aquí.
Suscribirse a:
Entradas (Atom)