A gestão ágil de projetos chama a atenção de gerentes de projetos, clientes e executivos que investem no desenvolvimento de produtos e estão conhecendo as vantagens da gestão ágil em comparação com as abordagens de gerenciamento mais tradicionais.

O gerenciamento de projetos que conhecemos passou a existir na metade do século XX, no período da segunda guerra mundial para que fosse possível concluir diversos projetos, criou-se  processos formais de gerenciamento baseados em modelos de fabricação e adaptados de setores, como a construção civil, fábricas e também das forças armadas, e por não ter sido pensado para ciclos mais rápidos como exigidos na vida contemporânea para desenvolvimento de software, produtos mais complexos, aplicativos móveis e devido ao aumento da competitividade por exemplo, acabaram se tornando inadequados, pois tais produtos requerem constante inovação.

Profissionais no ramo da computação na década de 40 e 50 adotaram esses processos de fabricação, no qual era a base da metodologia de gerenciamento de projetos cascata. No projeto em cascata a pessoa vai para a próxima fase, apenas quando a anterior está concluída, por isso o nome cascata, esse processo incorre em diversos problemas, conforme citado abaixo:

• A equipe deve conhecer todos os requisitos no início do projeto, o que acaba exigindo um alto custo ao detalhar os requisitos antes do desenvolvimento iniciar;
• Estimar é complexo e requer um grau de experiência, imagina fazer isso para todo um projeto que vai sofrer mudanças;
• Sabemos que a agenda dos clientes é apertada, esse formato reforça a participação somente nas fases de coletar requisitos e design dos principais stakeholders e clientes;
• Resistir a solicitações de mudanças e aumento de requisitos, pode trazer grandes prejuízos ao final do projeto;
• Documentação volumosa para controlar e gerenciar o projeto;
• O teste só poderá ser realizado, quando toda a funcionalidade estiver desenvolvida e integrada ao final do projeto;
• O feedback do cliente só é possível ao final do projeto, gerando um alto risco do valor entregue ser zero.

A gestão tradicional de projetos e a metodologia cascata, foi a mais comum no gerenciamento de software por exemplo, até ser superada pelas abordagens ágeis em 2008.

A grande questão é continuar utilizando metodologias de gestão de projetos de 1950, processos de sucesso com essa abordagem, possuem problemas com excesso de escopo, levando ao aumento de custos e outros problemas, como já citados anteriormente. Você pode perceber uma quantidade enorme de softwares e produtos sendo utilizados no mercado com excessos de recursos e ferramentas, como por exemplo num software de planilha eletrônica, mesmo utilizando diariamente, usamos apenas alguns recursos o tempo todo, usamos outros elementos com menos frequência, e nunca usamos outras ferramentas e tão pouco conhecemos alguém que a usou. Isso é um exemplo de resultado de excesso de escopo.

A gestão tradicional de projetos não equilibra de forma adequada as mudanças, pois tal mudança não é bem vista no meio do projeto, portanto a melhor possibilidade de ter um recurso incluso é no início do projeto.

Segundo os dados de uma pesquisa realizada pelo Standish Group em 2015, ilustra um excesso comum na gestão tradicional dos projetos, pois envolvidos desejam incluir tudo de que precisam ou que acham que podem precisar. Os resultados geraram os dados abaixo.:

Nas duas últimas décadas as pessoas que trabalham com a gestão tradicional de projetos vêm reconhecendo o aumento de problemas no gerenciamento tradicional e estão buscando modelos melhores e mais adequados a sua organização.

As raízes da agilidade, seus valores, princípios e práticas já estão por aí a um certo tempo, conforme a linha do tempo ilustrada na figura abaixo, extraída do livro Scrum for Dummies.

Em 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaram um artigo chamado “The New Product Development Game” na Havard Business Review, no qual descreviam uma estratégia de desenvolvimento flexível para atender rápidas demandas de produtos, correlacionando pela primeira vez o termo Scrum com o desenvolvimento de produtos, tornando-se hoje umas das estrutura mais populares da gestão ágil de projetos.

Em 2001 um grupo de especialista em software e projetos se reuniu para falar o que seus projetos bem-sucedidos tinham em comum. O grupo criou o Manifesto Ágil, revelando boas práticas para desenvolvimento de softwares, havendo valor nos itens à direita, porém os itens à esquerda devem ser mais valorizados.

Os processos ágeis proporcionam um formato de trabalho melhor em relação ao método cascata, devido a detecção de falhas de forma mais rápida, menos trabalho desnecessário, melhor desempenho da equipe e controle dos projetos. Vale enfatizar com base no primeiro valor do Manifesto Ágil “Indivíduos e interações mais que processos e ferramentas” que a equipe que vai desenvolver o projeto é a chave para o sucesso, em contra partida precisar ser competente e interativa, e principalmente precisa ser apoiada e suportada pela organização.

As abordagens ágeis são baseadas em um método de controle empírico, processo com base na tomada de decisão, a partir de observações durante do projeto. Uma abordagem empírica tende a ser mais assertiva no desenvolvimento e redesenho de novos produtos. A realização de inspeção constante, é possível adaptar e fazer ajustes imediatos, que são as etapas do processo empírico:

Transparência: Todos os envolvidos em um projeto ágil devem saber o que está acontecendo e como está o progresso do projeto ou produto que está sendo desenvolvido.

Inspeção: as pessoas envolvidas no produto e no processo devem avaliá-los regularmente.

Adaptação: ajustes são realizados de forma rápida para que problemas possam ser minimizados. Se a inspeção mostra que algo deve ser modificado, então deve ser feito imediatamente.

Um projeto ágil envolve o mesmo tipo de trabalho num projeto tradicional em cascata: cria-se requisitos, design, desenvolve o produto, documenta-o e, se necessário, realiza integrações em outros produtos. Testa-se, corrige qualquer problema e realiza a implementação para uso. Porém em vez de concluir essas etapas para todos os recursos de uma só vez, como no método cascata a divisão é feita iterações, ou seja, em ciclos menores no projeto para que seja possível a inspeção frequente e a adaptação imediata.

A redução do fracasso em projetos ágeis é fruto das equipes que fazem adaptações imediatas com base em inspeções frequentes do progresso e satisfação do cliente.

Concluindo…em diversos aspectos as abordagens ágeis tornaram-se superiores aos métodos tradicionais de gestão de projetos. As abordagens ágeis priorizam pelo valor comercial, ou seja, pelo retorno do investimento e mitigação de riscos constante, assegurando o sucesso ou fracasso iniciais. O fato de testar o projeto inteiro ajuda a garantir que você encontre os problemas no início, e não depois de investir muito tempo e dinheiro.

As mudanças são bem-vindas durante o projeto, o que minimiza a lentidão no avanço do escopo. É possível adicionar novos requisitos no início de cada ciclo sem afetar o fluxo de desenvolvimento. A inspeção regular e a adaptação funcionam como uma luva na gestão ágil. As equipes de projetos ágeis, que trabalham com feedback frequente nos ciclos completos de desenvolvimento e uma funcionalidade validada, que pode ser enviada, melhoram seus processos e produtos em cada ciclo.

Não esqueçam que testar no início e com frequência, ajustar as prioridades quando necessário, usar melhores técnicas de comunicação, demonstrar e liberar funcionalidade do produto regularmente permite o controle de vários fatores nos projetos ágeis.

Obrigada por terem ficado até aqui. Abraços

Brenda Nogueira – Família Sunsetti