Building Minds - o Blog da OnCast

Defino Débito Técnico como a distância entre o estado de um artefato técnico e como ele o seria em seu estado da arte. No ramo de desenvolvimento de software, é a medida de quanto uma deficiência técnica compromete o futuro do projeto e pode ser utilizado para antecipar problemas como bugs, baixa produtivadade, dificuldades com manutenção e dificuldades com transferência de tecnologia. Sua unidade é o spag (Sg), ou spaghetti :).

O termo foi cunhado em 1992 por Ward Cunningham, mas até hoje não há consenso de seu significado. Steve McConnell divide Débito Técnico em duas categorias: Intencional e Não Intencional (leia seu artigo). Uncle Bob em seu artigo “A Mess is not a Technical Debt” fala que um débito técnico não intencional (negligente) não deve ser considerado débito técnico. Martin Fowler subdivide débito técnico de duas maneiras: Prudente/Imprudente e Intencional/Inconsciente, gerando os quadrantes de débito técnico.

Minha classificação é algo como a de Steve. É muito útil determinar a existência de um Débito Técnico apenas avaliando o software em si, sem considerar as condições em que foi inserido. A separação entre intencional e não intencional não pode ser determinada apenas analisando o artefato. Um código mediano não é inapropriado se houve estratégia e todos estão conscientes das consequências da sua inserção.

Logo, a todo código ruim ou mediano dou o nome de Débito Técnico, a todo código que compromete o produto ou o futuro do projeto. É uma métrica direta da qualidade do software. Utilizo a subdivisão Intencional/Inconsciente para identificar se houve/não houve justificativas estratégicas para tal débito. As classificações Prudente/Imprudente dadas por Martin, credito mais à equipe, e não ao débito técnico em si.

Vamos descorrer um pouco mais sobre a distinção entre Débito Técnico Intencional e Débito Técnico Inconsciente.

Débito Técnico Intencional

Fazer o refactoring para abrigar a nova funcionalidade nos custará 5 dias, utilizar a arquitetura atual, mesmo que entortando alguns conceitos, nos custará 1 dia. Nossa entrega é no meio desta semana e a multa por atraso é indecente.

Qualquer gestor responsável diria:

1 dia! Faremos simplista agora! Agendamos um refactoring na próxima release, mesmo que nos custe 10 dias depois.

Existem momentos na vida de um projeto que atingir os deadlines é mais importante que a qualidade. O mundo está cheio de desafios: concorrência acirrada, time-to-market, pressões externas e internas… Não observar estes desafios é a pior das negligências de um projeto. De nada adianta um projeto que não atinge seus objetivos. Conhecer os prós e contras de suas estratégias é primordial para fazer a escolha correta.

Em uma boa equipe Scrum, o Product Owner tomaria esta decisão, principalmente porque conhece as necessidades do mercado. À equipe técnica (team) cabe o papel de levantar alternativas e alertar o Product Owner sobre os prós e contras de cada uma. O balanço entre qualidade e metas é o resultado esperado, bem como um agendamento de refactorings para amortizar o eventual débito técnico resultante.

Débito Técnico Inconsciente

Este débito técnico pode ser incorrido por algumas razões:

• Uma equipe técnica iniciante falha ao enxergar uma solução que não comprometa o futuro do projeto.
• O Product Owner é negligente ao considerar os riscos de suas ações, não considera os argumentos da equipe técnica e falha ao avaliar as necessidades de médio e longo prazo de seu projeto.
• O imponderável, algo que não pode ser antecipado nem por uma equipe sênior. Isto é comum a trabalhos de pesquisa e desenvolvimento de cunho científico.

De maneira geral, acredito que nem todo Débito Técnico não intencional seja negligente. Como visto acima, existem casos em que a complexidade do trabalho irá impor que débito técnico seja naturalmente inserido e permaneça desconhecido por algum tempo. Isto não configura negligência. Entretanto, ignorar o fato de que débitos técnicos serão inseridos é negligência. Cabe à equipe toda monitorá-los e corrigi-los a medida que sejam identificados.

Rodrigo Machado Metáforas, Riscos

Essa foi a pergunta que a Mirela, nossa Assessora de Marketing, fez ao Adriano e ao Samuel, dois dos três sócios da OnCast Technologies. Após receber várias respostas enumerando as qualidades do SCRUM/XP/Lean, me permitiram que falasse sobre uma delas. Expliquei que havia me identificado bastante com a característica do processo ágil que permite desenvolvimento de software sustentável, um dos princípios elencados no Manifesto Ágil.
Uma das maneiras de se atingir isso é com a criação de código simples, outro princípio discretizado no Manifesto Ágil. Com um código simples torna-se fácil a percepção de falhas precocemente, atacando cedo, aquele que poderia ser o câncer de todo o processo. Acabei criando o seguinte exemplo para explicar essa faculdade:

Imagine que um cliente nos peça que façamos uma casinha de Lego de determinada cor. Para isso nos entrega todas as peças necessárias sem notar que nos havia entregue uma peça de outra cor.

Caso executássemos essa tarefa utilizando o desenvolvimento tradicional, tirando toda burocracia envolvida, faríamos a casa e ao terminar, perceberíamos que na base da casa havia uma peça de cor errada. Isso implicaria em desconstruir toda a casa e, por sua vez, reconstruí-la, perdendo um tempo que o cliente provavelmente não possuía.

Caso estivéssemos usando o desenvolvimento ágil, teríamos notado a peça errada antes mesmo de terminar a casa, faríamos sua troca pela peça correta e continuaríamos nosso desenvolvimento sem essa perda tão considerável de tempo.

O que quis dizer com este exemplo é que um problema, dentro do desenvolvimento ágil, é atacado assim que é encontrado, desta forma é suplantado, minimizando o tempo gasto com isso.

Fazendo um gancho do exemplo do Lego com o desenvolvimento de softwares, podemos lembrar do Test-Driven Development (TDD) que é a abordagem que nos ajuda a encontrar a “peça” errada, antes desta “peça” influenciar nas outras “peças” que compõe o software.

Em suma, pode-se dizer que o desenvolvimento ágil tenta mitigar o efeito “bola de neve”, tornando mais simples e contínuo o processo criativo.

Marcelo Silva Ferramentas, Metáforas, Riscos