Técnicas

As organizações adotam ativamente a mentalidade de produto para dados como uma prática padrão para gerenciar os ativos de dados. Essa abordagem trata os dados como um produto com seu próprio ciclo de vida, padrões de qualidade e foco em atender às necessidades da pessoa consumidora. Agora a recomendamos como padrão para o gerenciamento de dados, independentemente de as organizações escolherem arquiteturas como malha de dados (data mesh) ou lakehouse.

Enfatizamos a importância do foco na pessoa consumidora na mentalidade de produto para dados, com o fim de promover maior adoção e realização de valor. Isso implica projetar produtos de dados antes dos casos de uso. Também damos foco em capturar e gerenciar metadados relevantes para os negócios e metadados técnicos usando catálogos de dados modernos como DataHub, Collibra, Atlan e Informatica. Essas práticas melhoram a capacidade de descoberta e a usabilidade dos dados. Além disso, adotamos a mentalidade de produto para dados para escalar iniciativas de IA e criar dados prontos para IA. Essa abordagem inclui o gerenciamento abrangente do ciclo de vida, garantindo que os dados não sejam apenas bem administrados e de alta qualidade, mas também descartados em conformidade com os requisitos legais e regulamentares quando não forem mais necessários.

Teste de fuzzing, ou simplesmente fuzzing, é uma técnica de teste que existe há muito tempo, mas ainda é uma das menos conhecidas. O seu objetivo é fornecer a um sistema de software todos os tipos de entradas inválidas e observar o seu comportamento. Para um endpoint HTTP, por exemplo, requisições inválidas deveriam resultar em erros 4xx, mas o teste de fuzzing provoca erros 5xx ou piores. Bem documentado e suportado por ferramentas, o teste de fuzzing se tornou mais relevante do que nunca, especialmente com o aumento do código gerado por IA e sua complacência. Isto significa que é uma boa hora para adotar o teste de fuzzing para garantir que o código continue robusto e seguro.

Desde o nosso blip inicial em 2021, a geração de lista de materiais de software (SBOM) passou de uma prática emergente para um um padrão sensato em nossos projetos. O ecossistema amadureceu significativamente, oferecendo um conjunto de ferramentas robusto e integração perfeita com CI/CD. Ferramentas como Syft, Trivy e Snyk fornecem uma geração de SBOM, desde código fonte até imagens de contêineres e análises de vulnerabilidades. Plataformas como a FOSSA e a Chainloop aprimoram a gestão de riscos de segurança ao se integrarem com o fluxo de desenvolvimento e aplicarem políticas de segurança. Embora um padrão universal de SBOM ainda esteja evoluindo, o amplo suporte ao SPDX e ao CycloneDX minimizou os desafios de adoção. Sistemas de IA também exigem SBOMs, como demonstrado pelo Código de Prática de Cibersegurança em IA do governo do Reino Unido e pelo Playbook de Colaboração em Cibersegurança em IA da CISA. Continuaremos monitorando os avanços nesse espaço.

No cenário em constante evolução de desenvolvimento de software impulsionado por IA, a modelagem de ameaças é mais essencial do que nunca para construir software seguro, mantendo a agilidade e evitando o “sanduíche de segurança”. A modelagem de ameaças — um conjunto de técnicas para identificar e classificar ameaças potenciais — aplica-se em vários contextos, incluindo aplicações de IA generativa, que introduzem riscos de segurança únicos. Para ser eficaz, ela deve ser realizada regularmente ao longo do ciclo de vida do software e funciona melhor em conjunto com outras práticas de segurança. Essas incluem definir requisitos de segurança interfuncionais para abordar riscos comuns nas tecnologias do projeto e utilizar scanners de segurança automatizados para monitoramento contínuo.

Tratar APIs como produto significa priorizar a experiência da pessoa desenvolvedora, não apenas inserindo um design sensato e padronizado nas próprias APIs, mas também fornecendo documentações abrangentes e boas experiências de onboarding. Embora as especificações de OpenAPI (Swagger) possam documentar as interfaces de APIs efetivamente, o onboarding permanece um desafio. As desenvolvedoras precisam de acesso rápido a exemplos funcionais, com autenticação pré-configurada e dados de testes realistas. Com o amadurecimento de ferramentas de clientes de API (como Postman, Bruno e Insomnia), recomendamos tratar a coleção de requisições de API como um artefato do produto. Essas coleções devem ser cuidadosamente projetadas para guiar efetivamente as desenvolvedoras através dos principais fluxos de trabalho, auxiliando na compreensão da funcionalidade e linguagem de domínio da API com o mínimo de esforço. Para manter as coleções atualizadas, recomendamos armazená-las em um repositório e integrar ao pipeline de entrega das APIs.

