Quem nunca esteve em um projeto caminhando conforme o planejado e, no momento que a equipe de qualidade colocou a mão para efetuar os testes no aplicativo, apareceram dezenas de defeitos os quais precisam ser corrigidos?
Grande parte dos gestores de projetos pensariam: “Estava indo tão bem, agora terei que replanejar e efetuar a gestão de mudança”. Este é uma ação comum que pode ser evitada com ações preventivas aliadas da experiência do gestor na gestão de projetos de desenvolvimento de software.
Eis aqui uma verdade: em projetos que envolvem o desenvolvimento de sistemas, o surgimento de defeitos pode ser tratado como um fato, e não como um risco. O que pode ser tratado como um risco é a possibilidade de surgirem mais defeitos do que o normal. Isso se deve à natureza dos desenvolvedores, os quais não são técnicos em identificação de defeitos, salvo exceções.
O planejamento da resolução dos defeitos
Abaixo serão apresentadas formas de planejar a resolução dos defeitos para projetos utilizando as metodologias tradicionais e ágeis.
Para metodologias tradicionais
Sabendo que defeitos serão encontrados após qualquer tipo de teste, é importante prever, durante o planejamento do projeto, um tempo para correções e reteste destes defeitos. Você não terá o tempo exato que estas atividades despenderão, mas pode usar como base o tempo de retrabalho de projetos realizados anteriormente, ou, se não há esta base histórica, pode-se iniciar com 20% do tempo de desenvolvimento total. Ao final do projeto, realize uma reunião de lições aprendidas e valide se o tempo utilizado foi coerente e se existem ações que possam mitigar ainda mais o surgimento de defeitos nos próximos projetos, como o caso de revisão de código ou checklists.
Para desenvolvimentos ágeis
Existem várias formas de tratar os defeitos porém, particularmente, prefiro que estes sejam tratados como User Stories, os quais devem ser armazenados no backlog de produto, estimados pelo time e priorizados pelo Product Owner. Se o defeito for do tipo Show Stopper (que impede a utilização do sistema), sua prioridade deverá ser automaticamente a máxima possível.
Quando existem profissionais de qualidade de software atuando no desenvolvimento ágil, o planejamento das Sprints poderá se dar conforme o quadro 1 à seguir:
Desta forma, os testes só ocorrerão na Sprint 2, com as entregas da Sprint 1, e os defeitos encontrados na Sprint 2 só serão corrigidos na Sprint 3, e assim por diante. Desta forma, a velocidade do time será dividida entre desenvolvimento de novas funcionalidades e correções de defeitos.
Conclusão
Perder a cabeça replanejando seu projeto é uma questão de entender que defeitos ocorrerão. Tendo esta premissa como base, sem dúvida o planejamento será mais coeso e com menos surpresas após os trabalhos da qualidade.
Vale ressaltar que existem muitas outras formas de planejar a correção de defeitos, e que elenquei algumas as quais trabalho. Cada caso é um caso, e as ações preventivas deverão levar isto em conta.
Até a próxima.
[Crédito da Imagem: Bug – ShutterStock]