15 Nov, 2007
Por que Gantt Charts não servem para projetos de Software?
No meu artigo “Entregue Software Funcionando! Gerenciamento de Projetos Ágil” (MundoJava #26) publiquei um manifesto contra o uso de Gantt Charts para projetos de software (ou qualquer outra atividade criativa e empírica). Segue o trecho!
Quase todas as organizações que tive contato tentam, e falham miseravelmente, aplicar Gantt Charts para controlar e reportar status do projeto. Vamos estudar um exemplo:
Clique para ver imagem completa…
PROBLEMA 1 – O processo é cíclico: É muito comum ver Gantt Charts de projetos de software com essa disposição, porém, uma das maiores razões do acompanhamento do projeto falhar com Gantt Charts é que o processo de desenvolvimento de software é cíclico e não linear da maneira Requisitos-Análise-Codificação-Teste. Além disso, os produtos dessas disciplinas são abstrações, assim, não podemos tomar um documento de requisitos e tratá-lo como “pronto” de maneira determinista.
O desenvolvimento de uma funcionalidade de software passa por VÁRIOS ciclos de Requisitos-Análise-Codificação-Teste. Essa é uma das razões que Gantt Charts sempre estão atrasados. Muitas vezes não é previsto pelo cronograma que durante os testes o processo pode voltar várias vezes para a codificação, para análise ou até para requisitos. Como esse tempo não está previsto, naturalmente o cronograma se torna impossível de se cumprir.
PROBLEMA 2 - Síndrome do Estudante: Um dos problemas comuns do foco em tarefas é um fenômeno chamado “Síndrome do Estudante” defendido por Eliyahu Goldratt na Teoria da Corrente Crítica. Esse fenômeno é simples de observar nos projetos. Alguma vez você viu um projeto de software controlado por Gantt Charts ser entregue antes do prazo? Creio que isso deve ser extremamente raro! Essa falha acontece porque um Gantt Chart funciona melhor para projetos com controle definido e não empírico. A Síndrome do Estudante é também chamada de Procrastinação. Procrastinar é adiar continuamente o início das tarefas simplesmente pelo fato do cronograma lhe dar “um prazo confortável”.
No cronograma acima podemos ver que foi dado 32 horas para o Júlio fazer a análise. Mesmo que ele consiga fazer esse trabalho em 8 horas, a tendência é que ele só diga que terminou após as 32 horas, ou talvez ele inicie a tarefa somente quando estiver lá pelas 24 horas do prazo. A síndrome do estudante é provada pelo fato que as pessoas realmente sabem o último minuto possível que elas têm para iniciar uma tarefa. Ela tem esse nome por conta do nosso comportamento quando temos uma prova marcada para daqui a um mês: só começamos a estudar um dia antes da prova!
PROBLEMA 3 – Essas dependências não existem! Muitas pessoas realmente acreditam que existe uma dependência Requisitos-Análise-Codificação-Teste. Essas pessoas estão em contato há muito tempo com Gantt Charts, organizações funcionais, divisão do trabalho e desenvolvimento em cascata, e essa exposição a práticas ruins gerou paradigmas na mente delas, porém, essas dependências não existem na prática! É possível que você faça Requisitos, Análise, Codificação e Teste tudo ao mesmo tempo, ou talvez, num prazo tão curto de tempo (em frações de minutos) de forma que não é interessante gerenciar essas dependências!
Uma das coisas que as pessoas não compreendem na metodologia XP (Extreme Programming) é a prática do TDD (Test-Driven Development). Nessa prática, testes são escritos antes que qualquer código da funcionalidade seja escrito. Dessa forma, não existe código não testado e os testes são feitos antes ou durante a codificação. A idéia é: codifica-se um pouco, testa-se um pouco, e esse ciclo ocorre centenas de vezes num único dia. Outro ponto: agilistas gostam de tomar os testes como sendo seus próprios requisitos, então, testes e requisitos tornam-se uma coisa só. Dessa forma, numa única semana, o ciclo requisitos-codificação-teste pode ocorrer MILHARES de vezes dentro de uma equipe!
O levantamento dos requisitos podem ser feitos a qualquer momento através da prática do “cliente presente”, ou através de uma ligação telefônica para o cliente. A análise pode ser feita de modo incremental assim que novos requisitos vão sendo adicionados no projeto (via refactoring). As disciplinas não são fases! Elas ocorrem ciclicamente e esse ciclo numa equipe ágil é tão rápido que o custo para gerenciar isso não vale a pena. Acredite! Antes das pessoas começarem a tentar aplicar idéias Tayloristas no desenvolvimento de software, essa atividade era bem simples, divertida e a última preocupação que existia era o cronograma.
PROBLEMA 4 – A Grande Mentira da Porcentagem Concluída Leia o restante deste artigo »
