Arquivos do Blog

Resultado da Enquete – Qual é a melhor ferramenta para criar a EAP do projeto?

Resultado - Qual é a melhor ferramenta para criar a EAP do Projeto

Análise

A pesquisa em questão foi criada com o objetivo de levantar qual é a ferramenta preferida dentre os gerentes de projetos para a construção da Estrutura Analítica do Projeto. Após o fechamento da enquete, foi possível constatar que a WBS Chart Pro, ferramenta utilizada exclusivamente para a criação da EAP, figura como a preferida pelos usuários com um percentual de 70%, totalizando 82 votos. Sua licença individual custa $199. Em segundo lugar, aparece a XMind com 12 votos e um total de 10%. Ela possui uma versão gratuita, porém com menos recursos. A versão mais completa está disponível por $99. Outras ferramentas que não foram listadas tiveram um total de 9 votos, representando 8% do total. Logo em seguida se destaca, dentre as favoritas dos usuários, a ferramenta de código aberto OpenProj. Ela representa 7 votos, totalizando 6% da preferência. Em seguida, aparece a WBS Tool (software web gratuito e exclusivo para criação da EAP) com 5 votos (4%). Por fim e em último lugar, figura a MindView – uma ferramenta profissional para construção de mapas mentais, estruturas analíticas, dentre outros. Com preço inicial a partir de $249, ela obteve um total de 2 votos (2%). 

Este slideshow necessita de JavaScript.

Anúncios

Resultado da enquete: “Na sua opinião, qual é a melhor ferramenta para planejar e controlar o cronograma do projeto?”

Pelo resultado da enquete é possível notar a preferência da comunidade de gerenciamento de projetos pelo uso do Microsoft Project como ferramenta de planejamento e controle do cronograma de projetos. Liderou a pesquisa com 56% dos votos. Logo atrás aparece o Oracle Primavera com 20% da preferência de mercado. Project Builder e GanntProject aparecem com apenas 1% dos votos, enquanto que, outras ferramentas como Trac (2 votos), Go Horse e Microsoft Excel (1 voto cada) figuram dentre as preteridas. É válido ressaltar que o Microsoft Excel não é uma ferramenta específica para gerenciar projetos, não possui funcionalidades voltadas a esse propósito. Porém , ela pode ser utilizada para organizar o cronograma e configurada para gerar cálculos e gráficos de acordo com as necessidades de cada usuário. A grande surpresa ficou por conta da poderosa IBM não ter sequer um voto para sua ferramenta de gerenciamento de projetos. o Clarity. OpenProj e NetProject foram outras ferramentas não votadas.

Gráfico Burndown como ferramenta para avaliar riscos em Projetos Ágeis

O gerenciamento de riscos é uma disciplina fundamental utilizada durante todo o processo de desenvolvimento de um projeto. E você sabe por que, caro leitor? Porque, na verdade, tudo o que nós gerenciamos são riscos.  Vamos pensar um pouco: se preciso concluir uma tarefa no prazo estimado de um dia e planejo quais serão os passos necessários para concluir essa tarefa no prazo estabelecido, não estou gerenciando  meu tempo. Não se engane! Na verdade, o que você estou gerenciando é o risco de atrasar a conclusão daquela tarefa. Essa mesma linha de raciocínio pode ser utilizada em diversas outras situações.

Muitos acreditam que as metodologias ágeis ignoram completamente os riscos em um projeto. Nao é bem assim! O que acontece é que o manisfesto ágil aposta em valores que vão de encontro às crenças das metodologias tradicionais. Os riscos são vistos como inerentes aos projetos e são aceitos, mas nunca ignorados! Com suas pequenas iterações  e entregas constantes de produto potencialmente utilizável ao cliente, o time evita o maior risco que os projetos enfrentam: não entregar nada. Assim, as metologias ágeis buscam se antecipar à ocorrência dos riscos, o que prova que eles não são ignorados.

