Gerenciamento Ágil De Projetos Em TA

1 Introdução

Desde a Crise do Software, que forçou com que as Software Houses realizassem projetos de desenvolvimento de Software de uma maneira mais profissional e organizada, muitas metodologias para esse desenvolvimento surgiram. Linguagens foram criadas para modelar e facilitar o entendimento do produto pelo cliente e pela própria empresa desenvolvedora [1].

Na década de 70, a atividade “desenvolvimento de software” era executada de forma desorganizada, desestruturada e sem planejamento. Gerava-se um produto final de má qualidade pois não existia documentação, era entregue fora do prazo ou o levantamento de tempo e esforço não correspondia com a real necessidade. Muitas vezes, esta atividade não satisfazia as necessidades do cliente, desperdiçavam-se recursos da empresa e aumentavam-se gastos que não viriam a ser compensadores para o cliente, demandando tempo, esforço e dinheiro. Essa época ficou conhecida como Crise do Software [1].

A partir deste cenário, surgiu a necessidade de tornar o Desenvolvimento de Software como um processo estruturado, planejado e padronizado, para que as necessidades fossem atendidas e os gastos com informatização de processos de informações se tornassem compensadores.

Para o atendimento desta padronização, surgiram Metodologias de Desenvolvimento que dividem o processo de desenvolvimento em fases pré-definidas. Essas Metodologias se adequam às características organizacionais, ao ambiente de desenvolvimento implantado em uma organização e às características dos projetos: O tempo que pode ser gasto e a real necessidade do cliente a fim de estimar custos e prazos reais.

Entretanto, a crise do software perdura até hoje. Mesmo com técnicas avançadas de desenvolvimento e padrões consolidados na área de criação de softwares, ainda existem características da época da crise: projetos atrasados, erros de estimativa de custos e de tempo que tornam o processo, ainda que sistematizado, passível de muitos erros.

Um famoso estudo feito pelo Standish Group, publicado anualmente, mostrava na sua última revisão em 2009 [2]:

• 24% dos projetos fracassam

• 44% dos projetos são entregues com sucesso parcial

• E apenas 32% dos projetos obtêm sucesso.

A pergunta que fica é: O que podemos fazer para aumentar estes 32%?

2 Processo de desenvolvimento de software

Pela perspectiva dos clientes o processo de desenvolvimento de um software muitas vezes se assemelha a uma “caixa-preta”. Os requisitos entram por um lado e o produto sai do outro, normalmente muito tarde. Neste intervalo podemos ver a Especificação Funcional e outros documentos e produtos que nos mostra que alguma coisa está acontecendo, mas que não podemos ter certeza do que exatamente. Normalmente, a probabilidade de uma mudança de requisito aumenta com o tamanho do projeto, o que aumenta ainda mais a dúvida se o resultado do projeto vai atender as nossas necessidades. Então só resta aguardar e ter esperança que tudo dê certo. Os resultados, no entanto, são incertos e normalmente decepcionantes. Os clientes normalmente ao verem o resultado pela primeira vez tem a síndrome da reação “Sim... Mas...” [3]:

Sim, isto é realmente legal e apreciamos o que foi feito, mas não é exatamente o que precisamos. Talvez:

1. Você não tenha entendido o que queríamos, ou

2. Você tenha entendido, mas mesmo assim tenha feito algo diferente, ou

3. Isto é o que queríamos, mas agora precisamos de algo diferente

O que precisamos é de uma forma do cliente ver e avaliar o progresso antes que seja tarde demais. Precisamos de um processo que ofereça visibilidade mais cedo e que aceite mudanças, mas que mantenha rigor em relação à qualidade.

3 Metodologias de desenvolvimento

Metodologia de Desenvolvimento é um conjunto de práticas recomendadas para o Desenvolvimento de Software, sendo que essas práticas, geralmente, passam por fases ou passos que são subdivisões do processo para ordená-lo e melhor gerenciá-lo [4].

3.1 Metodologias Tradicionais

As metodologias consideradas tradicionais têm como característica marcante serem divididas em etapas e/ou fases. Essas fases são muito bem definidas e englobam atividades como Análise, Modelagem, Desenvolvimento e Testes.

Muitas metodologias pesadas são desenvolvidas no modelo em cascata o que dificulta o controle do projeto. A cada alteração em determinado ponto do projeto, como os requisitos, será necessário uma volta ao início do mesmo para alteração de documentação ou outro marco. Neste modelo as fases definidas são sistematicamente seguidas de forma linear. É o modelo mais usado em todo o mercado, porém não é o mais eficaz. Raros projetos seguem esse fluxo linear, além das mudanças de requisitos que ocorrem no decorrer do projeto não serem de fácil adaptação porque alteram toda a documentação já desenvolvida, o que implica em retrabalho [1].

Uma abordagem linear significa que o projeto é desenvolvido etapa por etapa. Por exemplo:

1. O time de projeto primeiro analisa, determinando e priorizando os requisitos;

2. Em seguida, na fase de “Design” os requisitos são traduzidos em soluções técnicas e as decisões são tomadas em relação a qual tecnologia utilizar, i.e. Java, VB, etc.;

3. Uma vez que os processos são definidos se inicia a fase de “desenvolvimento do código”;

4. A próxima fase envolve o teste completo do software;

5. Por fim, a última fase envolve a manutenção do software;

A figura abaixo mostra a sequência de desenvolvimento em um modelo “cascata”

3.2 Metodologias de desenvolvimento Ágeis

No começo de 2001, motivados pela observação de times de desenvolvimento perdidos entre os processos que existiam na época,