Questão de Engenharia de Software — Geral — CESPE / CEBRASPE 2024

Dívida Técnica e Gestão de Requisitos

✅ CERTO. A afirmação está correta: a gestão de dívida técnica é um processo contínuo e pragmático, e não pagar algumas dívidas técnicas é uma decisão legítima e esperada dentro desse processo. A dívida técnica representa o custo implícito de escolhas de implementação que priorizam a entrega rápida em detrimento da qualidade ideal; gerenciá-la envolve priorizar quais dessas dívidas serão pagas (refatoradas) e quais serão aceitas e adiadas, com base em critérios como risco, custo e valor de negócio. Essa decisão faz parte da gestão dos problemas encontrados na implementação dos requisitos, pois nem toda dívida precisa ser quitada imediatamente — algumas podem ser postergadas ou até mesmo aceitas permanentemente.

A dívida técnica é um conceito central na engenharia de software moderna, especialmente em metodologias ágeis. Ela surge quando a equipe opta por uma solução mais rápida e menos robusta para cumprir um prazo ou entregar uma funcionalidade, acumulando um "débito" que precisará ser pago no futuro, na forma de retrabalho, correções ou dificuldade de manutenção. O termo foi cunhado por Ward Cunningham, que comparou o código mal estruturado a uma dívida financeira: se não for paga, acumula juros (complexidade crescente, bugs, lentidão no desenvolvimento).

A gestão da dívida técnica não é uma atividade binária (pagar tudo ou não pagar nada). É um processo de priorização contínua, onde a equipe deve avaliar:

• O custo de pagar a dívida agora (tempo e esforço de refatoração);

• O custo de não pagar (juros: bugs, dificuldade de adicionar novas funcionalidades, queda de desempenho);

• O valor de negócio de cada funcionalidade afetada.

Com base nessa análise, a equipe decide quais dívidas serão pagas em uma sprint futura, quais serão monitoradas e quais serão aceitas como parte do custo de fazer negócios. Essa decisão é, portanto, uma parte intrínseca da gestão dos problemas encontrados na implementação dos requisitos, pois a dívida técnica é frequentemente descoberta durante o desenvolvimento, quando os requisitos são implementados de forma apressada ou com soluções de contorno.

A banca explora aqui a ideia de que "dívida técnica" é algo intrinsecamente ruim e que deve ser sempre eliminada. No entanto, a prática e a teoria da engenharia de software reconhecem que nem toda dívida técnica precisa ser paga. Algumas dívidas são "estratégicas" — assumidas conscientemente para acelerar uma entrega crítica — e podem ser mantidas indefinidamente se o custo de pagá-las for maior que o benefício. Outras dívidas são "involuntárias" e devem ser priorizadas para pagamento. A gestão eficaz é justamente a capacidade de distinguir entre essas situações e tomar decisões informadas.

Na prática, ferramentas como o Dívida Técnica Quadrante (de Martin Fowler) classificam as dívidas em quatro tipos: imprudente vs. prudente e deliberada vs. inadvertida. Uma dívida "prudente e deliberada" é aquela assumida conscientemente, como quando a equipe entrega uma solução simplificada para validar uma hipótese de negócio rapidamente. Essa dívida pode ser mantida por um longo período, ou até para sempre, se a funcionalidade não for crítica. Já uma dívida "imprudente e inadvertida" (código mal escrito por falta de conhecimento) deve ser paga o quanto antes.

Portanto, a afirmação do enunciado está correta porque reflete a natureza pragmática da gestão de dívida técnica: ela não é sobre eliminar todas as dívidas, mas sobre gerenciá-las de forma inteligente, priorizando o pagamento daquelas que trazem mais risco e adiando ou aceitando aquelas que são menos impactantes. Essa decisão é parte integrante da gestão dos problemas encontrados na implementação dos requisitos, pois a dívida técnica é um dos principais problemas que surgem durante o desenvolvimento.

✅ CERTO.