{"id":4304,"date":"2026-04-10T22:34:26","date_gmt":"2026-04-10T22:34:26","guid":{"rendered":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/"},"modified":"2026-04-10T22:34:26","modified_gmt":"2026-04-10T22:34:26","slug":"stop-guessing-user-needs-use-case-diagrams-agile","status":"publish","type":"post","link":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/","title":{"rendered":"Deje de adivinar las necesidades del usuario: c\u00f3mo crear diagramas de casos de uso claros para equipos \u00e1giles"},"content":{"rendered":"

En el entorno acelerado del desarrollo de software, las suposiciones son el enemigo de la entrega. Cuando los equipos adivinan lo que los usuarios realmente necesitan, las caracter\u00edsticas a menudo fallan en el blanco, lo que conduce a sprints desperdiciados y stakeholders frustrados. Es aqu\u00ed donde el Diagrama de casos de uso<\/strong>se convierte en una herramienta esencial. Proporciona un contrato visual entre los objetivos del negocio y la implementaci\u00f3n t\u00e9cnica.<\/p>\n

Para los equipos \u00e1giles, la claridad es moneda corriente. Un diagrama bien construido hace m\u00e1s que simplemente mapear interacciones; alinea a todo el equipo sobre el alcance del trabajo antes de que se escriba una sola l\u00ednea de c\u00f3digo. Esta gu\u00eda explora c\u00f3mo construir estos diagramas de forma efectiva sin depender de herramientas propietarias complejas ni metodolog\u00edas r\u00edgidas.<\/p>\n

\n
\"Line<\/figure>\n<\/div>\n

\ud83e\udd14 Por qu\u00e9 adivinar las necesidades del usuario fracasa en proyectos \u00e1giles<\/h2>\n

Las metodolog\u00edas \u00e1giles priorizan la capacidad de respuesta al cambio, pero esto no significa ignorar los requisitos. El peligro radica en la \u00abbrecha de interpretaci\u00f3n\u00bb. Cuando un Propietario de Producto describe una caracter\u00edstica verbalmente, los desarrolladores la interpretan de forma diferente que los dise\u00f1adores, y los testers de QA la interpretan de forma distinta nuevamente.<\/p>\n

    \n
  • Expectativas desalineadas:<\/strong>Sin una norma visual, \u00abinicio de sesi\u00f3n de usuario\u00bb podr\u00eda significar correo electr\u00f3nico\/contrase\u00f1a para una persona y escaneo biom\u00e9trico para otra.<\/li>\n
  • Expansi\u00f3n del alcance:<\/strong>La ambig\u00fcedad permite que los requisitos crezcan de forma org\u00e1nica durante el desarrollo, inflando el cronograma.<\/li>\n
  • Puntos ciegos en las pruebas:<\/strong>Si el flujo de interacci\u00f3n no est\u00e1 documentado, los casos extremos a menudo se pasan por alto durante las pruebas de regresi\u00f3n.<\/li>\n<\/ul>\n

    Un Diagrama de casos de uso<\/strong>act\u00faa como un lenguaje compartido. Obliga al equipo a definir qui\u00e9n hace qu\u00e9 y por qu\u00e9 antes de que comience el trabajo. Esto reduce la carga cognitiva sobre los desarrolladores, permiti\u00e9ndoles centrarse en la l\u00f3gica en lugar de descifrar la intenci\u00f3n.<\/p>\n

    \ud83d\udee0\ufe0f \u00bfQu\u00e9 es exactamente un diagrama de casos de uso?<\/h2>\n

    Un diagrama de casos de uso es un diagrama de comportamiento que representa las interacciones entre un sistema y sus actores externos. Se centra en qu\u00e9<\/em>que hace el sistema, no en c\u00f3mo<\/em>lo hace. Esta distinci\u00f3n es vital para mantener la abstracci\u00f3n necesaria en la planificaci\u00f3n de alto nivel.<\/p>\n

    Componentes principales<\/h3>\n

    Para construir un diagrama claro, debes entender los elementos est\u00e1ndar de notaci\u00f3n:<\/p>\n

      \n
    • Actores:<\/strong>Representados por figuras de palo, estos son los usuarios o sistemas externos que interact\u00faan con el software. Un actor puede ser una persona (por ejemplo, Cliente<\/em>) o bien otro sistema (por ejemplo, Pasarela de pago<\/em>).<\/li>\n
    • Casos de uso:<\/strong> Representados por \u00f3valos, estos describen un objetivo o funci\u00f3n espec\u00edfica desde la perspectiva del actor (por ejemplo, Realizar pedido<\/em>).<\/li>\n
    • L\u00edmite del sistema:<\/strong> Un cuadro que encierra los casos de uso, definiendo el alcance del software que se est\u00e1 construyendo.<\/li>\n
    • Relaciones:<\/strong> L\u00edneas que conectan actores con casos de uso, mostrando qui\u00e9n inicia la acci\u00f3n.<\/li>\n<\/ul>\n

      Cuando estos elementos se organizan correctamente, el diagrama se convierte en un mapa de las capacidades del sistema. Responde a la pregunta: \u00abSi soy esta persona, \u00bfqu\u00e9 puedo lograr con este software?\u00bb<\/p>\n

      \ud83e\udd1d La conexi\u00f3n \u00e1gil: Por qu\u00e9 los equipos necesitan esto<\/h2>\n

      Algunos equipos consideran la documentaci\u00f3n como un antipatr\u00f3n en Agile. Argumentan que el software funcional tiene m\u00e1s valor que una documentaci\u00f3n exhaustiva. Sin embargo, la documentaci\u00f3n ligera como los diagramas de casos de uso cumple una funci\u00f3n diferente. No se trata de crear un documento de especificaciones masivo; se trata de crear un modelo mental compartido<\/strong>.<\/p>\n

      Beneficios para la planificaci\u00f3n del sprint<\/h3>\n

      Cuando un equipo se sienta para la planificaci\u00f3n del sprint, a menudo tiene dificultades para descomponer grandes epics en historias manejables. Un diagrama de casos de uso ayuda a visualizar el flujo.<\/p>\n

        \n
      • Identificaci\u00f3n de historias de usuario:<\/strong> Cada caso de uso a menudo puede asignarse a una o m\u00e1s historias de usuario. Por ejemplo, el Realizar pedido<\/em> caso de uso podr\u00eda descomponerse en historias sobre agregar art\u00edculos al carrito, seleccionar el pago y confirmar la direcci\u00f3n.<\/li>\n
      • Definici\u00f3n de terminado:<\/strong> El diagrama aclara los l\u00edmites de una caracter\u00edstica. Si un requisito cae fuera del l\u00edmite del sistema, no forma parte del sprint actual.<\/li>\n
      • Sesiones de refinamiento:<\/strong> Durante la refinaci\u00f3n del backlog, el diagrama sirve como punto de referencia. Si un interesado pregunta: \u00ab\u00bfPuede el usuario cancelar el pedido despu\u00e9s del env\u00edo?\u00bb, el diagrama ayuda a verificar si esa ruta existe.<\/li>\n<\/ul>\n

        \ud83d\udcd0 Gu\u00eda paso a paso para crear diagramas claros<\/h2>\n

        Crear un diagrama desde cero puede resultar abrumador. Para mantener claridad y autoridad, sigue un proceso estructurado. Esto garantiza la consistencia entre diferentes diagramas y diferentes miembros del equipo.<\/p>\n

        Paso 1: Identificar a los actores<\/h3>\n

        Empieza listando a todas las personas que interact\u00faan con el sistema. No lo compliques demasiado. Preg\u00fantate: \u00ab\u00bfQui\u00e9n interact\u00faa con este software?\u00bb<\/p>\n

          \n
        • Actores primarios:<\/strong> Aquellos que inician la interacci\u00f3n para lograr su propio objetivo (por ejemplo, Usuario registrado<\/em>).<\/li>\n
        • Actores secundarios:<\/strong>Sistemas o servicios externos necesarios para completar la tarea (por ejemplo, Servidor de base de datos<\/em>, Servicio de correo electr\u00f3nico<\/em>).<\/li>\n<\/ul>\n

          Consejo:<\/em>Si un actor no tiene un objetivo que alcanzar, podr\u00eda no ser necesario incluirlo en el diagrama. Mant\u00e9ngalo enfocado en el valor.<\/p>\n

          Paso 2: Definir los casos de uso (objetivos)<\/h3>\n

          Para cada actor, enumere los objetivos que desean alcanzar. Utilice frases verbo-nombre para mayor claridad.<\/p>\n

            \n
          • Mal:<\/strong> \u201cIniciar sesi\u00f3n\u201d (Esta es una acci\u00f3n, no un objetivo).<\/li>\n
          • Bueno:<\/strong> \u201cAutenticar usuario\u201d o \u201cAcceder al panel de control\u201d.<\/li>\n<\/ul>\n

            Aseg\u00farese de que cada caso de uso aporte valor. Si un paso no ayuda al usuario a alcanzar su objetivo, podr\u00eda tratarse de un proceso de apoyo m\u00e1s adecuado para un diagrama de secuencia m\u00e1s adelante.<\/p>\n

            Paso 3: Dibujar el l\u00edmite del sistema<\/h3>\n

            Dibuje un cuadro alrededor de los casos de uso. Todo lo que est\u00e9 dentro forma parte de su alcance actual. Todo lo que est\u00e9 fuera es el entorno. Esto ayuda a prevenir el crecimiento del alcance durante el desarrollo.<\/p>\n

            Paso 4: Conectar actores con casos de uso<\/h3>\n

            Dibuje l\u00edneas entre los actores y los casos de uso que inician. Una l\u00ednea s\u00f3lida indica una asociaci\u00f3n. Esto muestra la relaci\u00f3n directa.<\/p>\n

            \ud83d\udd17 Comprendiendo las relaciones<\/h2>\n

            Los sistemas complejos requieren m\u00e1s que l\u00edneas simples. Para capturar la sutileza de las interacciones, utilice las siguientes relaciones.<\/p>\n

            1. Relaciones de inclusi\u00f3n<\/h3>\n

            Util\u00edcelo cuando un caso de uso debe<\/strong>llame a otro caso de uso para completar su tarea. Es una dependencia obligatoria.<\/p>\n

              \n
            • Ejemplo:<\/strong> Realizar pedido<\/em> incluye<\/strong> Procesar pago<\/em>.<\/li>\n
            • \u00bfPor qu\u00e9 usarlo:<\/strong> Reduce la repetici\u00f3n. Si Procesar pago<\/em> se utiliza en Colocar pedido<\/em>, Reembolsar pedido<\/em>, y Pre-ordenar<\/em>, solo lo defines una vez y lo enlazas.<\/li>\n<\/ul>\n

              2. Relaciones de extensi\u00f3n<\/h3>\n

              \u00dasalo para comportamientos opcionales. El caso de uso extendido solo se ejecuta bajo condiciones espec\u00edficas.<\/p>\n

                \n
              • Ejemplo:<\/strong> Colocar pedido<\/em> extiende<\/strong> Aplicar c\u00f3digo de descuento<\/em>.<\/li>\n
              • \u00bfPor qu\u00e9 usarlo:<\/strong>Mantiene el flujo principal limpio. El flujo est\u00e1ndar es simplemente el pedido; el descuento es una excepci\u00f3n o una mejora.<\/li>\n<\/ul>\n

                3. Generalizaci\u00f3n (herencia)<\/h3>\n

                \u00dasalo cuando los actores o casos de uso compartan rasgos comunes.<\/p>\n

                  \n
                • Ejemplo de actor:<\/strong> Usuario invitado<\/em> y Usuario registrado<\/em> podr\u00edan compartir ambos el Ver producto<\/em> caso de uso. Puedes generalizarlos bajo un padre Cliente<\/em> actor.<\/li>\n
                • Ejemplo de caso de uso:<\/strong> Administrador<\/em> podr\u00eda tener un general Gestionar contenido<\/em> caso de uso que incluye Editar publicaci\u00f3n<\/em> y Eliminar publicaci\u00f3n<\/em>.<\/li>\n<\/ul>\n

                  \ud83d\udcca Comparaci\u00f3n de relaciones comunes<\/h2>\n\n\n\n\n\n\n
                  Tipo de relaci\u00f3n<\/strong><\/th>\nNotaci\u00f3n<\/strong><\/th>\nSignificado<\/strong><\/th>\nCaso de uso<\/strong><\/th>\n<\/tr>\n
                  Asociaci\u00f3n<\/td>\nL\u00ednea s\u00f3lida<\/td>\nComunicaci\u00f3n b\u00e1sica<\/td>\nEl actor inicia un caso de uso<\/td>\n<\/tr>\n
                  Incluir<\/td>\nFlecha punteada (<>)<\/include><\/td>\nInclusi\u00f3n obligatoria<\/td>\nFuncionalidad compartida requerida por m\u00faltiples casos de uso<\/td>\n<\/tr>\n
                  Extender<\/td>\nFlecha punteada (<>)<\/extend><\/td>\nComportamiento opcional<\/td>\nCasos especiales o manejo de errores<\/td>\n<\/tr>\n
                  Generalizaci\u00f3n<\/td>\nFlecha de tri\u00e1ngulo s\u00f3lido<\/td>\nRelaci\u00f3n padre-hijo<\/td>\nActores o funciones especializadas que heredan rasgos<\/td>\n<\/tr>\n<\/table>\n

                  \ud83d\udea7 Errores comunes que debes evitar<\/h2>\n

                  Incluso los equipos experimentados cometen errores al modelar. Evita estos errores para mantener la claridad del diagrama.<\/p>\n

                  1. Combinar la interfaz de usuario con la l\u00f3gica<\/h3>\n

                  No dibujes botones espec\u00edficos ni dise\u00f1os de pantallas. Un diagrama de casos de uso trata sobre el comportamiento del sistema, no sobre la interfaz de usuario. Evita escribir \u00abHacer clic en el bot\u00f3n Enviar\u00bb como un caso de uso. En su lugar, utiliza \u00abEnviar formulario\u00bb.<\/p>\n

                  2. Demasiados actores<\/h3>\n

                  Si tienes m\u00e1s de 10 actores, el diagrama se vuelve ilegible. Agr\u00fapalos l\u00f3gicamente. Por ejemplo, si tienes \u00abAdministrador\u00bb, \u00abGerente\u00bb y \u00abSupervisor\u00bb, considera si pueden agruparse bajo \u00abPersonal\u00bb si sus casos de uso son id\u00e9nticos.<\/p>\n

                  3. Ignorar los sistemas externos<\/h3>\n

                  El software moderno depende en gran medida de APIs y servicios de terceros. Tr\u00e1talos como actores. Si tu sistema env\u00eda datos a un CRM, el CRM es un actor. No documentarlo conduce a fallas de integraci\u00f3n m\u00e1s adelante.<\/p>\n

                  4. Nombres de casos de uso ambiguos<\/h3>\n

                  Nombres como \u00abProcesar\u00bb o \u00abManejar\u00bb son demasiado ambiguos. Usa siempre una estructura Verbo + Sustantivo. \u00abProcesar datos\u00bb es mejor que \u00abProcesar\u00bb.<\/p>\n

                  \ud83d\udd04 Integraci\u00f3n en el flujo de trabajo \u00e1gil<\/h2>\n

                  Una vez creado el diagrama, debe estar integrado en el flujo de trabajo. No debe ser un documento est\u00e1tico guardado en una carpeta. Debe formar parte del ritmo diario.<\/p>\n

                  Durante la refinaci\u00f3n del backlog<\/h3>\n

                  Revisa el diagrama con el Propietario del Producto. Verifica que cada caso de uso tenga historias de usuario correspondientes. Si un caso de uso no tiene historias, podr\u00eda ser un requisito fantasma. Si una historia no tiene caso de uso, podr\u00eda estar fuera de alcance.<\/p>\n

                  Durante la ejecuci\u00f3n del sprint<\/h3>\n

                  Mant\u00e9n el diagrama accesible en el pizarr\u00f3n del equipo o en el espacio de trabajo digital. Cuando un desarrollador se encuentre con una ambig\u00fcedad durante la codificaci\u00f3n, consulta el diagrama. \u00bfLa ruta actual se alinea con la interacci\u00f3n definida?<\/p>\n

                  Durante las retrospectivas<\/h3>\n

                  Si el equipo descubre nuevos requisitos a mitad de sprint, actualiza el diagrama. Este registro visual ayuda a comprender c\u00f3mo evolucion\u00f3 el alcance y por qu\u00e9 se tomaron ciertas decisiones.<\/p>\n

                  \ud83d\udee1\ufe0f Manejo de la complejidad: descomposici\u00f3n de sistemas grandes<\/h2>\n

                  A medida que el software crece, un solo diagrama se vuelve imposible de leer. Esto se conoce como \u00abesparcimiento de diagramas\u00bb. Para gestionarlo, utiliza paquetes<\/strong> o subsistemas<\/strong>.<\/p>\n

                    \n
                  • Paquete 1: Gesti\u00f3n de usuarios:<\/strong> Se centra en el inicio de sesi\u00f3n, el registro y las actualizaciones de perfil.<\/li>\n
                  • Paquete 2: Procesamiento de transacciones:<\/strong> Se centra en pedidos, pagos e facturas.<\/li>\n
                  • Paquete 3: Informes:<\/strong> Se centra en funciones de an\u00e1lisis y exportaci\u00f3n.<\/li>\n<\/ul>\n

                    Enlaza estos paquetes utilizando los actores principales. Esto mantiene la vista de alto nivel limpia, al tiempo que permite vistas detalladas para dominios espec\u00edficos.<\/p>\n

                    \ud83d\udcdd T\u00e9cnicas colaborativas de diagramaci\u00f3n<\/h2>\n

                    Construir estos diagramas rara vez es una tarea solitaria. Los mejores resultados provienen de la colaboraci\u00f3n. Aqu\u00ed tienes c\u00f3mo abordarlo con el equipo.<\/p>\n

                      \n
                    • Pizarra blanca:<\/strong>Comienza con una pizarra f\u00edsica o digital. Haz que todos dibujen su comprensi\u00f3n. Compara notas.<\/li>\n
                    • Juego de roles:<\/strong>Representa el caso de uso. Una persona hace de actor, otra hace de sistema. Esto revela lagunas l\u00f3gicas que los dibujos est\u00e1ticos pasan por alto.<\/li>\n
                    • Revisi\u00f3n entre pares:<\/strong>Haz que un desarrollador revise el diagrama desde la viabilidad t\u00e9cnica. Haz que un ingeniero de QA lo revise desde la testabilidad.<\/li>\n<\/ul>\n

                      Este enfoque colaborativo garantiza que el diagrama represente un consenso, no solo la interpretaci\u00f3n de una persona.<\/p>\n

                      \ud83d\udcc8 Medici\u00f3n de la efectividad de tus diagramas<\/h2>\n

                      \u00bfC\u00f3mo sabes si el diagrama realmente est\u00e1 ayudando? Busca estos indicadores.<\/p>\n

                        \n
                      • Reducci\u00f3n de ambig\u00fcedades:<\/strong>Menos preguntas de los desarrolladores durante la codificaci\u00f3n.<\/li>\n
                      • Menos errores:<\/strong>Disminuyen los defectos relacionados con l\u00f3gica de flujo incorrecta.<\/li>\n
                      • Onboarding m\u00e1s r\u00e1pido:<\/strong>Los nuevos miembros del equipo entienden el sistema m\u00e1s r\u00e1pido cuando hay un diagrama disponible.<\/li>\n
                      • Estimaciones precisas:<\/strong>La velocidad del sprint se vuelve m\u00e1s predecible porque el alcance est\u00e1 claramente definido.<\/li>\n<\/ul>\n

                        \ud83c\udf10 El futuro de la diagramaci\u00f3n en el desarrollo de software<\/h2>\n

                        A medida que las herramientas evolucionan, los principios fundamentales permanecen iguales. Ya sea que uses una herramienta simple basada en texto, una pizarra o un entorno de modelado digital, el objetivo es la comunicaci\u00f3n. La industria se est\u00e1 moviendo hacia el desarrollo impulsado por modelos, donde el c\u00f3digo se genera a partir de modelos. Aunque esto no es est\u00e1ndar para cada equipo, la disciplina de definir casos de uso desde temprano te prepara para ese futuro.<\/p>\n

                        Incluso si nunca generas c\u00f3digo a partir de un diagrama, la acci\u00f3n de modelar obliga al pensamiento cr\u00edtico. Expone lagunas l\u00f3gicas antes de que se conviertan en errores costosos. En un contexto \u00c1gil, esta es la diferencia entre iterar sobre lo correcto y iterar sobre lo incorrecto.<\/p>\n

                        \ud83c\udfc1 Reflexiones finales sobre el dise\u00f1o centrado en el usuario<\/h2>\n

                        Construir software no se trata solo de escribir c\u00f3digo; se trata de resolver problemas para las personas. Un diagrama de casos de uso coloca a esas personas en el centro del proceso de dise\u00f1o. Recuerda al equipo que cada caracter\u00edstica existe para servir a un objetivo del actor.<\/p>\n

                        Siguiendo los pasos descritos en esta gu\u00eda, tu equipo puede dejar de adivinar y comenzar a construir con claridad. Deja de asumir que conoces lo que el usuario necesita. Dib\u00fajalo, validalo y ejec\u00fatalo con confianza.<\/p>\n

                        Recuerda, el diagrama es un artefacto vivo. Debe evolucionar junto con tu producto. Mant\u00e9n actualizado, mant\u00e9n visible y mant\u00e9n \u00fatil. Eso es lo que marca una pr\u00e1ctica de ingenier\u00eda madura.<\/p>\n

                        \ud83d\udd11 Puntos clave<\/h2>\n
                          \n
                        • Define claramente a los actores:<\/strong>Conoce a qui\u00e9n est\u00e1 interactuando con el sistema.<\/li>\n
                        • Enf\u00f3cate en los objetivos:<\/strong>Los nombres de los casos de uso deben representar los objetivos del usuario.<\/li>\n
                        • Gestiona el alcance:<\/strong>Utiliza l\u00edmites del sistema para evitar el crecimiento de funciones.<\/li>\n
                        • Colabora:<\/strong>Involucra a todo el equipo en el proceso de creaci\u00f3n.<\/li>\n
                        • Itera:<\/strong>Trata el diagrama como un documento vivo durante todo el ciclo de vida del proyecto.<\/li>\n<\/ul>\n

                          Implementar este enfoque fortalecer\u00e1 tu proceso \u00c1gil y garantizar\u00e1 que el producto final satisfaga realmente las necesidades del usuario sin adivinanzas.<\/p>\n","protected":false},"excerpt":{"rendered":"

                          En el entorno acelerado del desarrollo de software, las suposiciones son el enemigo de la entrega. Cuando los equipos adivinan lo que los usuarios realmente necesitan, las caracter\u00edsticas a menudo fallan en el blanco, lo que conduce a sprints desperdiciados y stakeholders frustrados. Es aqu\u00ed donde el Diagrama de casos de usose convierte en una herramienta esencial. Proporciona un contrato visual entre los objetivos del negocio y la implementaci\u00f3n t\u00e9cnica. Para los equipos \u00e1giles, la claridad es moneda corriente. Un diagrama bien construido hace m\u00e1s que simplemente mapear interacciones; alinea a todo el equipo sobre el alcance del trabajo antes de que se escriba una sola l\u00ednea de c\u00f3digo. Esta gu\u00eda explora c\u00f3mo construir estos diagramas de forma efectiva sin depender de herramientas propietarias complejas ni metodolog\u00edas r\u00edgidas. \ud83e\udd14 Por qu\u00e9 adivinar las necesidades del usuario fracasa en proyectos \u00e1giles Las metodolog\u00edas \u00e1giles priorizan la capacidad de respuesta al cambio, pero esto no significa ignorar los requisitos. El peligro radica en la \u00abbrecha de interpretaci\u00f3n\u00bb. Cuando un Propietario de Producto describe una caracter\u00edstica verbalmente, los desarrolladores la interpretan de forma diferente que los dise\u00f1adores, y los testers de QA la interpretan de forma distinta nuevamente. Expectativas desalineadas:Sin una norma visual, \u00abinicio de sesi\u00f3n de usuario\u00bb podr\u00eda significar correo electr\u00f3nico\/contrase\u00f1a para una persona y escaneo biom\u00e9trico para otra. Expansi\u00f3n del alcance:La ambig\u00fcedad permite que los requisitos crezcan de forma org\u00e1nica durante el desarrollo, inflando el cronograma. Puntos ciegos en las pruebas:Si el flujo de interacci\u00f3n no est\u00e1 documentado, los casos extremos a menudo se pasan por alto durante las pruebas de regresi\u00f3n. Un Diagrama de casos de usoact\u00faa como un lenguaje compartido. Obliga al equipo a definir qui\u00e9n hace qu\u00e9 y por qu\u00e9 antes de que comience el trabajo. Esto reduce la carga cognitiva sobre los desarrolladores, permiti\u00e9ndoles centrarse en la l\u00f3gica en lugar de descifrar la intenci\u00f3n. \ud83d\udee0\ufe0f \u00bfQu\u00e9 es exactamente un diagrama de casos de uso? Un diagrama de casos de uso es un diagrama de comportamiento que representa las interacciones entre un sistema y sus actores externos. Se centra en qu\u00e9que hace el sistema, no en c\u00f3molo hace. Esta distinci\u00f3n es vital para mantener la abstracci\u00f3n necesaria en la planificaci\u00f3n de alto nivel. Componentes principales Para construir un diagrama claro, debes entender los elementos est\u00e1ndar de notaci\u00f3n: Actores:Representados por figuras de palo, estos son los usuarios o sistemas externos que interact\u00faan con el software. Un actor puede ser una persona (por ejemplo, Cliente) o bien otro sistema (por ejemplo, Pasarela de pago). Casos de uso: Representados por \u00f3valos, estos describen un objetivo o funci\u00f3n espec\u00edfica desde la perspectiva del actor (por ejemplo, Realizar pedido). L\u00edmite del sistema: Un cuadro que encierra los casos de uso, definiendo el alcance del software que se est\u00e1 construyendo. Relaciones: L\u00edneas que conectan actores con casos de uso, mostrando qui\u00e9n inicia la acci\u00f3n. Cuando estos elementos se organizan correctamente, el diagrama se convierte en un mapa de las capacidades del sistema. Responde a la pregunta: \u00abSi soy esta persona, \u00bfqu\u00e9 puedo lograr con este software?\u00bb \ud83e\udd1d La conexi\u00f3n \u00e1gil: Por qu\u00e9 los equipos necesitan esto Algunos equipos consideran la documentaci\u00f3n como un antipatr\u00f3n en Agile. Argumentan que el software funcional tiene m\u00e1s valor que una documentaci\u00f3n exhaustiva. Sin embargo, la documentaci\u00f3n ligera como los diagramas de casos de uso cumple una funci\u00f3n diferente. No se trata de crear un documento de especificaciones masivo; se trata de crear un modelo mental compartido. Beneficios para la planificaci\u00f3n del sprint Cuando un equipo se sienta para la planificaci\u00f3n del sprint, a menudo tiene dificultades para descomponer grandes epics en historias manejables. Un diagrama de casos de uso ayuda a visualizar el flujo. Identificaci\u00f3n de historias de usuario: Cada caso de uso a menudo puede asignarse a una o m\u00e1s historias de usuario. Por ejemplo, el Realizar pedido caso de uso podr\u00eda descomponerse en historias sobre agregar art\u00edculos al carrito, seleccionar el pago y confirmar la direcci\u00f3n. Definici\u00f3n de terminado: El diagrama aclara los l\u00edmites de una caracter\u00edstica. Si un requisito cae fuera del l\u00edmite del sistema, no forma parte del sprint actual. Sesiones de refinamiento: Durante la refinaci\u00f3n del backlog, el diagrama sirve como punto de referencia. Si un interesado pregunta: \u00ab\u00bfPuede el usuario cancelar el pedido despu\u00e9s del env\u00edo?\u00bb, el diagrama ayuda a verificar si esa ruta existe. \ud83d\udcd0 Gu\u00eda paso a paso para crear diagramas claros Crear un diagrama desde cero puede resultar abrumador. Para mantener claridad y autoridad, sigue un proceso estructurado. Esto garantiza la consistencia entre diferentes diagramas y diferentes miembros del equipo. Paso 1: Identificar a los actores Empieza listando a todas las personas que interact\u00faan con el sistema. No lo compliques demasiado. Preg\u00fantate: \u00ab\u00bfQui\u00e9n interact\u00faa con este software?\u00bb Actores primarios: Aquellos que inician la interacci\u00f3n para lograr su propio objetivo (por ejemplo, Usuario registrado). Actores secundarios:Sistemas o servicios externos necesarios para completar la tarea (por ejemplo, Servidor de base de datos, Servicio de correo electr\u00f3nico). Consejo:Si un actor no tiene un objetivo que alcanzar, podr\u00eda no ser necesario incluirlo en el diagrama. Mant\u00e9ngalo enfocado en el valor. Paso 2: Definir los casos de uso (objetivos) Para cada actor, enumere los objetivos que desean alcanzar. Utilice frases verbo-nombre para mayor claridad. Mal: \u201cIniciar sesi\u00f3n\u201d (Esta es una acci\u00f3n, no un objetivo). Bueno: \u201cAutenticar usuario\u201d o \u201cAcceder al panel de control\u201d. Aseg\u00farese de que cada caso de uso aporte valor. Si un paso no ayuda al usuario a alcanzar su objetivo, podr\u00eda tratarse de un proceso de apoyo m\u00e1s adecuado para un diagrama de secuencia m\u00e1s adelante. Paso 3: Dibujar el l\u00edmite del sistema Dibuje un cuadro alrededor de los casos de uso. Todo lo que est\u00e9 dentro forma parte de su alcance actual. Todo lo que est\u00e9 fuera es el entorno. Esto ayuda a prevenir el crecimiento del alcance durante el desarrollo. Paso 4: Conectar actores con casos de uso Dibuje l\u00edneas entre los actores y los casos de uso que inician. Una l\u00ednea s\u00f3lida indica una asociaci\u00f3n. Esto muestra la relaci\u00f3n directa. \ud83d\udd17 Comprendiendo las relaciones Los sistemas complejos<\/p>\n","protected":false},"author":1,"featured_media":4305,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[77,87],"class_list":["post-4304","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uml","tag-academic","tag-use-case-diagram"],"yoast_head":"\nDeja de adivinar las necesidades del usuario: Diagramas de casos de uso claros para \u00c1gil<\/title>\n<meta name=\"description\" content=\"Aprende a crear diagramas de casos de uso claros para equipos \u00e1giles. Mejora el an\u00e1lisis de las necesidades del usuario y reduce el crecimiento de alcance con esta gu\u00eda completa.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/\" \/>\n<meta property=\"og:locale\" content=\"es_ES\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Deja de adivinar las necesidades del usuario: Diagramas de casos de uso claros para \u00c1gil\" \/>\n<meta property=\"og:description\" content=\"Aprende a crear diagramas de casos de uso claros para equipos \u00e1giles. Mejora el an\u00e1lisis de las necesidades del usuario y reduce el crecimiento de alcance con esta gu\u00eda completa.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/\" \/>\n<meta property=\"og:site_name\" content=\"Diagrams AI Spanish\" \/>\n<meta property=\"article:published_time\" content=\"2026-04-10T22:34:26+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.diagrams-ai.com\/es\/wp-content\/uploads\/sites\/5\/2026\/04\/use-case-diagram-agile-teams-infographic-line-art.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1664\" \/>\n\t<meta property=\"og:image:height\" content=\"928\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"vpadmin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Escrito por\" \/>\n\t<meta name=\"twitter:data1\" content=\"vpadmin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tiempo de lectura\" \/>\n\t<meta name=\"twitter:data2\" content=\"12 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/\"},\"author\":{\"name\":\"vpadmin\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\"},\"headline\":\"Deje de adivinar las necesidades del usuario: c\u00f3mo crear diagramas de casos de uso claros para equipos \u00e1giles\",\"datePublished\":\"2026-04-10T22:34:26+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/\"},\"wordCount\":2426,\"image\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/04\\\/use-case-diagram-agile-teams-infographic-line-art.jpg\",\"keywords\":[\"academic\",\"use case diagram\"],\"articleSection\":[\"UML\"],\"inLanguage\":\"es\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/\",\"name\":\"Deja de adivinar las necesidades del usuario: Diagramas de casos de uso claros para \u00c1gil\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/04\\\/use-case-diagram-agile-teams-infographic-line-art.jpg\",\"datePublished\":\"2026-04-10T22:34:26+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\"},\"description\":\"Aprende a crear diagramas de casos de uso claros para equipos \u00e1giles. Mejora el an\u00e1lisis de las necesidades del usuario y reduce el crecimiento de alcance con esta gu\u00eda completa.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/#breadcrumb\"},\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/04\\\/use-case-diagram-agile-teams-infographic-line-art.jpg\",\"contentUrl\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/wp-content\\\/uploads\\\/sites\\\/5\\\/2026\\\/04\\\/use-case-diagram-agile-teams-infographic-line-art.jpg\",\"width\":1664,\"height\":928},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/stop-guessing-user-needs-use-case-diagrams-agile\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Deje de adivinar las necesidades del usuario: c\u00f3mo crear diagramas de casos de uso claros para equipos \u00e1giles\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/#website\",\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/\",\"name\":\"Diagrams AI Spanish\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"es\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/#\\\/schema\\\/person\\\/ecc36153eaeb4aeaf895589c93d5de12\",\"name\":\"vpadmin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g\",\"caption\":\"vpadmin\"},\"sameAs\":[\"https:\\\/\\\/www.diagrams-ai.com\"],\"url\":\"https:\\\/\\\/www.diagrams-ai.com\\\/es\\\/author\\\/vpadmin\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Deja de adivinar las necesidades del usuario: Diagramas de casos de uso claros para \u00c1gil","description":"Aprende a crear diagramas de casos de uso claros para equipos \u00e1giles. Mejora el an\u00e1lisis de las necesidades del usuario y reduce el crecimiento de alcance con esta gu\u00eda completa.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/","og_locale":"es_ES","og_type":"article","og_title":"Deja de adivinar las necesidades del usuario: Diagramas de casos de uso claros para \u00c1gil","og_description":"Aprende a crear diagramas de casos de uso claros para equipos \u00e1giles. Mejora el an\u00e1lisis de las necesidades del usuario y reduce el crecimiento de alcance con esta gu\u00eda completa.","og_url":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/","og_site_name":"Diagrams AI Spanish","article_published_time":"2026-04-10T22:34:26+00:00","og_image":[{"width":1664,"height":928,"url":"https:\/\/www.diagrams-ai.com\/es\/wp-content\/uploads\/sites\/5\/2026\/04\/use-case-diagram-agile-teams-infographic-line-art.jpg","type":"image\/jpeg"}],"author":"vpadmin","twitter_card":"summary_large_image","twitter_misc":{"Escrito por":"vpadmin","Tiempo de lectura":"12 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/#article","isPartOf":{"@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/"},"author":{"name":"vpadmin","@id":"https:\/\/www.diagrams-ai.com\/es\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12"},"headline":"Deje de adivinar las necesidades del usuario: c\u00f3mo crear diagramas de casos de uso claros para equipos \u00e1giles","datePublished":"2026-04-10T22:34:26+00:00","mainEntityOfPage":{"@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/"},"wordCount":2426,"image":{"@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/#primaryimage"},"thumbnailUrl":"https:\/\/www.diagrams-ai.com\/es\/wp-content\/uploads\/sites\/5\/2026\/04\/use-case-diagram-agile-teams-infographic-line-art.jpg","keywords":["academic","use case diagram"],"articleSection":["UML"],"inLanguage":"es"},{"@type":"WebPage","@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/","url":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/","name":"Deja de adivinar las necesidades del usuario: Diagramas de casos de uso claros para \u00c1gil","isPartOf":{"@id":"https:\/\/www.diagrams-ai.com\/es\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/#primaryimage"},"image":{"@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/#primaryimage"},"thumbnailUrl":"https:\/\/www.diagrams-ai.com\/es\/wp-content\/uploads\/sites\/5\/2026\/04\/use-case-diagram-agile-teams-infographic-line-art.jpg","datePublished":"2026-04-10T22:34:26+00:00","author":{"@id":"https:\/\/www.diagrams-ai.com\/es\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12"},"description":"Aprende a crear diagramas de casos de uso claros para equipos \u00e1giles. Mejora el an\u00e1lisis de las necesidades del usuario y reduce el crecimiento de alcance con esta gu\u00eda completa.","breadcrumb":{"@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/"]}]},{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/#primaryimage","url":"https:\/\/www.diagrams-ai.com\/es\/wp-content\/uploads\/sites\/5\/2026\/04\/use-case-diagram-agile-teams-infographic-line-art.jpg","contentUrl":"https:\/\/www.diagrams-ai.com\/es\/wp-content\/uploads\/sites\/5\/2026\/04\/use-case-diagram-agile-teams-infographic-line-art.jpg","width":1664,"height":928},{"@type":"BreadcrumbList","@id":"https:\/\/www.diagrams-ai.com\/es\/stop-guessing-user-needs-use-case-diagrams-agile\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.diagrams-ai.com\/es\/"},{"@type":"ListItem","position":2,"name":"Deje de adivinar las necesidades del usuario: c\u00f3mo crear diagramas de casos de uso claros para equipos \u00e1giles"}]},{"@type":"WebSite","@id":"https:\/\/www.diagrams-ai.com\/es\/#website","url":"https:\/\/www.diagrams-ai.com\/es\/","name":"Diagrams AI Spanish","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.diagrams-ai.com\/es\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"es"},{"@type":"Person","@id":"https:\/\/www.diagrams-ai.com\/es\/#\/schema\/person\/ecc36153eaeb4aeaf895589c93d5de12","name":"vpadmin","image":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/56e0eb902506d9cea7c7e209205383146b8e81c0ef2eff693d9d5e0276b3d7e3?s=96&d=mm&r=g","caption":"vpadmin"},"sameAs":["https:\/\/www.diagrams-ai.com"],"url":"https:\/\/www.diagrams-ai.com\/es\/author\/vpadmin\/"}]}},"_links":{"self":[{"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/posts\/4304","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/comments?post=4304"}],"version-history":[{"count":0,"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/posts\/4304\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/media\/4305"}],"wp:attachment":[{"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/media?parent=4304"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/categories?post=4304"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.diagrams-ai.com\/es\/wp-json\/wp\/v2\/tags?post=4304"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}