Você sabe o que é isso. Colocar tudo o que você precisa no sprint já é muito difícil, mas você ainda precisa encontrar em outro lugar 10 a 20% do tempo dos desenvolvedores para devolver a dívida técnica . Se você já defendeu a necessidade de reservar tempo para isso, sabe que isso é como uma cruzada de proporções épicas.
Mas você pode fazer isso e, neste guia, descobriremos exatamente como.
Eu já vi muitas reuniões em que exatamente essa questão passou muito tempo. Os argumentos geralmente são infundados, e as emoções podem aumentar - e aquela com a voz mais alta da sala vence.
O dilema é o seguinte: se a pressão dos negócios supera, sua empresa corre o risco de ganhar muita dívida técnica - e então os desenvolvedores perdem a motivação, a empresa chega à falência técnica e seus concorrentes o derrotam. Se você superar a pressão dos desenvolvedores , a empresa corre o risco de assumir muito pouco débito técnico e seus concorrentes poderão fornecer produtos e recursos mais rapidamente, capturar o mercado e, posteriormente, usar o lucro recebido para devolver o débito técnico. Você está perdendo de novo.
O senso comum sugere que as equipes de desenvolvimento desenvolvam uma compreensão intuitiva da base de código, onde a dívida técnica se esconde, bem como suas conseqüências para a empresa, construindo assim a confiança dentro da organização. Se o seu principal arquiteto e fundador disser que você precisa refatorar agora, você (normalmente) simplesmente aceita e faz.
Faz sentido tentar reter seus desenvolvedores para criar uma cultura de conhecimento, troca e confiança. Mas levará anos de trabalho duro e, terminando a refatoração, ainda não temos quase nenhuma ideia se perdemos nosso tempo. Talvez tenhamos economizado alguns dias no tempo de desenvolvimento futuro? Ou podemos esperar um pouco para pagar a dívida técnica mais tarde e, em vez disso, adicionar alguns novos recursos? Nunca sabemos ao certo e atribuímos nossa ignorância ao fato de que o desenvolvimento de produtos é mais uma arte do que uma ciência.
Bem, é hora de adicionar um pouco de ciência ao processo.
Qual é a confiabilidade semelhante do site e o orçamento da dívida técnica
Uma dívida técnica adequadamente gerenciada e planejada com propósito pode ser uma ferramenta inestimável. Percebendo o que estamos fazendo, podemos usá-lo da mesma forma que usamos a dívida financeira como alavancagem. Mas se, sem suspeitar disso, assumimos muito - por exemplo, não entendemos completamente os termos da transação (isto é, o impacto que a dívida técnica tem em nossa base de códigos, clientes, equipe e negócios) - o negócio pode terminar no colapso de nossa empresa.
As melhores equipes de gerenciamento de confiabilidade do site operam com seu orçamento de confiabilidade do site em termos de dívida técnica gerenciada. Confiabilidade do site é um conceito popularizado pelo Google; ela é responsável por manter o software em um estado "operacional", mas, curiosamente, empresas como o Google não pretendem aumentar o tempo de atividade para 100%. O motivo é que um tempo de atividade de 99,99% é suficiente para que os produtos do Google sejam excepcionalmente confiáveis para usuários reais. E este último 0,01% é exponencialmente difícil de alcançar, e simplesmente não faz sentido lutar por isso.
Portanto, se isso der um total de 52 minutos de inatividade por ano, o Google tentará chegar o mais próximo possível desse valor; mas tudo o que é menos de 52 minutos por ano é uma oportunidade perdida de correr riscos adicionais e fornecer rapidamente recursos promissores aos seus clientes.
Pense no seu orçamento de dívida técnica como um orçamento para a confiabilidade do site. Desde que você assuma uma dívida técnica razoável e fique abaixo da quantia máxima de dívida que pode pagar antes que ela comece a afetar seus clientes e negócios, você deve aumentar a quantidade de dívida para assumir mais riscos e vencer seus concorrentes.
Se sua dívida técnica estiver na zona vermelha, você precisará pagá-la parcialmente. Se ele estiver na zona verde, você pode assumir mais riscos e mais dívidas. Seu objetivo é manter constantemente o montante da dívida o mais próximo possível do ideal. Em outras palavras, se você está no auge da parte vermelha do gráfico, o orçamento ideal para a dívida técnica é A ⇒ B. Se você está na depressão da parte verde do gráfico, o orçamento ideal é C ⇒ B. Lembre-se apenas de que A ⇒ C é um orçamento muito grande para a dívida técnica .
Como a dívida técnica pode ser mensurada (escrevemos sobre isso em outro artigo ), isso agora não é apenas um conceito - ele atende totalmente às necessidades práticas.
Como tirar o máximo proveito do seu orçamento de dívida técnica
Você deve se esforçar para obter um orçamento de dívida técnica que o devolva para cima ou para baixo, até o valor máximo da dívida técnica que puder pagar. Para determinar esse orçamento, especifique nas áreas de base de código onde a dívida técnica deve ser paga imediatamente, ou seja, dívidas que impedirão sua empresa de atingir seus objetivos atuais. Não é aconselhável que você pague muito pouca dívida ou muito.
Andreas Klinger , coordenador de equipe remota da AngelList, descreve isso bem em seu artigo Refatorando grandes bases de código herdado :
Nem tudo precisa ser refatorado. Se essa não é uma parte crítica, ou ninguém precisa melhorar essa funcionalidade nos próximos meses, ou é muito complicado, considere reconhecer esse local como uma dívida técnica.
Simplificando, seu objetivo é descobrir onde duas coisas se sobrepõem: o que você trabalhará no sprint atual, mês ou trimestre e as partes da sua base de códigos que contêm dívida técnica. Pague a dívida na área desse cruzamento, mas não além.
E é aqui que a ciência complementa a arte. Você pode usar os dados para identificar áreas nas quais você precisa pagar dívidas técnicas em um futuro próximo:
- Destaque arquivos com baixa propriedade em sua base de códigos, pois a propriedade de código é um indicador importante do bem-estar de sua base de códigos. Mais sobre isso em nosso artigo "Um recurso da cultura corporativa necessário para o bem-estar da base de código" .
- Avalie a coesão e o acoplamento desses arquivos e deixe apenas arquivos com baixa propriedade, baixa conectividade e alta velocidade na lista. Você pode aprender mais sobre cada um desses indicadores em nosso artigo "Usando estudos de líderes da indústria para medir dívida técnica" .
- Calcule a atividade recorrente (rotatividade) de cada um desses arquivos para determinar um subconjunto dos arquivos problemáticos. De acordo com um estudo da Microsoft , a alteração ativa de arquivos representa apenas 2 a 8% do total de arquivos no sistema, mas eles representam 20 a 40% de todas as alterações e são responsáveis por 60 a 90% de todos os erros.
- Relacione a lista de arquivos resultante aos seus planos trimestrais. Algum dos recursos listados em seus planos exigirá que você trabalhe em um subconjunto dos arquivos com problemas descritos? Se sim, defina metas relacionadas à refatoração desses arquivos, avalie a quantidade necessária de trabalho e atribua tarefas a desenvolvedores específicos, preferencialmente aqueles que possuem os arquivos correspondentes. Inclua esse trabalho em seus planos.
Para começar, dê uma olhada na nossa extensão gratuita VSCode - ela ajudará você a monitorar e pagar constantemente as dívidas técnicas mais urgentes.
Estabelecer um relacionamento de longo prazo com dívida técnica
Implementamos essa abordagem baseada em dados no Stepsize, bem como em muitas empresas de software de classe mundial. Agora, o tópico da dívida técnica não apenas se tornou muito mais claro, como também sabemos quanta dívida estamos prontos para assumir, e quando / como devolvê-la. Todos raramente pensamos se escolhemos corretamente um compromisso entre novos recursos e dívida técnica. Conseguimos eliminar uma parte significativa da adivinhação, bem como muitos medos e ansiedades que acompanharam essa escolha.
Vamos esclarecer novamente: essa não é uma bala de prata que pode ser usada uma vez por ano e depois esquecida. Você precisa conhecer melhor seu dever técnico. Acompanhe seu progresso em todos os indicadores de cada sprint e continue a melhorar todo o processo para alcançar o bem-estar técnico .
Nós escrevemos sobre várias maneiras de fazer isso, para criar a motivação certa, ler sobre como cultivar uma cultura de desenvolvimento baseada na propriedade e honrar os desenvolvedores que retornam dívidas técnicas .