A identidade da Engenharia Caracol
Nesta aula
O que a metáfora organiza
A Engenharia Caracol é a proposta de organização do trabalho apresentada por Graciliano Tolentino. Ela combina compreensão, estrutura, ciclos, autoridades, decisões de passagem, auditoria e continuidade entre pessoas e ferramentas. A imagem do caracol representa avançar levando consigo uma estrutura que preserva orientação e memória. Não transforma demora em indicador de qualidade.
Uma decisão de passagem, chamada gate, examina se existe base suficiente para a próxima ação. Uma auditoria confronta afirmações com evidências. Continuidade é a capacidade de outra pessoa retomar o trabalho sem reconstruir tudo pela conversa. Esses termos serão aprofundados; por enquanto, observe que cada um responde a um problema diferente. Um arquivo organizado pode ajudar a continuidade e ainda conter uma regra errada.
Requisitos, testes, controle de versões e registros de decisão arquitetural são práticas anteriores ao método. A contribuição proposta está na forma de articulá-las operacionalmente. Essa descrição preserva a autoria da proposta sem atribuir ao autor a invenção de todas as práticas utilizadas ou afirmar validação científica da combinação.
Três compromissos para um projeto pequeno
| Compromisso | Aplicação na Oficina Caracol | Excesso a evitar |
|---|---|---|
| Preservar orientação | O README indica como iniciar e onde estão requisitos e dados. | Copiar o mesmo texto em todos os diretórios. |
| Verificar uma capacidade | A listagem deve ocultar serviços inativos e tratar a ausência de resultados. | Acumular documentos antes de observar a primeira listagem. |
| Deixar uma retomada possível | A anotação final informa mudança, evidência e pendência. | Narrar cada clique sem explicar o que falta decidir. |
A Oficina Caracol usa o perfil Essencial: contexto didático, dados inventados e mudanças locais reversíveis. Essencial não significa dispensar os requisitos. Significa aplicar controles pequenos, suficientes para reconhecer um erro e recuperar o estado anterior. Uma aplicação com dados sensíveis ou alto custo de falha exigiria outra análise, pessoas habilitadas e controles adicionais.
Um ciclo contado do começo ao retorno
Suponha que a primeira versão de estudo mostre todos os serviços. O requisito REQ-002 exige ocultar inativos. A necessidade abre uma unidade de trabalho: ajustar a seleção, verificar uma lista mista e confirmar o efeito na página. O registro esperado liga requisito, arquivo alterado, entrada usada e resultado observado. Estes são passos de uma demonstração; os resultados efetivos devem ser preenchidos depois da execução.
Se a seleção funcionar isoladamente e a página continuar exibindo uma lista antiga, o trabalho retorna à integração. Não precisamos abandonar todo o projeto. Investigamos o caminho entre a fonte e a tela, corrigimos o consumidor e repetimos a verificação afetada. O retorno tem endereço: a evidência falhou na integração, não na formulação da necessidade.
- Escolha uma capacidade reconhecível pelo usuário.
- Defina o que precisa ser verdadeiro para demonstrá-la.
- Produza e verifique a menor mudança suficiente.
- Decida se pode seguir ou se precisa retornar a uma dependência.
- Registre o ponto de retomada, sem atribuir à anotação o valor de um teste.
Promessas e limites
O método não garante ausência de defeitos nem transforma assistência de inteligência artificial em responsabilidade institucional. Uma IA pode propor código, casos de teste e explicações; pessoas continuam responsáveis por aceitar decisões e verificar seu alcance. A formação de competência depende de prática, retorno e avaliação, não do número de páginas lidas.
Como referências de apoio, o SWEBOK organiza áreas consolidadas de engenharia de software; Pro Git apresenta controle de versões; a orientação sobre ADRs explica registros de decisões arquiteturais. Essas fontes apoiam práticas específicas. Sua presença na bibliografia não representa endosso externo da Engenharia Caracol.
Erros de identidade e critério de avanço
| Desvio | Correção específica |
|---|---|
| Chamar qualquer checklist de Caracol | Mostrar qual risco o item controla e qual decisão ele permite. |
| Produzir documentos para parecer rigoroso | Eliminar duplicações e conservar somente registros úteis à ação e à continuidade. |
| Prometer que a IA aprova com segurança | Reservar a aceitação a uma autoridade humana e apresentar evidências verificáveis. |
A explicação do método está pronta para orientar um primeiro projeto quando apresenta uma capacidade, uma forma de verificar e um retorno possível, além de declarar seus limites. A quantidade de artefatos, sozinha, não atende a esse critério.
Exercício de identificação
Duas equipes dizem usar o método. A equipe A cria vinte modelos antes de conhecer o catálogo. A equipe B registra REQ-002, demonstra a seleção de ativos, identifica uma falha de integração e anota a próxima verificação. Qual delas apresenta um uso operacional mais convincente? O que ainda não podemos concluir?
Ver solução comentada
Resposta comentada: B apresenta uma ligação entre necessidade, ação, evidência e retorno. A pode ter preparado materiais úteis, mas ainda não demonstrou a finalidade deles. Não podemos concluir que B entregou todo o sistema ou que suas verificações são suficientes para todos os riscos. Uma boa resposta justifica a escolha pelo encadeamento observado e mantém esses limites.
Referências para aprofundamento
Para situar os antecedentes, consulte S01, áreas Software Requirements e Software Configuration Management; S07, capítulo Git Basics; e S08, orientação sobre registros de decisão arquitetural. O apoio dessas práticas não constitui avaliação externa do método.
Fontes relacionadas
Consulte os limites e as seções de apoio de cada referência.
S01 S07 S08Tente o exercício antes de consultar a solução. Marque a aula para organizar sua leitura.
A conclusão desta leitura não equivale a certificação ou aceite de um projeto real. Teste os exemplos no escopo indicado e registre as limitações.