Hiren Doshi e Kane Mar publicaram, recentemente, alguns artigos sobre a análise do Gráfico de Burndown, apresentando que tipo de informações ou perguntas podemos extrair dele. Trata-se de “uma ferramenta importante para o acompanhamento do progresso de um time ágil e muitas informações podem ser extraídas do mesmo. Também podemos utilizá-lo para acompanhamento do projeto, produto ou releases” [HAZRATI, 2010].  A análise de Hiren Doshi foi baseada nas perguntas e no gráfico abaixo:

Em um gráfico de burndown eixo Y pode ter como unidade horas, semanas ou story points, enquanto o eixo X pode ser em dias ou sprints. É importante frisar que a unidade escolhida deve ser a mais adequada com a realidade de cada projeto ou organização, visto que cada unidade possui visões e objetivos diferentes.

“Burndown por horas e burndown por pontos tem propósitos diferentes!! Ninguém espera que um burndown por horas diga o quanto de valor foi entregue, mas apenas o acompanhamento do ritmo dirário do time. Os dois são importantes!” Alexandre Magno, CST

Podemos fazer uma análise do gráfico acima, o que nos trará subsídios para que possamos evitar que riscos futuros de projeto.

Observando a linha azul (linha 1) podemos visualizar um cenário não desejado. O time não conseguiu alcançar seus objetivos traçados durante a Sprint Planning, o que indica que o planejamento e/ou a execução não estão bons. Podemos citar algumas situações que podem contribuir para a construção deste cenário: planejamento de mais histórias do que a capacidade do time, alteração de prioridades durante o sprint ou uma falta de união do time. E quais são os riscos que este cenário apresenta?

  • Atrasos na entrega de partes potencialmente utilizáveis do produto ao cliente;
  • Desgastes com renegociação de prazos;

A linha roxa (linha 2) apresenta um cenário onde o time conseguiu atingir a meta, porém esteve longe do progresso ideal. A curva acentuada pode indicar que o time não atualizou suas estimativas de maneira adequada ou ainda que hisórias incompletas foram retiradas da sprint. Isso demonstra um time comprometido com o prazo, porém pouco interessado com a qualidade do processo e do produto gerado. O principal risco envolvido nesse cenário é a insatisfação do cliente com relação ao que foi prometido e o que realmente foi entregue. A consequência imediata pode ser desgaste na relação com o cliente, bem como eventuais quebras de contratos.

Por fim, a linha verde (linha 3) demonstra um cenário ideal, onde planejamento e execução foram bem feitos. O time é auto-organizado e bastante adaptável a mudanças. Porém, como diria o poeta,  nem tudo são flores! Sempre existe algo que pode ser melhorado e isso deve ser feito durante a Sprint Retrospective, que envolve uma análise dos pontos positivos e negativos apresentados pelo time durante a Sprint.

Bem o objetivo desse post foi demonstrar que o Gráfico de Burndown pode ser uma ótima ferramenta de apoio na gestão de riscos de projetos ágeis.  E para tanto, ela deve ser utilizada de acordo com as necessidades que o negócio ou organização necessita. Caso o leitor queira se aprofundar um pouco mais no assunto, existe um artigo publicado na LOCAWEB que faz uma outra análise sobre o Burndown focada em mudanças na sprint. Há também um outro artigo muito interessante de Kane Mar, Seven common Sprint Burndown graph signatures, onde ele separa o Burndown em sete categorias apresentando as nuances desses diversos cenários. Vale a pena conferir!

DOSHI, Hiren. Sprint Burndown says a lot about your scrum team... PracticeAgile  Software Development, 2010.
HAZRATI, Vikas. Analisando gráficos de Burndown. InfoQ, 2010.
Mudanças de Sprint. LOCAWEB, 2010.
MAR, Kane. Seven common Sprint Burndown graph signatures. 2006.
%d blogueiros gostam disto: