Causas de fracassos em projetos de TI e como as metodologias geis poderiam ajudar

Entregas atrasadas, prazos estourados, qualidade aqum do desejado Quem nunca vivenciou uma ou mais situaes dessas em projetos de tecnologia? Que existem problemas, todos sabem.. Mas onde est a causa dos mesmos? Paulo Moraes, diretor do captulo So Paulo do PMI, apontou alguns destes problemas no site CIO. Ok, mas onde a agilidade se relaciona com esses problemas? Seria possvel fazermos uma relao entre os problemas levantados por Paulo Moraes com as melhorias que conseguiramos com a utilizao de metodologias geis? Vamos tentar: - Falta de uma camada de gerenciamento de projetos: Achei interessante sua opinio qualquer metodologia serve, desde que esteja presente. No qualquer metodologia que ir resolver os problemas. Mas ter uma metodologia e segui-la j um bom passo. - Falha no planejamento do projeto: As pessoas tm preguias de escrever, fazer diagramas etc., porque muitas vezes no vem resultados rpidos nos seus trabalhos. A entra o conceito de entregas peridicas das metodologias geis. - Processos crticos de negcios mal definidos: a empresa ter de fazer mudanas no sistema depois de estar pronto. Para evitar mudanas no sistema depois de pronto, entregue em partes e avalie a adequao do sistema periodicamente. - Falha em detalhar os processos nas pontas: Conhea o P.O. (Product Owner) e entregue software sempre. Assim, voc ir conhecer seus usurios com mais rapidez.

- Falta de envolvimento do pessoal das pontas: Se voc entregar um software sempre, esse problema no ocorrer. Os problemas sero descobertos com antecedncia. - Falha em preparar o sistema para agentar os picos de utilizao: Novamente mais um problema que seria facilmente resolvido com entregas peridicas. - Evangelizar os patrocinadores do projeto: Todos os envolvidos no projeto precisam ter conscincia do que est no papel e saber que isso que ser realizado, nada menos, nada mais. Os patrocinadores tero conscincia do que ser desenvolvido e ver o resultado mais rapidamente em partes.

- Iniciar a implantao antes de definir o escopo: Terminar todo um escopo antes de implantar um sistema muito bonito (na teoria!). Clientes tm pressa, o mercado dinmico, no pode esperar. Para isso, entregue software sempre. - Estouro do escopo: No possvel modificar o projeto a cada novidade de mercado. possvel, desde que seja combinado e que voc esteja preparado para se antecipar s mudanas. - Falhas de testes: O SCRUM define o envolvimento de toda equipe (inclusive os testadores) durante o Sprint Planning, onde os requisitos so definidos. Alm disso, diariamente os testers acompanham a evoluo das tarefas, conhecem os impedimentos dos desenvolvedores e tentem a errar menos, porque sabem mais. - Falta de treinamento: Um plano de treinamento necessrio, mas quase impossvel de ser colocado em prtica. As metodologias geis prevem a integrao de todo o time durante todo o projeto. Com isso, voc no tem um treinamento formal propriamente dito, mas consegue disseminar o conhecimento durante o dia-a-dia com muito mais facilidade. - Falhas ao carregar os dados no sistema: Entregue software periodicamente que esse problema ser descoberto antes da implantao. Com base nos comentrios acima, percebemos que um dos grandes, seno o maior, problema do RUP tradicional voc ter as fases muito amarradas: primeiro o escopo, depois o dsv, depois os testes e depois a implantao. Isso gera inmeras possibilidades de falhas no escopo, de entendimento etc. Neste aspecto, as metodologias geis apresentam uma soluo muito simples, mas que resolveria a maioria dos problemas: entregue software de forma iterativa e incremental.