Dificilmente algum projeto da sua empresa está livre de refatoração de código em algum momento do processo. É estimado que o retrabalho corresponda de 25 a 40% do esforço total do desenvolvimento do projeto e desse retrabalho, 70 a 80% é devido a erro de especificação de requisitos, de acordo com a pesquisa de Gustavo Souza e Gláucia Silva, da Universidade Federal de Viçosa, em Minas Gerais.
Cristiano Baumgartner, do Testing Company, aponta que, de acordo com um levantamento do PMI (Project Management Institute), 26% das empresas afirmam que o retrabalho é um dos problemas mais frequentes em projetos.
E quais seriam os vícios durante o ciclo de vida do projeto que poderiam influenciar esses números?
O que motiva as equipes re-codarem com tanta frequência?
Existem inúmeras possibilidades em um projeto que gere a necessidade de reescrever (ou re-codar, refatorar, etc) algo que já estava publicado ou em vias de entrar em produção. Confira quais são as mais comuns:
1. Falhas no levantamento de requisitos e testes especializados
Um dos argumentos mais comuns no ciclo de desenvolvimento dos projetos é a falta de tempo para levantamentos e testes, por conta da grande carga cognitiva necessária para a execução das tarefas de desenvolvimento.
A dificuldade de alinhamento entre as pessoas usuárias e desenvolvedoras e a necessidade de construir um projeto “do zero”, acaba impactando mais no tempo do ciclo de desenvolvimento do que no levantamento da necessidade, ou seja, aquele velho argumento: precisamos entregar pra ontem!
De acordo com Dean Leffingwell, criador do Scaled Agile Framework, os problemas mais complexos encontrados em projetos apontam em relação à definição e entendimento de requisitos como premissa fundamental.
Ainda sobre o tema, de acordo com o PMBOK, Project Management Body of Knowledge, um guia referência sobre gerenciamento de ações, o ciclo de vida de um projeto se divide em quatro fases, sendo duas delas respectivas a identificação e levantamento de requisitos, uma fase de desenvolvimento e uma fase de testes. Ou seja, 50% do projeto deveria ser gasto com análises e levantamentos, 25% com desenvolvimento e 25% com testes.
Caso o tempo de desenvolvimento pudesse ser diminuído de uma forma consistente, as respectivas equipes responsáveis teriam mais tempo para fazer o planejamento do projeto e o levantamento de requisitos, resultando em uma entrega mais assertiva, de acordo com a expectativa da pessoa usuária e melhor testada.
2. Código duplicado
Com a cultura e ampla adoção dos microsserviços e publicação em nuvem, nos deparamos com uma maior fragmentação dos projetos, com serviços menores e com funções específicas.
3. Muitas equipes distribuídas, sem integração entre si
Em grandes empresas, com muitos times de pessoas desenvolvedoras, é comum ter várias equipes atuando em um mesmo projeto, ou mesmo que seja em outros projetos. Cada profissional tem uma percepção diferente e forma de trabalho.
Isso faz com que cada time e cada projeto acabe tendo formas diferentes de fazer a mesma coisa, como por exemplo, formas diferentes de implementar uma mesma lógica, sem padronização, o que também acaba dificultando em muito a manutenção e a documentação dos processos na empresa.
Quando acontece da pessoa mudar de time/projeto acaba sendo como se a pessoa tivesse sido contratada novamente pela empresa e todo o conhecimento adquirido por fim, não é utilizado em função dessa falta de padronização. O mesmo acontece quando uma nova pessoa inicia sua jornada, sua curva de aprendizado acaba sendo mais demorada.
Enfim, times otimizados e empresas consolidadas que focam no ciclo de vida do desenvolvimento de software pautado no levantamento de requisitos e testes automatizam e padronizam inúmeros processos.
Sobre o StackSpot
A partir dessas dores, nasceu a StackSpot. A plataforma oferece conjuntos de ferramentas para acelerar o processo de desenvolvimento, padronizar e facilitar a publicação dos projetos, centralizando os templates com as tecnologias utilizadas na empresa, dando uma maior agilidade e assertividade, diminuindo a possibilidade de erros humanos.
Ao criar um projeto novo, utilizando o STK, um trabalho que levava meio período ou um dia, pode ser executado em poucos minutos, criando um projeto funcional, com plugins adicionando funcionalidades, como conexão a banco de dados, observabilidade, dentre outros.
Além do desenvolvimento em si, a StackSpot auxilia na publicação dos projetos, diminuindo a carga cognitiva da pessoa desenvolvedora e a necessidade de configurações manuais, automatizando o desenvolvimento e deploy. Ou seja, tudo aquilo do projeto que foi feito mais de uma vez, pode ser transportado para uma stack, automatizado e flexível, tornando tudo muito mais simples.
E você? Tem alguma experiência sobre refatoração de código que gostaria de compartilhar? Já conhece a StackSpot e todas as facilidades que ela pode trazer para seu projeto? Comente aqui embaixo!
Referências
BAUMGARTNER, Cristiano. Retrabalho em projetos de software: será que ele está impactando a produtividade?. Testing Company, Novembro 2019. Disponível em: <https://testingcompany.com.br/blog/retrabalho-em-projetos-de-software-sera-que-ele-esta-impactando-a-produtividade>. Acesso em: 06 de Setembro de 2022.
LEFFINGWELL, D.; WIDRIG, D. (2003). Managing Software Requirements. Boston:
Addison Wesley.
SOUSA, G. G.; SILVA, G. B. Análise de focos de retrabalho em repositórios de software: um estudo em projetos do GitHub. Universidade Federal de Viçosa, Minas Gerais. Setembro de 2019.
STACKSPOT. Como a StackSpot funciona?. Documentação StackSpot. Versão 4.2. Disponível em: <https://docs.stackspot.com/docs/getting-started/how-it-works/> Acesso em: 06 de Setembro de 2022.
Sobre o autor
Pedro Henrique Massa Pilz
Apaixonado por tecnologia, desenvolvedor há 14 anos, geek, pai e cadeirante nas horas vagas.
