Scrum

Gráficos Burndown e Burnup: qual a diferença?

Quando estamos desenvolvendo um projeto, uma parte fundamental é o controle e monitoramento, por isso o quanto mais ferramentas e opções tivermos para fazer essa verificação do progresso do projeto é bem útil. Se você já fez uso ou conhece as metodologias ágeis, como o Scrum por exemplo, já deve ouvido falar em pelo menos um desses gráficos: burndown e burnup. Caso você nunca tenha ouvido falar sobre Scrum, sugiro a leitura de nosso artigo “Scrum como ferramenta de apoio ao gerenciamento de projetos” antes de prosseguir com este.

Scrum - Planejamento e Desenvolvimento Ágeis
Curso de Scrum - Planejamento e Desenvolvimento Ágeis
CONHEÇA O CURSO

Os gráficos de burndown e burnup são ferramentas do Scrum que basicamente representam o progresso do projeto. Com esses gráficos, você consegue medir a velocidade média de entrega da equipe, além de identificar fatores que possam influenciar na produtividade, como tarefas mal planejadas, ausência de membros da equipe, etc. Existem diversas maneiras de medir a performance da equipe em um projeto, esses gráficos são um deles, fazendo a comunicação ser direta e clara, informando sobre o trabalho em curso.

Gráfico de Burndown

O gráfico de burndown mede o progresso da Sprint, comparando o que foi planejado ao que foi entregue. Assim, é possível verificar se a equipe está adiantada, no prazo ou atrasada no cronograma, e assim, ajudá-los a tomar as medidas para adaptação caso necessário e a encontrar maneiras de melhorar o trabalho de acordo com os inconvenientes que enfrentam.

Nesse gráfico é mostrado as datas no eixo horizontal e no eixo vertical é mostrado o esforço em horas. Esse gráfico deve ser atualizados todos os dias, para monitorar o progresso diário do time.

Gráfico de Burnup

O gráfico de Burnup apesar de ser apresentado de uma maneira próxima ao Burndown, tem o propósito de exibir o total que foi planejado e o quanto a equipe já progrediu para alcançar esse objetivo. É utilizado para medir a entrega do projeto como um todo, onde podemos ver claramente em que ponto o time está, permitindo prever se a entrega será feita na data estimada.

Esse gráfico representa o progresso em direção à finalização do projeto, tendo como eixo vertical a story points e no eixo horizontal as datas. A ideia é que as linhas se aproximem, até as duas projeções se encontrarem, assim o projeto estará completo. Você pode atualizar esse gráfico ao final de cada sprint, para que o time possa ver o desempenho em relação a todo o projeto.

Quais as diferenças?

Os dois gráficos representam o progresso na entrega do projeto. O gráfico de burndown mostra o quanto falta para atingir a meta, enquanto o burnup mostra o que já foi feito até o momento do projeto. O gráfico de Burnup mostra as informações sobre o status do projeto como um todo, não apenas da sprint (caso do burndown).

Esses gráficos nos auxiliam muito pois conseguimos ver de forma clara e visual, principalmente em reuniões de equipe, para ver se tudo está caminhando como deveria. Caso tenha algo afetando, pode ser discutido ações e medidas para solucionar esses problemas, a fim de não comprometer a entrega do projeto. Nas imagens deste artigo, vimos que até o Trello nos ajuda na elaboração destes gráficos.

Metodologias ágil x tradicional: Quais as diferenças?

Para qualquer coisa que queremos desenvolver hoje em dia precisamos fazer um projeto. Em meio ao processo do projeto, devemos ficar atentos a algumas especificações, como os prazos, custos, qualidade e satisfação do cliente, pois o não cumprimento destes pode nos trazer alguns problemas mais à frente. Por isso, cada vez mais damos a devida importância ao gerenciamento de projetos e em como a utilização de metodologias podem nos ajudar a gerir melhor tudo isso.
Atualmente temos dois tipos de metodologias que são bem conhecidas, principalmente se tratando de desenvolvimento de software: as metodologias tradicional e ágil.

