Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Disseminando conhecimento e inovação em desenvolvimento de software corporativo
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Postado por Vikas Hazrati , traduzido por Rodrigo Branas em 26 Out 2009
O termo "dívida técnica" foi definido por Ward Cunningham. e descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de implementar no curto prazo mas com grande impacto negativo no longo prazo. Alguns agilistas opinaram sobre o que deve ser considerada dívida técnica e como poderia ser classificada.
Martin Fowler sugeriu a seguinte definição para dívida técnica,
A dívida técnica é similar à dívida financeira. Assim como a dívida financeira, a dívida técnica exige o pagamento de juros. Estes vem na forma de esforço extra, que devem ser pagos em desenvolvimentos futuros por conta da escolha de um design mais rápido e de baixa qualidade. Nós podemos optar por continuar pagando estes juros ou quitar de uma vez a dívida fazendo uma refatoração, transformando um design de baixa qualidade em um design melhor. Apesar dos custos para saldar a dívida, ganhamos reduzindo os juros no futuro.
Steve McConnell classificou a dívida técnica em dois tipos,
Uncle Bob, adiciona que muitas vezes um código bagunçado é considerada divida técnica. Mas isso está errado. Segundo ele,
Bagunça não é dívida técnica. Bagunça é só bagunça. Decisões que geram dívidas técnicas se baseiam em restrições do projeto. Elas são arriscadas, mas podem trazer beneficios. A decisão de fazer uma bagunça no código nunca é racional; é sempre baseada na preguiça e na falta de profissionalismo e não têm chances de ser pagas no futuro. A bagunça é sempre uma perda.
Uncle Bob sugere que a dívida técnica cria a necessidade de limpeza no código, assim como a necessidade de ser mais disciplinado quando assumir uma grande dívida. Ele adiciona que uma vez que a equipe decida assumir um dívida técnica, torna-se ainda mais importante manter o código completamente limpo. Caso contrário, a situação poderá se agravar e pagar a dívida pode se tornar um grande desafio.
Martin Fowler aponta que bagunça também é um dívida técnica embora de natureza diferente. Ele a descreve como dívida irresponsável, a qual resulta em desafios ainda maiores se comparados com uma dívida prudente baseada em uma situação pensada. Além disso, ele classifica a dívida técnica como proposital e sem querer para completar a lista.
Martin cita os seguintes exemplos de classificação de dívidas técnicas:
Desta forma, ter uma dívida técnica em um projeto é normalmente inevitável e deve ser considerado como sendo uma expectativa. A chave está em ter certeza de que o time não está introduzindo dívidas irresponsáveis que contribuem para bagunçar o código e são muito difíceis, senão impossíveis de lidar.
Em português, a tradução correta de "technical debt" seria "dívida técnica" e não "débito técnico".
debt = dívida (algo que não foi pago e precisará ser pago no futuro)
debit = débito (um valor que foi retirado de uma conta). Sugiro, se possível, acertar a tradução do artigo para usar o termo correto.
Fazendo a tradução correta, o termo dívida deixa mais claro o problema e o que significa isso. Débito dá mais a ideia de que está faltando algo, que foi retirado algo. Dívida dá mais a ideia de algo que o time está devendo algo tecnicamente.
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.
Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.
Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.
O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.
Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.
Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.
Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.
2 comentários
Acompanhar Discussão Responder