Os bugs fazem parte da dívida técnica?

Nosso Scrum Master continua se referindo a bugs como dívida técnica. Ele está certo, os bugs são considerados dívida técnica no mundo do Agile?

Penso que a resposta aqui é bastante simples - a principal característica da dívida técnica é que é algo que incorremos por opção.

Optamos por tomar decisões de arquitetura, design ou implementação que esperamos que causem problemas mais tarde, a fim de alcançar objetivos específicos mais cedo.

Um bug não é algo que escolhemos ter em nosso código - de fato, não é uma dívida técnica.

É claro que se pode fazer todos os tipos de argumentos interessantes (e possivelmente válidos) sobre as escolhas feitas após a descoberta, mas fundamentalmente (e particularmente no contexto da questão) não, os bugs não são dívida técnica - parece-me mais um abuso de buzzword.

Como pós-escrito - não concordo com a afirmação de que, dado que a dívida técnica levará a erros por si só, isso leva a muitas suposições sobre a natureza das escolhas feitas. Por exemplo, você pode ter códigos bem escritos, bem estruturados e cobertos por testes que ainda comprometem, digamos, a arquitetura, para entrega antecipada. Da mesma forma, você pode optar por não automatizar seus processos de implantação, o que não causará bugs, mas provavelmente causará muito estresse e dor. É claro que se a dívida é que você escreveu um código que não é SOLID (ou o que seja), então sim ... mas isso não é sempre o caso.

Sim.

Dívida técnica (também conhecida como dívida de projeto ou dívida de código) é uma metáfora neologística que se refere às conseqüências eventuais da arquitetura ou desenvolvimento de software ruim ou em evolução dentro de uma base de código.

Fonte: Wikipedia

Leia a dívida técnica como algo que você poderia ter evitado com um melhor fluxo de trabalho (por exemplo, fazendo arquitetura corretamente antes de passar para a codificação, fazendo TDD etc.), melhores práticas de codificação etc.

A maioria dos erros poderia ter sido evitada por uma revisão adicional ou pelo uso de métodos mais formais. Ao não fazer tudo o que pode para não ter bugs, você reduz o custo imediato / a curto prazo do projeto, mas aumenta a dívida técnica.

Depois de ler a resposta de BЈовић , vejo que pode não ser tão fácil quanto eu pensava.

• Por exemplo, os bugs fazem parte da dívida técnica? O artigo afirma que apenas os bugs que você conhece, mas que decidiu não consertar, fazem parte da dívida técnica.

• Outro exemplo, os Pensamentos de Christopher sobre a dívida técnica qualificam os erros como resultado de uma dívida técnica, e não parte dela. Dito isto, muitos dos resultados listados, como "custo para implementar novos recursos", são influenciados pelo número de bugs.

• Finalmente, ao criar o modelo de dívida técnica ABCDE-T , incluí os bugs como um dos seis fatores, mas eles são considerados de maneira diferente. O foco não está nos próprios erros, mas nas maneiras como eles são coletados, priorizados e resolvidos. Os próprios bugs aparecem como resultado de uma dívida técnica (como no exemplo anterior), mas nunca aparecem como um fator de dívida técnica.

Dito isto, ainda estou inclinado a responder que os bugs - todos os bugs - fazem parte da dívida técnica.

Primeiro argumento:

Lendo a citação de Jeff Atwood, a maioria dos erros se qualificaria como:

o esforço extra que temos que fazer no desenvolvimento futuro por causa da escolha rápida e suja do projeto

Nos aplicativos de negócios, quase todos os erros vêm de opções de design rápidas e sujas ou de práticas inadequadas (seria a falta de teste, o uso de tecnologias que os desenvolvedores não conhecem o suficiente, falta de comunicação, falta de entendimento do domínio, etc.) Isso significa que "refatorando o design rápido e sujo para o melhor design" e adaptando as melhores práticas, as empresas poderiam resolver a maioria dos erros.

Segundo argumento:

Se fizermos um paralelo entre a dívida ordinária de uma empresa, que é importante levar em consideração quando uma empresa é vendida para outra, e a dívida técnica, que é igualmente importante a ser levada em consideração quando um projeto é vendido para outra empresa ou para outra equipe, podemos ver facilmente que os bugs fazem parte da dívida técnica, pois a nova equipe faria:

• Você precisa lidar com esses bugs antes de criar novos recursos (ponto 5 do Joel Test: você corrige bugs antes de escrever um novo código?)

• Ou mantenha os bugs, preservando / aumentando desta forma a dívida técnica.

Jeff Atwood, em seu artigo Pagando sua dívida técnica, fornece uma resposta bastante agradável sobre o que é dívida técnica:

