Técnicas

Las organizaciones adoptan activamente pensamiento de producto de datos como práctica estándar para gestionar activos de datos. Este enfoque trata los datos como un producto con su propio ciclo de vida, estándares de calidad y un enfoque en conocer las necesidades del consumidor. Ahora lo recomendamos como la elección predeterminada para la gestión de datos, independientemente de si las organizaciones eligen arquitecturas como data mesh o lakehouse.

Enfatizamos la orientación al consumidor en el pensamiento de producto de datos para impulsar un mayor adopción y generación de valor. Esto significa diseñar productos de datos trabajando desde los casos de uso hacia atrás. También nos enfocamos en capturar y gestionar tanto metadatos relevantes del negocio como metadatos técnicos usando catálogos de datos modernos como DataHub, Collibra, Atlan e Informatica. Estas prácticas mejoran el descubrimiento y usabilidad de los datos. Adicionalmente, aplicamos el pensamiento de producto de datos para escalar iniciativas de IA y crear datos listos para IA. Este enfoque incluye una gestión integral del ciclo de vida, asegurando que los datos no solo estén bien gobernados y sean de alta calidad, sino que también se retiren en cumplimiento con los requisitos legales y regulatorios cuando ya no sean necesarios.

Fuzz testing , o simplemente fuzzing, es una técnica de pruebas que ha existido durante mucho tiempo, pero sigue siendo una de las técnicas menos conocidas. El objetivo es proporcionar a un sistema de software todo tipo de entradas inválidas y observar su comportamiento. Para un endpoint HTTP, por ejemplo, las solicitudes incorrectas deberían resultar en errores 4xx, pero el fuzz testing a menudo provoca errores 5xx o peores. Bien documentado y soportado por herramientas, el fuzz testing es más relevante que nunca con mayor cantidad de código generado por IA y Complacencia con el código generado por IA. Esto significa que ahora es un buen momento para adoptar el fuzz testing y asegurar que el código siga siendo robusto y seguro.

Desde nuestro primer blip sobre Software Bill of Materials (SBOM) en 2021, la generación de SBOM ha pasado de ser una práctica emergente a una práctica por defecto en nuestros proyectos. El ecosistema ha madurado significativamente, ofreciendo un conjunto de herramientas robusto y una integración fluida con CI/CD. Herramientas como Syft, Trivy y Snyk permiten la generación integral de SBOM, desde el código fuente hasta las imágenes de contenedores, además de escaneo de vulnerabilidades. Plataformas como FOSSA y Chainloop mejoran la gestión de riesgos de seguridad al integrarse con los flujos de desarrollo y reforzar políticas de seguridad. Aunque un estándar universal para SBOM sigue en evolución, el amplio soporte para SPDX y CycloneDX ha reducido los desafíos de adopción. Los sistemas de IA también requieren SBOM, como lo demuestran el AI Cyber Security Code of Practice del gobierno del Reino Unido y el AI Cybersecurity Collaboration Playbook de CISA. Seguiremos monitoreando los avances en este ámbito.

En el panorama en rápida evolución del desarrollo de software impulsado por IA, el modelado de amenazas es más crucial que nunca para crear software seguro, manteniendo la agilidad y evitando el security sandwich. El modelado de amenazas; un conjunto de técnicas para identificar y clasificar potenciales amenazas, se aplica en diversos contextos, incluyendo aplicaciones de IA generativa, que introducen riesgos de seguridad únicos. Para que sea eficaz, debe realizarse con frecuencia a lo largo del ciclo de vida del software y funciona mejor junto con otras prácticas de seguridad. Entre ellas se incluye la definición de requisitos de seguridad interfuncionales para abordar riesgos comunes en las tecnologías del proyecto y el aprovechamiento de escáneres de seguridad automatizados para monitoreo continuo.

Tratar APIs como producto significa priorizar la experiencia del desarrollador(a), no sólo mediante un diseño razonable y estandarizado de dichas APIs sino también proporcionando una documentación completa y una experiencia de onboarding fluida. Aunque las especificaciones de OpenAPI (Swagger) pueden documentar interfaces de APIs de manera efectiva, el onboarding continúa siendo un desafío. Los desarrolladores(as) necesitan acceso rápido a ejemplos funcionales, con autenticación pre-configurada y datos de prueba realistas. Con la evolución de herramientas de clientes API (como Postman, Bruno e Insomnia), recomendamos tratar las colecciones de peticiones API como artefactos del producto API. Las colecciones de peticiones API deben ser diseñadas cuidadosamente para guiar a los desarrolladores(as) a través de flujos de trabajo clave, ayudándoles a comprender el lenguaje y funcionalidad del dominio de la API con el mínimo esfuerzo. Para mantener estas colecciones actualizadas, recomendamos almacenarlas en un repositorio e integrarlas dentro del pipeline de despliegue de la API.

