Apostila – Unidade 4

Práticas Gerenciais

Disciplina: Metodologias Ágeis de Desenvolvimento

Prof. Vinícius Alves Silva

1 Práticas Gerenciais

Nesta aula veremos conceitos relacionados com gerenciamento de projetos e métricas

ágeis.

1.1 Gerenciamento de Projetos

O “gerenciamento de projetos modernos” teve seu início quando as pessoas
envolvidas em trabalhos como controle dos custos, desenvolvimento do trabalho, compra
e procura de recursos e avaliação dos riscos para uma gama grande de projetos em
áreas como arquitetura, engenharia civil, automobilística, pavimentação, dentre outras,
tinha uma aplicabilidade para todas elas. Nesse movimento, a produção de software, que
é uma atividade mais recente e também possui características de “projeto” entrou nesse
“bolo”.
Dentre as diversas instituições que buscaram organizar e formalizar a área,
destaca-se o PMI, Instituto de Gerenciamento de Projetos (Project Management Institute -
PMI), uma das maiores associações para profissionais de gerenciamento de projetos do
mundo. O PMI é o responsável por publicar o PMBOK, um guia que oferece uma visão
geral sobre o gerenciamento de projetos. Em 2017 foi publicada a sexta edição do guia
(geralmente uma nova edição é lançada a cada quatro anos).
Segundo PMBOK, um projeto é “um empreendimento temporário, planejado,
executado e controlado, com o objetivo de criar um produto ou serviço único”. Já o
gerenciamento de projetos é “a aplicação de conhecimentos, habilidades, ferramentas e
técnicas nas atividades do projeto a fim de atender aos requisitos do projeto”.
O guia PMBOK reuni um grupo de cinco processos (Iniciação, Planejamento,
Encerramento, Execução e Monitoramento e Controle) e nove áreas de conhecimento
(Integração do Projeto, Escopo, Tempo, Custos, Qualidade, Recursos Humanos,
Comunicação, Riscos e Fornecimentos de Bens e Serviços).
Não é objetivo do material da aula abordar o PMBOK. Vamos destacar aqui um
pouco mais sobre o processo de Planejamento para fins de comparação entre
gerenciamento de projetos mais tradicional x ágil.
No processo Planejamento do PMBOK desenvolve-se um plano de gerenciamento
de projetos. Inicialmente, é realizada a “Coleta de Requisitos” buscando todas as
informações necessárias do cliente sobre a sua necessidade no produto.
Essa coleta é realizada por meio de ferramentas como entrevistas, oficinas,
questionários e pesquisas, protótipos, dinâmicas de grupo, dentre outras, tendo como
resultado um documento de requisitos, um plano de gerenciamento de requisitos e uma
matriz de rastreabilidade dos requisitos.
Feita essa coleta, partimos para o Escopo do Projeto, que servirá de base para seu
desenvolvimento. Esse escopo precisa ser claramente definido seguindo um processo
formal, identificando o escopo explícito e o escopo implícito, o que gera a necessidade de
um controle desse escopo. Essa definição do escopo, por garantia, deve ser registrada e
assinada, proporcionando um acordo dos desejos e das expectativas do produto,
isentando-nos, no futuro, de uma possível discordância sobre o que foi registrado
(sabemos que na maioria das vezes há discordância).

1.1.1 Gerenciamento tradicional de projetos e metodologias ágeis