Um dos desafios persistentes em grandes equipes de software é determinar quem toma as decisões arquiteturais que moldam a evolução dos sistemas. O Relatório sobre o Estado do DevOps revela que a abordagem tradicional dos Conselhos de Revisão de Arquitetura é contraproducente, muitas vezes prejudicando o fluxo de trabalho e correlacionando-se com baixo desempenho organizacional. Uma alternativa convincente é um processo de aconselhamento arquitetural — uma abordagem descentralizada onde qualquer pessoa pode tomar qualquer decisão arquitetural, desde que busque aconselhamento daqueles afetados e daqueles com experiência relevante. Este método permite que as equipes otimizem o fluxo sem comprometer a qualidade arquitetural, tanto em pequenas quanto em grandes escalas. À primeira vista, essa abordagem pode parecer controversa, mas práticas como Registros de Decisão de Arquitetura e fóruns consultivos garantem que as decisões permaneçam informadas, enquanto capacitam aqueles mais próximos do trabalho a tomar decisões. Temos visto este modelo ter sucesso em escala em um número crescente de organizações, incluindo aquelas em indústrias altamente regulamentadas.

Em nossa última atualização do RAG, introduzimos o GraphRAG, originalmente descrito no artigo da Microsoft como uma abordagem de duas etapas: (1) divisão de documentos em segmentos e uso de uma análise baseada em modelos de linguagem de grande porte (LLMs) dos segmentos para criar um gráfico de conhecimento; (2) recuperação de segmentos relevantes no momento da consulta por meio de embeddings, enquanto seguimos as bordas no gráfico de conhecimento para descobrir segmentos relacionados adicionais, que são então adicionados ao prompt aumentado. Em muitos casos, essa abordagem aprimora as respostas geradas pelo LLM. Observamos benefícios semelhantes ao usar o GenAI para entender bases de código legadas, em que usamos informações estruturais — como árvores de sintaxe abstratas e dependências — para criar o gráfico de conhecimento. O padrão GraphRAG ganhou força com o surgimento de ferramentas e estruturas como o pacote GraphRAG Python da Neo4j para oferecer suporte a ele. Também consideramos que o Graphiti se encaixa em uma interpretação mais ampla do GraphRAG como um padrão.

O princípio de menor privilégio garante que sistemas e usuárias tenham apenas o acesso mínimo necessário para realizar suas tarefas. O abuso de credenciais privilegiadas é um fator significativo por trás das violações de segurança, sendo a escalada de privilégios um vetor de ataque comum. Frequentemente, as invasoras começam com acesso de baixo nível e exploram vulnerabilidades de software ou configurações incorretas para obter privilégios de administrador, especialmente quando as contas têm direitos excessivos ou desnecessários. Outro risco negligenciado são os privilégios permanentes — acessos privilegiados disponíveis continuamente, que ampliam a superfície de ataque. O gerenciamento de acesso privilegiado sob demanda mitiga esse risco, concedendo o acesso privilegiado apenas quando necessário e revogando-o imediatamente após o uso, minimizando a exposição. Um modelo de segurança que aplica rigorosamente o princípio de menor privilégio garante que usuárias, aplicações e sistemas tenham apenas os direitos essenciais pelo menor tempo possível – um requisito crítico para conformidade e segurança regulatória. Nossas equipes implementaram essa abordagem por meio de um fluxo de trabalho automatizado, que aciona um processo leve de aprovação, atribui funções temporárias com acesso restrito e impõe um tempo máximo de validade (TTL) para cada função, garantindo que os privilégios expirem automaticamente assim que a tarefa for concluída.

As leis de escala têm sido um fator essencial no avanço da IA — o princípio de que modelos maiores, conjuntos de dados mais extensos e maior poder computacional resultam em sistemas de IA mais poderosos. No entanto, hardwares de consumo e dispositivos de borda frequentemente não possuem capacidade suficiente para suportar modelos em larga escala, criando a necessidade da destilação de modelos.

A destilação de modelos transfere conhecimento de um modelo maior e mais potente (professor) para um modelo menor e mais eficiente (aluno). O processo normalmente envolve a geração de um conjunto de dados amostral a partir do modelo professor e o ajuste fino do modelo aluno para capturar suas propriedades estatísticas. Diferente da poda ou da quantização, que reduzem modelos removendo parâmetros, a destilação busca preservar o conhecimento específico do domínio, minimizando a perda de precisão. Além disso, ela pode ser combinada com quantização para otimização adicional.

