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:
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. Antes de continuar a ler esse texto quero que você olhe atentamente para o cronograma acima. Agora, quero que você olhe novamente e me responda qual é o percentual de andamento do projeto. Se você já trabalhou com Gantt Charts logicamente você deve ter respondido com toda a certeza e autoridade: “Com certeza o projeto está 82% concluído”. Se você mostrar esse Gantt para qualquer gerente de projetos, todos eles vão dizer que o projeto está 82% concluído. Eles estão treinados a procurar pela coluna “% Complete” e subir os olhos até a primeira linha para saber como está o projeto.
Antes de falar do problema “82% concluído”, quero que você imagine uma máquina de fazer suco de laranja. O processo é fácil, você abre o saco de laranjas, e coloca as laranjas dentro da máquina e após alguns instantes, sai suco da máquina. Esse é o comportamento esperado da máquina. Agora, imagine que você coloca laranjas dentro da máquina e não sai suco nenhum. Você liga para o vendedor da máquina e ele lhe diz para continuar colocando laranjas que o suco vai começar a sair. Você continua colocando laranjas, mas nada do suco sair. Abismado, você liga novamente para o vendedor e ele diz para continuar colocando laranjas. Então, você acha estranho, mas continua colocando laranjas na máquina, sem conseguir obter uma gota de suco. Esse processo continua até que você já colocou 100 sacos de laranja na máquina e agora começa a desconfiar que não vai sair suco nenhum, ou se sair, vai sair um suco de péssima qualidade. Geralmente é isso que ocorre em equipes focadas em tarefas. Elas não conseguem extrair o suco da fruta. Se você colocou 100 sacos de laranja na máquina você pode dizer que “o projeto está avançando” mesmo sem ter obtido suco nenhum? O cliente que quer o suco ficaria satisfeito em saber que esses 100 sacos já estão na máquina? De jeito nenhum! O que ele quer é o suco!
Muitas empresas de desenvolvimento de software, por mais incrível que possa parecer, têm uma dificuldade ENORME em entregar software funcionando regularmente. Por conta dessa dificuldade, elas adotam um processo de desenvolvimento em cascata exatamente para postergar ao máximo as atividades que evidenciam problemas (como a codificação e os testes). Por conta disso, para elas é muito desconfortável reportar status do projeto baseado em software funcionando, de maneira iterativa. Para esse tipo de organização, reportar status baseado em tarefas que não agregam valor nenhum é mais confortável, mesmo que seja mentira.
Essas empresas usam Gantt Charts, pois eles fornecem um andamento do projeto que atendem aos seus interesses, porém, reportar andamento de projetos de software baseado em tarefas é extremamente arriscado. Quero que você olhe novamente o cronograma. Você consegue perceber que mesmo com 82% concluído não temos NENHUMA funcionalidade pronta? Se você parar para pensar, o software literalmente não existe! O que temos são pilhas de documentos, modelos e código não testado. Sequer sabemos se o que está sendo gerado atende ao negócio do cliente. Os “82% concluídos” é um grande engodo que normalmente se transformam nos “99% pronto, só falta testar”. O gerenciamento focado em tarefas e o uso do Gantt Chart são os responsáveis pelo famoso “corre-corre”, horas extras e explosão do custo no final dos projetos. Já uma equipe ágil na maioria das vezes tem uma tranqüilidade enorme no final do projeto. É comum que após as primeiras iterações os maiores riscos como as funcionalidades críticas do sistema já estejam resolvidas. A prática de antecipar riscos e trabalhar ao lado do cliente garante noites de sono mais tranqüilas.
Pingback:Débito Técnico » Blog Archive » Entregue Software Funcionando! Gerenciamento de Projetos Ágil
Pingback:Débito Técnico » Blog Archive » O Anti-Pattern “Caso de Uso – UML – Codificação – Teste”
Eh por isso que ele eh chamado de Cant Chart…. 🙂
Abracos,
Francisco
http://franktrindade.wordpress.com
Eu particularmente acho que tudo depende da cultura da empresa e do cliente. Em muitos casos, é necessário fornecer um prazo, um orçamento, uma estimativa de recursos e acompanhar as horas gastas em um projeto, através de fases, marcos etc, utilizando uma abordagem “industrial” de trabalho. Sem a mudança de cultura, é impossível adotar as práticas e “jogar no lixo” o acompanhamento do projeto com cronogramas. Eu já trabalhei em projetos com clientes convervadores ou do setor público, que exijiam ter relatórios de status semanais, onde constavam as horas do projeto, as horas gastas, alocação de recursos, orçamento, marcos de entrega etc.
Qual a tua sugestão para não usar esta abordagem diante de um cenário tradicional (a maioria dos casos)? Como mudar a cultura do cliente? Como fornecer status report semanais com informações de andamento de projeto sem ter um controle (aparentemente) mais efetivo do mesmo?
[]s
Claudio Kinzel
O número de iterações fornece o prazo. O custo da equipe vezes o número de iterações dá o orçamento. Fases e Marcos devem ser sempre baseados em software funcionando, no melhor estilo iterativo para projetos empíricos. Software não é um produto de linha de produção, assim, não pode ser tomado como uma abordagem industrial sob nenhum aspecto.
Não existe mudança cultural envolvida. O que existe são gerentes de projeto na maioria das vezes acomodados que teimam em usar ferramentas erradas.
Um product backlog do Scrum é uma ferramenta muito melhor para reportar status do projeto da maneira menos arriscada possível. Nós planejamos baseados em entregas de software funcionando e reportamos baseados em software funcionando.
O melhor controle de projeto de software que existe é “na sexta passada prometemos entregar o pedido de vendas com o cálculo de impostos (pronto, testado, integrado) e aqui está o pedido de vendas funcionando com o calculo.” É esse tipo de feedback que seu cliente espera do andamento. “Gastamos 1200 horas e ainda faltam 1300 horas” é um report pouco fundamentado em RESULTADOS. O que não não pode ser medido não pode ser controlado.
Não concordo quando dizes que não existe mudança de cultura. Existe, sim, e na minha opinião é o principal dificultador da adoção de formas alternativas ao desenvolvimento de software. Se fosse tão fácil quando dizes mudar a perspectiva de desenvolvimento, acredito que muitas empresas já o teriam feito. Quando falas em “acomodação”, acredito que tem um fundo de verdade, porém são diversos fatores envolvidos. Tomando como base XP, por exemplo, a coragem é tida como um valor, no sentido de fazer aquilo que é “certo”, e que muitas vezes não se faz por diversos fatores, alguns irracionais. E isso é, sim, mudança de cultura, que envolve perceber o software não como um produto de um esforço repetitivo e mecânico, mas sim criativo. E, para a coisa toda funcionar, o cliente, que no final é que justifica o software, precisa estar confortável nesse modelo (a sinceridade como princípio) e alinhado, como sugere o XP, membro da equipe de desenvolvimento.
Ora, por mais que se tente, em alguns casos é impossível mudar a visão das pessoas e, nestes casos, uma abordagem mais tradicional é o único caminho viável. Muitas vezes, em projetos de TI, as decisões que impactam em prazo, escopo e custo são unilaterais e tomadas por pessoas alheias à equipe de desenvolvimento. O ponto-chave para mim é: mudança de cultura, abrir a cabeça para coisas novas, pensar diferente (e isso é a parte mais difícil de se conseguir, podes apostar).
Para finalizar, a síndrome do estudante reforça uma tese importante: as pessoas motivadas tendem a não esperar pelo tempo estimado, elas querem fazer as próximas tarefas e ver a qualidade de seu trabalho, por isso precisam de menos gerenciamento. E motivar as pessoas envolve, sim um forte mudança de cultura, de um pensamento de trabalho industrial para um digital (uma tese interessante é a do Ócio Criativo, de Domenico De Masi).
[]s
Claudio Kinzel
Também acho que exista um questão cultural sim, não da equipe talvez, mas dos maus gerentes e principalmente do cliente.
Um exemplo: eu trabalho para uma consultoria e estou alocado atualmente em uma financeira, que possui uma montadora de veículos como cliente. Nossa equipe está trabalhando em um projeto para essa montadora, ou seja, para o cliente do nosso cliente. Há pouco tempo o representante desse cliente nos visitou para dirimir quaisquer dúvidas sobre o projeto, e acredite, o objetivo da visita foi exatamente esse, esgotar TODAS as dúvidas. O que eu vi aqui foi uma correria monumental da equipe em reuniões num esforço sobrehumano de imaginação a respeito das dúvidas do projeto numa área de negócios que nenhum da equipe tinha experiência. Ouvi do líder desse projeto a frase: “Por favor!!! Vamos tomar cuidado pra não fazer perguntas que já foram feitas”. Nosso cliente age com medo de seu cliente, e nossa equipe age com medo dos dois. Todos entenderam implicitamente que uma ligação para o cliente após essa reunião miraculosa seria absolutamente inaceitável.
Toda a proposta dos projetos ágeis é linda e eu adoraria trabalhar assim, mas a realidade é ridícula, principalmente no que tange o entendimento do cliente a respeito do que é um software.
Como lidar com isso sendo um mero programador e quando o resto da equipe, e principalmente, quem pode agir no sentido de mudar a cultura do cliente, aceita tudo isso chamando waterfall de RUP?
Diante disso, como não se tornar um medíocre programador batedor-de-cartão-só-interessado-no-salário-de-fim-de-mês?
Pois é Eduardo. Se você procurar profundamente você verá que a origem de todos os pecados é o MEDO. Desde modo, Kent Beck acertou em cheio quando colocou a CORAGEM como um valor importante no XP.
“Como lidar com isso sendo um mero programador e quando o resto da equipe, e principalmente, quem pode agir no sentido de mudar a cultura do cliente, aceita tudo isso chamando waterfall de RUP?”
É isso que nós da comunidade ágil aqui no Brasil queremos mudar e estamos nos esforçando nesse sentido. Mas, saiba também que meros programadores podem demonstrar valores ágeis importantes e resultados. Realmente Gerentes são uma pedra no sapato. Saiba que um dia vc irá liderar também (não necessariamente como gerente, mas algum momento você liderará).
Para não se tornar um programador medíocre, creio que vc já está fazendo o possível. Estude. Tenha respostas. Quando possível introduza mudanças. Acredite, com alguma influência você pode liderar seus líderes.
Pingback:Débito Técnico » Blog Archive » Só Agilidade funciona
Pingback:Débito Técnico » Blog Archive » Síndrome da Gestão Covarde
Pingback:Débito Técnico » Blog Archive » Um exemplo a ser seguido
Pingback:TPW - Dicas para o Desenvolvedor « 1up4Developers
Pingback:1up4Developers » Blog Archive » Os guardiões da cascata
Guardião esta foi boa. hahahahahahahahahaha
Pingback:Pessoas e relacionamentos: metodologias ágeis sabem o que realmente importa « Tupi
papo de programador que não gosta de controle nos projetos.
só vi criticas, mas nenhuma proposta de alternativa.
Um gantt Bem feito pode modelar projetos usando metodologias RUP, XP, waterfall, etc… é questão de modelagem na criação e disciplina no monitoramento.
Não sou só programador, mas também gerente de produto, gerente de projetos e lider de equipes e pode ter certeza que meus projetos são muito bem controlados!
RUP não diz para usar Gantt Chart e MUITO MENOS XP. Você não vai encontrar equipes XP NUNCA usando Gantt Charts.
Waterfall é um anti-padrão…
As idéias colocadas aqui não são só minhas, mas sim concordando com literaturas do Schwaber e do Sutherland entre outros.
Um Product Backlog do Scrum é uma alternativa. No meu treinamento de Scrum eu mostro isso, além de outros artigos aqui no Blog. Se tiver interessado é só falar!
Infelizmente muitas pessoas só se preocupam com o projeto, e não com o produto. Com isso, corremos o risco de ter um projeto de sucesso (todos os artefatos entregues, documentação completa, prazo e custo atendidos) sem ter um produto de sucesso (software funcionando).
Sempre atento aos adeptos do XP para que seus discursos não pareçam de “programador que não gosta de controle”. O controle é necessário em todo projeto. Imagine que você é deno de uma emrpesa, e precisa selecionar projetos para serem desenvolvidos. A primeira coisa que você vai querer saber é: qual o custo e o prazo? Esse é o mínimo de informação que um gestor precisa ter para tomar essa decisões de quais projetos serão executados e quais projetos não serão. A grande dificuldade dos projetos de escopo aberto é estabelecer um prazo para conclusão. Todos já sabemos os motivos de o Scrum ser melhor que a gerêncai tradicional. Mas uma coisa que sempre faço, em qualquer projeto, é planejar quais itens do product backlog serão desenvolvidos em cada ciclo, e por qual equipe. Dessa forma, estou estimando o projeto, e informando um custo e prazo. Isso não quer dizer que não possa mudar, mas preciso informar um custo e um prazo. E se voce utilizar dados histórios para isso esse “chute” vai sair bem melhor do que pensa!
Eduardo, é um mito achar que métodos ágeis não tem controle. Existem controles muito eficientes e muito inteligentes. Eu sou dono de uma empresa e tomo essas decisões que vc falou. Sei também que software é algo complexo e sei que qualquer tentativa de ter custos e prazos precisos é algo muito dispendioso.
Eu trabalho com contratos de escopo negociável e meus clientes sabem a cada iteração a previsão do fim do projeto e seu custo sem problemas. A questão é que isso não está no contrato e damos toda a liberdade para o cliente fazer aquilo que ele quiser.
Dados históricos não funcionam. As métricas que uso hoje sempre levam em consideração o sentimento da equipe. Se um sistema nunca é igual ao outro, dados históricos tem confiabilidade nula.
Gente, apesar das ótimas noções gerenciadas, com as quais concordo de modo geral, notei que existe uma boa dose de extremismo em algumas opiniões. Na prática já convivi com detestáveis “guardiões de projeto” com uso da metodologia SCRUM também, não é a metodologia que os gera e sim a inflexibilidade e estupidez do gerente de projeto!
Sim, o SCRUM é um formato mais flexível e iterativo que por si só influencia o gerente de projeto a adotar uma atitude mais produtiva, porém ele não faz milagres. Já vi a metodologia Gantt ser adotada de forma produtiva *e* cumprindo prazos numa equipe multi-disciplinar de mais de sessenta pessoas. Tudo depende de onde vêm os prazos e da confiabilidade desta informação. Se os prazos vêm da “experiência” ou do “feeling” do gerente de projetos, de algum dos líderes ou do cliente, esqueça, não funciona – e é este tipo de cenário que vocês estão criticando. Concordo. Agora, se os prazos vêm dos próprios programadores e outros contribuidores, aqueles que realmente vão ter que executar as tarefas, eles sentem-se naturalmente respeitados pela consulta e dão o seu máximo para cumprir os mesmos.
O SCRUM é excelente para o desenvolvimento de software puro (se é que isso ainda existe..), mas uma coisa que o SCRUM não consegue resolver satisfatoriamente é a inter-dependência de funções em equipe multi-disciplinares. Com o avanço da indústria de entretenimento e multimídia, cada vez mais este tipo de software e equipe torna-se comum. Trabalho com desenvolvimento de games e simulações interativas que envolvem bastante integração de arte e software, sei por experiência o quanto o SCRUM é inadequado para tais aplicações. Também apliquei com sucesso sistemas Gantts “flexibilizados” para funcionar com modelos iterativos.
Não importa o quanto a teoria seja boa, se o dinheiro só vai sair se você apresentar marcos (milestones) confiáveis a seu cliente e posteriormente cumprí-los, é bom tratar de resolver o problema de forma adequada senão não existirá sequer um projeto para você gerenciar.
Breno, o Scrum foi feito para “resolver satisfatoriamente a inter-dependência de funções em equipe multi-disciplinares.”
No meu exemplo a questão não é multi-disciplinar, mas sim de proporções, lead-times e propósitos.
Não sou expert na indústria de games, mas se o pessoal de arte e do pessoal de desenvolvimento estão junto para fazer um game, eu vejo que é possível fazer eles trabalharem juntos num Backlog logicamente adaptando o que for possível.
Perguntaram aí sobre uma opção ao Gantt Chart, ou “Can’t Chart” como o Frank citou.
Fica a indicação do diagrama de Parking Lot (bastante usado em projetos com Feature Driven Development).
Artigo de exemplo:
http://www.nebulon.com/articles/fdd/fddimplementations.html
Material em português:
http://www.heptagon.com.br/fdd-links
Para os que gostam de Excel, existem algumas planilhas bem legais que modelam estes gráficos.
E softwares livres também. Exemplo:
http://fddtools.sourceforge.net/
Yoshima,
eu vi esse post faz um tempo e já devia ter comentado, olha, tem a ver com cultura sim porque tive que mudar a minha.
Você não sabe o quanto sofri (e impus sofrimento) tentando enfiar gantt goela abaixo dos desenvolvedores. Se essa forçação toda ainda tivesse gerado um bom resultado do lado do negócio tudo bem, mas não gerou, o Gantt só funciona com software quando você usa ele para mostrar o passado, o que não serve muito.
Mesmo para cascata, qual é o valor de diagramar que a etapa 2 fica depois da 3 que fica antes da 4? Isso cabe em uma listinha. É muito pouco valor.
Acho que para impedir isso de ocorrer, poderíamos incluir “Gantt não funciona com software” no currículo do primeiro grau para ninguém mais perder tempo.
O que indica progresso no desenvolvimento é software rodando*, mais nada. E olha que é um analista de negócios falando. Agora sempre equilibro a quantidade de análise feita antes e depois da primeira iteração.
*Ahh, como incomodei meu amigo agilista Ronan até entender isso 🙂
Este post já é velhinho, mas ainda cumpre um bom papel.
grande abraço,
Claudio Br
Pingback:O que é Scrum? « André Nascimento
Pingback:André Nascimento » Blog Archive » Entrega Cascata VS Entrega Incremental
Pingback:Gantt Chart, só que não « SharpDomains
Belíssimo texto. Concordo, também com comentários do autor abaixo do post. Talvez um Gantt seja mais um “gráfico para inglês ver”, usando a terminologia do Akita (http://www.akitaonrails.com/2013/11/01/off-topic-agile-feito-errado).
Mesmo no Waterfall é difícil acreditar que entregas como Requisitos e Codificação sejam executadas de forma continua e em seqüência sem que sejam revistadas no futuro, como em um processo iterativo e incremental.
Não acredito que um cliente valorize mais um Gantt do que um Status do projeto baseado em funcionalidades do Backlog entregues, que provavelmente representam software rodando.
Com certeza o Gantt é legal para outros tipos de projeto onde as entregas tenham dependências fortes e sejam de fato sequenciais, como na construção civil, talvez. Deve ser mais ou menos legal para mostrar tarefas em execução em um determinado e curto espaço de tempo, mas para planejar e reportar em projetos de software, não é legal!
Achei um ótimo post na Infoq sobre essa questão e dando alternativas sobre como planejar e dar feedback do andamento em projetos de software. Tem Parking Lot, Burndown e um bocado de coisa. Vale à pena a leitura.
http://www.infoq.com/br/news/2013/06/relatorios-status-agil
Yoshima, acho que você poderia até ter escrito esse post e se aposentado. Ainda faço uso.