4 minutos de leitura
Aposto que você que tem algum interesse em desenvolvimento de software já se deparou com alguns desses termos: Kanban, Scrum, Extreme Programming, Lean Development, etc.
Todos esses nomes estranhos se referem a metodologias de gestão de projetos de software. Elas foram criadas a partir do conjunto de princípios que estão presentes no que chamamos de Agile. Esses princípios foram publicados no “Manifesto Ágil” (“Manifesto for Agile Software Development”, em Inglês), publicado em 2001, em Utah, por desenvolvedores que se encontraram para discutir inovações possíveis na gestão de seus projetos, procurando algo menos rígido do que o que prevalecia no mercado.
Waterfall: o que é?
A metodologia que se usava no mundo até então, Waterfall (ou Cascata), era predominante nos estudos de melhores práticas de gestão de projetos. O seu nome advém do formato que adota para criar, produzir e entregar projetos. O projeto é feito de maneira sequencial: é demandado com um objetivo final, forma-se o escopo, divide-se em pequenas tarefas, associa-se à dependência existente entre elas e traça-se os diferentes “caminhos” que serão percorridos para realização do produto.
Como este processo é sequencial, uma vez que uma etapa foi concluída, os desenvolvedores não podem voltar para uma etapa anterior – não sem descartar o projeto inteiro e recomeçar desde o início. Não há espaço para mudança ou erro, portanto, um resultado do projeto e um plano extenso devem ser definidos no início e seguidos com cuidado
“Novamente o time de vendas subestimou o projeto!”
A metodologia “Waterfall” se mostrava falha. Por que?
1 – Muitas vezes, as pessoas para as quais estamos construindo software não sabem exatamente o que precisarão e não sabem o que é possível com a tecnologia disponível. Esta maneira de trabalhar não consegue arcar com isso.
2 – Muitas vezes, os designers da solução não são capazes de prever os problemas que surgirão da implementação de seus projetos.
3 – Mudanças nos requisitos (por exemplo, como aqueles resultantes de novas tecnologias, mudanças em um mercado ou mudanças nos objetivos de negócios) não podem ser facilmente incorporadas com a “Waterfall” e muitas vezes há procedimentos de controle de mudança árduos para serem realizados quando isso acontece.
E então veio a solução: agilidade
Devido às recorrentes falhas do mercado de desenvolvimento de software, eis que surge o “Manifesto Ágil”.
“[…]Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano […]”
Ao invés de lidar com processos pré-estabelecidos sequenciais, façamos interações entre a equipe de desenvolvimento e o cliente. Ao invés de fazer um escopo enorme e traduzi-lo em funcionalidades (que virá a não cobrir os verdadeiros desejos do cliente), entreguemos um software funcional. Ao invés de papelada e incessantes reuniões presenciais, vamos inserir o cliente no processo produtivo. Ao invés de tentar seguir um plano – falho desde sua concepção – vamos rapidamente nos adaptar às mudanças, de um jeito rápido e barato.
Se na “Waterfall” a palavra-chave era sequência, em metodologias que seguem os princípios da “Agile” prevalecem as iterações.
Exemplo: Scrum
Os desenvolvedores começam com um design de projeto simplista e, em seguida, começam a trabalhar em pequenos módulos. O trabalho nesses módulos é feito em sprints semanais e, ao término de cada sprint, as prioridades do projeto são avaliadas e os testes são executados. Esses sprints permitem que os bugs sejam descobertos e que o feedback do cliente seja incorporado ao projeto antes que o próximo sprint seja executado. Isso é, o cliente faz parte do processo produtivo e são realizadas iterações semanais com ele para validação.
Por que a Agile?
1 – A metodologia Agile permite que mudanças sejam feitas após o planejamento inicial. É feita justamente para podermos facilmente reescrever o programa sem prejudicar todas as outras tarefas (passadas ou futuras), conforme as já esperadas alterações cliente surgirem.
2 – Como a metodologia Agile permite que você faça alterações, é mais fácil adicionar recursos que o manterão atualizado com os últimos desenvolvimentos da indústria.
3 – No final de cada Sprint, as prioridades do projeto são avaliadas. Isso permite que os clientes para adicionar o seu feedback para que eles finalmente obter o produto que eles desejam.
4 – O teste no final de cada sprint garante que os bugs são capturados e cuidados no ciclo de desenvolvimento. Eles não serão encontrados no final.
5 – Porque os produtos são testados tão completamente com ágil, o produto poderia ser lançado no fim de todo o ciclo. Como resultado, é mais provável que alcance sua data de lançamento.
Hoje, os príncipios Ágeis reinam nas formas de gestão para desenvolvimento de software. Dentre todas as metodologias usadas, cabe ao gestor e ao time escolher quais utilizar ou – como vamos discutir nos próximos artigos – desenvolver a própria juntando mais de uma metodologia.