Os princípios da gestão de projetos Agile criaram raízes nos domínios do desenvolvimento de software e engenharia. Existem muitas metodologias diferentes (como Scrum ou Kanban) sobre como implementar estes processos, mas ágil não tem que ser complicado e pode ser aplicado em qualquer campo (mas talvez não deveria ser).

Este artigo pretende dar-lhe alguns passos para além dos princípios simples de Ágil, com informações acionáveis, evitando ao mesmo tempo o dogma de qualquer metodologia particular.

Se quer saber como a gestão de projetos Agile difere da gestão tradicional do projeto, este artigo é para si. Uma vez que somos uma empresa de software que vende uma aplicação de gestão de projetos, vou concluir o artigo com a forma como a OneDesk pode ajudá-lo a alcançar as coisas que discutimos.

O Espectro do Planeamento de Projetos

Os projetos são essencialmente objetivos finais que são divididos nos passos necessários para chegar a esses objetivos. A gestão de projetos está a criar esses passos, organizando-os, executando-os e acompanhando o seu progresso. Os projetos maiores exigem equipas maiores – e, portanto, planear, estimar, atribuir, rastrear e coordenar, é frequentemente um trabalho a tempo inteiro.

Como podem imaginar, nem todos os projetos são criados iguais. Uma receita simples pode bastar quando se faz o jantar, mas isso não vai funcionar para desenhar uma ponte. Os métodos de gestão do projeto necessários variam radicalmente em todo este espectro, assim como as ferramentas.

