O que é ser Ágil em Desenvolvimento de Software?

Os métodos ágeis estão provocando um bom agito no mercado de desenvolvimento de software.

Tem gente curiosa para saber o que é e como aplicar, outros não acreditam que estes métodos possam gerar resultados aceitáveis e muitos tentam provar que eles são uma bala de prata e a solução para todos os problemas que enfrentam por décadas nos setores e empresas que desenvolvem sistemas.

Muitos mitos foram criados ao redor dos métodos ágeis, alguns deturpando conceitos e fundamentos e até mesmo criando uma certa aversão aos métodos tradicionais.

Então vamos fazer algumas associações para conceituar o que é Agile:

 

Agile x Waterfall:

Não temos como afirmar que Agile é algo totalmente contraditório a Waterfall. No desenvolvimento em cascata podemos desenvolver em iterações, desenvolver o que é mais importante primeiro, alinhar as necessidades de negócio do usuário, fazer testes automatizados, entregar produtos rodando de forma antecipada, documentar somente o que é necessário. Tudo aquilo que é reforçado como prática de métodos ágeis.

Normalmente os processos de desenvolvimento de software que usam RUP ou alinhados ao CMM são desenhados de forma mais burocrática e entregam porções maiores de produtos, mas isto é a forma como os processos são configurados, não existindo uma regra ou uma lei obrigando que eles sejam desta forma.

 

Agile x Disciplina:

Muita gente acha que ser ágil permite a ausência de disciplina. Muito pelo contrário. Os métodos ágeis exigem que as pessoas sejam disciplinadas pois eles estão fundamentados em auto-organização e delegação de responsabilidades para tomada de decisões, buscando atingir objetivos negociados. Isto implica em assumir um compromisso com a empresa e com o grupo de trabalho do qual faz parte. Se os compromissos assumidos não forem bem planejados e cumpridos, os objetivos não serão atingidos e o resultado alcançado será ruim.

 

Agile x Documentação:

Existem pessoas que não gostam de documentar e aí também criaram este mito. Documentação é fundamental em métodos ágeis.

 Uma User Story pode ser escrita para os requisitos, mas se este formato de requisito não for efetivo para meus projetos, dá para utilizar Use Cases ou qualquer outro. A documentação para o usuário precisa ser gerada se ela for uma entrega de negócio importante. A documentação do código é obrigatória.

Assim como nos métodos tradicionais a documentação precisa ser planejada e realizada conforme a necessidade de cada projeto.

 

Agile x Seguir um Plano:

Para ser ágil eu, não preciso seguir um plano, certo? Errado.

Os métodos ágeis exigem planejamento. Ele só é executado de forma diferente do que é mais comum. Ele não visa todo o projeto, focando em porções mais curtas de tempo e escopo. A cada entrega de uma pequena parte, um novo planejamento é realizado. Uma visão de longo prazo também é desenhada, mas será difícil você encontrar um cronograma com todas as entregas planejadas.

 

Agile é leve e os outros são pesados:

Essa é outra associação que não pode ser feita.

O que vai determinar se um processo é pesado ou leve, burocrático ou não, é como ele foi escrito e a quais exigências ele está sujeito.

Já vi auditorias de processo onde várias atividades eram feitas apenas para apresentar aos órgãos certificadores. Era aquela correria para deixar a documentação em dia.

Algumas destas atividades realmente eram exigências legais ou contratuais. Neste caso os métodos ágeis também não estão acima de leis e contratos.

Outras atividades podiam ser suprimidas dos processos pois não condiziam com a realidade da operação da empresa e desta forma poderiam deixar de ser um peso. Neste caso existem vários motivos pelos quais os processos não são alterados que vão desde “eu faço assim por que foi assim que eu aprendi” até o receio de mexer em algo e causar problemas que não podem ser previstos em um primeiro momento.

 

Então como poderíamos tentar definir Agile ou criar uma base de comparação que possa demonstrar de forma mais fácil tudo que está por traz deste conceito?

Gosto muito da comparação que fala em:

 

Adaptação x Antecipação:

Os métodos que podemos chamar de tradicionais tentam antecipar todos os problemas. Se não todos, pelo menos tentam prever muita coisa.

Mesmo que seja possível quebrar um projeto em várias entregas, normalmente tenta-se detalhar tudo que é possível e, é claro, com tudo documentado. Depois disto, cada mudança torna-se um parto e gera reflexos em outras entregas, num efeito cascata de cansar muita gente.

Os métodos ágeis assumem que não dá para prever tudo e focam em entregas mais curtas, mesmo que incompletas, tentando reduzir a ansiedade de usuários e clientes e adaptando estas entregas as novas realidades de mercado, de gosto ou simplesmente de alinhamento de informação (aquela velha frase: “não foi isto que eu pedi”).

 

A grande relação entre métodos ágeis e métodos tradicionais é que nenhum deles tem a capacidade por si só de resolver todos os problemas que temos em desenvolvimento de software. Existem situações onde será melhor utilizar um ou outro.

Cabe a nós entendermos e estudarmos os dois e em cada situação termos habilidade para distinguir qual deles se encaixa melhor.

O que não podemos fazer é simplesmente assumir um dos lados como se fosse religião e começar a criticar o outro método sem conhecê-lo direito.

Tenha em mente:

Se você precisa antecipar tudo, vai ser difícil usar métodos ágeis. Talvez possa utilizar algumas técnicas ditas ágeis em conjunto com métodos tradicionais, mas o princípio de antecipar tudo está muito mais ligado aos métodos tradicionais.

Se você pode ou precisa trabalhar com maior dinamismo de escopo, de design, de tecnologia ou por exigência da área de negócio, os métodos ágeis se encaixam muito bem.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

catorze + dezessete =

Consultoria Conduzimos gestores e suas equipes à conquista de resultados! Outsourcing Alocação de profissionais especializados e de alta maturidade Capacitação Treinamentos In Company