Metodologia Tradicional

A metodologia tradicional tem etapas bem definidas sendo o planejamento do projeto, uma estimativa em termos de prazo e orçamento, a execução e entrega no final. Por exemplo, em um desenvolvimento de software financeiro, teríamos o seguinte fluxo:

  • Planejamento do software (como ele ficará no final)
  • Planejamento das atividades que serão necessárias (programação, design, etc)
  • Definição de prazos e custos
  • Execução
  • Testes
  • Implantação

A metodologia tradicional segue um modelo sequencial, ou seja, uma etapa deve ser executada após a outra, sendo assim, uma tarefa não pode ser iniciada enquanto a anterior não for concluída. Também se espera que seja executado exatamente o que foi planejado, focando no resultado final. Para ser um sucesso, não basta apenas seguir essa ordem, é importante entregar no prazo, dentro do orçamento e da qualidade esperada. Na metodologia tradicional o produto só irá “fazer sentido” e ter valor quando o projeto estiver 100% concluído. Dentro dessa metodologia a mais conhecida é o modelo cascata.

O principal receio dentro da metodologia tradicional é que ela não tem muita flexibilidade em relação a mudanças. Qualquer mudança no meio do caminho é vista com grande preocupação pelo gerente de projetos.

Para nos ajudar nesse quesito, entra uma outra metodologia: a ágil.

Metodologia Ágil

Apesar do nome, a palavra ágil aqui não significa agilidade e sim o poder de “quebrar” o projeto em partes menores. Ao contrário da metodologia tradicional que você faz apenas uma entrega já com o projeto final, aqui você faz entregas constantemente até entregar todo o projeto.

A preocupação com custo, qualidade e prazos são as mesmas da metodologia tradicional, porém você consegue controlar e gerenciar as mudanças que provavelmente irão aparecer no decorrer do projeto. Na metodologia ágil o foco principal é a entrega de valor ao cliente, por isso é priorizado a entrega à documentação, por exemplo. Mas isso não quer dizer que não é documentado, não planejado, assim como na tradicional. Na metodologia ágil também existem esses aspectos, mas de maneiras diferentes. Por exemplo, o planejamento da metodologia ágil é de forma iterativa e incremental enquanto a da tradicional planeja com muita antecedência como será cada etapa do projeto.
Dentro desta metodologia o mais utilizado e que provavelmente você já ouviu falar é o Scrum.

Scrum - Planejamento e Desenvolvimento Ágeis
Curso de Scrum - Planejamento e Desenvolvimento Ágeis
CONHEÇA O CURSO

Como saber qual utilizar?

Isso vai depender muito do tipo de projeto e cultura da empresa. A própria empresa pode preferir a metodologia tradicional, ainda mais se os envolvidos do projeto não estão acostumados a trabalhar com uma metodologia ágil, ainda que ela se aplique a aquele projeto.

O ideal é estudar o projeto, conhecer os requisitos, tecnologias a serem utilizadas… tudo o que julgar necessário. E a partir disso tudo analisar se é melhor partir pela metodologia ágil ou a tradicional. Em um projeto onde as necessidades do cliente podem mudar a qualquer momento (o que é muito comum), você precisará ter a liberdade de poder fazer mudanças necessárias tanto pelo lado do cliente quanto de tecnologia, se precisar. Projetos que provavelmente terão mudanças constantes, precisa ter um planejamento mais flexível, sendo assim a metodologia mais viável seria a ágil.

A metodologia tradicional é uma boa opção em casos mais específicos, como por exemplo em algo que precisa ser planejado e decidido desde o início. Se o projeto tem poucas chances de ter mudanças e com baixo risco, o ideal é ter um plano de projeto mais detalhado antes de iniciar.

Concluindo…

