Como usar métodos ágeis para gestão de projetos

Semana passada participei de uma palestra sobre o uso de métodos ágeis aplicados a uma equipe de criação de conteúdo.

A palestra apresentou um exemplo prático de uso de metodologias ágeis, mais especificamente Scrum, para fazer gestão de projetos em um ambiente que não era desenvolvimento de software, que é a origem da metodologia.

Pensei em fazer apenas um relato da palestra, mas acabei adicionando informações para deixar mais explicativo.


Conteúdo

Começando do princípio: o que são os métodos ágeis?

Eles surgiram na área de desenvolvimento de software para tentar diminuir as principais dificuldades encontradas nos projetos:

  • mudança de escopo durante o desenvolvimento;
  • validação durante o desenvolvimento (e não só na entrega final);
  • problemas de comunicação;
  • desperdício de tempo em funcionalidades pouco usadas.

A ideia principal é responder às mudanças, fazendo um desenvolvimento iterativo e incremental, com ciclos curtos e entregas constantes.

O manifesto ágil

Em 2001 foi criado o manifesto ágil, definindo valores e princípios. Conforme a tradução oficial do manifesto, os valores são:

  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

“Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

E os princípios podem ser resumidos, em livre interpretação:

  1. Satisfação do cliente através de entrega contínua.
  2. Tirar vantagem das mudanças que acontecem durante o projeto.
  3. Entregas frequentes de software funcionando, em curtos espaços de tempo.
  4. Todos os envolvidos devem trabalhar diariamente em conjunto durante o projeto.
  5. Indivíduos motivados e confiança na equipe.
  6. Conversas presenciais para transmissão de informações.
  7. Software funcionando é a medida primária de progresso.
  8. Todos os envolvidos devem ser capazes de manter um ritmo constante indefinidamente.
  9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
  10. Simplicidade é essencial.
  11. Os melhores trabalhos emergem de equipes auto-organizáveis.
  12. Periodicamente a equipe reflete como ser mais eficaz e ajusta o comportamento.

Resumo do resumo dos princípios: adaptação, entregas e ciclos rápidos, auto-organização da equipe, confiança na equipe, comunicação frequente, foco no cliente.

Como utilizar métodos ágeis?

Existem diferentes formas de aplicar metodologias ágeis. Uma das principais e que também é aplicada fora do desenvolvimento de softwares é Scrum, que surgiu no início dos anos 90, antes mesmo do manifesto ágil.

Scrum é um framework que apesar de ter algumas coisas imutáveis, permite adaptar seu uso à cultura da empresa.

O projeto é dividido em ciclos, em fases que costumam durar uma semana, mas pode variar conforme o projeto. No Scrum o ciclo se chama “Sprint”.

De forma bem simplificada o scrum possui: papéis, artefatos e eventos.

Papéis do Scrum

  • Scrum Master: atua como líder da equipe, remove impedimentos durante o projeto e faz com que a instituição esteja preparada para adoção do Scrum.
  • Product Owner: é o especialista do negócio, quem mais conhece sobre o projeto e as necessidades do cliente, define e prioriza as tarefas, tem uma visão global do projeto.
  • Development Team: são os desenvolvedores, ou em nosso caso, a equipe que está fazendo as tarefas diariamente, desenvolvendo o projeto propriamente dito.

Para que o Scrum funcione, a equipe deve ser comprometida e auto-organizada, saber assumir responsabilidades e não ser individualista.

Principais artefatos

  • Product backlog: é a lista de micro tarefas a serem feitas no projeto.
    • Conforme exemplo da palestra, aqui não se colocaria “Escrever artigo” mas, sim: “Pesquisar assunto nas fontes”, “Escrever introdução”, “Escrever metodologia”, “Revisar o Português”, “Revisar as normas”, “Enviar para avaliação”…
  • Sprint backlog: como o projeto é dividido em ciclos, é necessário ter também uma lista de micro tarefas para cada ciclo.

Principais eventos

  • Sprint: a fase, o ciclo do projeto.
  • Planning: reunião de planejamento para definir prioridades, tarefas a serem feitas e responsáveis. Deve ser documentada e poder ser consultada por todos os envolvidos.
  • Sprint review: reunião ao final do ciclo, para validar o andamento com o cliente (ou chefe) e ir adequando-se às mudanças (= ÁGIL), verificar pontos positivos e negativos. Deve ser documentada, registrada em uma ata. Deve ser feita uma também ao final do projeto.
  • Daily: reunião diária de monitoramento.

Quadro Scrum

Para acompanhamento das atividades utiliza-se um quadro onde devem constar todas as tarefas daquele ciclo (Sprint). O quadro pode ser organizado por macro tarefas ou por pessoa da equipe. E pode ser dividido em dias da semana ou conforme o andamento da tarefa.

Pode ser um quadro físico ou uma parede adesivada que fique em um local onde todos os envolvidos no projeto possam ter fácil acesso. As tarefas são colocadas em post-its para facilitar as alterações feitas nas reuniões diárias. Após a conclusão eles podem ser descartados.

Ou pode ser um quadro virtual utilizando o Trello ou outra ferramenta para organizar tarefas e pessoas dentro da equipes.

Exemplo 1 – Quadro organizado por dia da semana

O quadro é dividido em dias da semana (colunas) e pessoas (linhas).

