Conheça 3 metodologias ágeis que vão transformar o seu jeito de conduzir projetos

Metodologias ágeis

Quando se fala em gerenciar projetos, não existe bala de prata. O que pode funcionar muito bem em determinados projetos pode não servir para outros. Uma dúvida muito comum nesse sentido é a aplicação de metodologias ágeis na gestão de projetos. Quer saber o que são e quais as principais? Continue lendo este post! Se preferir, navegue no índice para ir direto ao tópico de seu interesse. Boa leitura!

Índice


Vamos começar com um conceito básico:

O que são metodologias ágeis?

Metodologias ágeis são conjuntos de práticas que proporcionam uma forma de gerenciar projetos mais adaptável às mudanças. Elas são estruturadas em ciclos curtos sendo que, a cada novo ciclo, é entregue um conjunto de funcionalidades pré-determinado. Portanto, as metodologias ágeis têm como principal restrição o tempo e são caracterizadas por produzirem entregas rápidas e frequentes.

É importante ressaltar que as metodologias ágeis partem do pressuposto que a condução do projeto será feita por uma equipe pequena e autogerenciável. Essa equipe normalmente será sênior, multidisciplinar e concentrada em um único local. Todo o esforço da equipe será empregado na qualidade da solução apresentada, que deverá acrescentar alto valor para o cliente do projeto.

São consideradas metodologias ou frameworks ágeis:

  • Scrum;
  • Scaled Agile Framework (SAFe);
  • Feature Driven-Development (FDD);
  • Test Driven Development (TDD);
  • eXtreme Programming (XP);
  • Dynamic Systems Development Method (DSDM);
  • Microsoft Solutions Framework (MSF);
  • Adaptative Software Development (ASD);
  • Entre outras.

Utilizar metodologias ágeis NÃO significa:

  • Ausência de disciplina;
  • Ausência de documentação;
  • Falta de planejamento.


Vale dizer que o conceito de metodologias ágeis é relativamente novo. Ele surgiu a partir do Manifesto Ágil, lançado em 2001 por um grupo de 17 desenvolvedores de software. Confira a seguir o que diz o manifesto.

Manifesto Ágil: o início de uma nova era na gestão de projetos

O Manifesto Ágil é um documento lançado por um grupo de desenvolvedores, que não queriam mais ter que gerar documentações ou responder aos gerentes de projetos. Afinal, as metodologias clássicas de gestão de projetos muitas vezes não dão davam conta de atender determinadas particularidades dos projetos de software.

O método cascata, por exemplo, contém processos conflitantes com a dinâmica dos projetos de software, que muitas vezes ocorrem sob grande falta de informações e mudanças frequentes nos requisitos e no escopo.

Essas incertezas dificultam o uso do método cascata, que define que as fases do processo são executadas de forma sequencial. Ou seja, não é possível passar para a próxima etapa sem ter concluído a etapa anterior. Na verdade, nos dias de hoje, essa forma de condução é incompatível com a agilidade e a flexibilidade das organizações.

Confira, abaixo, os principais pontos do Manifesto Ágil.

Valores do Ágil

O Manifesto Ágil elencou quatro valores que, para seus autores, são essenciais na gestão de projetos adaptativos. São eles:

  1. Valorizar mais indivíduos e interações do que processos e ferramentas (isso não significa fazer tudo no papel de pão, sem uma organização mínima);
  2. Valorizar mais software em funcionamento do que documentação abrangente (isso não significa não fazer nenhuma documentação);
  3. Valorizar mais colaboração com o cliente do que negociação de contratos (isso não significa a ausência de acordos mínimos);
  4. Valorizar mais respostas às mudanças do que seguir um plano (isso não significa a ausência de um plano que considere pelo menos o que é conhecido, dentro de um período curto);


Dessa forma, estabeleceu-se que, na gestão ágil de projetos, todos itens à esquerda são mais importantes do que os itens à direita. Essa visão dos 4 valores do ágil é fundamental para entendermos as diferenças entre a gestão clássica e a gestão adaptativa.

Diferenças entre metodologias clássicas e metodologias ágeis de gestão de projetos

Existem basicamente dois pontos nos quais você deve prestar atenção para entender as diferenças entre as metodologias clássicas e as metodologias ágeis de gestão de projetos. São eles: a restrição primária e o conjunto de ferramentas utilizadas.

Restrição primária

Uma restrição primária é o maior fator limitante de um projeto.