Originalmente proposta por Geoffrey Hinton et al., a destilação de modelos tem sido amplamente adotada. Um exemplo notável é a versão destilada do Qwen/Llama do DeepSeek R1, que mantém fortes capacidades de raciocínio em modelos menores. Com sua crescente maturidade, a técnica não está mais restrita a laboratórios de pesquisa; agora é aplicada em projetos industriais e pessoais. Provedores como OpenAI e Amazon Bedrock oferecem guias para ajudar desenvolvedoras a destilar seus próprios modelos de linguagem de pequeno porte (SLMs). Acreditamos que a adoção da destilação de modelos pode ajudar as organizações a gerenciar os custos de implantação de modelos de linguagem de grande porte (LLMs), ao mesmo tempo em que desbloqueia o potencial da inferência de LLM em dispositivos.

Engenharia de prompt se refere ao processo de projetar e refinar prompts de modelos de IA generativa para produzir respostas de alta qualidade e contextualizadas. Isso envolve a elaboração de prompts claros, específicos e relevantes para tarefas sob medida ou aplicações, para otimizar a saída do modelo. À medida que as capacidades dos modelos de linguagem de grande porte (LLMs) evoluem, particularmente com o surgimento dos modelos de raciocínio, as práticas da engenharia de prompt devem também se adaptar. Baseado em nossa experiência em geração de código com IA, nós observamos que o few-shot prompting pode ter uma performance inferior ao zero-shot prompting quando trabalhado com modelos de raciocínio. Adicionalmente, o amplamente utilizado chain-of-thought (CoT) pode degradar a performance de modelos de raciocínio — provavelmente porque a aprendizagem por reforço já tem ajuste fino embutido no macanismo CoT.

Nossa experiência prática está alinhada com as pesquisas acadêmicas, que sugerem que “modelos avançados podem eliminar a necessidade de engenharia de prompt na engenharia de software.” No entanto, técnicas de engenharia de prompt tradicionais ainda desempenham um papel crucial na redução de alucinações e na melhoria da qualidade das respostas, especialmente considerando as diferenças em tempo de resposta e custos de token entre modelos de raciocínio e LLMs genéricos. Ao construir aplicações de agente, nós recomendamos a escolha estratégica dos modelos com base nas suas necessidades, enquanto continua a refinar seus modelos de prompt e técnicas correspondentes. Encontrar o equilíbrio certo entre desempenho, tempo de resposta e custo de token continua sendo essencial para maximizar a eficácia dos LLMs.

O anúncio recente do DeepSeek R1 é um ótimo exemplo de por que modelos de linguagem de pequeno porte (SLMs) permanecem interessantes. O R1 em tamanho real tem 671 bilhões de parâmetros e requer cerca de 1.342 GB de VRAM para funcionar, o que só é possível usando um mini cluster de oito GPUs NVIDIA de última geração. Mas o DeepSeek também está disponível destilado em Qwen e Llama — modelos menores e de peso aberto — transferindo efetivamente suas habilidades e permitindo que seja executado em hardware muito mais modesto. Embora o modelo perca algum desempenho nesses tamanhos menores, ele ainda permite um grande salto de desempenho em relação aos modelos de linguagem de pequeno porte anteriores. O espaço dos SLMs continua a inovar em outros lugares também. Desde o último Radar, a Meta introduziu o Llama 3.2 nos tamanhos 1B e 3B, a Microsoft lançou o Phi-4, oferecendo resultados de alta qualidade com um modelo 14B, e o Google lançou o PaliGemma 2, um modelo de linguagem de visão nos tamanhos 3B, 10B e 28B. Esses são apenas alguns dos modelos menores que estão sendo lançados, consolidando uma tendência importante a ser acompanhada.

Nos últimos meses, o uso de GenIA para entender bases de código legadas tem avançado significativamente. Ferramentas populares, como o GitHub Copilot, estão sendo destacadas como capazes de ajudar na modernização de bases de código legadas. Ferramentas como o Cody, da Sourcegraph, estão facilitando a navegação e compreensão de bases de código inteiras. Essas ferramentas utilizam diversas técnicas de GenIA para fornecer ajuda contextual, simplificando o trabalho com sistemas legados complexos. Além disso, frameworks especializados como o S3LLM estão demonstrando como modelos de linguagem de grande porte (LLMs) podem lidar com softwares científicos em larga escala — como aqueles escritos em Fortran ou Pascal — trazendo uma compreensão aprimorada por GenIA para bases de código fora do tradicional ambiente corporativo de TI. Acreditamos que essa abordagem continuará ganhando força, dado o enorme volume de software legado existente no 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.