Segundo Prikladnicki et. al. (2016), mesmo o PMBOK sendo um guia com boas
práticas de gerenciamento de projetos flexível e independente de uma metodologia de
desenvolvimento específica, ele e demais formas de gerenciamento mais tradicional de
projetos seguem um roteiro prescrito de atividades, sendo acompanhado pelo controle do
término de cada uma delas.
Esse modelo baseia-se no princípio que o desenvolvimento de software é uma
atividade previsível e que, desenvolvendo no início do projeto todos os requisitos de
negócio, eles permanecerão estáveis e não haverá alteração de escopo nas etapas
seguintes.
Prikladnicki et. al. (2016) destaca também que um dos pontos fracos na cultura do
modelo tradicional de gestão de projetos é que, ao final das atividades, para compormos e
finalizarmos a fase de concepção dos requisitos (planejamento), o cliente, maior
interessado em saber como está sendo gasto o dinheiro que ele está investindo no
produto, não conseguirá mensurar o valor de negócio agregado ao produto nos artefatos
de saída dessa fase. Por quê? O que ele recebe na saída dessa fase é uma porção de
documentação, protótipos, casos de uso, cronogramas, etc; isso não tem valor algum
para o cliente, não permitindo nem mesmo mensurar o ROI (Retorno sobre Investimento)
no seu produto.
Na próximas seções veremos níveis e características de um planejamento ágil.

1.1.2 Níveis do Planejamento Ágil

É muito comum a interpretação de que não existe planejamento em Métodos Ágeis.
Na verdade, o planejamento está presente desde a concepção de um projeto até o
trabalho diário (ou pelo menos deveria estar). Uma das bases do planejamento é a
iteratividade e o no replanejamento periódico. Segundo Prikladnicki et.al. (2016), alguns
métodos da Engenharia de Software tradicional até usam a iteratividade, porém o grande
diferencial é que os Métodos Ágeis recomendam iterações curtas e feedback rápido.
A Figura 1 ilustra os cinco níveis de planejamento ágil e a forte presença da
iteratividade no planejamento. Os cinco níveis são: Visão, Roadmap do Produto, Plano de
Entregas, Plano da Sprint e Plano Diário.
 Figura 1. Cinco níveis do planejamento ágil (Fonte: PRIKLADNICKI, 2016).

1.1.2.1 Concepção e visão do produto

Durante a concepção do produto, deve-se estabelecer uma visão do projeto, que
descreverá aonde se quer chegar com as atividades a serem desempenhadas pela
equipe do projeto. Nessa fase, é fundamental certificar-se de que todos no projeto tenham
a mesma visão, de forma que estejam trabalhando em torno desta.

1.1.2.2 Planejamento de entrega (iteração)

Descendo um pouco mais no nível de abstração do planejamento ágil, chegamos
ao planejamento da iteração. Durante o planejamento da iteração (no Scrum, conhecido
como Sprint Planning ou Planejamento da Sprint), a equipe do projeto colabora em torno
dos objetivos os quais irá se comprometer em entregar na iteração. O planejamento da
iteração pode gerar qualquer artefato relevante para a comunicação dentro do projeto. O
artefato gerado no Scrum chama-se Sprint Backlog e é o que menos sofre alterações no
decorrer de uma iteração.

1.1.2.3 Planejamento do produto (roadmap)

Um roadmap consiste na entrada do produto no mercado. É semelhante a um
planejamento de entregas, mas em um nível de abstração mais alto. Sendo assim, uma
ou mais características desejadas para o produto são descritas para uma data específica.
É uma ferramenta muito útil para gestores de produto. Com ele é possível planejar e
comunicar a visão de futuro que você tem para o seu produto. Um roadmap de produto
ágil gira em torno das metas e resultados que você deseja, em vez de recursos ou
cronogramas.

Figura 2. Roadmap de produto.

1.1.2.4 Planejamento de release

O planejamento de entregas, ou release planning, é o momento no qual são
delineadas as entregas para o cliente do projeto. Nesse nível de planejamento, entramos
em mais detalhes sobre as características do produto a ser desenvolvido. Por exemplo,
com Scrum, o planejamento de releases é o artefato que determina as features de um
produto ao longo das sprints. Na prática, o PE (Planejamento de Entregas) é o conjunto
das features produzidas por um determinado número de sprints.
Em um cronograma de entregas do produto distribuído entre Sprints,
cada Sprint pode conter um conjunto histórias de usuário, enquanto em determina-
da Sprint a soma dos incrementos criados nas Sprints passadas constituirá o produto a
ser entregue.
Vejam o exemplo:
SPRINT A: Histórias 1, 2 e 3 – Incremento 1
Data prevista: XX/XX

