Depois que o software foi desenvolvido, você pode descobrir que o sistema funciona muito bem na maior parte do tempo, mas talvez haja um recurso ou uma jornada que não esteja funcionando como você deseja. Talvez você tenha um sistema legado que parece estar apresentando cada vez mais falhas após a instalação de uma solução comercial pronta para uso. Ou talvez você descubra que toda a infraestrutura precisa ser revisada logo após a implementação. Cada uma dessas situações pode se dever a vários fatores, inclusive ao próprio fluxo de trabalho ágil. Embora o Agile seja excelente no ambiente certo e com o grupo certo de pessoas, há algumas armadilhas que podem levar você a obter o mínimo de resultados aceitáveis.
O ágil pode não admitir o cenário mais amplo
O principal problema do Agile é que, muitas vezes, os desenvolvedores não conseguem enxergar a floresta por trás das árvores. As equipes ágeis escrevem e testam seu código em sprints. Isso faz sentido em um nível superficial, pois escrever tudo de uma vez antes de testar leva a suas próprias confusões. Assim, à medida que os requisitos são atendidos, esses componentes são testados e, em seguida, você segue em frente. Nas reuniões matinais do scrum, os desenvolvedores explicam seus planos para o dia e os problemas persistentes do dia anterior. As pessoas da equipe podem oferecer suporte e soluções para esses problemas. Mas quando um desenvolvedor concluiu suas tarefas do dia anterior sem problemas, essas reuniões às vezes se tornam nada mais do que uma lista do trabalho que foi feito, e não oportunidades de colaborar ou buscar feedback. Nesses casos, os desenvolvedores podem estar preocupados apenas em conseguir passar pela reunião e escrever o código que os ajudará a passar pelo sprint.
O Agile pode permitir a codificação para o teste, e não o teste para encontrar erros
Se uma equipe tem um sprint de duas semanas para concluir uma lista de tarefas de um quilômetro de comprimento, é bem provável que uma equipe não muito boa encontre uma maneira de cortar custos aqui e ali. Um dos lugares mais fáceis (e piores) para cortar caminho é na fase de teste de garantia de qualidade do processo. Frequentemente, as equipes criam testes que são executados várias vezes. Saber o que é necessário para passar no teste significa que os requisitos serão atendidos todas as vezes. O que precisa acontecer é a realização de testes exploratórios que examinem esse novo código em busca de novos erros. Mas, muitas vezes, os prazos apertados levam ao oposto. As equipes estão apenas chutando a lata pela estrada… e no final da estrada você pode ter um produto com bugs que não atende aos requisitos.
Na iLAB, sabemos como manter o panorama geral em mente enquanto monitoramos os mínimos detalhes desse sprint, do próximo e do seguinte. Além disso, treinamos nossos funcionários para conversar com os desenvolvedores sobre os defeitos encontrados e como resolvê-los de forma a capacitar a equipe, e não frustrá-la. A iLAB pode trabalhar com você do início ao fim para garantir que o mínimo necessário não afete seus resultados. Entre em contato conosco hoje mesmo para saber mais.