Para a maioria de nós, os projetos que fazemos no trabalho caem algures no meio do espectro:

  • Trabalhamos em equipa e pessoas diferentes farão diferentes partes do projeto
  • Temos de prestar atenção à ordem das nossas tarefas.
  • Devemos ter uma estimativa razoável de quanto tempo vai demorar, e quando será terminado
  • Para alguns de nós, os custos precisam de ser contabilizados
  • Temos de ser capazes de ver se estamos no caminho certo e até onde estamos no projeto. Se isto soa como o tipo de projetos em que trabalha, com talvez uma ou duas preocupações adicionais, então o seu trabalho pode ser capaz de beneficiar de uma abordagem ágil ou may NOT. Mesmo dentro destes projetos de média dimensão, há graus de quanto um projeto precisa de ser planeado e gerido. Na extremidade mais leve, uma lista de a fazer escrita num quadro branco pode funcionar. No final mais pesado, podem ser necessárias linhas de tempo, gráficos de gantt e calendários de recursos. O truque é encontrar o ponto no espectro onde gerir o seu projeto não custa mais do que beneficia. Pode ser difícil de encontrar.

    Gestão tradicional de projetos

    Não há definição fixa de gestão tradicional de projetos, mas para efeitos deste artigo vamos descrever algumas práticas que são frequentemente seguidas.

    Com uma gestão de projetos mais tradicional, antes de os projetos serem lançados são cuidadosamente planeados. Isto significa que:

  • O maior número possível de tarefas são identificadas.
  • As estimativas em termos de trabalho/duração são feitas para estas tarefas.
  • Os custos também são estimados.
  • As atribuições são feitas entre tarefas e recursos.
  • Estima-se uma data para a conclusão do projeto. Como podem ver, esta abordagem é pesada em termos de planeamento e requer muito trabalho inicial antes mesmo do início do projeto. Embora esta abordagem possa ser necessária para alguns projetos, pode sobrecarregá-lo com despesas desnecessárias para muitos outros projetos. A gestão ágil do projeto rejeita esta abordagem pesada do planeamento, substituindo-a frequentemente por técnicas e ferramentas alternativas. Três destas técnicas são pontos ágeis, iterações/time-boxe, e placas de estado.

    Pontos Ágeis

    Pontos ágeis (pontos de história) são estimativas de esforço. Embora a gestão tradicional do projeto normalmente estima o esforço de tarefa em termos de horas de trabalho, com ágil você simplesmente marcar uma tarefa em uma escala de pontos (por exemplo: 1 a 5) e deixá-lo assim. Uma vez que este tipo de estimativa leva muito pouco tempo a fazer, está a negociar um planeamento de despesas mais baixas para uma menor precisão na estimativa.

    Um número total de pontos (ou capacidade de pontos) é atribuído a um projeto ou iteração. Apenas preenchemos o projeto com tarefas, até que a sua capacidade de pontos seja alcançada. Uma vez que algumas tarefas serão sobrestimadas e outras subestimadas, esperamos que seja uma média para cerca de certo. A experiência dir-nos-á quantos pontos a nossa equipa pode conseguir num determinado período de tempo.

    Tempo-boxe ao fazer iterações

    As iterações são pequenos projetos ou as sub-divisões de projetos. O tempo-boxe é o conceito de manter as suas iterações sempre na mesma duração. Por exemplo, pode dividir o seu projeto de 2 meses em quatro iterações de duas semanas. Pode soltar-se ou não entre iterações. Tarefas que não são completadas numa iteração são empurradas para a próxima. Com o tempo, melhora-se a estimar o que pode ser feito numa iteração.

    O time-boxing é muitas vezes uma das técnicas mais difíceis de aplicar, uma vez que muitos projetos, não podem ser cortados arbitrariamente em períodos fixos. Além disso, empurrar tarefas para a próxima iteração significa que não saberá quantas iterações terá.

    Conselhos de Estado

    Os quadros de estatuto, embora não são exigidos pelo ágil, são frequentemente utilizados em projetos ágeis. Ao continuar com a filosofia de reduzir a sobrecarga da gestão do projeto, os conselhos de estado permitem que alguém apenas arraste e deixe cair a sua tarefa de uma coluna para a seguinte para atualizar o estado da sua tarefa. Estas placas também permitem a fácil visualização de onde as tarefas estão em termos de estatuto para toda a iteração.

    Outras técnicas

    Aqui estão algumas outras técnicas e ferramentas ágeis que pode considerar usar nos seus projetos.
    Reuniões diárias de stand-up: Estas reuniões diárias são onde cada membro da equipa diz o que trabalharam ontem, o que planeiam realizar hoje, e se têm algum bloqueador. São mantidos de pé para mantê-los curtos.
    Gráficos de queima e velocidade: Os gráficos de burn-down mostram a redução das tarefas abertas no projeto ao longo do tempo. Os gráficos de velocidade comparam iterações encaixotadoras entre si para ver se o que a equipa consegue fazer está a melhorar com o tempo.
    Autoatribuição: Esta é a prática de não atribuir as tarefas, mas deixar os membros da equipa agarrarem a próxima tarefa para si mesmos quando terminarem com a última.

    Como o OneDesk o ajuda a fazer Agile

    O OneDesk difere da maioria dos sistemas de gestão de projetos na medida em que permite executar um projeto usando a sua escolha de métodos ágeis, métodos tradicionais ou uma mistura de ambos. É assim que se faz.

    Criar projetos que se aussam a carteiras ou pastas que se aussam a projetos.

    Altere facilmente entre as vistas do cartão ou a lista hierárquica.


     

    Use pontos ágeis ou horas-homem para estimar tarefas

    Os gráficos de burn-down e os gráficos de velocidade são cozidos em (e muitos outros gráficos também).

    Veja um vídeo sobre onde encontrar as funcionalidades ágeis no OneDesk

    O OneDesk está especialmente sintonizado para os projetos de média dimensão que, por vezes, precisam de um pouco de planeamento e outras vezes muito menos. A OneDesk tem a flexibilidade para permitir que a sua equipa planeie os seus projetos ao nível que necessita para atender ao fluxo de trabalho da sua organização, sem sobrecarregar demasiado a sua equipa com demasiado excesso de cabeça. Com o OneDesk obtém-se todos os benefícios da gestão de projetos Agile, ao mesmo tempo que ainda tem acesso a uma ferramenta avançada que às vezes pode precisar. Ainda melhor, pode alternar entre modos para combinar um planeamento cuidadoso com uma execução rápida e sem esforço.

    Avise-nos se tiver perguntas.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>