Uno de los retos constantes en equipos grandes de software es determinar quién toma las decisiones arquitectónicas que dan forma a la evolución de los sistemas. El informe State of DevOps report revela que el enfoque tradicional de las Juntas de Revisión de Arquitectura es contraproducente, y a menudo obstaculiza el flujo de trabajo y se correlaciona con un bajo rendimiento organizacional. Una alternativa convincente es architectural advice process — un enfoque descentralizado donde cualquiera puede tomar una decisión arquitectónica, siempre que busque asesoramiento de los afectados y de aquellos con experiencia relevante. Este método permite a los equipos optimizar el flujo sin comprometer la calidad arquitectónica, tanto a pequeña como a gran escala. A primera vista, esta alternativa puede parecer controversial, pero prácticas como Architecture Decision Records y los foros de asesoramiento garantizan que las decisiones se mantengan informadas, mientras que también empoderan a quienes están más cerca del trabajo a tomar decisiones. Hemos visto este modelo tener éxito a escala en un gran número de organizaciones, incluyendo aquellas en industrias altamente reguladas

En nuestra última actualización de RAG, introdujimos GraphRAG , descrito originalmente en el artículo de Microsoft como un enfoque en dos pasos: (1) fragmentación de documentos y uso de análisis basado en LLM de los fragmentos para crear un grafo de conocimientos; (2) recuperación de fragmentos relevantes en el momento de la consulta mediante incrustaciones mientras se siguen las aristas del grafo de conocimiento para descubrir fragmentos relacionados adicionales, que se añaden al prompt aumentado. En muchos casos, este enfoque mejora las respuestas generadas por LLM. Hemos observado beneficios similares al utilizar IA generativa para comprender bases de código heredadas, donde utilizamos información estructural, como árboles sintácticos abstractos y dependencias, para construir el grafo de conocimiento. El patrón GraphRAG ha ganado adeptos, con herramientas y frameworks como el paquete en Python GraphRAG de Neo4j, que están surgiendo para soportarlo. También consideramos que Graphiti se ajusta a una interpretación más amplia de GraphRAG como patrón.

El principio de privilegio mínimo garantiza que los usuarios y sistemas solo tengan el acceso mínimo necesario para realizar las tareas. El abuso de credenciales privilegiadas es un factor clave en las brechas de seguridad, siendo la escalada de privilegios un vector de ataque común. Los atacantes suelen empezar con un acceso de bajo nivel y explotan vulnerabilidades del software o configuraciones erróneas para obtener privilegios de administrador, especialmente cuando las cuentas tienen permisos excesivos o innecesarios. Otro riesgo que a menudo se pasa por alto es el de los privilegios permanentes: accesos privilegiados disponibles de forma continua que amplían la superficie de ataque. La gestión de acceso privilegiado justo a tiempo mitiga este riesgo al conceder acceso solo cuando es necesario y revocarlo inmediatamente después, minimizando la exposición. Un modelo de seguridad de menor privilegio garantiza que los usuarios, aplicaciones y sistemas tengan únicamente los derechos imprescindibles durante el mínimo tiempo posible, un requisito fundamental para el cumplimiento normativo y la seguridad regulatoria. Nuestros equipos lo han implementado a través de un flujo de trabajo automatizado que activa un proceso de aprobación ligero, asigna roles temporales con acceso restringido e impone un tiempo de vida a cada rol, lo que garantiza que los privilegios expiren automáticamente una vez completada la tarea.

Las leyes de Escalabilidad han sido un factor clave del auge de la IA; el principio de que modelos más grandes, conjuntos de datos más extensos y mayores recursos de cómputo conducen a sistemas de IA más potentes. Sin embargo, el hardware de consumo y los dispositivos perimetrales a menudo carecen de la capacidad para soportar modelos a gran escala, lo que crea la necesidad de la destilación de modelos.