As metodologias clássicas são mais indicadas quando conhecemos bem o escopo do produto e o escopo do projeto, ou seja, sabemos o que fazer e como fazer. Esse nível de certeza em relação ao projeto traz previsibilidade, tornando possível antecipar as atividades, os custos e os recursos do projeto de forma bem específica. Portanto, a restrição primária das metodologias clássicas é o escopo.

Leia também  Visão de produto: alinhando expectativas com o Product Box

As metodologias ágeis, por outro lado, são mais indicadas quando não há muitas informações sobre o projeto ou quando se está lidando com um ambiente que muda com frequência. Ou seja, não sabemos direito o que fazer ou como fazer. Tudo o que sabemos é o prazo em que o projeto deve estar concluído.

Esse nível de incerteza em relação ao projeto exige uma forma de conduzir a iniciativa que leve em consideração essas mutações e encare os problemas como naturais e inevitáveis. Portanto, a restrição primária das metodologias ágeis é o tempo.

Conjunto de ferramentas

As ferramentas utilizadas na gestão de projetos clássica são diferentes das ferramentas utilizadas na gestão de projetos ágil.

Escopo

Na hora de detalhar o escopo, a gestão clássica normalmente utiliza a estrutura analítica de projeto (EAP) para decompor o esforço em pacotes de trabalho, mais fáceis de gerenciar. No ágil isso não existe: tudo o que temos é um backlog com a lista priorizada do que deve ser feito. A cada novo ciclo, o backlog passa por uma repriorização.

Outro ponto é que, enquanto a EAP é fixa e mais difícil de mudar, o backlog do projeto comporta melhor as mudanças, pois em todo ciclo há uma revisão dos itens da lista. Mas vale ressaltar que não é possível mudar os itens que estão no ciclo que está sendo executado.

Desvendando a Estrutura de um Projeto (EAP)

Tempo

A gestão do tempo nas metodologias clássicas é feita utilizando um instrumento chamado cronograma, que reúne atividades (e sua sequência de execução), prazos e recursos de forma estruturada em um único lugar. Esse cronograma é montado com base no escopo do projeto.

Já nas metodologias ágeis, existe um prazo fixo e o tempo é controlado a cada ciclo do projeto. Os ciclos de um projeto podem ter durações diferentes, dependendo da quantidade de demandas no backlog. Porém, todos os ciclos ou sprints do projeto ágil devem ter a mesma duração.

Esforço

Lembra que a gente te contou que as metodologias clássicas são mais indicadas para projetos cujo escopo é conhecido? É por isso que nas metodologias clássicas geralmente optamos por mensurar o esforço por inteiro, pois normalmente já teremos as informações necessárias para fazer esse tipo de estimativa.

Quando aplicamos metodologias ágeis, por outro lado, normalmente é porque estamos lidando com projetos que mudam com frequência. Portanto, é praticamente impossível fazer uma estimativa de esforço confiável. Comumente, trabalhamos com uma estimativa de tamanho e não com uma estimativa de esforço.

Conforme o time vai trabalhando em conjunto e melhorando a sua produtividade, mais assertiva passa ser a visibilidade do esforço. Em projetos ágeis, o tamanho é estimado a cada ciclo, tornando a estimativa mais confiável.

Gestão

Outra diferença entre metodologias clássicas e metodologias tradicionais é a forma de conduzir a gestão do projeto. Nas metodologias clássicas, a gestão fica centralizada no gerente de projetos. Já nas metodologias ágeis, a equipe é autogerenciável, tendo apenas o apoio de um mediador, que tem como principal foco retirar qualquer dificuldade que possa impedir a equipe de atingir o objetivo do ciclo.

Performance

E, por fim, as metodologias clássicas se diferenciam das metodologias ágeis quanto à mensuração da performance. Enquanto nas metodologias clássicas o desempenho é medido através das linhas de base do projeto (comparação entre real vs. planejado), nas metodologias ágeis a performance é medida principalmente pela verificação das ações concluídas a cada ciclo.

A briga da gestão de projetos: ágil x clássica

E aí, conseguiu entender a diferença e as especificidades de cada metodologia? Confira agora por que você deveria investir mais em gestão ágil!

Benefícios das metodologias ágeis

1. Assertividade

