Tem uma pergunta que aparece cedo em todo projeto de sistema embarcado novo: “a gente vai rodar isso em Scrum?”. E a resposta sincera, na maioria das vezes, é: só uma parte. Porque diferente de um time fazendo aplicação web, aqui você tem uma placa que leva semanas para chegar do fornecedor, um layout de PCB que não muda depois de fabricado, e um firmware que só faz sentido testado de verdade em cima do hardware real — não num mock.
Já escrevi separadamente sobre como escolher a metodologia certa para o seu projeto, sobre metodologias process-driven e sobre Scrum, Kanban e XP de forma geral. O que falta nesses artigos — e é o que a maioria dos times de embarcados realmente precisa resolver — é como aplicar as duas coisas ao mesmo tempo, porque em sistema embarcado raramente é “uma ou outra”.
Por que sistema embarcado puxa para os dois lados
Três características empurram embarcados para metodologia mais rígida, e ao mesmo tempo pedem agilidade:
- Confiabilidade e segurança exigem teste contínuo e validação — isso pede rigor de processo, documentação e critério de aceite claro, principalmente se o produto vai para automotivo, industrial ou dispositivo médico.
- Recurso limitado de hardware significa que cada decisão de arquitetura pesa mais e é mais cara de reverter — o que empurra para planejamento antecipado, não para “vamos descobrir no caminho”.
- Ciclo de vida longo — um produto embarcado roda em campo por anos, então documentação e manutenção planejada importam mais do que num SaaS que você reescreve a cada dois anos.
Ao mesmo tempo, firmware tem bug, requisito de cliente muda, e integração de hardware sempre revela alguma coisa que não estava no papel. Fingir que dá para travar tudo numa cascata única e nunca mais tocar é ingenuidade — e fingir que dá para rodar sprint de duas semanas sem nenhum checkpoint rígido de integração de hardware é outra.
O modelo que funciona na prática: rígido no início, ágil no meio
A estratégia que eu vejo funcionar de verdade não é escolher um lado — é dividir o projeto em fases com regras diferentes.
Fase 1 — Planejamento inicial em process-driven
Use uma abordagem tipo cascata ou modelo V só para o que realmente não pode mudar depois de decidido: requisitos essenciais do sistema, arquitetura de hardware-software, escolha de SoC, interfaces físicas e critério de validação. Isso inclui:
- Levantamento de requisitos detalhado, com foco especial no que envolve escolha de componente físico (esse não tem “sprint 2, vamos revisar” — o componente já foi comprado).
- Planejamento de documentação técnica desde já, porque ela vai servir de referência por anos de manutenção.
- Definição clara dos critérios de teste e validação que vão valer o projeto inteiro.
Esse rigor inicial não é burocracia por burocracia — é reconhecer que hardware não tem “refactor”. Se você decidiu tarde demais que precisava de mais memória, a resposta é atrasar o projeto e trocar a placa, não um merge request.
Fase 2 — Iterações ágeis para o que pode mudar
Depois que a base de hardware está definida, o desenvolvimento de módulos e funcionalidades específicas roda muito melhor em ciclos curtos:
- Sprints permitem feedback contínuo e ajuste rápido conforme o teste em cima do hardware real revela comportamento que não dava para prever só no papel.
- Cada incremento pode (e deve) ser validado com o hardware físico, não só simulado — é aqui que “ágil de aplicação web” e “ágil de embarcado” mais se diferenciam: seu “ambiente de produção” para teste é uma bancada com osciloscópio, não um container.
- Comunicação entre firmware, hardware e demais áreas fica mais fácil em cerimônias curtas do tipo Scrum ou Kanban do que em um cronograma de Gantt de seis meses.
Fase 3 — Integração contínua com simulação de hardware
Automatize o que puder: teste de software roda em CI normal, mas complemente com simulação de hardware (HIL — hardware-in-the-loop, quando o orçamento permitir) para pegar falha de integração antes da última hora. Isso reduz o risco clássico de “no laboratório funcionou, na placa de produção não” aparecer só na reta final.
Fase 4 — Documentação e revisão periódica, mesmo dentro do ágil
Mesmo rodando sprint, mantenha documentação atualizada e faça revisão periódica de arquitetura. Isso não é “voltar para cascata” — é reconhecer que documentação em sistema embarcado não é nice-to-have, é o que permite alguém dar manutenção nesse firmware daqui a três anos, quando ninguém do time original estiver mais no projeto.
Onde isso costuma quebrar
Sendo honesto sobre os dois lados: process-driven puro falha quando o hardware chega e revela um problema que a especificação não previu — e não tem espaço formal para incorporar essa mudança sem reabrir todo o cronograma. Ágil puro falha quando o time trata “sprint” como desculpa para pular planejamento de interface de hardware, decisão que devia ter sido travada antes de qualquer linha de firmware ser escrita — porque naquele ponto já é tarde para mudar componente físico.
Na prática, o erro mais comum que vejo não é escolher o modelo errado — é aplicar o mesmo grau de rigidez (ou de flexibilidade) em decisão de hardware e em decisão de firmware, quando elas têm custo de reversão completamente diferente.
O ponto central
Combinar process-driven e ágil em sistema embarcado não é meio-termo morno entre os dois — é usar rigor onde reverter é caro (hardware, arquitetura, requisito crítico de segurança) e usar ciclos curtos onde reverter é barato (lógica de firmware, funcionalidade específica, ajuste de comportamento). Fazer isso bem melhora a qualidade do produto final e também facilita a colaboração entre quem cuida do hardware e quem cuida do software — que, em embarcados, quase sempre são pessoas diferentes com prioridades diferentes.
Se você quer se aprofundar em cada metodologia individual antes de decidir como combiná-las, os artigos sobre process-driven e sobre Scrum, Kanban e XP aqui no blog cobrem os detalhes de cada uma. E se o seu projeto tem uma restrição específica de hardware que não se encaixa nessa divisão em fases, esse é exatamente o tipo de caso concreto que vale discutir nos comentários ou no canal do FortShield.