La destilación de modelos transfiere conocimiento de un modelo más grande y potente (maestro) a un modelo más pequeño y eficiente en coste (estudiante). El proceso suele implicar la generación de un conjunto de datos de muestra a partir del modelo maestro y el ajuste del modelo estudiante para que capture sus propiedades estadísticas. A diferencia de la poda o la cuantización, que se enfocan en la compresión de modelos suprimiendo parámetros, la destilación intenta retener conocimiento específico del dominio, minimizando la pérdida de precisión. También se puede combinar con la cuantización para una optimización adicional.

Propuesta originalmente por Geoffrey Hinton y otros, la destilación de modelos ha sido ampliamente adoptada. Un ejemplo destacado es Qwen/Llama la versión destilada de DeepSeek R1, que mantiene sólidas capacidades de razonamiento en modelos más pequeños. Con su creciente madurez, la técnica ya no se limita sólo a los laboratorios de investigación; ahora se aplica en una amplia variedad de proyectos, desde industriales hasta personales. Proveedores como OpenAI y Amazon Bedrock ofrecen guías para ayudar a los desarrolladores a destilar sus propios modelos de lenguaje reducido (SLMs, small language model, por sus siglas en inglés). Creemos que la adopción de la destilación de modelos puede ayudar a las organizaciones a gestionar los costes de despliegue de los LLM al tiempo que libera el potencial de la inferencia LLM en dispositivos.

Prompt engineering se refiere al proceso de diseñar y refinar los prompts (instrucciones) para modelos de IA generativa, con el objetivo de producir respuestas de alta calidad conscientes del contexto. Esto implica elaborar indicaciones claras, específicas y relevantes, ajustadas a la tarea o a la aplicación, para optimizar el resultado del modelo. A medida que las LLM evolucionan, particularmente con las llegada de los modelos de razonamiento, las prácticas del prompt engineering deben ser adaptadas. Basados en nuestra experiencia con la generación de código con IA, hemos observado que los prompts con pocos ejemplos pueden ofrecer un menor rendimiento comparado con prompts sin ejemplos al trabajar con modelos de razonamiento. Además, la técnica ampliamente usada de cadena de razonamiento o chain-of-thought (CoT) puede degradar el desempeño de los modelos de razonamiento, probablemente debido a que el aprendizaje por refuerzo ya ha afinado su mecanismo interno de CoT.

Nuestra experiencia práctica se alinea con lo que señala la investigación académica, que sugiere que “los modelos más avanzados podrían eliminar la necesidad del prompt engineering en el desarrollo de software”. No obstante, las técnicas tradicionales del prompt engineering seguirán teniendo un rol crucial en reducir alucinaciones y mejorar la calidad de las respuestas, especialmente considerando las diferencias en tiempos de respuestas y costos de tokens entre los modelos de razonamiento y los LLM generales. Al crear aplicaciones con agentes autónomos, recomendamos elegir los modelos estratégicamente, con base en las necesidades y seguir refinando tanto las plantillas de prompts cómo sus técnicas correspondientes. Encontrar el equilibrio entre la calidad, el tiempo de respuesta y el costo de los tokens sigue siendo clave para maximizar la efectividad de los LLM.

El reciente anuncio de DeepSeek R1 es un gran ejemplo de por qué los small language models (SLMs) siguen siendo interesantes. La versión completa de R1 tiene 671 mil millones de parámetros y requiere alrededor de 1.342 GB de VRAM para funcionar, algo que solo se logra utilizando unmini cluster de ocho GPUs NVIDIA de última generación. Pero DeepSeek también está disponible en versión distilled en Qwen y Llama — modelos más pequeños yopen-weight —, transfiriendo efectivamente sus capacidades y permitiendo que se ejecute en hardware mucho más modesto. Aunque el modelo sacrifica algo de rendimiento en esos tamaños reducidos, aún permite un gran salto en rendimiento respecto a los SLMs anteriores. El campo de los SLM sigue innovando en otros ámbitos, también. Desde el último Radar, Meta introdujo Llama 3.2 en tamaños de 1B y 3B, Microsoft lanzó Phi-4, ofreciendo resultados de alta calidad con un modelo de 14B, y Google presentó PaliGemma 2, un modelo de visión-lenguaje en tamaños de 3B, 10B y 28B. Estos son solo algunos de los modelos que se están lanzando actualmente en tamaños más pequeños y, sin duda, es una tendencia importante a seguir.