Vale lembrar que a escolha da metodologia é importante não somente para se ter sucesso no processo, mas principalmente, na entrega do produto. As duas metodologias têm vantagens e podem ser utilizadas até mesmo de forma conjunta, convivendo perfeitamente bem, até mesmo porque o foco das duas é a otimização de projetos. A escolha entre a metodologia tradicional e ágil não precisa ser um conflito. Deve-se respeitar às premissas das duas metodologias e saber o que cada uma pode agregar aos objetivos de cada projeto.

Scrum como ferramenta de apoio ao gerenciamento de projetos

No post anterior, vimos como os projetos de TI podem ser beneficiados utilizando as técnicas do PMI. Foi citado também sobre a utilização de metodologias ágeis como forma de complemento para o sucesso nos projetos de TI. Veremos neste artigo mais profundamente sobre o Scrum, principal metodologia ágil utilizada no mercado.

UML - Unified Modeling Language
Curso de UML - Unified Modeling Language
CONHEÇA O CURSO

O que é e como funciona o Scrum?

O Scrum é uma metodologia ágil que permite manter o foco na entrega de valor para o negócio no menor tempo possível. Seu conceito principal é decompor um projeto em pequenas tarefas mais simples, chamadas de Sprints. Uma Sprint pode ser semanal ou mensal, tendo datas de início e fim bem definidas, possuindo as atividades que devem ser cumpridas dentro deste prazo.

Essa metodologia é composta basicamente por três papéis:

Product Owner ou Dono do Produto

Representa o negócio em si, além de ser o ponto central de liderança do projeto. É função dele comunicar a todos quais objetivos quer atingir. Para isso, ele precisa colaborar ativamente com o Scrum Master e toda a equipe de desenvolvimento, como por exemplo, participar das reuniões e responder rapidamente às questões realizadas pelo time. Ele é responsável por aceitar ou rejeitar o resultado dos trabalhos.

Scrum Master

O Scrum Master orienta a equipe para que as metas sejam cumpridas devidamente. É responsável para que o Scrum seja entendido e aplicado por todos da equipe. Ele também ajuda a desenvolver sua própria abordagem do Scrum, porém sempre respeitando as particularidades de cada organização.

Time de desenvolvimento

O time de desenvolvimento deve ser constituído por poucas pessoas, é recomendado no máximo 10. Aí você deve estar se perguntando o que fazer caso você tenha uma equipe de 15 ou 20 pessoas. A resposta é simples! Você sempre deve dividir sua equipe nesses casos. Uma equipe de 20 pessoas pode ser dividida em 3 equipes menores, podendo ser duas equipes com 7 pessoas e uma equipe com 6 pessoas.

Estas devem se programar para que a meta do Product Owner seja atingida. O time deve conter as habilidades e conhecimentos necessários para produzir com qualidade.

Principais artefatos da metodologia

Agora vamos fazer um passo a passo de como deve funcionar a metodologia Scrum. Primeiramente deve ser determinado quais são as funcionalidades a serem implementadas, estas ficarão em uma lista chamada “Product Backlog”, podendo ser requisitos funcionais, não-funcionais e até mesmo configurações do ambiente. A “Sprint Planning Meeting” é uma reunião na qual é decidido os requisitos, estes devem agregar valor de negócio do produto.

A Sprint deve começar com uma “Daily Scrum Meeting”, onde é priorizada as funcionalidades contidas na “Product Backlog”, selecionando as atividades que cada um da equipe irá realizar na Sprint que irá ser iniciada, priorizando as atividades mais importantes primeiro, porém devem ser tarefas que possam ser completadas durante a Sprint.

É importante ressaltar que não pode ter mudanças nas tarefas durante a realização da Sprint

Cada membro do time escolhe uma tarefa da “Product Backlog” e deve atualizar o status dessa tarefa a cada dia.