SPRINT B: Histórias 4, 5 e 6 – Incremento 2

Data prevista: XX/XX

SPRINT C: Histórias 7,8 e 9 – Incremento 3

RELEASE 1: Incrementos 1, 2 & 3 – Previsto para: DATA XX/XX

1.1.2.5 Planejamento diário

O planejamento diário acontece em diversas cerimônias de frequência diária
encontradas em métodos como Scrum e XP, por exemplo. No caso de Scrum, temos o
Daily Scrum (ou Reunião Diária), durante o qual a equipe do projeto discute três
perguntas:
• O que foi feito ontem?
• O que pode ser feito hoje?
• Existem obstáculo ao trabalho?
1.2 Métricas

Figura 3. Métricas, por Willian Deming.

As métricas em software funcionam como um conjunto de indicadores utilizados

para medir algo a ser gerenciado. As métricas podem ser utilizadas também como
ferramenta para a melhoria continua.

Scott M. Graffius, autor do Livro Agile Scrum

Se você não coletar nenhuma métrica, estará voando às cegas. Se coletar e focar em
muitas, elas podem obstruir seu campo de visão.

Existem várias métricas que podem ser analisadas em um processo de

desenvolvimento. Assim como nos processos envolvendo metodologias ágeis, não existe
uma regra rígida formal a ser seguida.
O ideal é utilizar/coletar as informações do próprio processo de desenvolvimento e
da equipe e organizar de forma coerente para que a métrica gere valor e possibilite ações
proativas.
 Figura 4. Funil das boas métricas

Se procuramos no Google sobre métricas ágeis, encontraremos algumas dezenas

de exemplos, cada qual com suas características. Aqui neste documento veremos CFD e
Burndown.

1.2.1 CFD
O CFD (Cumulative Flow Diagram) é um tipo de visualização que trata
essencialmente do fluxo de itens de desenvolvimento. O CFD é um instrumento de muito
valor no processo de monitoramento em projetos ágeis, pois, usando-o, você poderá
rapidamente analisar: quanto de trabalho foi realizado, quanto de trabalho está em
progresso e quanto de trabalho ainda precisa ser feito.
A estrutura do gráfico é muito simples. O eixo horizontal representa um período de
tempo (semanas, sprints etc.) e o eixo vertical indica, de forma acumulada, o número de
itens no processo (total de tarefas, total de histórias etc.). Cada área pintada no gráfico
está relacionada a uma etapa do fluxo de trabalho (backlog, em progresso, finalizado etc.)
e as curvas são basicamente o número de itens acumulados em tais etapas.
A figura a seguir mostra um CFD exemplo preenchido manualmente (pode-se usar
planilhas ou softwares). O CFD deve ser preenchido diariamente e os itens devem ser
representados por cores diferentes (finalizados em verde, testes em roxo,
desenvolvimento em azul, análise em vermelho). No exemplo, o diagrama foi preenchido
ao longo de 4 Sprints de 10 dias cada.

Figura 5. CFD preenchido manualmente

Vale ressaltar que as fases contempladas no CFD podem variar, mas geralmente
incluem itens que estão no Product Backlog, em análise, em desenvolvimento, em testes
e finalizados.
Independente da forma como o time gerará o gráfico, o importante é dar visibilidade
da evolução do fluxo para todos que estiverem envolvidos com o processo de
desenvolvimento.
A Figura 6 mostra algumas informações que podem ser lidas no CFD, como WIP
(Work in Progress – Trabalho em progresso), Lead time, Cycle time.
 Figura 6. Como ler um CFD

Analisando verticalmente em um determinado ponto os itens entre Em andamento