Nas metodologias ágeis, o foco na entrega de valor agregado para o cliente do projeto fica muito mais evidente do que na maioria dos projetos clássicos. É comum que o cliente seja envolvido diversas vezes na construção do projeto. A divisão do projeto em ciclos curtos, normalmente de até um mês, permite a validação mais rápida das entregas.

Leia também  Matriz de Rastreabilidade de Requisitos: gerenciando e controlando mudanças no escopo do projeto

Uma vez que você já tenha alinhado partes do projeto às expectativas do cliente, o resultado final será muito mais assertivo. Esse feedback constante também ajuda a aprender com os erros e consolidar as chamadas lições aprendidas.

2. Flexibilidade

Ao contrário das metodologias preditivas, em que o objetivo é seguir o planejamento previamente elaborado, nas metodologias ágeis existe mais flexibilidade às mudanças. Isso acontece porque há uma percepção de que as mudanças são parte constante do gerenciamento do projeto e precisam ser atendidas para gerar valor.

3. Colaboração

As metodologias ágeis envolvem equipes multidisciplinares, que trabalham em conjunto na busca das soluções. Por serem equipes menores, isso facilita a criação de um ambiente colaborativo e motivador. Afinal, a proximidade da equipe será maior, facilitando o relacionamento no dia a dia e criando laços entre as pessoas. Além disso, uma das práticas do ágil é o envolvimento do cliente durante a execução do projeto. Dessa forma, o cliente passa a ser um parceiro do time.

4. Comunicação

Outro ponto bastante considerado nas metodologias ágeis é estabelecer uma boa comunicação entre as partes interessadas no projeto. O recomendado é que as conversas sejam feitas cara a cara, pois a presença física da outra pessoa permite uma melhor interpretação do que está sendo colocado. Isso evita ambiguidades que podem comprometer o resultado do projeto.

Além disso, no ágil tudo é muito visual: trabalhamos com painéis, kanban e dashboard, que são atualizados diariamente, permitindo assim que qualquer pessoa saiba a situação do projeto, seus riscos e desvios.

5. Simplicidade

Se você comparar a documentação gerada por um projeto que utiliza metodologia preditiva e a documentação gerada por um projeto que utiliza metodologia ágil, verá que a diferença é gigantesca. Enquanto uma metodologia preditiva exige um esforço de planejamento muito grande, pois o foco é antecipar o máximo possível de trabalho, em uma metodologia ágil é suficiente ter um backlog com as entregas pendentes do projeto.

Não é que não fazemos planejamento na gestão ágil de projetos, mas fazemos isso de uma forma mais simples, que permita reavaliar prioridades e fazer mudanças.

Qual metodologia de gestão de projetos é mais utilizada na sua organização?

View Results

Carregando ... Carregando ...


Quer obter todos esses benefícios utilizando metodologias ágeis na gestão do seu projeto? Confira algumas metodologias que você pode adotar.

3 metodologias ágeis para adotar na gestão dos seus projetos

1. Scrum

O Scrum é um framework que contém processos e técnicas de gestão ágil para o desenvolvimento de projetos de software. No Scrum, as pessoas envolvidas no projeto podem assumir três papéis: product owner, scrum master e development team, que juntos formam o scrum team.

  • O product owner é o responsável por gerenciar o backlog do produto, isto é, o conjunto de funcionalidades e características que o produto deve ter. Portanto, o product owner atua como representante do cliente.
  • O scrum master é o responsável por disseminar o scrum pela organização, garantindo que ele esteja sendo aplicado de forma correta. Portanto, atua como um facilitador.
  • Já o development team é a equipe de desenvolvedores responsável por entregar as funcionalidades do produto e o produto final.

O scrum tem como base 4 reuniões.

A primeira reunião (ou cerimônia) é o sprint planning (reunião de planejamento da sprint), que ocorre no primeiro dia da sprint e é o momento em que criamos o backlog da sprint. O backlog da sprint nada mais é do que o conjunto de funcionalidades e características selecionadas do backlog do produto, que deve ser entregue ao final da sprint.

Essa reunião é dividida em duas partes. Na primeira parte é feito o entendimento dos itens do backlog, onde o product owner vai explicar e esclarecer as dúvidas sobre os itens ou histórias que estão backlog. Na segunda parte, o development team vai estimar o tamanho do item do backlog e decompor em ações que precisam ser feitas para entregar um valor agregado ao cliente.

