Jump to content

New pages

New pages
Hide registered users | Hide bots | Show redirects
(newest | oldest) View ( | older 50) (20 | 50 | 100 | 250 | 500)

20 May 2026

  • 11:2011:20, 20 May 2026 Dimensión operativa (hist | edit) [5,613 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} La '''dimensión operativa''' es el ámbito de una organización que produce los productos o servicios de la compañía. En el marco AgiLevel de Scrum Manager, es una de las tres dimensiones que se evalúan para medir la madurez ágil de una organización, junto con la dimensión organizativa y el soporte. La dimensión operativa agrupa los principios que describen cómo trabajan los equipos en su...")
  • 11:1911:19, 20 May 2026 Dunning-Kruger (hist | edit) [4,005 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} El '''efecto Dunning-Kruger''' es un sesgo cognitivo por el cual las personas con un nivel de competencia limitado en un dominio tienden a sobreestimar su habilidad, mientras que las personas con alta competencia tienden a subestimarla. Fue descrito por los psicólogos David Dunning y Justin Kruger en un estudio de 1999 en la Universidad de Cornell. El efecto se produce porque la competencia para evaluar la propia habilidad en un d...")
  • 11:1811:18, 20 May 2026 Modelo SCARF (hist | edit) [4,625 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} El '''modelo SCARF''' es un marco de neurociencia social desarrollado por David Rock en 2008 que identifica cinco dominios de amenaza y recompensa social que el cerebro procesa con la misma intensidad que las amenazas y recompensas físicas: '''S'''tatus (estatus), '''C'''ertainty (certeza), '''A'''utonomy (autonomía), '''R'''elatedness (relación) y '''F'''airness (equidad). Comprender estos dominios ayuda a diseñar entornos y dinámicas de equipo q...")
  • 11:1711:17, 20 May 2026 Ventana de Johari (hist | edit) [3,706 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} La '''Ventana de Johari''' es un modelo psicológico que representa las distintas áreas de autoconocimiento y conocimiento interpersonal de una persona dentro de un grupo. Fue desarrollado por los psicólogos Joseph Luft y Harry Ingham en 1955 (el nombre combina sus nombres de pila: Jo-Harry). En contextos de equipos ágiles, se usa como herramienta de coaching y desarrollo para mejorar la comunicación, la confianza y la retroalimentación. == Las c...")
  • 11:1611:16, 20 May 2026 Conway's Law (hist | edit) [3,650 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} La '''Ley de Conway''' (''Conway's Law'') es una observación formulada por Melvin Conway en 1967 que establece que las organizaciones que diseñan sistemas están inevitablemente condicionadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones. En palabras sencillas: la arquitectura del software tiende a reflejar la estructura organizativa del equipo que lo construye. Conway publicó la observación en el...")
  • 11:1611:16, 20 May 2026 Theory of Constraints (hist | edit) [3,907 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} La '''Teoría de las Restricciones''' (TOC, del inglés ''Theory of Constraints'') es un marco de gestión desarrollado por Eliyahu Goldratt que sostiene que cualquier sistema tiene al menos una restricción que limita su rendimiento global, y que la mejora del sistema debe concentrarse en identificar y gestionar esa restricción. El rendimiento del sistema no está determinado por la suma de sus partes, sino por su eslabón más débil. Goldratt pres...")
  • 11:1511:15, 20 May 2026 Cuello de botella (hist | edit) [3,464 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} Un '''cuello de botella''' (''bottleneck'' en inglés) es el punto de un sistema o proceso donde la capacidad de procesamiento es menor que la demanda que recibe, causando una acumulación de trabajo pendiente que ralentiza o bloquea el flujo del sistema completo. En gestión ágil, el cuello de botella es la restricción que limita la velocidad del equipo o la frecuencia de entrega. El concepto proviene de la manufactura lean y e...")
  • 11:1211:12, 20 May 2026 Bienestar corporativo (hist | edit) [4,339 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} El '''bienestar corporativo''' (''corporate well-being'' en inglés) es el conjunto de condiciones, prácticas y valores que aseguran que las personas puedan desarrollarse en un entorno laboral saludable y sostenible. En el contexto de la agilidad organizativa, el bienestar no se limita a beneficios o iniciativas puntuales de recursos humanos: incluye la seguridad psicológica, la confianza, la autonomía y la percepción de...")
  • 11:1211:12, 20 May 2026 Pensamiento sistémico (hist | edit) [4,470 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} El '''pensamiento sistémico''' es la disciplina de ver las situaciones y problemas como parte de un sistema interconectado de causas y efectos, en lugar de como fenómenos aislados. En lugar de buscar una causa única para un problema, el pensamiento sistémico examina los bucles de retroalimentación, las interdependencias y los efectos a largo plazo que producen el comportamiento del sistema como un todo. El término fue popularizado por Peter Seng...")
  • 11:0911:09, 20 May 2026 Journey map (hist | edit) [3,495 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} Un '''journey map''' (mapa del viaje del usuario o mapa de la experiencia) es una representación visual que describe la secuencia de pasos, pensamientos y emociones que atraviesa una persona al interactuar con un producto, servicio u organización para alcanzar un objetivo. Muestra la experiencia completa desde la perspectiva del usuario, no desde la perspectiva de los departamentos o funcionalidades del producto. == Estructura típica == Un journey...")
  • 11:0811:08, 20 May 2026 Card sorting (hist | edit) [3,701 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} El '''card sorting''' (clasificación de tarjetas) es una técnica de investigación de arquitectura de información en la que se pide a los usuarios que agrupen y etiqueten conceptos, funcionalidades o contenidos escritos en tarjetas, según su propio criterio mental. Su objetivo es entender cómo los usuarios categorizan la información para diseñar navegaciones, menús y estructuras de producto que sean intuitivas para ellos. == Por qué existe ==...")
  • 11:0711:07, 20 May 2026 Think-aloud protocol (hist | edit) [3,823 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} El '''think-aloud protocol''' (protocolo de pensamiento en voz alta) es una técnica de investigación de usabilidad en la que se pide al usuario que verbalice sus pensamientos, percepciones y decisiones de forma continua mientras realiza una tarea con el producto. El investigador escucha sin intervenir, registrando los razonamientos del usuario para entender cómo interpreta la interfaz y qué le resulta confuso, intuitivo o frustrante. La técnica f...")
  • 11:0611:06, 20 May 2026 Gains (hist | edit) [3,314 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=2}} Los '''gains''' (ganancias o beneficios) son los resultados positivos, beneficios y aspiraciones que un usuario espera obtener al usar un producto o servicio. En el marco del Mapa de empatía 2.0 y el Value Proposition Canvas, los gains representan lo que haría feliz al usuario: desde los resultados mínimos esperados hasta los beneficios que le sorprenderían positivamente. Los gains son complementarios a los pains: mi...")
  • 11:0411:04, 20 May 2026 Pains (hist | edit) [3,168 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=2}} Los '''pains''' (dolores o frustraciones) son los obstáculos, dificultades, riesgos y emociones negativas que un usuario experimenta al intentar completar una tarea o alcanzar un objetivo. En el marco del Mapa de empatía 2.0 y el Value Proposition Canvas, los pains representan todo aquello que hace la experiencia del usuario difícil, frustrante o incompleta. Los pains son uno de los tres elementos del Mapa de empatía 2.0 que c...")
  • 11:0311:03, 20 May 2026 Shadowing (hist | edit) [3,459 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} El '''shadowing''' (observación sombra) es una técnica de investigación cualitativa en la que el investigador sigue a un usuario en su contexto natural sin intervenir, observando cómo interactúa con un producto, servicio o entorno en la vida real. El término evoca la imagen de seguir a alguien como una sombra: presente pero sin influir en el comportamiento observado. Es una de las tres técnicas de observación directa descritas en el contexto d...")
  • 11:0211:02, 20 May 2026 Mapa de empatía (hist | edit) [4,002 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} El '''mapa de empatía''' es una herramienta visual que sintetiza lo que el equipo sabe sobre un usuario: qué piensa y siente, qué ve, qué oye, qué dice y hace, qué le motiva y qué le frena. Su objetivo es desarrollar una comprensión compartida y profunda del usuario que vaya más allá de los datos demográficos o los perfiles superficiales. Fue desarrollado por Dave Gray (XPLANE) y es una herramienta habitual en la fase de empatía del Desi...")
  • 11:0011:00, 20 May 2026 User persona (hist | edit) [3,935 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} Una '''user persona''' (persona de usuario) es una representación ficticia pero realista de un tipo de usuario del producto, construida a partir de observaciones, entrevistas y datos cualitativos recogidos durante la investigación con usuarios reales. No es un arquetipo estadístico ni un perfil demográfico: es una descripción narrativa de un usuario específico —con nombre, contexto, motivaciones y frustraciones— que hace tangible al usuario d...")
  • 10:4210:42, 20 May 2026 Sesgo cognitivo (hist | edit) [4,562 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} Un '''sesgo cognitivo''' es un patrón sistemático de desviación del pensamiento racional que afecta a las decisiones y juicios de las personas. No son errores aleatorios: son atajos mentales (heurísticas) que el cerebro usa para procesar información de forma eficiente, pero que en determinados contextos producen conclusiones incorrectas de forma predecible. En gestión ágil de producto y equipos, los sesgos cognitivos son especialmente relevante...")
  • 10:4210:42, 20 May 2026 Perspective pause (hist | edit) [4,074 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=2}} La '''perspective pause''' (pausa de perspectiva) es una técnica de facilitación breve —entre 5 y 15 minutos— que invita a los participantes de una reunión a detenerse y considerar deliberadamente la situación desde el punto de vista de otros stakeholders antes de tomar una decisión o continuar un debate. Actúa como antídoto al pensamiento en grupo y a los puntos ciegos colectivos. == Cómo aplicarla == # El facilitador detiene la conversa...")
  • 10:4010:40, 20 May 2026 Burnout (hist | edit) [4,052 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} El '''burnout''' (agotamiento profesional o síndrome de estar quemado) es un estado de agotamiento físico, emocional y mental causado por una exposición prolongada a situaciones de trabajo estresantes o sobreexigentes. La Organización Mundial de la Salud lo reconoció en 2019 como un fenómeno laboral en su Clasificación Internacional de Enfermedades (CIE-11), caracterizado por tres dimensiones: sentimiento de agotamiento de energía o extenuació...")
  • 10:3810:38, 20 May 2026 Antipatrones (hist | edit) [4,694 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} Un '''antipatrón''' (''antipattern'' en inglés) es una respuesta habitual a un problema recurrente que parece razonable pero que en la práctica produce consecuencias negativas. A diferencia de los errores, los antipatrones son soluciones que alguien ha adoptado conscientemente —y que incluso han funcionado en el corto plazo— pero que generan problemas mayores a medida que escalan o el tiempo avanza. El término fue acuñado por Andrew Koenig en...")
  • 10:3610:36, 20 May 2026 Dual-track discovery & delivery (hist | edit) [4,162 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} El '''dual-track discovery & delivery''' (también llamado dual-track agile) es un modelo de organización del trabajo de producto que ejecuta simultáneamente dos flujos paralelos: un '''track de discovery''' que investiga y valida oportunidades de producto, y un '''track de delivery''' que construye e implementa lo ya validado. Ambos coexisten en el tiempo y se alimentan mutuamente. Fue articulado por Marty Cagan y Jeff Patton entre otros, y sistema...")
  • 10:3510:35, 20 May 2026 Gobernanza de IA (hist | edit) [4,319 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} La '''gobernanza de IA''' (''AI governance'' en inglés) es el conjunto de políticas, procesos y mecanismos de supervisión que determinan cómo un equipo u organización usa, controla y rinde cuentas del uso de herramientas de inteligencia artificial. Define qué puede hacer la IA de forma autónoma, en qué condiciones, con qué recursos, y quién es responsable de su output. A medida que los equipos ágiles incorporan agentes de IA en sus flujos d...")
  • 10:0810:08, 20 May 2026 Double-Track (hist | edit) [4,621 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} El '''doble carril''' (''Double-Track'' en inglés) es un modelo de trabajo con dos velocidades simultáneas para equipos que desarrollan software con herramientas de IA generativa. Define dos modos operativos diferenciados: un '''carril rápido''' orientado a la exploración y validación de hipótesis mediante vibe coding, y un '''carril robusto''' orientado a la construcción de código de producción con estándares completos median...")
  • 10:0710:07, 20 May 2026 Prompt library (hist | edit) [3,794 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} Una '''prompt library''' o '''biblioteca de prompts''' es una colección curada de prompts reutilizables, organizados por tipo de tarea, que un equipo mantiene y comparte para garantizar consistencia en la calidad de los outputs de IA y reducir el tiempo de diseño de prompts para tareas recurrentes. == Por qué un equipo necesita una biblioteca == Cuando los miembros de un equipo trabajan con IA de forma individual y ad hoc, c...")
  • 10:0610:06, 20 May 2026 Context engineering (hist | edit) [4,352 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} El '''context engineering''' (ingeniería de contexto) es la disciplina de diseñar y gestionar de forma deliberada la información que se proporciona a un modelo de lenguaje en su ventana de contexto para maximizar la calidad y relevancia de sus respuestas. Va más allá del prompt engineering individual: se ocupa de qué información persiste entre interacciones, cómo se organiza, qué se prioriza y qué se descarta. Si el pr...")
  • 09:4909:49, 20 May 2026 Behavior-Driven Development (hist | edit) [4,824 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} El '''Behavior-Driven Development''' (BDD, desarrollo guiado por comportamiento) es una extensión de Test-Driven Development que traslada el foco de las pruebas técnicas al comportamiento esperado del sistema desde la perspectiva del usuario de negocio. Las pruebas se escriben en lenguaje natural estructurado —comprensible para personas no técnicas— antes de que el código exista, siguiendo el formato '''Given/When/Then''' (dado/cuando/e...")
  • 09:4809:48, 20 May 2026 Entrega continua (hist | edit) [3,869 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} La '''entrega continua''' (''Continuous Delivery'' o CD en inglés) es la práctica que mantiene el código siempre en un estado que puede desplegarse a producción de forma segura, rápida y repetible a través de un pipeline automatizado de build, pruebas y despliegue. A diferencia del despliegue continuo, el despliegue final a producción es una decisión humana, no automática. Fue sistematizada por Jez Humble y David Farley en ''Continuous Delive...")
  • 09:4609:46, 20 May 2026 Servant leadership (hist | edit) [3,283 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} El '''liderazgo servil''' (''Servant leadership'' en inglés) es un modelo de liderazgo en el que el líder prioriza las necesidades del equipo y lo apoya para que pueda hacer su trabajo de la mejor manera posible, en lugar de ejercer autoridad descendente para dirigir y controlar. El líder sirve al equipo; no al revés. El término fue acuñado por Robert K. Greenleaf en su ensayo "The Servant as Leader" (1970). En el contexto ágil, el Scrum Mast...")
  • 09:4509:45, 20 May 2026 North Star Metric (hist | edit) [3,105 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} La '''North Star Metric''' (NSM, "métrica estrella polar") es la métrica única que mejor captura el valor central que el producto entrega a sus usuarios y que, cuando crece de forma sostenida, predice el crecimiento a largo plazo del negocio. Es la estrella que orienta las decisiones de producto: si una iniciativa no contribuye a moverla, su prioridad debería cuestionarse. El concepto fue popularizado por Sean Ellis (GrowthHackers). Responde a la...")
  • 09:4409:44, 20 May 2026 Feature factory (hist | edit) [3,524 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} Una '''feature factory''' (fábrica de features) es una organización de producto que mide el éxito por la velocidad y el volumen de funcionalidades entregadas, no por el impacto que esas funcionalidades generan en los usuarios o en el negocio. Es uno de los antipatrones más habituales y dañinos en el desarrollo de producto digital. El término fue popularizado por John Cutler en 2016 para describir la dinámica en la que los equipos están tan ocu...")
  • 09:4309:43, 20 May 2026 Jobs to Be Done (hist | edit) [3,993 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} '''Jobs to Be Done''' (JTBD, "trabajos a realizar") es un marco para entender por qué las personas contratan productos o servicios. En lugar de preguntar "¿quién es nuestro usuario?" o "¿qué funcionalidades quiere?", JTBD pregunta "¿qué trabajo está intentando hacer esta persona?". El foco se desplaza del perfil del usuario a la motivación que lo impulsa a buscar una solución. El marco fue desarrollado principalmente por Clayton Christensen...")
  • 09:4209:42, 20 May 2026 Product discovery (hist | edit) [4,280 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} El '''product discovery''' (descubrimiento de producto) es el proceso continuo de investigar, validar y aprender sobre los problemas de los usuarios y las oportunidades de negocio antes de comprometer recursos en la construcción de una solución. Su objetivo no es definir qué construir: es reducir la incertidumbre sobre si lo que se va a construir merece construirse. El término fue popularizado por Marty Cagan (''Inspired'', 2017) y Teresa Torres (...")
  • 09:4109:41, 20 May 2026 Agentic AI (hist | edit) [4,749 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} La '''IA agéntica''' (''Agentic AI'' en inglés) es la capacidad de un sistema de inteligencia artificial para actuar de forma autónoma hacia un objetivo, tomando decisiones secuenciales, usando herramientas externas y adaptando su comportamiento en función de los resultados intermedios. A diferencia de un modelo de lenguaje que responde a una sola pregunta, un agente de IA puede planificar, ejecutar múltiples pasos y persistir hasta completar una...")
  • 09:4009:40, 20 May 2026 Human-in-the-loop (hist | edit) [3,701 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} Los términos '''Human-in-the-loop''' (HITL) y '''Human-on-the-loop''' (HOTL) describen dos modelos de supervisión humana en sistemas de inteligencia artificial que difieren en el grado de autonomía del agente y en el tipo de intervención que realiza la persona. Ambos describen la posición de la persona en el ciclo de decisión de un sistema de IA. == Human-in-the-loop (HITL) == La persona está '''dentro del bucle''': el sistema no puede complet...")
  • 09:3909:39, 20 May 2026 Alucinación de IA (hist | edit) [5,067 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} La '''alucinación de IA''' (''AI hallucination'' en inglés) es el fenómeno por el cual un modelo de lenguaje genera información falsa, incorrecta o inventada presentándola con la misma confianza y fluidez que la información correcta. El modelo no "sabe" que está equivocado: produce lo más probable estadísticamente, aunque sea incorrecto. A diferencia de un error de programación clásico, que produce un resultado incorrecto de forma predecibl...")
  • 09:3609:36, 20 May 2026 Integración continua (hist | edit) [5,220 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} La '''integración continua''' (''Continuous Integration'' o CI en inglés) es la práctica de integrar los cambios de código de todos los miembros del equipo en la rama principal del repositorio varias veces al día, validando cada integración mediante una suite de pruebas automatizadas. Su objetivo es detectar los problemas de integración de forma temprana, cuando son pequeños y fáciles de resolver, en lugar de acumularlos hasta el final del des...")
  • 09:3309:33, 20 May 2026 Scrum Guide (hist | edit) [3,121 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=3}} La '''Scrum Guide''' (Guía de Scrum) es el documento oficial que define el marco de Scrum: sus roles, eventos, artefactos y las reglas que los conectan. Es mantenida por Ken Schwaber y Jeff Sutherland, los creadores de Scrum, y se publica de forma gratuita en [https://scrumguides.org scrumguides.org]. Es la referencia normativa del marco estándar de Scrum. == Historia y versiones == La Scrum Guide no ha existido siempre. Scrum fue descrito por pri...")
  • 09:3109:31, 20 May 2026 Seguridad psicológica (hist | edit) [5,649 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} La '''seguridad psicológica''' es la creencia compartida por los miembros de un equipo de que no serán castigados ni humillados por expresar ideas, preguntas, preocupaciones o errores. Es la condición que permite a las personas hablar con honestidad, asumir riesgos y aprender de los fallos sin miedo a consecuencias negativas. El término fue acuñado por la investigadora Amy Edmondson (Harvard Business School) en 1999 y popularizado por el proyecto...")
  • 09:2809:28, 20 May 2026 DevOps (hist | edit) [5,620 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} '''DevOps''' es un conjunto de prácticas, herramientas y una filosofía cultural que integra el desarrollo de software (''Development'') y las operaciones de sistemas (''Operations'') para mejorar la capacidad de una organización de entregar aplicaciones y servicios a alta velocidad con calidad y fiabilidad. El término fue popularizado por Patrick Debois en 2009 a partir de la primera DevOpsDays conference en Gante (Bélgica). == Origen == La sepa...")
  • 09:2609:26, 20 May 2026 Marco Cynefin (hist | edit) [6,401 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} El '''marco Cynefin''' (pronunciado "ku-NEV-in", del galés: "hábitat") es un modelo de toma de decisiones desarrollado por Dave Snowden en IBM en 1999 que ayuda a las personas y organizaciones a entender el tipo de situación a la que se enfrentan y, desde ahí, elegir la respuesta más adecuada. Clasifica los contextos en cinco dominios según la relación entre causa y efecto. El nombre proviene del galés y hace referencia al concepto de que somo...")
  • 09:2509:25, 20 May 2026 Nexus (hist | edit) [4,587 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} El '''marco Cynefin''' (pronunciado "ku-NEV-in", del galés: "hábitat") es un modelo de toma de decisiones desarrollado por Dave Snowden en IBM en 1999 que ayuda a las personas y organizaciones a entender el tipo de situación a la que se enfrentan y, desde ahí, elegir la respuesta más adecuada. Clasifica los contextos en cinco dominios según la relación entre causa y efecto. El nombre proviene del galés y hace referencia al concepto de que somo...")
  • 09:1909:19, 20 May 2026 SAFe (hist | edit) [4,749 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} <div class="bok-def"> '''SAFe''' (''Scaled Agile Framework'') es el marco de escalado ágil más adoptado en la industria. Proporciona una guía de principios, roles, eventos y artefactos para aplicar los valores ágiles y lean en organizaciones con múltiples equipos. Fue creado por Dean Leffingwell y publicado en 2011. </div> == Origen == Dean Leffingwell, autor de ''Agile Software Requirements'' (2011), desarrolló SAFe a partir de su experiencia...")
  • 09:1509:15, 20 May 2026 OKR (hist | edit) [9,936 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=6}} <div class="bok-def"> Los '''OKR''' (''Objectives and Key Results'', objetivos y resultados clave) son un sistema de definición y seguimiento de objetivos que conecta la dirección estratégica de una organización con el trabajo concreto de sus equipos. Cada OKR tiene dos componentes: un '''objetivo''' cualitativo e inspirador que describe qué se quiere lograr, y entre dos y cuatro '''resultados clave''' (KR) medibles que definen cómo se sabrá si...")

19 May 2026

  • 17:4417:44, 19 May 2026 IA como teammate (hist | edit) [22,626 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} <div class="bok-def"> '''IA como teammate''' es un enfoque para integrar la inteligencia artificial en equipos de trabajo como colaborador operativo, no como herramienta pasiva ni como sustituto de la responsabilidad humana. Implica gestionar modelos, contexto, prompts y gobernanza para que la IA pueda aportar valor de forma útil, verificable y alineada con el equipo. </div> La expresión “IA como teammate” no significa que la inteligencia artif...")
  • 17:4217:42, 19 May 2026 Prompt engineering (hist | edit) [18,669 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} <div class="bok-def"> ''Prompt engineering'' es la práctica de diseñar, probar y mejorar instrucciones para que un modelo o agente de IA produzca resultados útiles, consistentes y verificables. En equipos ágiles, no consiste en encontrar una “frase mágica”, sino en convertir una intención de trabajo en una instrucción clara, contextualizada y revisable. </div> El prompt engineering se ha vuelto una competencia básica para...")
  • 17:3817:38, 19 May 2026 Agente de IA (hist | edit) [16,191 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} <div class="bok-def"> Un '''agente de IA''' es un sistema basado en inteligencia artificial capaz de ejecutar tareas con cierto grado de autonomía a partir de instrucciones, contexto, herramientas y mecanismos de control. En equipos ágiles con IA, un agente no sustituye la responsabilidad humana: actúa como colaborador operativo bajo supervisión, límites y criterios de verificación definidos por el equipo. </div> Un agente de IA no es simplemen...")
  • 17:3317:33, 19 May 2026 Vibe engineering (hist | edit) [13,354 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} <div class="bok-def"> ''Vibe engineering'' es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante vibe coding, se convierte en software mantenible, seguro y liberable mediante Spec-Driven Development, revisión humana, pruebas, QA y una Definition of Done reforzada. </div> Vibe engineering es el complemento del vibe coding. Mientras e...")
  • 17:2717:27, 19 May 2026 Vibe coding (hist | edit) [15,004 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=4}} ''Vibe coding'' es una forma de desarrollo asistido por IA en la que una persona describe en lenguaje natural lo que quiere construir, el agente de IA genera código y el resultado se va ajustando mediante conversación, pruebas y correcciones sucesivas. Es útil para exploración rápida y prototipos, pero no debe confundirse con ingeniería de producción. El término fue popularizado por Andrej Karpathy en febrero de 2025 para desc...")
  • 17:2117:21, 19 May 2026 Spec-Driven Development (SDD) (hist | edit) [15,012 bytes] Mberne (talk | contribs) (Created page with "{{Meta-bok|min=5}} <div class="bok-def"> ''Spec-Driven Development'' (SDD), o desarrollo dirigido por especificación, es una forma de organizar el desarrollo asistido por IA en la que una spec precede y guía la implementación. En lugar de pedir código directamente a un agente de IA, el equipo define primero qué debe construirse, bajo qué restricciones y con qué criterios de verificación. </div> Spec-Driven Development surge como respue...")
(newest | oldest) View ( | older 50) (20 | 50 | 100 | 250 | 500)