Cada pessoa é responsável por colocar suas tarefas: há quem coloque apenas as tarefas do dia e na Daily organize o próximo dia. Há quem já distribua as tarefas nos dias da semana e na Daily ajuste conforme o andamento.

Exemplo 2 – Quadro organizado por tarefa

O quadro é dividido por “a fazer”, “fazendo”, “pronto” (colunas), no estilo Kanban, e as tarefas vão mudando de coluna conforme o andamento. Pode ser também dividido por pessoas ou por macro tarefas.

A ideia do quadro é apresentar uma visão geral do andamento do projeto.

Reuniões diárias

Scrum é baseado em acompanhamento diário, então vamos falar um pouco mais sobre a Daily.

Ela é uma reunião realizada diariamente, como o próprio nome já indica, com toda a equipe do projeto.

Deve ser feita sempre no mesmo horário e ter duração de 10 a 15 minutos. Os participantes devem estar de pé na frente do quadro que apresenta o andamento daquele ciclo do projeto.

Não é uma reunião para tirar dúvidas ou discutir outros assuntos: cada participante deve responder objetivamente a três perguntas:

  1. O que eu fiz ontem?
  2. O que eu vou fazer hoje?
  3. Há algum impedimento nas minhas tarefas?

Essas perguntas dispensam as cobranças que costumam ser feitas no gerenciamento tradicional de projetos, pois cada membro da equipe vai indicar proativamente o andamento de seu trabalho.

O impedimento pode ser qualquer “coisa” que não permita que a pessoa faça a tarefa que estava prevista para aquele momento, por exemplo: outra tarefa demandou mais tempo, outra pessoa não entregou algo que era necessário, houve uma ausência no trabalho… Enfim, descrever brevemente o motivo de uma tarefa estar atrasada.

Conforme as pessoas vão falando, o quadro é atualizado para indicar o andamento das tarefas.

OK, mas… como usar de fato?

Agora que já apresentei um pouco sobre Scrum, vou voltar para a prática apresentada na palestra assistida.

Uma das motivações para o uso de métodos ágeis para a equipe de conteúdo foi terem produzido um material impresso, tipo um guia, e só terem apresentado aos chefes (no caso, aos sócios da empresa) quando o conteúdo já estava todo pronto e diagramado, faltando apenas enviar para a gráfica.

A resposta dos sócios foi de que o material não estava como eles imaginavam mas que, devido ao tempo e investimento já feitos, seria impresso daquela forma.

Os guias subsequentes foram feitos utilizando Scrum, o que evitou a frustração dos chefes e da equipe, além de diminuir o retrabalho: a cada semana eram apresentadas partes do conteúdo, de forma que os chefes sugeriam as alterações sem o material estar finalizado. Assim era menor o esforço para ajustar o que fosse necessário.

Boa parte do conteúdo deles é uma publicação semanal, então eles consideram cada semana como se fosse um projeto.

O “dono do projeto” (Product Owner) organiza as micro tarefas do projeto em uma planilha (Microsoft Excel, Google Drive, Open Office…), cada tarefa em uma linha, com coluna indicando qual o ciclo que ela vai ser feita (Sprint 1, Sprint 2…) e o responsável pela tarefa (às vezes, mais de uma pessoa).

O “dono da metodologia” (Scrum Master) organiza a Daily e estimula a equipe a seguir a metodologia.

O quadro usado por eles é uma parede adesivada dividida por colunas de segunda a sexta e linhas por pessoa, cada pessoa tem uma cor de post-it. Nas reuniões diárias o andamento é apresentado e os post-its ajustados conforme o necessário.

A palestrante contou que demorou cerca de um mês para toda a equipe (composta por doze pessoas) se adequar à nova forma de trabalho e que a ferramenta de comunicação que funcionou melhor foi o e-mail. Mesmo sendo uma equipe composta por pessoas entre 20 e 30 anos, não conseguiram adequar-se ao Trello ou outras ferramentas específicas.

Isso demonstra que as ferramentas são úteis, mas o que importa mesmo é que a equipe esteja engajada e que sejam escolhidas as melhores formas para o contexto e pessoas envolvidas.

Para finalizar, destaco um dos resultados obtidos com a adoção do Scrum: a palestrante relatou que com as reuniões diárias criou-se uma maior empatia pelo trabalho que o colega realiza.

Quebrar as tarefas em micro tarefas ajudou as pessoas a entenderem como é o trabalho dos colegas que fazem atividades diferentes e quantas coisas são necessárias até que uma tarefa que achavam simples seja realizada.

O método ágil também ajudou a verificar quem poderia fazer mais tarefas do que vinha fazendo…

Leia mais

Manifesto ágil (em Português)
Guia do Scrum – site oficial (em Inglês)
Guia do Scrum (PDF em Português)

Notas

  1. O conteúdo deste post é baseado na minha interpretação da palestra apresentada por Joanna Romero, com inclusão de materiais da especialização que fiz em Desenvolvimento de Aplicações Web e links adicionais.
  2. Agradeço ao Conselho Regional de Biblioteconomia da 10ª Região (CRB-10) e à Associação Rio-grandense de Bibliotecários (ARB), pela oportunidade!

Créditos – Imagem do post: Business vector created by vectorpouch – www.freepik.com

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *