Cada produto evolui de uma maneira misteriosa. Mesmo a equipe experiente não consegue prever cada reviravolta no ciclo de vida do produto. Recursos simples podem ser transferidos para fluxos de trabalho multicondições monstruosos. Alguns cenários paralelos de desenvolvimento rápido podem se tornar os mais usados. Até mesmo a popularidade do produto pode gerar problemas inesperados de desempenho. E é completamente normal adaptar o software às necessidades do mercado. A única maneira de ter um produto confiável e previsível é reservar algum tempo para consertar dívidas técnicas e fornecer um processo de refatoração adequado. É melhor incluir algumas definições de termos neste artigo. Dívida técnica, ou dívida tecnológica, são os comprometimentos acumulados na base de código, que podem ocorrer durante o desenvolvimento rápido ou outras flutuações. O processo de refatoração é mais sobre melhorar o produto em geral. Pode envolver atividades relacionadas ao desempenho, melhor estrutura de código e simplicidade da solução. No entanto, às vezes esses dois conceitos podem ser muito próximos. Por exemplo, alguns recursos cheios de dívida tecnológica podem exigir a refatoração adequada de todo o módulo para corrigir o problema de uma vez por todas com novas ideias e reimplementação. E aqui está o truque. Em geral, bons desenvolvedores de software têm muitas ideias para melhorias de produtos. "Ok, poderíamos ajustar algumas coisas durante esse recurso." "Ah, isso não é tão importante, mas seria legal consertar essa coisa neste módulo lateral". Ainda assim, é crucial permitir que os membros da sua equipe tenham a oportunidade de aprimorar a base de código, pois isso ajuda a construir equipes realmente envolvidas. No entanto, neste artigo, gostaria de revelar o processo de refatoração da perspectiva de um gerente. Os exemplos acima têm um problema - eles podem ser opacos para toda a equipe, exceto os desenvolvedores. Embora o QA e os gerentes tenham seu plano para lançar software adequado e estável no prazo, algumas melhorias ocultas podem criar reviravoltas inesperadas e novos testes nervosos durante o lançamento. Ou até mesmo novos bugs na produção se, durante o estágio de regressão, algumas mudanças não documentadas passarem despercebidas. Portanto, as melhorias de código são necessárias, mas devem ser gerenciáveis. Como construir um processo de refatoração gerenciável em sua equipe A solução é complexa. Agile é nosso melhor amigo porque princípios e rituais comuns de metodologias de desenvolvimento Agile cobrem pontos problemáticos. Você precisa: Crie um backlog de dívida técnica e aloque recursos regularmente. Estabeleça processos adequados de preparação e planejamento para descobrir possíveis melhorias. Declare processos em caso de problemas inesperados durante a iteração. Por preparação, quero dizer comunicação entre membros da equipe antes da iteração, visando definir o escopo da iteração, especificar requisitos, decompor tarefas, estimar esforços e priorizar itens de trabalho futuros. O processo de planejamento está conectado com o escopo resultante da iteração. Nem toda tarefa preparada pode ser incluída na iteração. Vamos nos aprofundar em cada tópico. Construindo backlog de dívida técnica e regra de alocação de recursos A maneira mais fácil para cada desenvolvedor construir um backlog de dívida técnica é usar tags “To do” no código-fonte. Mais tarde, você pode pesquisar a base de código, melhorar algo e enviar solicitações de pull para aprovação. Mas isso não é suficiente. Não ajuda os membros da equipe a fornecer planejamento adequado e a ter certeza sobre o escopo do lançamento. A melhor alternativa ao uso de “To Do” é estabelecer um processo para criar as tarefas para mudanças futuras. Se o desenvolvedor encontrar algum ponto problemático em potencial ou tiver uma ideia para melhorar a base de código, ele deve criar um item de trabalho no sistema de tickets (Jira, Azure DevOps ou qualquer sistema que a equipe use). Seria exagero exigir que os engenheiros forneçam uma descrição detalhada de sua ideia para cada membro da equipe, mas a explicação deve ser clara o suficiente para que o líder da equipe entenda o ponto-chave e o escopo das mudanças. Isso abrange a primeira etapa - como podemos criar uma lista de tarefas potenciais e fornecer uma descrição de alto nível de mudanças futuras. O segundo passo é torná-lo compreensível para todos. Essa tarefa pode ser tratada pelo líder da equipe de desenvolvimento, gerente de lançamento ou gerente de produto, dependendo de sua qualificação. O resultado deve fornecer os seguintes detalhes: O que estamos fazendo? - Uma explicação de alto nível da ideia. Por que estamos fazendo isso? - Uma descrição de como essas mudanças podem melhorar a velocidade de desenvolvimento, reduzir o risco de instabilidade causada pelo código espaguete ou aumentar o desempenho do software. Quão importantes são essas mudanças para o desenvolvimento futuro? - A prioridade das mudanças. Por exemplo, sem essas mudanças, o custo de melhorias futuras ou recursos de negócios pode crescer exponencialmente. Quais riscos essas mudanças criam? - Uma lista de recursos ou módulos afetados para ajudar o controle de qualidade a verificar as mudanças. Se o item de trabalho tiver respostas para todas essas perguntas, ele ajuda a mitigar problemas potenciais no futuro. No entanto, ter um backlog sozinho não é suficiente para uma refatoração gerenciável. Você precisa planejar possíveis mudanças, e elas devem ser uma parte constante do seu processo. Claro, você enfrentará a pressão de recursos de negócios e demandas de mercado, onde a tentação de omitir tarefas técnicas é alta. Mas sem a manutenção adequada, você enfrentará problemas ainda maiores no futuro. A recomendação para o processo de backlog de tecnologia é: Em cada iteração, a equipe deve reservar tempo para melhorias tecnológicas. Se houver alguma ideia de melhoria, ela deve ser formalizada como um item de trabalho com uma descrição adequada. Os itens de trabalho devem participar do processo de preparação e ser discutidos por toda a equipe até que todos os benefícios e riscos sejam identificados e as estimativas de todos os membros da equipe sejam coletadas. Os itens de trabalho devem ser planejados em iterações ágeis de acordo com suas estimativas. A equipe deve ser reconhecida sobre o possível volume de dívida técnica na iteração. O tempo reservado pode ser aumentado se necessário, mas nunca deve ser menor que o valor regular. Isso ajuda a encorajar os engenheiros a criar novas tarefas no backlog e priorizá-las. Todos sabem que suas sugestões podem ser implementadas e que o backlog vai encolher algum dia, não crescer em uma enorme lista desmoralizante. Usando processos de preparação e planejamento para divulgação de dívidas tecnológicas potenciais Às vezes, tarefas de dívida técnica podem ser reveladas durante a discussão e estimativa, enquanto a equipe enfrenta obstáculos inesperados que tornam a realização menos confiável e flexível. Por exemplo, você pode perceber que há recursos semelhantes e criar um totalmente novo só agravaria a base de código. Mas esses recursos não contêm a funcionalidade comercial necessária em novos. E é melhor criar um serviço unificado que conecte todos os recursos semelhantes para simplificar a manutenção no futuro. Ainda assim, essa mudança pode afetar e desestabilizar recursos antigos e é aí que está o desafio. Talvez haja uma maneira de desenvolver novos recursos de forma barata e fechar os olhos para as imperfeições. Ou talvez agora seja a melhor oportunidade para criar um serviço unificado enquanto há apenas alguns recursos semelhantes. O mais importante é estabelecer um processo que ajude os membros da equipe a tomar uma decisão com base em fatos revelados e estimativas devidamente preparadas. É crucial ter um sistema que evite situações em que tais decisões devam ser adotadas durante a fase de implementação em um backlog comprometido. Se seus estágios de iteração funcionarem bem, a divulgação de tais momentos acontecerá automaticamente por meio de um processo de preparação e planejamento adequado. Existem algumas regras e etapas básicas que podem proteger a equipe de obstáculos inesperados na maioria dos casos: O backlog de preparação deve conter tarefas com requisitos claros e viáveis. O backlog de preparação deve ser compartilhado com os membros da equipe antes da discussão e estimativa. Todos os membros da equipe devem estar preparados e familiarizados com as tarefas antes da preparação. Se algum item pendente exigir investigação adicional ou reimplementação, a preocupação deve ser discutida. Os requisitos para itens de backlog problemáticos devem ser finalizados com base nas peculiaridades reveladas. Todas as áreas com problemas potenciais devem ser documentadas. Cada item do backlog deve ser estimado. Itens problemáticos do backlog podem ser decompostos em tarefas separadas e planejados de acordo com as prioridades. As decisões sobre a estratégia de implementação podem ficar a cargo do gerente de lançamento, de acordo com os riscos e prazos. Mas essa abordagem ajuda a documentar todas as decisões. Mesmo que a tarefa de dívida técnica tenha sido adiada, ela ainda é adicionada ao backlog. Mais tarde, essas tarefas devem ser revisadas e programadas. Esse processo corrige cenários em que algumas ideias boas e necessárias são esquecidas durante uma iteração agitada. Estabelecer processo em caso de problemas inesperados durante a iteração Ainda assim, mesmo com um backlog de dívidas tecnológicas bem mantido e um processo de preparação e planejamento funcional, é possível encontrar obstáculos inesperados e demorados no desenvolvimento. Produtos de software podem ser complicados, especialmente antigos ou contendo funcionalidades ricas. Usar práticas Agile ajuda a reunir informações antecipadamente e tomar uma decisão adequada. Uma das soluções mais fáceis são as reuniões diárias. Se um engenheiro enfrentar algum problema, ele deve ser levantado durante a reunião e discutido mais tarde. Cada obstáculo é único e pode consumir diferentes quantidades de tempo. Não importa se a mudança será implementada na iteração atual, em vez de um recurso "Bom ter", ou se requer uma revisão completa do escopo da iteração. O problema deve ser criado como uma tarefa típica de dívida técnica no sistema de rastreamento, decomposto e descrito como qualquer outra tarefa semelhante em artigos anteriores. Consistência é a chave, e a equipe tem que saber como lidar com essas situações. Críticas à burocracia adicional e como responder a elas Todos esses métodos podem parecer uma forma adicional de tomar o tempo de toda a equipe com burocracia inútil. E pode ser assim se apenas a ausência de regras rígidas e claras não criasse tempos difíceis para todos. Não tem problema não seguir essas recomendações em projetos de curto prazo ou no estágio de produto mínimo valioso (MVP). No entanto, trabalhar em produção com responsabilidades de qualidade e grandes produtos requer um sistema de processo interno bem definido. Vamos analisar as objeções mais comuns. Criar tais tarefas consome tempo e às vezes é mais rápido fazer alterações no código do que descrevê-las E isso é verdade. Descrever suas tarefas em linguagem natural pode às vezes ser mais difícil do que consertar o código. Mas aqui estão algumas soluções: Criar um sistema de modelos no sistema de tickets pode ser útil. Ele permite que tarefas sejam adicionadas rapidamente e preenchidas com os parâmetros e links corretos. É ótimo ter algumas políticas de tickets no wiki corporativo, como Confluence / Notion / SharePoint ou qualquer outra plataforma de documentação de equipe. Essas páginas podem fornecer bons exemplos de tarefas criadas corretamente. É do melhor interesse do líder da equipe manter a documentação técnica e polir modelos para ajudar qualquer outro membro da equipe a enviar tickets claros e compreensíveis. No nível básico, é o suficiente para obrigar os engenheiros a criar tarefas com descrições de alto nível, sem artigos extensos sobre visão estratégica ou o potencial de suas sugestões. A descrição deve ajudar o revisor (geralmente o líder da equipe) a obter a ideia principal das mudanças. Mais tarde, o líder da equipe pode validar a sugestão e preenchê-la com detalhes adicionais de acordo com o processo. Isso também ajuda a entender se essas mudanças são mesmo necessárias e fornece algum filtro de qualidade. Se o desenvolvedor tiver tempo para implementar a sugestão, a política feature-branch pode ser muito útil. Ainda assim, é necessário criar uma tarefa, porque é útil ter uma regra para a criação de feature branches nomeadas por ticket. Mas, como resultado, obtemos um engenheiro satisfeito, que implementou alguma parte da dívida técnica, ticket e implementação vinculada que pode ser preparada e planejada para verificação em uma iteração adequada, sem o risco de desestabilização inesperada. Todas essas mudanças são altamente técnicas e a descrição não ajuda porque ninguém vai entender a ideia Talvez. Mas depende da explicação. A prioridade é a descrição do que pode dar errado e qual funcionalidade pode ser desestabilizada. No entanto, é útil escrever sobre o impacto da mudança porque ajuda a identificar possibilidades e cenários adicionais. Além disso, mesmo as ideias mais profundamente técnicas podem ser descritas em frases simples usando linguagem natural. Se não puderem, pode haver algo errado com a ideia em si, e isso pode ser um risco potencial, toda a proposta deve ser reconsiderada. Basta escrever algo como: “O método “XXX” consome muita RAM em cada chamada. Criar um cache adicional para esse método ajuda a reduzir o consumo de RAM e a acelerar todas as APIs. O método usa dados que mudam raramente, é suficiente descartar o cache na reinicialização. As alterações são seguras, mas podem afetar potencialmente os seguintes recursos: XXX, XXX, XXX…”. Em alguns casos, isso seria suficiente. Em outros, essa sugestão pode desencadear a discussão, porque o engenheiro pode esquecer de alguma funcionalidade antiga, mas ainda usada, onde esse cache pode causar problemas. Durante o processo de preparação, a ideia será revisada e a equipe encontrará um meio-termo. Todas essas políticas apenas impedem que os usuários recebam novos aprimoramentos Estabilidade e confiabilidade são melhores do que algumas melhorias percentuais em algum tempo de execução de recurso. Ninguém ficará desapontado por perder um potencial aumento de desempenho, mas é fácil manchar a reputação de um produto. Precisamos de toda essa burocracia para um estilo de código simples que nunca causará danos em 99,99% dos casos? A ideia é agilizar processos e ajudar a avaliar riscos. Engenheiros devem ter a oportunidade de manter a base de código e fornecer algumas melhorias. Para coisas que são pequenas e não desestabilizam todo o produto, é possível criar itens de trabalho agregativos que podem ser concluídos durante a iteração. Essas tarefas ainda precisam ser revisadas como solicitações de pull, mas não é necessário anunciá-las formalmente para a equipe. Conclusão Melhorias constantes de produtos são críticas para os negócios e ajudam a preservar a qualidade geral. Se você mantiver a dívida técnica e as novas ideias na prateleira, ficará preso a um produto desatualizado e logo terá dificuldades para encontrar engenheiros especialistas para mantê-lo. Por outro lado, essas tarefas competem com recursos de negócios e outras ideias que podem levar os negócios a novos horizontes. Essas recomendações sobre backlog de tarefas técnicas podem ajudar a revelar e avaliar a importância dessas tarefas não apenas para os membros da equipe, mas também para as partes interessadas. Elas ajudam a apresentar essas ideias em linguagem natural e a manter e proteger o tempo para implementação. Isso sobrecarrega os engenheiros com ações adicionais, mas, no final, ajuda toda a equipe a entregar produtos confiáveis e de alta qualidade. E a responsabilidade de um gerente é escolher o instrumento ou política certa para manter esse processo.
