Três mitos sobre agilidade no desenvolvimento de software
Método é necessário para desenvolvedores de todos os níveis. Especialista lista mitos sobre a área
Metodologias ágeis no desenvolvimento de software estão muito ligadas à mentalidade e cultura em comum dentro de uma equipe de desenvolvimento. Além disso, as decisões a respeito das tecnologias usadas também podem influenciar o quão ágil uma equipe pode ser.
“A agilidade é uma ferramenta útil para os processos, mas depender somente dela pode desacelerar as estratégias. Cegamente, seguir a agilidade não te dá tudo o que você quer, fazer Ágil é diferente de ser ágil”, pondera Joseph Yoder, fundador da consultoria global Refactory e instrutor dos cursos do ITuring.
Segundo o especialista, o Ágil valoriza indivíduos, softwares em funcionamento, colaboração do cliente e resposta à mudança. Tendo isso em mente, Yoder selecionou aqueles que consideram os três maiores mitos da área.
1. Soluções simples são sempre as melhores
Surgiu a partir do princípio do “keep it simple”, ou seja, mantenha simples. Algumas vezes é possível manter a simplicidade, em outras os desafios são maiores e requerem complexidade. Portanto, ser adaptável é realmente a melhor abordagem, diz Yoder.
2. Mais rápido é mais ágil
Às vezes isso é verdade quando novos requisitos não estão totalmente construídos e não é preciso lidar com situações diversas. Ao longo do desenvolvimento, podem aparecer novos requisitos e este processo pode demorar mais. Isso ocorre ao ter um sistema maior e muitas dependências.
Seguir um processo ágil com feedbacks regulares e scrum é importante. E é comum que se pense que a adaptação nesse meio é fácil, mas se há riscos na arquitetura de software. É preciso priorizar para que não existam maiores problemas.
3. Scrum, TDD e outros processos ágeis garantem bom design de arquitetura
A boa arquitetura surge através de boas práticas de desenvolvimento. No entanto, algumas vezes se pensa na possibilidade de mudanças significativas de arquitetura e é preciso pensar que certas mudanças podem trazer consequências. Por exemplo, refatoração de um sistema para adicionar segurança pode trazer desaceleração das adaptações, o que tem impacto de negócio direto.
Pensar na arquitetura na perspectiva de negócios é importante e definitivamente influencia no entendimento sobre agilidade.