e Aprovado é possível analisar o WIP do time em qualquer intervalo de tempo. O WIP
consiste na soma dos itens que estão em Em andamento+Pronto+Testes+Aprovado.
Traçando uma linha horizontal entre determinados estados é possível extrair o tem-
po médio aproximado que os itens levam para serem processados e entregues. O tempo
entre assumirmos o compromisso com a entrega e a entrega de fato é chamado de “Lead
Time“. O “Cycle Time“ é o tempo entre etapas específicas de um projeto.
O CFD permite identificar também gargalos e características do desenvolvimento
do projeto, como pouca entrega do time e poucos/muitos itens em desenvolvimento.
 Figura 7. Características do desenvolvimento identificadas no CFD

1.2.2 Burndown
O gráfico de Burndown demonstra a performance da equipe comparando o que foi
planejado ao que foi entregue. Por meio desse gráfico, é possível verificar se a equipe
está à frente ou atrás do cronograma. Isso é fundamental para tomar as medidas
necessárias para adaptação, se necessário.
O gráfico possui um eixo X que representa o tempo, que pode ser medido em dias,
semanas, sprints, entre outros. Enquanto o eixo Y demonstra a entrega planejada, que
pode ser em horas de trabalho ou em pontos de histórias.
Este gráfico terá uma linha ideal que representa uma meta de entregas que irá
declinando ao longo do tempo e uma linha que representará a entrega real da equipe.
Quanto mais próxima a linha de entrega estiver próxima da linha ideal, melhor foi o
planejamento/execução da equipe. Quanto mais distante ou com maior variações,
significa que houveram problemas durante a sprint que comprometeram a entrega. A
Figura a seguir mostra um exemplo de gráfico Burndown.
 Figura 8. Gráfico Burndown

A próxima Figura 9 mostra um gráfico Burndown escada. Quando a linha que

representa as entregas afasta-se muito da linha ideal, como no exemplo a seguir, há um
sério risco da equipe não conseguir entregar os itens da etapa.

Figura 9. Burndown escada

 O próximo gráfico mostra o chamado Burndown perigoso. Quando o início do ciclo
ocorrer como no exemplo, o indicado é parar a Sprint e revisar o que está acontecendo. A
parte final do gráfico demostra que o time entregou muitos itens na última hora. Isso
compromete o feedback do cliente (PO).

Figura 10. Burndown perigoso

O próximo gráfico mostra uma situação em que as entregas estão bem abaixo do
que foi acordado no planejamento da Sprint.

Figura 11. Burndown negativo

 No próximo exemplo, vemos que a equipe conseguiu entregar o que foi planejado.
Porém, em alguns dias houve uma grande variação que afastou a linha de entrega da
linha ideal. Isso pode ter sido causado, por exemplo, pela ausência de membros da
equipe, ou por qualquer outra situação isolada.

Figura 12. Burndown lento

2 Referências
AGILE MANIFESTO. Disponível em http://agilemanifesto.org/. Acessado em 10 de
fevereiro de 2022.

BRASILEIRO, Roberto. Workshop Métricas para times ágeis. Belo Horizonte, MG. 2018.

DESENVOLVIMENTO ÁGIL. Disponível em http://www.desenvolvimentoagil.com.br.

Acessado em 10 de fevereiro de 2022.

DUARTE, Luiz. Scrum e Métodos Ágeis: Um Guia Prático. Editora LuizTools. Edição do
Kindle. 2016.

MÉTODO ÁGIL. Disponível em http://www.metodoagil.com/. Acessado em 10 de fevereiro

de 2022.

PRESSMAN, Roger S. Engenharia de Software: uma abordagem tradicional; tradução. 7

ed. Porto Alegre: AMGH, 2011.

PRIKLADNICKI, Rafael; WILL, Renato; MILANI, Fabiano. Métodos Ágeis para

Desenvolvimento de Software. Editora Bookman, 2014.