En los últimos meses, el uso de GenAI para comprender bases de código legado ha generado verdaderos progresos. Herramientas populares como GitHub Copilot se están promocionando como capaces de ayudar a modernizar bases de código legado. Herramientas como Cody de Sourcegraph facilitan a los desarrolladores la navegación y comprensión de bases de código completas. Estas herramientas utilizan multitud de técnicas de GenAI para proporcionar ayuda contextual, simplificando el trabajo con sistemas legados complejos. Además, frameworks especializados como S3LLM están mostrando cómo los modelos de lenguaje extensos (LLMs) pueden manejar software científico de gran escala -como los escritos en Fortran o Pascal- llevando la comprensión mejorada por GenAI a bases de código fuera de la TI empresarial tradicional. Creemos que esta técnica continuará ganando terreno dada la enorme cantidad de software legacy en el mundo.

Los agentes de ingeniería de software supervisados son cada vez más capaces de identificar actualizaciones necesarias e implementar cambios más extensos en una base de código. Al mismo tiempo, se observa un mayor nivel de complacencia con el código generado por IA, con desarrolladoras y desarrolladores que se resisten a revisar conjuntos de cambios extensos realizados por IA. Una justificación típica para esta actitud es la percepción de que la calidad del código orientado a humanos no es tan crítica porque la IA podrá encargarse de futuras modificaciones; sin embargo, los asistentes de codificación basados en IA funcionan mejor con bases de código bien estructuradas y diseñadas, lo que hace que un código amigable hacia la IA sea crucial para su mantenibilidad. Afortunadamente, un buen diseño de software para humanos también beneficia a la IA. Los nombres significativos proporcionan contexto de dominio y funcionalidad; la modularidad y las abstracciones permiten a la IA gestionar mejor el contexto al limitar las modificaciones necesarias; y el principio DRY (Don’t Repeat Yourself o No te repitas) reduce el código duplicado, ayudando a que la IA tenga un comportamiento más predecible. Hasta ahora, los patrones más amigables con la IA coinciden con las mejores prácticas establecidas en el desarrollo de software. A medida que la IA siga evolucionando, es probable que surjan patrones aún más específicos para su optimización, por lo que tener esto en cuenta al diseñar código será de gran utilidad.

Están surgiendo nuevas técnicas de asistencia impulsadas por IA en equipos de desarrollo de software, más allá de la mera generación de código. Un área que está ganando tracción es la de pruebas de IU impulsadas por IA , que se apoyan en la capacidad de los LLMs para interpretar interfaces gráficas de usuario. Existen diversas aproximaciones para esto. Hay una categoría de herramientas que usan LLMs multimodales ajustados para el procesamiento de instantáneas de la IU, que permiten a los scripts de prueba escritos en lenguaje natural, navegar por la aplicación. Ejemplos en este espacio son QA.tech o LambdaTests' KaneAI. Otro enfoque, visto en Browser Use, combina modelos de base multimodal con las perspectivas que Playwright extrae de la estructura de la pagina web, en lugar de apoyarse en modelos finamente ajustados.

Al integrar pruebas de IU impulsadas por IA en una estrategia de pruebas, es crucial considerar donde producen más valor. Estos métodos pueden complementar las pruebas manuales exploratorias, y aunque la falta de determinismo de los LLMs puede introducir fallos aleatorios, su imprecisión puede ser una ventaja. Esto puede ser útil para probar aplicaciones heredadas con selectores faltantes o aplicaciones que cambian frecuentemente sus etiquetas y rutas de clic.

La Teoría de la Extensibilidad Grácil define las reglas básicas que gobiernan sistemas adaptativos, incluyendo los sistemas socio-técnicos involucrados en software de construcción y operación. Un concepto clave en esta teoría es el de Competence envelope — el límite en el que un sistema puede funcionar robustamente frente a fallas. Cuando un sistema es llevado más allá de su competence envelope, se vuelve frágil y es más propenso a fallar. Este modelo provee un lente valioso para comprender fallas sistémicas, como se pudo observar en las fallas complejas que llevaron a la caída de Canva de 2024. La Teoría de la Residualidad, un desarrollo reciente en Software Architecture Thinking, ofrece una forma de poner a prueba el Competence Envelope de un sistema a partir de la introducción deliberada de factores de estrés a dicho sistema, y el posterior análisis de cómo éste se ha adaptado a estos estresores de manera histórica a lo largo del tiempo. Los enfoques se alinean con los conceptos de anti-fragilidad, resiliencia y robustez en sistemas socio-técnicos, y nos entusiasma ver aplicaciones prácticas emerger en este campo.