Todos os dias é realizado o daily scrum, uma reunião de alinhamento em que o time conta o que foi feito no dia anterior, planeja o que será feito no dia e elenca elementos e situações que podem impedir a realização do que foi planejado para o dia. Nesse ponto, o time pode levantar dificuldades e riscos que precisam ser removidos pelo scrum master, que deve atuar na proteção da produtividade da equipe, em busca do atingimento dos objetivos estabelecidos no planejamento do sprint.

Leia também  Gerenciamento de Projetos: Análise da Maturidade utilizando o OPM3

A cada conclusão de sprint é feita também a sprint review que, como o próprio nome já diz, trata-se do momento em que o scrum team verifica se o que foi feito está de acordo com os requisitos do produto e, se necessário, atualiza o backlog. Outra reunião feita após a conclusão de uma sprint é a sprint retrospective, em que o scrum team verifica possíveis pontos do processo que podem ser melhorados.

2. Feature Driven-Development (FDD)

Enquanto o Scrum foca na gestão do projeto, o Feature Driven-Development (FDD) foca no desenvolvimento do produto por funcionalidades. O FDD pode ser dividido em duas etapas.

A primeira etapa, chamada de concepção e planejamento, é o momento de criar um modelo, especificando as principais informações sobre o projeto, além de montar a lista de funcionalidades. Essa fase é executada apenas uma vez e dura de 1 a 2 semanas.

A segunda etapa é a construção, em que as funcionalidades são desenvolvidas de forma iterativa (em ciclos) e incremental (cada ciclo gera um novo incremento, isto é, uma nova funcionalidade). Essa fase pode ter no máximo 2 semanas.

É importante lembrar que no FDD a equipe que cuida do desenvolvimento das funcionalidades deve ter no mínimo 3 e no máximo 6 programadores. Outro ponto é que, ao final de cada iteração, são feitas inspeções para eliminar erros e consolidar as lições aprendidas.

3. eXtreme Programming (XP)

O eXtreme Programming (XP) é um método de gestão ágil baseado em cinco valores: comunicação, simplicidade, feedback, coragem e respeito. Quando se fala em XP podemos elencar algumas práticas, que devem ser levadas “ao extremo” durante a condução do projeto:

  • Fases pequenas (small releases): dividir o projeto em ciclos curtos.
  • Jogo de planejamento (planning game): priorizar quais funcionalidades serão desenvolvidas antes de cada ciclo.
  • Metáfora (metaphor): entender a realidade do cliente e traduzir as necessidades dele nos requisitos do projeto.
  • Design simples (simple design): entregar apenas o que o cliente pediu, em vez de tentar reinventar a roda.
  • Testes de aceitação (customer tests): cada nova funcionalidade disponibilizada deve ser validada pelo cliente.
  • Semana de 40 horas (sustainable pace): programar é uma atividade que exige que a mente esteja descansada, por isso, o XP defende que não seja feito trabalho extra.
  • Propriedade coletiva (colective ownership): ninguém deve ter que pedir permissão para poder modificar o código-fonte, pois o código-fonte é uma criação colaborativa.
  • Programação pareada (pair programming): a programação do código deve ser feita em duplas, preferencialmente composta por um profissional iniciante e outro mais experiente, no mesmo computador.
  • Padronização do código (coding standards): a equipe de desenvolvimento precisa definir padrões para a construção do código, pois isso fará com que o código fique uniformizado e mais compreensível.
  • Desenvolvimento orientado a testes (test driven development): toda funcionalidade deve passar por um rigoroso processo de testes antes de ser validada, a fim de que não haja retrabalho para a equipe.
  • Refatoração (refactoring): o código deve passar por revisões periódicas, para ser continuamente aperfeiçoado.
  • Integração contínua (continuous integration): depois que uma funcionalidade for testada ela deve ser imediatamente sincronizada entre a equipe, evitando conflitos.

Conclusão

Como dissemos lá no começo deste post, não existe bala de prata quando se fala em gestão de projetos. Você pode e deve adaptar as coisas conforme a realidade da sua empresa. Ainda ficou com dúvidas sobre o assunto? Assista ao nosso webinar gratuito sobre metodologias ágeis e descubra se a sua organização está preparada para adotá-las!

Métodos Ágeis: sua empresa está preparada?

Email Marketing by E-goi

Deixe uma resposta

Consultoria Conduzimos gestores e suas equipes à conquista de resultados! Outsourcing Alocação de profissionais especializados e de alta maturidade Capacitação Treinamentos In Company