a dívida técnica incorre em pagamentos de juros, que vêm na forma do esforço extra que temos que fazer no desenvolvimento futuro por causa da escolha rápida e suja do projeto. Podemos optar por continuar pagando os juros ou pagar o principal, refatorando o design rápido e sujo para o melhor design. Embora custe pagar o principal, ganhamos com pagamentos de juros reduzidos no futuro.

A rigor, os bugs não fazem parte da dívida técnica, se não atrasam o desenvolvimento de software (mudando as coisas, adicionando novos recursos, etc.). Eles são defeitos de software.

No entanto, quando é muito caro corrigir um bug ou o força a contorná-lo (e introduzir ainda mais dívida técnica), ele se torna parte de uma dívida técnica.

Um bug não é uma dívida técnica. A dívida técnica está diminuindo a qualidade, não a ausência dela. O software não deve ser entregue com erros em primeiro lugar. Você sabe, todo esse software funcionando sobre documentação abrangente.

Os maiores infratores da dívida técnica são as "correções temporárias de erros", você sabe as que colocou para passar no teste e aceita a história. As que você prometeu a si mesmo que refatoraria mais tarde, mas nunca o fará. À medida que essas correções temporárias, patches e outras coisas se acumulam, o código se torna desnecessário desordenado, difícil de atualizar e testar e, em geral, é um pesadelo, mas ainda funciona.

Para apoiar essa opinião, fui direto à fonte, Ward Cunningham. Quanto a isso, Ward fez uma boa entrevista há algum tempo com Capers Jones, vale a pena assistir.

Debate técnico da dívida, com Ward Cunningham & Capers Jones

Outro artigo que vale a pena ler é de Martin Fowler

Martin Fowler sobre Dívida Técnica

No artigo de Martin, encontre o link para a menção original de dívida técnica por Ward Cunningham, de OOPSLA92:

O Sistema de Gerenciamento de Portfólio WyCash

Uma citação do artigo acima:

Embora o código imaturo possa funcionar bem e ser completamente aceitável para o cliente , quantidades excessivas tornarão um programa desorganizável, levando a uma especialização extrema dos programadores e, finalmente, um produto inflexível. Enviar código pela primeira vez é como entrar em dívida.

No final, a Dívida Técnica pode ter incluído bugs para algumas pessoas, e acho que está bem. Eu simplesmente não acho que essa era a intenção original.

A rigor, a resposta para sua pergunta é Não.

Dívidas técnicas podem (e provavelmente levarão) a erros, mas concluir que qualquer bug é o resultado de uma dívida técnica está colocando uma interpretação entre dois fatos: há um bug e há uma dívida técnica (supondo que possa ser concluído como fato).

Se o seu Scrum Master está afirmando 'como uma teoria' que os erros são o resultado de uma dívida técnica, ele está cortando os cantos. Se ele está dizendo isso sobre erros específicos que continuam aparecendo, ele pode estar certo - não podemos ver a qualidade do código a partir daqui ;-)

Ele também pode ter uma reclamação em andamento sobre pessoas que não o ouvem sobre a dívida técnica e, portanto, rotular cada bug como dívida técnica, mas agora estou especulando.

Na minha opinião, realmente não importa se você diz que os bugs fazem parte da dívida técnica ... ou não.

O fato claro é que os erros existentes representam um trabalho extra que pode precisar ser executado no futuro, para corrigi-los ou contorná-los.

A dívida técnica (como o rótulo normalmente é usado) também representa um trabalho extra que pode precisar ser executado no futuro ... de uma maneira ou de outra.

Então, se você diz que erros conhecidos (ou desconhecidos) são dívida técnica ... ou não ... é realmente apenas uma questão de definições. E como não há uma definição autorizada ¹ de "dívida técnica", toda a discussão é meio inútil.

Como Lewis Carroll escreveu:

"Quando uso uma palavra", disse Humpty Dumpty, num tom desdenhoso, "significa exatamente o que escolho que signifique - nem mais nem menos". .

É assim que a linguagem natural funciona. Palavras significam o que as pessoas pensam que significam. As definições de dicionário e assim por diante meramente documentam a maneira como as palavras são usadas e não são necessariamente uma documentação precisa. Se seu Scrum Master quer se referir a erros conhecidos como dívida técnica, quem pode dizer que ele está "errado"?

^{1 - Citar pessoas como Ward Cummingham e Caper Jones também não ajuda. Na melhor das hipóteses, ele nos diz o que eles significam (ou significam) quando usam (usam) a frase. Eles não "possuem" a frase. Embora sejam indubitavelmente autoridades sobre essas questões, essa ainda é apenas a opinião deles.}