|
|
| Line 1: |
Line 1: |
| {{Meta-bok|min=5}} | | {{Meta-bok|min=4}} |
| 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.
| | '''Nexus''' es un marco de escalado de Scrum diseñado para coordinar entre 3 y 9 equipos Scrum que trabajan juntos en un único [[Pila del producto|product backlog]] y entregan un [[Incremento|incremento integrado]] al final de cada sprint. Fue creado por Ken Schwaber y publicado por Scrum.org. Nexus extiende Scrum añadiendo la mínima estructura necesaria para gestionar las dependencias entre equipos y producir un incremento integrado utilizable. |
|
| |
|
| El nombre proviene del galés y hace referencia al concepto de que somos productos de múltiples experiencias, lugares e identidades. Snowden eligió este nombre para subrayar que el modelo no es un modelo de clasificación estático sino un reconocimiento de que los contextos tienen historia y contexto propios.
| | == Origen == |
|
| |
|
| == Los cinco dominios ==
| | Ken Schwaber, cofundador de Scrum, desarrolló Nexus a partir de la observación de que los principales problemas al escalar Scrum no eran de proceso sino de integración: múltiples equipos generando código que hay que combinar al final del sprint. La primera versión del Nexus Guide se publicó en 2015 en scrum.org. |
| === Dominio obvio (antes: "simple") ===
| |
|
| |
|
| Las relaciones causa-efecto son predecibles, repetibles y conocidas por todos. Las mejores prácticas existen y son la respuesta correcta.
| | == Estructura == |
|
| |
|
| '''Respuesta recomendada:''' percibir → categorizar → responder. Aplicar la práctica establecida.
| | === El Nexus Integration Team === |
|
| |
|
| '''Ejemplos:''' procesamiento de una factura estándar, resolución de un incidente de soporte con procedimiento documentado. | | El elemento diferencial de Nexus es el '''Nexus Integration Team''' (NIT): un equipo responsable de asegurar que el trabajo de todos los equipos Scrum se integra correctamente en cada sprint. El NIT no sustituye a los equipos: los apoya en la resolución de problemas de integración técnica. |
|
| |
|
| '''Riesgo:''' clasificar una situación como obvia cuando en realidad es complicada o compleja. La comodidad de "siempre lo hemos hecho así" puede ocultar señales de cambio.
| | Compuesto habitualmente por el Product Owner (compartido con todos los equipos), un Scrum Master y personas con habilidades técnicas de integración. Los miembros del NIT también pueden pertenecer a equipos Scrum individuales. |
|
| |
|
| === Dominio complicado === | | === Los eventos de Nexus === |
|
| |
|
| Las relaciones causa-efecto existen y son cognoscibles, pero no son evidentes para todo el mundo: se necesita análisis experto para identificarlas. Hay múltiples respuestas correctas.
| | Nexus añade eventos al ciclo Scrum estándar: |
|
| |
|
| '''Respuesta recomendada:''' percibir → analizar → responder. Consultar a expertos, analizar opciones, elegir entre buenas prácticas. | | * '''Nexus Sprint Planning:''' antes de la planificación individual de cada equipo, los equipos coordinan dependencias y seleccionan qué partes del backlog abordará cada uno. |
| | * '''Nexus Daily Scrum:''' breve sincronización diaria para representantes de los equipos, enfocada en identificar y resolver impedimentos de integración. |
| | * '''Nexus Sprint Review:''' los equipos presentan juntos el incremento integrado a los stakeholders. |
| | * '''Nexus Sprint Retrospective:''' en tres fases — representantes de todos los equipos identifican problemas de integración, cada equipo hace su retrospectiva individual, y todos juntos acuerdan acciones de mejora. |
|
| |
|
| '''Ejemplos:''' diseño de una arquitectura de software, diagnóstico médico, ingeniería estructural.
| | === El Nexus Sprint Backlog === |
|
| |
|
| '''Riesgo:''' "parálisis por análisis": el dominio complicado puede convertirse en una trampa si se busca la solución perfecta en lugar de la suficientemente buena.
| | Una vista de las historias del sprint que ayuda a visualizar dependencias entre equipos y a identificar dónde puede haber problemas de integración. |
|
| |
|
| === Dominio complejo === | | == Cuándo usar Nexus == |
|
| |
|
| Las relaciones causa-efecto solo son reconocibles a posteriori. No hay respuestas correctas predefinidas. El sistema es emergente y se comprende experimentando con él.
| | Nexus es adecuado cuando un solo Product Owner gestiona un producto que requiere más capacidad de la que puede dar un equipo Scrum. Si el producto puede descomponerse en componentes verdaderamente independientes gestionados por equipos distintos, puede no necesitarse Nexus. |
|
| |
|
| '''Respuesta recomendada:''' explorar → percibir → responder. Realizar experimentos seguros para que emerja el conocimiento y la dirección.
| | == Nexus vs. SAFe == |
|
| |
|
| '''Ejemplos:''' desarrollo de un nuevo producto digital, gestión del cambio organizativo, innovación.
| | Nexus es más ligero que [[SAFe]]: no prescribe niveles de portfolio ni de solución, no tiene roles adicionales más allá del NIT, y asume que los equipos ya conocen Scrum. Es la opción más adecuada cuando el problema es de integración técnica entre equipos, no de alineamiento estratégico a escala organizativa. |
| | |
| '''Relación con la agilidad:''' la gestión ágil de proyectos —Scrum, Kanban— es la respuesta metodológica al dominio complejo. Los sprints cortos, la inspección y adaptación continua, y la entrega iterativa son precisamente el mecanismo de "explorar → percibir → responder" que el dominio complejo requiere.
| |
| | |
| === Dominio caótico ===
| |
| | |
| No hay relaciones causa-efecto reconocibles. La situación es turbulenta y requiere acción inmediata para estabilizarla. No hay tiempo para análisis.
| |
| | |
| '''Respuesta recomendada:''' actuar → percibir → responder. Actuar para establecer orden, luego percibir el efecto y responder.
| |
| | |
| '''Ejemplos:''' una crisis grave en producción, un ciberataque en curso, una catástrofe.
| |
| | |
| === Dominio desordenado ===
| |
| | |
| No se sabe en qué dominio está la situación. Es el dominio central del diagrama y el estado de mayor riesgo: las personas interpretan la situación desde su perspectiva habitual sin cuestionar si ese encuadre es el correcto.
| |
| | |
| == Cómo usar Cynefin para elegir el enfoque de gestión ==
| |
| | |
| Cynefin no dice que la agilidad es siempre la respuesta correcta. Dice que la respuesta correcta depende del dominio:
| |
| | |
| {| class="wikitable"
| |
| |-
| |
| ! Dominio !! Enfoque de gestión !! Por qué
| |
| |-
| |
| | Obvio || Gestión predictiva, procesos estándar || Las mejores prácticas existen y deben seguirse
| |
| |-
| |
| | Complicado || Gestión predictiva con análisis experto || Se pueden planificar soluciones con conocimiento suficiente
| |
| |-
| |
| | Complejo || Gestión evolutiva (Scrum, Kanban) || Se necesita experimentación iterativa para descubrir la solución
| |
| |-
| |
| | Caótico || Respuesta de crisis, liderazgo directivo || No hay tiempo para análisis; hay que actuar y estabilizar
| |
| |}
| |
| | |
| == Cynefin y la IA ==
| |
| | |
| La IA generativa introduce una nueva fuente de complejidad en los dominios de Cynefin: las interacciones entre personas, sistemas y agentes de IA en proyectos reales tienen efectos emergentes que no pueden predecirse desde el inicio. Esto sitúa muchos proyectos de desarrollo con IA en el dominio complejo, reforzando la pertinencia de un enfoque ágil de experimentación iterativa corta.
| |
|
| |
|
| == Error frecuente == | | == Error frecuente == |
|
| |
|
| <div class="bok-aviso"> | | <div class="bok-aviso"> |
| '''Usar Cynefin para justificar agilidad en todos los contextos.''' Cynefin es una herramienta para elegir el enfoque correcto, no para defender el enfoque preferido. Un proyecto de integración de un ERP con requisitos completamente definidos y experiencia previa puede estar en el dominio complicado: necesita análisis experto y planificación rigurosa, no sprints de dos semanas. Cynefin desafía tanto al directivo que aplica siempre gestión predictiva como al agilista que aplica siempre Scrum. | | '''Usar Nexus sin resolver primero las dependencias técnicas entre equipos.''' Nexus gestiona las dependencias; no las elimina. Si el diseño del sistema hace que los equipos estén muy acoplados entre sí, el Nexus Daily Scrum y el NIT estarán constantemente ocupados resolviendo bloqueos. Invertir en arquitectura que reduzca las dependencias entre equipos es más productivo que añadir eventos de coordinación sobre un sistema altamente acoplado. |
| </div> | | </div> |
|
| |
|
| == Referencias == | | == Referencias == |
|
| |
|
| * Snowden, David J.; Boone, Mary E. (2007). "A Leader's Framework for Decision Making". ''Harvard Business Review'', noviembre 2007. | | * Schwaber, Ken; Caña, Patricia. (2021). ''The Nexus Guide''. Scrum.org. [https://www.scrum.org/resources/nexus-guide nexusguide.org]. |
|
| |
|
| == Véase también == | | == Véase también == |
|
| |
|
| <div class="bok-tags"> | | <div class="bok-tags"> |
| [[Agilidad]] [[Gestión evolutiva]] [[Gestión predictiva]] [[Espiral de conocimiento]] [[Scrum estándar: componentes y marco]] [[Mapa de metodologías]] | | [[SAFe]] [[Modelos de escalado ágil]] [[Modelo Spotify]] [[Scrum estándar: componentes y marco]] [[Sprint]] [[Integración continua]] |
| </div> | | </div> |
|
| |
|
| Line 97: |
Line 64: |
| [[Category:Glosario de términos]] | | [[Category:Glosario de términos]] |
| [[Category:Marcos y modelos]] | | [[Category:Marcos y modelos]] |
| | [[Category:Escalado ágil]] |