La salida estructurada de LLMs se refiere a la práctica de restringir la respuesta de un modelo de lenguaje, a un esquema definido. Esto se puede lograr ya sea a través de instruir a un modelo generalizado que responda en un formato particular o realizando fine-tuning a un modelo para obtener una salida “nativa”, por ejemplo, JSON. OpenAI ahora soporta salida estructurada, permitiendo a los desarrolladores proporcionar un esquema JSON, pydantic o un objeto Zod para limitar las respuestas de un modelo. Esta capacidad es particularmente valiosa ya que permite llamadas a funciones, interacciones con una API e integraciones externas, donde la precisión y el cumplimiento de un formato son críticas. La salida estructurada no solo mejora la forma en que los LLMs pueden interactuar con el código, sino que también soporta un mayor cantidad de casos de uso, como generación de markup para el renderizado de gráficos. Adicionalmente, la salida estructurada ha demostrado reducir las posibilidades de alucinaciones en la salida de un modelo.

La IA está reduciendo las barreras para que quienes no codifican puedan crear e integrar software por sí mismos, en lugar de esperar a que el departamento de TI se encargue de sus necesidades o requisitos. Aunque nos entusiasma el potencial que esto desbloquea, también nos preocupan los primeros indicios de TI en la sombra acelerado por IA. Las plataformas de automatización de flujos de trabajo sin código ahora admiten la integración de API de IA (por ejemplo, OpenAI o Anthropic), lo que hace tentador usar la IA como cinta adhesiva — uniendo integraciones que antes no eran posibles, como convertir mensajes de chat de un sistema en llamadas a la API de un ERP mediante IA. Al mismo tiempo, los asistentes de codificación impulsados por IA se están volviendo más autónomos, lo que permite a quienes no codifican, pero tienen una formación básica, la posibilidad de crear aplicaciones de utilidad internas.

Esto tiene todas las características de la próxima evolución de las hojas de cálculo que aún impulsan procesos críticos en algunas empresas — pero con un alcance mucho mayor. Si no se controla, esta nueva TI en la sombra podría provocar la proliferación de aplicaciones no gobernadas y potencialmente inseguras, dispersando los datos en cada vez más sistemas. Las organizaciones deben ser conscientes de estos riesgos y evaluar cuidadosamente las ventajas y desventajas entre la rápida resolución de problemas y la estabilidad a largo plazo.

A medida que los asistentes de IA para escritura de código ganan peso, también lo hace el número de investigaciones y datos que traen a la luz la preocupación por la complacencia con el código generado por IA. El último estudio de calidad de código de GitClear's (https: //www.gitclear.com/aiassistantcodequality2025_research)‌) muestra que, en el 2024, el código duplicado y la rotación de código aumentaron más de lo previsto, mientras la actividad de refactorización en el historial de commits disminuyó. Además, como reflejo de la complacencia en el código generado por IA, un estudio de Microsoft (https: //www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/)‌) sobre trabajadores de conocimiento mostró que la confianza generada por la IA suele venir a costa del pensamiento crítico, un patrón que hemos observado a medida que la complacencia se instala con el uso prolongado de asistentes de programación. El auge de los agentes de ingeniería de software supervisados (https: //www.thoughtworks.com/es/radar/techniques/software-engineering-agents)‌) amplifica aún más los riesgos, ya que, cuando la IA genera conjuntos de cambios cada vez más grandes, los desarrolladores se enfrentan a mayores desafíos a la hora de revisar los resultados. La aparición de la codificación por vibras, donde los desarrolladores permiten que la IA genere código con una revisión mínima, ilustra la creciente confianza en los resultados generados por la IA. Si bien este enfoque puede ser adecuado para prototipos u otros tipos de código descartable, recomendamos encarecidamente no usarlo para código de producción.

Las organizaciones se mantienen cautelosas con respecto a las IAs asistentes de código de terceros, particularmente debido a preocupaciones con respecto a la confidencialidad del código. Como resultado, muchos desarrolladores están considerando asistentes de código locales , IAs que corren completamente en sus propias máquinas, eliminando la necesidad de enviar código a servidores externos. Sin embargo, los asistentes locales aún se quedan atrás de sus contrapartes de nube, que confían en modelos más grandes y más capaces. Incluso en máquinas de desarrollo de alta gama, los modelos más pequeños mantienen capacidades limitadas. Hemos encontrado que tienen dificultades con prompts complejos, carecen de la ventana de contexto necesaria para problemas más grandes y a menudo no pueden gatillar integraciones de herramientas o llamadas a funciones. Estas capacidades son especialmente esenciales para los flujos de trabajo agentivos, los cuales son la vanguardia en asistencia de código actualmente.

