{"id":24376,"date":"2026-09-10T17:08:10","date_gmt":"2026-09-10T20:08:10","guid":{"rendered":"http:\/\/import-004-spec-driven-development"},"modified":"2026-09-10T17:08:11","modified_gmt":"2026-09-10T20:08:11","slug":"spec-driven-development","status":"publish","type":"post","link":"https:\/\/uds.com.br\/blog\/spec-driven-development\/","title":{"rendered":"Spec-driven development: o que \u00e9 e como aplicar"},"content":{"rendered":"<p dir=\"ltr\">O <em>spec-driven development<\/em> ganhou espa\u00e7o como resposta a um problema que a ado\u00e7\u00e3o acelerada de intelig\u00eancia artificial tornou vis\u00edvel: gerar c\u00f3digo ficou barato, enquanto garantir que esse c\u00f3digo fa\u00e7a a coisa certa continua caro. Segundo o <a href=\"https:\/\/services.google.com\/fh\/files\/misc\/2025_state_of_ai_assisted_software_development.pdf\" target=\"_blank\" rel=\"noopener\">relat\u00f3rio DORA 2025<\/a>, do Google Cloud, 90% dos profissionais j\u00e1 usam IA no trabalho e mais de 80% percebem ganho de produtividade. O mesmo estudo mostra que a ado\u00e7\u00e3o de IA passou a acelerar o ritmo de entregas, mas continua associada a mais instabilidade nas mudan\u00e7as que chegam \u00e0 produ\u00e7\u00e3o.<\/p>\n<p dir=\"ltr\">Esse descompasso tem uma explica\u00e7\u00e3o concreta no dia a dia. Quando a instru\u00e7\u00e3o dada ao modelo \u00e9 uma frase solta em uma conversa, o resultado depende do que o desenvolvedor lembrou de mencionar naquele momento, e regras de neg\u00f3cio que ningu\u00e9m citou simplesmente n\u00e3o aparecem no c\u00f3digo. A aus\u00eancia s\u00f3 \u00e9 percebida na revis\u00e3o, no teste ou, no pior caso, em produ\u00e7\u00e3o, e quanto mais r\u00e1pido o c\u00f3digo \u00e9 gerado, mais cedo esse gargalo aparece.<\/p>\n<p dir=\"ltr\">A resposta que vem se consolidando no mercado \u00e9 deslocar o esfor\u00e7o para antes da gera\u00e7\u00e3o. O time escreve uma especifica\u00e7\u00e3o revis\u00e1vel, aprova esse documento e s\u00f3 ent\u00e3o libera o agente para executar, de modo que o artefato aprovado passa a ser o contrato do que ser\u00e1 constru\u00eddo e a revis\u00e3o alcan\u00e7a tamb\u00e9m a inten\u00e7\u00e3o por tr\u00e1s do c\u00f3digo.<\/p>\n<p dir=\"ltr\">Neste guia, voc\u00ea vai entender o que \u00e9 <em>spec-driven development<\/em>, como ele funciona, quais s\u00e3o suas fases, quando ele vale mais que a abordagem informal e como aplic\u00e1-lo em um time que j\u00e1 produz com intelig\u00eancia artificial. Acompanhe:<\/p>\n<h2 dir=\"ltr\">O que \u00e9 <em>spec-driven development<\/em>?<\/h2>\n<p dir=\"ltr\"><strong><em>Spec-driven development<\/em> \u00e9 a pr\u00e1tica de escrever uma especifica\u00e7\u00e3o estruturada e revis\u00e1vel antes de gerar c\u00f3digo, tratando esse documento como a fonte de verdade da implementa\u00e7\u00e3o.<\/strong> A especifica\u00e7\u00e3o passa por aprova\u00e7\u00e3o humana antes de qualquer linha ser escrita, e o c\u00f3digo se torna consequ\u00eancia do documento aprovado. Em geral, ela descreve:<\/p>\n<ul dir=\"ltr\">\n<li><strong>Comportamento esperado:<\/strong> o que a funcionalidade deve fazer, incluindo os casos de exce\u00e7\u00e3o;<\/li>\n<li><strong>Decis\u00f5es t\u00e9cnicas:<\/strong> quais componentes mudam e quais contratos s\u00e3o afetados;<\/li>\n<li><strong>Tarefas:<\/strong> os passos de implementa\u00e7\u00e3o, em ordem e verific\u00e1veis um a um.<\/li>\n<\/ul>\n<p dir=\"ltr\">O diferencial est\u00e1 no destino do artefato, uma vez que um documento de requisitos costuma ser lido por pessoas e traduzido manualmente para c\u00f3digo, com perdas em cada tradu\u00e7\u00e3o. Nesse m\u00e9todo, um agente consome a especifica\u00e7\u00e3o diretamente, o que reduz a dist\u00e2ncia entre o que foi combinado e o que foi implementado.<\/p>\n<h2 dir=\"ltr\">Como funciona o <em>spec-driven development<\/em>?<\/h2>\n<p class=\"PDq2pG_selectionAnchorContainer\" data-start=\"0\" data-end=\"415\"><strong data-start=\"0\" data-end=\"105\">O <em data-start=\"4\" data-end=\"29\">spec-driven development<\/em> funciona em um ciclo de tr\u00eas movimentos: especificar, aprovar e executar.<\/strong> A demanda \u00e9 descrita em linguagem natural, transformada pela ferramenta em requisitos, desenho t\u00e9cnico e tarefas, e ent\u00e3o revisada pelo time antes da implementa\u00e7\u00e3o. A execu\u00e7\u00e3o acontece a partir dessa especifica\u00e7\u00e3o, mantendo a rastreabilidade entre o pedido original, as decis\u00f5es t\u00e9cnicas e o que foi entregue.<\/p>\n<h3 data-start=\"417\" data-end=\"763\"><strong data-start=\"417\" data-end=\"445\">1. Especificar a demanda<\/strong><\/h3>\n<p data-start=\"417\" data-end=\"763\">O processo<strong> come\u00e7a com a descri\u00e7\u00e3o do que precisa ser desenvolvido<\/strong>, preferencialmente em linguagem natural e com contexto suficiente para deixar claro o resultado esperado. A ferramenta transforma essa demanda em uma especifica\u00e7\u00e3o estruturada, que pode incluir requisitos, crit\u00e9rios de aceita\u00e7\u00e3o e regras do sistema.<\/p>\n<h3 data-start=\"765\" data-end=\"1134\"><strong data-start=\"765\" data-end=\"795\">2. Aprovar a especifica\u00e7\u00e3o<\/strong><\/h3>\n<p data-start=\"765\" data-end=\"1134\">Antes de escrever c\u00f3digo, o time revisa os requisitos e o desenho t\u00e9cnico proposto. \u00c9 nesse momento que decis\u00f5es sobre arquitetura, valida\u00e7\u00f5es e comportamento podem ser discutidas e ajustadas. <strong data-start=\"991\" data-end=\"1134\">Uma diverg\u00eancia sobre onde deve ficar a valida\u00e7\u00e3o de um dado, por exemplo, pode ser resolvida aqui antes de se espalhar pela implementa\u00e7\u00e3o.<\/strong><\/p>\n<h3 data-start=\"1136\" data-end=\"1552\"><strong data-start=\"1136\" data-end=\"1163\">3. Executar e verificar<\/strong><\/h3>\n<p data-start=\"1136\" data-end=\"1552\" data-is-last-node=\"\" data-is-only-node=\"\">Com a especifica\u00e7\u00e3o aprovada, as tarefas s\u00e3o executadas de acordo com o que foi definido. Cada entrega pode ser verificada em rela\u00e7\u00e3o aos requisitos e crit\u00e9rios de aceita\u00e7\u00e3o, mantendo a conex\u00e3o entre a demanda original e o c\u00f3digo produzido. <strong data-start=\"1407\" data-end=\"1552\" data-is-last-node=\"\">O ganho est\u00e1 justamente em deslocar parte da discuss\u00e3o t\u00e9cnica para antes da implementa\u00e7\u00e3o, quando corrigir uma decis\u00e3o tende a custar menos.<\/strong><\/p>\n<h3 dir=\"ltr\"><em>Spec-driven development<\/em> \u00e9 a mesma coisa que documenta\u00e7\u00e3o de requisitos?<\/h3>\n<p dir=\"ltr\"><strong>N\u00e3o, embora os dois tenham parentesco.<\/strong> A documenta\u00e7\u00e3o de requisitos tradicional descreve o que o sistema deve fazer e fica separada do c\u00f3digo, envelhecendo \u00e0 medida que a implementa\u00e7\u00e3o avan\u00e7a. J\u00e1 a especifica\u00e7\u00e3o desse m\u00e9todo \u00e9 versionada junto ao reposit\u00f3rio, consumida por um agente e atualizada no mesmo fluxo da mudan\u00e7a. Veja as diferen\u00e7as:<\/p>\n<div dir=\"ltr\">\n<table>\n<thead>\n<tr>\n<th scope=\"col\">Crit\u00e9rio<\/th>\n<th scope=\"col\">Documenta\u00e7\u00e3o de requisitos<\/th>\n<th scope=\"col\">Especifica\u00e7\u00e3o do m\u00e9todo<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Onde fica<\/td>\n<td>Em documento separado do c\u00f3digo<\/td>\n<td>Versionada no reposit\u00f3rio<\/td>\n<\/tr>\n<tr>\n<td>Quem consome<\/td>\n<td>Pessoas, que traduzem para c\u00f3digo<\/td>\n<td>Um agente, com revis\u00e3o humana<\/td>\n<\/tr>\n<tr>\n<td>Escopo<\/td>\n<td>Grandes blocos do sistema<\/td>\n<td>Uma mudan\u00e7a execut\u00e1vel em uma sess\u00e3o<\/td>\n<\/tr>\n<tr>\n<td>Atualiza\u00e7\u00e3o<\/td>\n<td>Costuma envelhecer com o tempo<\/td>\n<td>Revisada a cada mudan\u00e7a<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p dir=\"ltr\">Essa escala menor \u00e9 o que mant\u00e9m a especifica\u00e7\u00e3o viva, porque revis\u00e1-la custa pouco. O time l\u00ea, comenta e aprova um documento curto, com a mesma frequ\u00eancia com que revisa c\u00f3digo.<\/p>\n<h2 dir=\"ltr\">Quais s\u00e3o as fases do <em>spec-driven development<\/em>?<\/h2>\n<p dir=\"ltr\"><strong>O m\u00e9todo se organiza em tr\u00eas fases encadeadas, 1) requisitos, 2) desenho t\u00e9cnico e 3) tarefas, e cada uma tem um crit\u00e9rio de sa\u00edda pr\u00f3prio.<\/strong> Pular qualquer uma delas devolve o time ao improviso: sem requisitos claros o desenho vira palpite, e sem desenho aprovado a lista de tarefas n\u00e3o tem como estar correta. Explicamos cada fase:<\/p>\n<h3 dir=\"ltr\">1. Requisitos<\/h3>\n<p dir=\"ltr\">A primeira fase transforma o pedido em crit\u00e9rios de aceita\u00e7\u00e3o verific\u00e1veis, incluindo os casos de exce\u00e7\u00e3o que costumam ficar impl\u00edcitos. \u00c9 aqui que aparecem as perguntas que ningu\u00e9m tinha feito, como o que acontece quando o cliente j\u00e1 tem um cadastro parcial ou quando o pagamento \u00e9 aprovado depois do cancelamento.<\/p>\n<h3>2. Desenho t\u00e9cnico<\/h3>\n<p dir=\"ltr\">A segunda fase define como a solu\u00e7\u00e3o ser\u00e1 constru\u00edda: quais componentes mudam, quais contratos s\u00e3o afetados e quais decis\u00f5es de arquitetura est\u00e3o envolvidas. Revisar esse documento \u00e9 o ponto de maior alavancagem do m\u00e9todo, porque corrigir uma escolha estrutural nessa etapa custa uma fra\u00e7\u00e3o do que custaria depois.<\/p>\n<h3 dir=\"ltr\">3. Tarefas<\/h3>\n<p dir=\"ltr\">A terceira fase quebra o desenho em passos execut\u00e1veis e verific\u00e1veis individualmente. Uma lista bem constru\u00edda permite acompanhar o avan\u00e7o item a item e interromper a execu\u00e7\u00e3o no meio sem deixar a base em estado inconsistente. A execu\u00e7\u00e3o dessas fases dentro de uma ferramenta espec\u00edfica est\u00e1 detalhada no conte\u00fado sobre <a href=\"https:\/\/uds.com.br\/blog\/spec-driven-development-kiro\/\" target=\"_blank\" rel=\"noopener\"><em>spec-driven development<\/em> com Kiro<\/a>.<\/p>\n<h2 dir=\"ltr\"><em>Vibe coding<\/em> ou <em>spec-driven development<\/em>: quando usar cada um?<\/h2>\n<p dir=\"ltr\"><strong>A escolha entre a abordagem informal, conhecida como <em>vibe coding<\/em>, e o <em>spec-driven development<\/em> depende do custo do erro e da vida \u00fatil do que est\u00e1 sendo constru\u00eddo.<\/strong> Descrever a tarefa em uma frase e iterar r\u00e1pido funciona bem em explora\u00e7\u00e3o, <a href=\"https:\/\/uds.com.br\/blog\/poc-o-que-e-prova-de-conceito\/\" target=\"_blank\" rel=\"noopener\">prova de conceito<\/a> e <em>script<\/em> descart\u00e1vel. J\u00e1 em c\u00f3digo que vai para produ\u00e7\u00e3o e ser\u00e1 mantido por anos, a especifica\u00e7\u00e3o pr\u00e9via se paga na primeira regress\u00e3o evitada. Veja a compara\u00e7\u00e3o:<\/p>\n<div dir=\"ltr\">\n<table>\n<thead>\n<tr>\n<th scope=\"col\">Crit\u00e9rio<\/th>\n<th scope=\"col\">Abordagem informal<\/th>\n<th scope=\"col\"><em>Spec-driven development<\/em><\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Melhor cen\u00e1rio<\/td>\n<td>Prot\u00f3tipo e explora\u00e7\u00e3o<\/td>\n<td>Produ\u00e7\u00e3o e c\u00f3digo mantido<\/td>\n<\/tr>\n<tr>\n<td>Onde est\u00e1 a revis\u00e3o<\/td>\n<td>No c\u00f3digo pronto<\/td>\n<td>Na inten\u00e7\u00e3o, antes do c\u00f3digo<\/td>\n<\/tr>\n<tr>\n<td>Rastreabilidade<\/td>\n<td>Baixa, dispersa no hist\u00f3rico da conversa<\/td>\n<td>Alta, versionada no reposit\u00f3rio<\/td>\n<\/tr>\n<tr>\n<td>Custo inicial<\/td>\n<td>Muito baixo<\/td>\n<td>M\u00e9dio, concentrado no in\u00edcio<\/td>\n<\/tr>\n<tr>\n<td>Risco de regress\u00e3o<\/td>\n<td>Alto em base complexa<\/td>\n<td>Reduzido pelos crit\u00e9rios de aceita\u00e7\u00e3o<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p dir=\"ltr\">As duas abordagens convivem no mesmo time, desde que a fronteira esteja combinada. Um arranjo comum reserva a abordagem informal para investiga\u00e7\u00e3o e prot\u00f3tipo e exige especifica\u00e7\u00e3o para qualquer altera\u00e7\u00e3o que chegue ao reposit\u00f3rio principal.<\/p>\n<h2 dir=\"ltr\">Como aplicar <em>spec-driven development<\/em> no time?<\/h2>\n<p dir=\"ltr\"><strong>Aplicar <em>spec-driven development<\/em> em um time que j\u00e1 usa IA passa por cinco etapas: 1) escolher uma demanda piloto, 2) documentar os padr\u00f5es do projeto, 3) definir quem aprova cada fase, 4) revisar a especifica\u00e7\u00e3o como c\u00f3digo e 5) medir o resultado.<\/strong> A ado\u00e7\u00e3o \u00e9 principalmente uma mudan\u00e7a de processo, por isso vale come\u00e7ar pequeno, com uma demanda de complexidade m\u00e9dia que o time j\u00e1 compreende. Explicamos cada etapa:<\/p>\n<h3 dir=\"ltr\">1. Escolha uma demanda piloto<\/h3>\n<p dir=\"ltr\"><strong>Selecione uma demanda real e delimitada para ser piloto<\/strong>, evitando come\u00e7ar pela tarefa mais cr\u00edtica do trimestre. Assim, o time consegue comparar o resultado com a pr\u00f3pria estimativa original sem press\u00e3o excessiva de prazo.<\/p>\n<h3 dir=\"ltr\">2. Documente os padr\u00f5es do projeto<\/h3>\n<p dir=\"ltr\"><strong>Registre conven\u00e7\u00f5es, bibliotecas e decis\u00f5es de arquitetura<\/strong> em arquivos de contexto versionados, como os <a href=\"https:\/\/uds.com.br\/blog\/kiro-steering-files-configuracao\/\" target=\"_blank\" rel=\"noopener\"><em>steering files<\/em><\/a> do Kiro. Dessa forma, cada especifica\u00e7\u00e3o nasce alinhada \u00e0 arquitetura existente.<\/p>\n<h3 dir=\"ltr\">3. Defina quem aprova cada fase<\/h3>\n<p dir=\"ltr\"><strong>Nomeie os respons\u00e1veis e os crit\u00e9rios de aprova\u00e7\u00e3o de requisitos, desenho e tarefas<\/strong> antes da primeira execu\u00e7\u00e3o. Sem esse combinado, a aprova\u00e7\u00e3o vira formalidade e o m\u00e9todo perde a raz\u00e3o de existir.<\/p>\n<h3 dir=\"ltr\">4. Revise a especifica\u00e7\u00e3o como se revisa c\u00f3digo<\/h3>\n<p dir=\"ltr\"><strong>Trate a especifica\u00e7\u00e3o com coment\u00e1rios, pedidos de ajuste e aprova\u00e7\u00e3o expl\u00edcita<\/strong>, no mesmo fluxo da revis\u00e3o de c\u00f3digo. A participa\u00e7\u00e3o de quem conhece a regra de neg\u00f3cio nessa etapa \u00e9 o que revela as exce\u00e7\u00f5es n\u00e3o documentadas.<\/p>\n<h3 dir=\"ltr\">5. Me\u00e7a o resultado<\/h3>\n<p dir=\"ltr\">Compare tempo de ciclo e taxa de falha em mudan\u00e7as antes e depois de dois ciclos completos de entrega. O efeito desse tipo de ado\u00e7\u00e3o nos indicadores est\u00e1 detalhado no conte\u00fado sobre <a href=\"https:\/\/uds.com.br\/blog\/kiro-ai-produtividade-times\/\" target=\"_blank\" rel=\"noopener\">produtividade de times com o Kiro<\/a>, e a capacita\u00e7\u00e3o pr\u00e1tica do time \u00e9 tratada no conte\u00fado sobre treinamento de IA para times de desenvolvimento<\/p>\n<p dir=\"ltr\"><strong>Leia tamb\u00e9m:<\/strong><\/p>\n<ul dir=\"ltr\">\n<li><a href=\"https:\/\/uds.com.br\/blog\/como-instalar-configurar-kiro-ide\/\" target=\"_blank\" rel=\"noopener\">Como instalar e configurar o Kiro IDE?<\/a><\/li>\n<li><a href=\"https:\/\/uds.com.br\/blog\/ia-desenvolvimento-software-ferramentas\/\" target=\"_blank\" rel=\"noopener\">Ferramentas de IA para desenvolvimento de software<\/a><\/li>\n<\/ul>\n<h2 dir=\"ltr\">Quais ferramentas suportam <em>spec-driven development<\/em>?<\/h2>\n<p dir=\"ltr\"><strong>O <em>spec-driven development<\/em> pode ser praticado com qualquer agente capaz de ler arquivos versionados no reposit\u00f3rio, e o que muda entre as ferramentas \u00e9 o grau de formaliza\u00e7\u00e3o.<\/strong> Algumas oferecem as tr\u00eas fases como recurso nativo, enquanto outras exigem que o time crie a conven\u00e7\u00e3o manualmente. Na pr\u00e1tica, as op\u00e7\u00f5es se dividem em:<\/p>\n<ul dir=\"ltr\">\n<li><strong>IDEs com fluxo nativo:<\/strong> o Kiro, IDE da AWS, integra especifica\u00e7\u00f5es e arquivos de direcionamento ao editor, como mostra o <a href=\"https:\/\/uds.com.br\/blog\/kiro-aws\/\" target=\"_blank\" rel=\"noopener\">guia do Kiro AWS<\/a>;<\/li>\n<li><strong>Agentes de terminal:<\/strong> atendem ao mesmo m\u00e9todo com conven\u00e7\u00f5es pr\u00f3prias, compara\u00e7\u00e3o detalhada no conte\u00fado sobre <a href=\"https:\/\/uds.com.br\/blog\/claude-code-vs-kiro\/\" target=\"_blank\" rel=\"noopener\">Claude Code e Kiro<\/a>;<\/li>\n<li><strong>Agentes conectados a sistemas internos:<\/strong> usam o protocolo MCP para consultar dados e ferramentas da empresa durante a execu\u00e7\u00e3o.<\/li>\n<\/ul>\n<h2 dir=\"ltr\">Qual a import\u00e2ncia do <em>spec-driven development<\/em> para a empresa?<\/h2>\n<p dir=\"ltr\"><strong>O <em>spec-driven development<\/em> reduz o retrabalho causado por mal-entendidos sobre requisitos, que \u00e9 uma das principais fontes de atraso em times que geram c\u00f3digo com IA.<\/strong> Como a especifica\u00e7\u00e3o fica versionada, a empresa tamb\u00e9m <strong>ganha:<\/strong><\/p>\n<ul>\n<li dir=\"ltr\"><strong>Hist\u00f3rico das decis\u00f5es: <\/strong>algo valioso em auditorias e na entrada de novas pessoas no time;<\/li>\n<li dir=\"ltr\">Refor\u00e7o em pr\u00e1ticas como <strong>controle de vers\u00e3o bem estabelecido<\/strong> e <strong>trabalho em lotes pequenos.<\/strong><\/li>\n<\/ul>\n<p>Com especifica\u00e7\u00f5es curtas e revisadas, a velocidade da gera\u00e7\u00e3o de c\u00f3digo passa a vir acompanhada de previsibilidade na entrega.<\/p>\n<h2 dir=\"ltr\"><em>Spec-driven development<\/em> com a UDS<\/h2>\n<p dir=\"ltr\">Levar especifica\u00e7\u00e3o estruturada para dentro do fluxo de engenharia demanda padr\u00f5es documentados, crit\u00e9rios de aprova\u00e7\u00e3o definidos e indicadores acompanhados. A UDS Tecnologia tem 23 anos de mercado, \u00e9 AWS Advanced Consulting Partner e mant\u00e9m certifica\u00e7\u00f5es ISO 27001 e PCI DSS, credenciais que sustentam esse rigor em projetos com exig\u00eancia formal de qualidade. A experi\u00eancia da UDS com ferramentas ag\u00eanticas aparece no relato sobre <a href=\"https:\/\/uds.com.br\/blog\/uds-usa-kiro-projetos\/\" target=\"_blank\" rel=\"noopener\">como a UDS usa o Kiro em projetos<\/a>.<\/p>\n<p dir=\"ltr\">Esse cuidado com processo aparece tamb\u00e9m em entregas de longo prazo. No <a href=\"https:\/\/uds.com.br\/blog\/cases\/verocard-desenvolvimento-software-app\/\" target=\"_blank\" rel=\"noopener\">case da Verocard<\/a>, uma equipe de 16 especialistas da UDS construiu a plataforma pr\u00f3pria de benef\u00edcios da empresa, com arquitetura <em>serverless<\/em> baseada em microsservi\u00e7os na AWS, e a migra\u00e7\u00e3o da infraestrutura para a nuvem gerou 35% de economia e 75% menos chamados de suporte.<\/p>\n<p dir=\"ltr\">Quem quer estruturar esse m\u00e9todo internamente pode conhecer os servi\u00e7os de <a href=\"https:\/\/uds.com.br\/desenvolvimento-de-software\/\" target=\"_blank\" rel=\"noopener\">desenvolvimento de software<\/a> e a atua\u00e7\u00e3o da <a href=\"https:\/\/uds.com.br\/uds-tecnologia\/\">UDS.<\/a><\/p>\n<h2 dir=\"ltr\">Perguntas frequentes sobre <em>spec-driven development<\/em><\/h2>\n<h3 dir=\"ltr\">O que \u00e9 <em>spec-driven development<\/em>?<\/h3>\n<p dir=\"ltr\">\u00c9 uma forma de trabalhar em que a especifica\u00e7\u00e3o aprovada vem antes do c\u00f3digo e orienta toda a implementa\u00e7\u00e3o. O nome vem do ingl\u00eas e pode ser traduzido como desenvolvimento orientado por especifica\u00e7\u00e3o.<\/p>\n<h3 dir=\"ltr\"><em>Spec-driven development<\/em> serve s\u00f3 para projetos grandes?<\/h3>\n<p dir=\"ltr\">Serve para qualquer altera\u00e7\u00e3o cujo erro tenha custo relevante, inclusive corre\u00e7\u00f5es pequenas em sistemas cr\u00edticos. Em <em>scripts<\/em> descart\u00e1veis e em explora\u00e7\u00e3o, a formaliza\u00e7\u00e3o costuma custar mais do que entrega.<\/p>\n<h3 dir=\"ltr\">O m\u00e9todo deixa a entrega mais lenta?<\/h3>\n<p dir=\"ltr\">O tempo at\u00e9 a primeira linha de c\u00f3digo aumenta, e o tempo total at\u00e9 a entrega est\u00e1vel costuma cair, porque boa parte do retrabalho nasce de mal-entendidos sobre o requisito. Por isso, a compara\u00e7\u00e3o justa considera o ciclo inteiro da demanda.<\/p>\n<h3 dir=\"ltr\">Preciso de uma ferramenta espec\u00edfica?<\/h3>\n<p dir=\"ltr\">N\u00e3o \u00e9 obrigat\u00f3rio, j\u00e1 que o m\u00e9todo pode ser praticado com conven\u00e7\u00f5es manuais em qualquer agente que leia arquivos do reposit\u00f3rio. Ferramentas com suporte nativo ajudam principalmente times maiores, em que manter a mesma conven\u00e7\u00e3o entre muitas pessoas \u00e9 mais dif\u00edcil.<\/p>\n<h3 dir=\"ltr\">Quem escreve a especifica\u00e7\u00e3o?<\/h3>\n<p dir=\"ltr\">Normalmente o desenvolvedor respons\u00e1vel pela demanda, com apoio do agente para estruturar o texto em requisitos, desenho e tarefas. A revis\u00e3o envolve quem conhece a regra de neg\u00f3cio, porque \u00e9 nesse momento que aparecem as exce\u00e7\u00f5es n\u00e3o documentadas.<\/p>\n<h3 dir=\"ltr\">A especifica\u00e7\u00e3o substitui os testes?<\/h3>\n<p dir=\"ltr\">N\u00e3o. Os crit\u00e9rios de aceita\u00e7\u00e3o orientam quais testes escrever, e a verifica\u00e7\u00e3o automatizada continua necess\u00e1ria, j\u00e1 que especifica\u00e7\u00e3o e teste atuam em momentos diferentes, um antes e outro depois da implementa\u00e7\u00e3o.<\/p>\n<h3 dir=\"ltr\">Como o m\u00e9todo lida com mudan\u00e7a de escopo?<\/h3>\n<p dir=\"ltr\">Mudan\u00e7as entram como revis\u00e3o da especifica\u00e7\u00e3o, que \u00e9 versionada junto ao c\u00f3digo e passa por nova aprova\u00e7\u00e3o. Isso preserva o hist\u00f3rico da decis\u00e3o e evita altera\u00e7\u00f5es silenciosas que ningu\u00e9m consegue explicar meses depois.<\/p>\n<h3 dir=\"ltr\"><em>Spec-driven development<\/em> funciona para corre\u00e7\u00e3o de <em>bugs<\/em>?<\/h3>\n<p dir=\"ltr\">Funciona bem, com a especifica\u00e7\u00e3o descrevendo o comportamento observado, o comportamento esperado e o crit\u00e9rio de verifica\u00e7\u00e3o. Em <em>bugs<\/em> intermitentes, esse registro costuma ser o que permite reproduzir o problema de forma confi\u00e1vel.<\/p>\n<h3 dir=\"ltr\">Qual o maior erro de quem come\u00e7a?<\/h3>\n<p dir=\"ltr\">Escrever especifica\u00e7\u00f5es longas demais, que ningu\u00e9m revisa com aten\u00e7\u00e3o e que envelhecem antes de serem executadas. Escopo estreito e revis\u00e3o r\u00e1pida sustentam o m\u00e9todo muito melhor do que documentos extensos.<\/p>\n<h3 dir=\"ltr\">Como convencer o time a adotar?<\/h3>\n<p dir=\"ltr\">O argumento que costuma funcionar \u00e9 comparar o retrabalho de duas demandas semelhantes, uma conduzida de cada forma. N\u00fameros da pr\u00f3pria equipe convencem mais do que a descri\u00e7\u00e3o do m\u00e9todo em abstrato.<\/p>\n<h3 dir=\"ltr\">O que acontece se o agente ignorar a especifica\u00e7\u00e3o?<\/h3>\n<p dir=\"ltr\">Isso normalmente indica especifica\u00e7\u00e3o amb\u00edgua ou contexto insuficiente sobre os padr\u00f5es do projeto. Ajustar os arquivos de direcionamento e estreitar o escopo da tarefa resolve a maior parte desses casos.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Entenda o que \u00e9 spec-driven development, como ele funciona, quais s\u00e3o as tr\u00eas fases, quando ele vale mais que a abordagem informal e como aplicar no seu time.<\/p>\n","protected":false},"author":47,"featured_media":24377,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[864],"tags":[],"yst_prominent_words":[],"_links":{"self":[{"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/posts\/24376"}],"collection":[{"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/users\/47"}],"replies":[{"embeddable":true,"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/comments?post=24376"}],"version-history":[{"count":1,"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/posts\/24376\/revisions"}],"predecessor-version":[{"id":24378,"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/posts\/24376\/revisions\/24378"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/media\/24377"}],"wp:attachment":[{"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/media?parent=24376"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/categories?post=24376"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/tags?post=24376"},{"taxonomy":"yst_prominent_words","embeddable":true,"href":"https:\/\/uds.com.br\/blog\/wp-json\/wp\/v2\/yst_prominent_words?post=24376"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}