As tarefas escolhidas para a Sprint passarão do “Product Backlog” para um outro quadro, podendo ser chamado por exemplo de “Sprint 1”, “Primeira Sprint”, etc.

A comunicação é essencial no Scrum, por isso temos o “Daily Scrum”. Ele é um encontro diário rápido, normalmente de 15 minutos e geralmente realizado logo no início do dia. Basicamente todos do time respondem às seguintes perguntas:

  • O que você fez ontem?
  • O que vai fazer hoje?
  • Quais foram os problemas encontrados?

A reunião é de grande importância pois a partir daí o Scrum Master pode medir os avanços e caso tenha algum problema, pode ser resolvido de forma imediata.

Depois que a Sprint acaba ocorre a “Sprint Review”, onde a equipe apresenta seus resultados. Nesta etapa os resultados devem ser comparados com o início da Sprint. O Product Owner identifica o que foi finalizado e o que não foi, e discute com a equipe o atual “Product Backlog” onde todos colaboram sobre o que deve ser feito a seguir, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais uma Sprint. A “Sprint Review” fornece dados importantes para a reunião da próxima Sprint.

A “Sprint Retrospective Meeting”, a retrospectiva da Sprint, tem o objetivo de verificar o que funciona e o que não funciona, caso necessite será realizada adaptações no processo de trabalho. Essa reunião deve ser realizada depois de cada Sprint e todos devem participar, levantando as seguintes questões:

  • O que gostaria de começar a fazer?
  • O que gostaria de parar de fazer?
  • O que gostaria de continuar fazendo?

Após esses passos, tudo volta novamente, sendo iniciada uma nova Sprint.

Scrum Master X Gerente de Projetos

Então se eu tenho Scrum Master para gerenciar o time, eu não preciso de um gerente de projetos, certo?

Errado. O Scrum Master tem um papel de facilitador, de um líder, mas não substitui o gerente de projetos. A metodologia Scrum defende que o time deve ser auto-gerenciável, ou seja, não deve haver a necessidade de um gerente de projetos na equipe. Porém, a ideia é que isso mude e que a contribuição do gerente de projetos venha complementar o time Scrum.

O gerente de projetos e o Scrum Master tem papéis diferentes. O gerente de projetos é capacitado para liderar e trabalhar para garantir que todos os processos serão implementados corretamente. Além disso, também auxilia na prestação de contas, contribuindo para a resolução de conflitos em relação ao que é esperado pelos usuários e protege a equipe de influências externas.

Já o Scrum Master tem o seu papel de orientador, sendo que as tarefas de planejamento e execução do projeto ficam a cargo do Product Owner e da equipe do projeto. Apesar disso, ele enfrenta diversos desafios como por exemplo, a gestão do tempo para garantir a execução das atividades da melhor forma.

Quando se trata de Agile, por mais que o termo “time auto gerenciado” esteja na moda, a figura do gerente de projetos ainda é fundamental, pois um gerente de projetos pode auxiliar o Scrum Master, não o sobrecarregando com outros tipos de tarefas.

O fato é que a figura do gerente de projetos continua existindo no papel de apoiador e não de controlador. A responsabilidade total do projeto e de integração com todas as outras frentes continua sendo do gerente de projetos.

Concluindo

Apesar de tudo isso e todas as vantagens que a metodologia tem a nos oferecer, sabemos que sua aplicação é um pouco complexa, ademais, você estará lidando com pessoas. Porém, se a metodologia for aplicada corretamente e houver comunicação e planejamento entre absolutamente todos da equipe (incluindo o gerente se projetos, se houver) há grandes chances de o produto final sair conforme o planejado e em um curto prazo de tempo.

O que achou dessa metodologia? Já participou de um projeto onde o Scrum foi utilizado? Conta pra gente. =)

JavaScript - Testes automatizados com Jasmine
Curso de JavaScript - Testes automatizados com Jasmine
CONHEÇA O CURSO