Así que, si bien recomendamos proceder con bajas expectativas, existen algunas capacidades que son válidas a nivel local. Ciertos IDEs populares actualmente incorporan modelos más pequeños en sus características centrales, tales como el completado de código predictivo de Xcode y el completado de líneas completas de código JetBrains. Y LLMs que puedan correr localmente como Qwen Coder son un paso hacia sugerencias locales en línea y manejo de queries simples de código. Se puede probar estas capacidades con Continue, que soporta la integración de modelos locales vía tiempo de ejecución como Ollama.

Cuando se habla de codificación en pares, inevitablemente surge el tema de pair programming. Nuestra profesión tiene una relación de amor-odio con ella: algunos la adoran, otros no la soportan. Los codificadores en pares plantean ahora la siguiente pregunta: ¿puede un humano trabajar en par con la IA, en lugar de con otro humano, y obtener los mismos resultados para el equipo? GitHub Copilot incluso se llama a sí mismo «tu codificador en parejas de IA». Aunque creemos que un asistente de programación puede aportar algunas de las ventajas de la programación en parejas, desaconsejamos totalmente reemplazar la programación en parejas por la IA. Enmarcar a los asistentes de programación como codificadores en pareja ignora uno de los principales beneficios de la programación en pareja: mejorar el equipo, no sólo a los colaboradores individuales. Los asistentes de programación pueden ser útiles para desbloquearse, aprender sobre una nueva tecnología, incorporarse o agilizar el trabajo táctico para que podamos centrarnos en el diseño estratégico. Pero no contribuyen a ninguno de los beneficios de la colaboración en equipo, como mantener bajo el trabajo en curso, reducir los traspasos y el re-aprendizaje, hacer posible la integración continua o mejorar la propiedad colectiva del código.

Estamos observando una preocupante proliferación del llamado Reverse ETL. Los procesos ETL tradicionales tienen su lugar en las arquitecturas de datos convencionales, donde transfieren información desde sistemas de procesamiento transaccional hacia un sistema de análisis centralizado, como un data warehouse o un data lake. Si bien esta arquitectura tiene limitaciones bien documentadas, muchas de las cuales son abordadas por un data mesh, sigue siendo común en las empresas. En este contexto, mover datos desde un sistema de análisis centralizado de vuelta a un sistema transaccional puede tener sentido en ciertos casos, como cuando el sistema central puede agregar datos de múltiples fuentes o como parte de una arquitectura transicional en el proceso de migración hacia un data mesh. Sin embargo, estamos viendo una creciente tendencia en la que proveedores de productos utilizan Reverse ETL como excusa para trasladar cada vez más lógica de negocio a una plataforma centralizada: su propio producto. Este enfoque agrava muchos de los problemas que generan las arquitecturas de datos centralizadas, por lo que recomendamos tener extrema precaución al introducir flujos de datos desde una plataforma de datos centralizada y expansiva hacia sistemas de procesamiento transaccional.

Observamos una adopción continua de SAFe™ (Scaled Agile Framework®). También seguimos observando que los procesos excesivamente estandarizados y basados en fases de SAFe generan fricción, que puede promover silos y que su control de arriba hacia abajo genera desperdicios en el flujo de valor y desalienta la creatividad del talento de ingeniería, mientras limita la autonomía y experimentación en los equipos. Una razón clave para su adopción es la complejidad de hacer que una organización se vuelva ágil, con empresas que esperan que un marco como SAFe ofrezca un atajo simple y basado en procesos para volverse ágiles. Dada la amplia adopción de SAFe -incluso entre nuestros clientes- hemos capacitado a más de 100 consultores de Thoughtworks para apoyarlos mejor. A pesar de este conocimiento profundo y los múltiples intentos, nuestra impresión es que a veces simplemente no hay una solución simple para un problema complejo, y seguimos recomendando un enfoque ágil, basado en entrega de valor y gobernanza que funcionen en conjunto con un programa integral de cambio.

Scaled Agile Framework® y SAFe™ son marcas comerciales de Scaled Agile, Inc.