ELABORAÇÃO E ESTRUTURAÇÃO DE PROJETOS

ABORDAGENS ÁGEIS PARA GESTÃO

Prof. MSc Marcus Gregório Serrano

marcusgregorio@fucape.br

linkedin.com/in/marcusgregorio

instagram.com/marcusgregorio
 CAIXA DE FERRAMENTAS

Os métodos ágeis não irão resolver todos

os problemas. Você não vai abandonar as
ferramentas que já utiliza. A ideia é
agregar e ampliar a sua caixa e que você
tenha sempre à mão um leque de opções
para lidar com as mais diversas situações
nos seus projetos. Ferramenta boa é a que
funciona.
 Empresas Tradicionais

▪ Trabalho em áreas isoladas e com pouca interação.

▪ Tendência em executar projetos em cascata.
▪ Muita presença de gerentes intermediários, que não tem
poder de decisão, o que trava o processo.
▪ As pessoas dividem sua atenção entre excessivos
projetos simultâneos.
▪ As pessoas estão participando de várias atividades,
processos e entregas.
▪ Falhar não é uma opção
 Empresas Modernas

▪ Buscam desenvolver em seus funcionários uma mentalidade de

inovação constante
▪ Permite que as pessoas sejam empreendedoras, com uma cultura
de “startup interna”
▪ Equipes multidisciplinares, com pessoas de várias áreas com o
objetivo de desenvolver um projeto e entregar a melhor
experiência para os consumidores
▪ Buscam metas ousadas, começam pequeno e escalam
rapidamente, por meio da execução de projetos dinâmicos
▪ Compreendem que o erro é parte do aprendizado e do crescimento
O QUE É AGILIDADE
Agilidade como um estado de
alta adaptabilidade alcançada
por meio de adaptações regulares
no trabalho real produzindo
resultados observáveis.
CULTURA ORGANIZACIONAL
Como os drones estão se
aperfeiçoando
Origens da Agilidade
Embora o Manifesto Ágil tenha suas origens
no desenvolvimento de software, hoje os
conceitos da agilidade são aplicados nos
mais diversos setores. É difícil encontrarmos
uma área que não se possa aplicá-los.

O guia do Scrum por exemplo não menciona

em nenhum momento a palavra Software e
sim Produtos Complexos em ambientes de
grande incerteza.
 Linha do
TEMPO
Desenvolvimento Ágil
Dentre os frameworks que
lidam com agilidade o
Scrum é o mais utilizado no
mundo. Há aplicações do
Scrum em diversas áreas. A
certificação PSM tem cerca
de 500.000 profissionais.
1986
Jeff Sutherland e Ken
Schwaber
Desenvolvem uma forma
ais rápida, eficaz e confiável
de criar softwares para o
setor de tcnologia.
2001
The New New Product
Development Game
Artigo publicado na Havard
Business Review por
Hirotaka Takeuchi e Ikujiro
Nonaka
1993
Manifesto Ágil
Jeff e Ken assinam com
outros 15 profissionais o
Manifesto Ágil.
Linha do Scrum Alliance

TEMPO Ken Schwaber fundou a

Scrum Alliance junto com
2002

Mike Cohn e Esther Derby.

Ken era o presidente.
Ken Schwaber hoje
comanda a scrum.org

Scrum Inc
2006
Jeff Sutherland criou a sua
empresa: a Scrum Inc.

Guia do Scrum
2010
Publicado o primeiro
Scrum Guide
“A lição aqui é que o maior fator de
alavancagem para melhorar a efetividade
de um projeto está em educar gerentes
para gerenciarem melhor.”

Lessons in Agile Management: On the Road to

Kanban - David J. Anderson (2012)
 MANIFESTO ÁGIL
agilemanifesto.org

▪ Kent Beck ▪ James Grenning ▪ Robert C. Martin

▪ Mike Beedle ▪ Jim Highsmith ▪ Steve Mellor
▪ Arie van Bennekum ▪ Andrew Hunt ▪ Ken Schwaber
▪ Alistair Cockburn ▪ Ron Jeffries ▪ Jeff Sutherland
▪ Ward Cunningham ▪ Jon Kern ▪ Dave Thomas
▪ Martin Fowler ▪ Brian Marick
MANIFESTO ÁGIL
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o
nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho,
passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
INDIVÍDUOS E INTERAÇÕES
mais que processos e ferramentas

Em última instância quem gera os produtos são as pessoas. Pessoas e equipes são mais
importantes que os diagramas dos processos. Estes indivíduos possuem habilidades únicas que
em colaboração aumentam exponencialmente a criatividade, a motivação e a produção.
 SOFTWARE EM FUNCIONAMENTO
mais que documentação abrangente

O produto entregue é a única forma que podemos afirmar que a equipe de fato produziu. Os
clientes se interessam por resultados, ou seja, é o produto que vai agregar valor ao negócio.
Devemos produzir somente a documentação necessária para a realização do trabalho.
 COLABORAÇÃO COM O CLIENTE
Mais que negociação de contratos

O cliente faz parte da equipe. Para Alistair Cockburn, no desenvolvimento Ágil não há “nós e “eles”,
há simplesmente “nós”. Ambos estão do mesmo lado. Essa parceria envolve companheirismo,
tomada de decisão conjunta e rapidez na comunicação.
 RESPONDER A MUDANÇAS
Mais que seguir um plano

Devemos balancear o plano com as mudanças. Construir um plano é útil, mas seguir o plano só é útil
até o momento em que ele ainda esteja próximo o suficiente da situação atual. As empresas que
buscam prosperar devem alterar tanto seus projetos e suas perspectivas em consideração à mudança.
 Princípios do Manifesto Ágil
1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e
contínua de software de valor.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis

se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

3. Entregar software funcionando com frequência, na escala de semanas até meses,

com preferência aos períodos mais curtos.

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto

e diariamente, durante todo o curso do projeto.

5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e

suporte necessário, e confiar que farão seu trabalho.

6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de

um time de desenvolvimento, é através de uma conversa cara a cara.
 Princípios do Manifesto Ágil
7. Software funcional é a medida primária de progresso.

8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores,

desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos
constantes.

9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
feito.

11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam
e otimizam seu comportamento de acordo.
DIAGNÓSTICO ORGANIZACIONAL
Vamos fazer uma análise sobre a percepção em relação à sua
organização / setor em busca de pontos de melhoria

1. Como é feita a priorização de projetos?

2. Como está o equilíbrio entre projetos e demandas urgentes /
rotinas?
3. Como é feita a coleta de feedback em relação aos projetos?
4. Existem métricas? Quais? Elas parecem adequadas?
5. O trabalho está alinhado ao planejamento estratégico?
6. Como está a comunicação?
7. Você enxerga que sua organização é ágil em seus projetos? E em
termos de estratégia? O que poderia mudar para melhor?
 DIAGNÓSTICO ORGANIZACIONAL
Há pontos de atenção, Há pontos de
Não estamos
Muito bom! Sob controle... mas estamos atenção, e estão
fazendo
melhorando piorando
Priorização
Projetos vs processos
Feedback
Métricas
Planejamento Estratégico
Comunicação
Você considera que sua
organização é ágil? O que
poderia melhorar?
CYNEFIN
 FRAMEWORK CYNEFIN

▪ Pelo que conversamos até agora, métodos ágeis são

aplicáveis a todas as organizações.

▪ Mas, será que toda (a) organização deve aplicar?

 FRAMEWORK CYNEFIN

▪ Modelo criado em 1999 por Dave Snowden, consultor de inovação, que

trabalhava na IBM

▪ O Cynefin Framework é um modelo conceitual para apoiar a tomada de

decisões. Ajuda a compreender os contextos nos quais uma organização atua e
como esses contextos impactam na tomada de decisão, na inovação, no
planejamento e na gestão de projetos

▪ Assim, ele é um instrumento de sensemaking que apoia a seleção do fluxo de

trabalho mais apropriado para cada cenário.
 Práticas ▪ Sondar, experimentar, avaliar
emergentes ▪ Mergulhar no novo (sentir) e definir
próximos passos
▪ Responder – tomar ações para levar
o assunto para o domínio complicado
Práticas
novas
▪ Agir, confiando na experiência e saindo
imediatamente da zona de perigo
▪ Sentir, fora da zona de perigo, e avaliar a
situação, determinando os próximos passos
▪ Responder para mover seu problema para
outros domínios
▪ Sentir (entender) o problema
▪ Analisar os problemas e possíveis Boas práticas
caminhos
▪ Responder com planejamento
Melhores
▪ Sentir (entender) a situação
práticas
▪ Categorizar em intervalos conhecidos
▪ Responder com solução bem conhecida e
universal
Vamos analisar a nossa organização/setor utilizando o
Framework Cynefin
SCRUM
 É um método de reinício de jogada no rugby, onde
SCRUM os jogadores dos dois times se juntam com a
É uma jogada do Rugby! cabeça abaixada e se empurram com o objetivo
de ganhar a posse de bola. O termo deriva da
palavra inglesa scrimmage que significa
escaramuça.
SCRUM É ITERATIVO E INCREMENTAL
O produto é desenvolvido em ciclos de iterações
sucessivas.

As famosas Sprints
Falaremos mais sobre elas em breve
SCRUM É ITERATIVO E INCREMENTAL

O produto é desenvolvido em ciclos de iterações sucessivas.

SCRUM É ITERATIVO E INCREMENTAL

Um processo iterativo é aquele que faz progresso através de

tentativas sucessivas de refinamento. A cada iteração seu
produto ou serviço é melhorado.

Um processo incremental é aquele em que o produto é

construído e entregue por pedaços. Cada pedaço ou incremento
representa uma parte completa do seu produto.
SCRUM É ITERATIVO E INCREMENTAL

Métodos ágeis são tanto iterativos, quanto incrementais. São

iterativos por que o trabalho realizado é sempre melhorado em
ciclos subsequentes. São também incrementais, porque o
trabalho planejado é entregue em partes que são adicionadas ao
todo do projeto.

Não faz sentido em ter um sem o outro.

 SCRUM

Ciclos curtos de
feedback.

ÁGIL
WATERFALL
MODELO CASCATA - WATERFALL
Análise de necessidades
(requisitos)

Design

Implementação

Testes

Implantação

Manutenção
SCRUM OVERVIEW
 AMBIENTE PREDITIVO

Autor: Gino Terentim

 AMBIENTE ADAPTATIVO

Autor: Gino Terentim

PILARES DO SCRUM
TRANSPARÊNCIA
▪ O que esperam de mim e o que eu espero dos outros
▪ A informação precisa ser a mesma, não importa quem perguntou ou quem
respondeu
▪ Todos devem entender claramente a informação

INSPEÇÃO
▪ Os processos, práticas e tarefas devem ser constantemente observados:
▪ O que posso fazer melhor?
▪ O que não fiz bem?
▪ O que posso deixar de fazer?

ADAPTAÇÃO
▪ Conhecendo os pontos críticos, o que preciso fazer para melhorar?
▪ Como garantir que o que deu errado não aconteça novamente?
▪ Como garantir que o que deu certo volte a ocorrer?
ESTRUTURA DO SCRUM
TIME - PAPÉIS NO SCRUM
O Product Owner – Dono do produto

É o responsável por maximizar o valor do produto e do trabalho do Time de

Desenvolvimento. Como isso é feito pode variar amplamente através das organizações,
Times Scrum e indivíduos.

É a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do

Backlog do Produto inclui:
▪ Expressar claramente os itens do Backlog do Produto;
▪ Priorização: ordenar os itens do Backlog do Produto para alcançar melhor as metas e
missões;
▪ Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
▪ Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e
mostrar o que o Time Scrum vai trabalhar a seguir; e,
▪ Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no
nível necessário.
TIME - PAPÉIS NO SCRUM
O Time de Desenvolvimento

Consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente
incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento
criam incrementos.

Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar
seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de
Desenvolvimento como um todo. Os Times de Desenvolvimento tem as seguintes características:
▪ Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento
como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente
utilizáveis;
▪ Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias.
▪ O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o
Desenvolvedor.
▪ Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas,
mas a responsabilidade pertence ao Time de Desenvolvimento como um todo; e,
▪ Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento,
tais como teste ou análise de negócios.
TIME - PAPÉIS NO SCRUM
Scrum Master

O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para
garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o
Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações
com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para
maximizar o valor criado pelo Time Scrum.

O Scrum Master trabalhando para o Product Owner – atua de várias formas, incluindo:
▪ Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
▪ Claramente comunicar a visão, objetivo e itens do Backlog do Produto para o Time de Desenvolvimento;
▪ Ensinar ao Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;
▪ Compreender a longo-prazo o planejamento do Produto no ambiente empírico;
▪ Compreender e praticar a agilidade; e,
▪ Facilitar os eventos Scrum conforme exigidos ou necessários.
TIME - PAPÉIS NO SCRUM
Scrum Master

O Scrum Master trabalhando para o Time de Desenvolvimento, inclui:

▪ Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;
▪ Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto valor;
▪ Remover impedimentos para o progresso do Time de Desenvolvimento;
▪ Facilitar os eventos Scrum conforme exigidos ou necessários; e,
▪ Treinar o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente
adotado e compreendido.

O Scrum Master trabalhando para a Organização, inclui:

▪ Liderando e treinando a organização na adoção do Scrum;
▪ Planejando implementações Scrum dentro da organização;
▪ Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de
produto empírico;
▪ Causando mudanças que aumentam a produtividade do Time Scrum; e,
▪ Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum nas organizações.
EVENTOS NO SCRUM
Existem para criar uma rotina e minimizar a necessidade de reuniões
não definidas no Scrum. Todos os eventos são eventos time-boxed,
de tal modo que todo evento tem uma duração máxima.

Uma vez que a Sprint começa, sua duração é fixada e não pode ser
reduzida ou aumentada. Os eventos restantes podem terminar
sempre que o propósito do evento é alcançado, garantindo que uma
quantidade adequada de tempo seja gasta sem permitir perdas no
processo.
EVENTOS NO SCRUM
Sprint
O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um
“Pronto”, versão incremental potencialmente utilizável do produto, é criado. Sprints tem
durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia
imediatamente após a conclusão da Sprint anterior.

As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias,
o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.
Durante a Sprint:
▪ Não são feitas mudanças que possam por em perigo o objetivo da Sprint;
▪ As metas de qualidade não diminuem; e,
▪ O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de
Desenvolvimento quanto mais for aprendido.
EVENTOS NO SCRUM
Sprint – Cancelamento

Custa caro cancelar uma sprint!

Somente o PO pode fazer isso. Geralmente isso ocorre quando a

meta da sprint se torna obsoleta ou não é mais necessária.

Guia do Scrum
EVENTOS NO SCRUM
Reunião de Planejamento da Sprint

O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da

Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum.
Reunião de planejamento da Sprint possui um time-box com no máximo oito
horas para uma Sprint de um mês de duração. Para Sprints menores, este evento
é usualmente menor.

A reunião de planejamento da Sprint responde a algumas questões:

▪ O que pode ser entregue como resultado do incremento da próxima Sprint?
▪ Como o trabalho necessário para entregar o incremento será realizado?
EVENTOS NO SCRUM
Reunião Diária

A Reunião Diária do Scrum dura 15 minutos, para que o Time de Desenvolvimento possa
sincronizar as atividades e criar um plano para as próximas 24 horas.
O time realiza a inspeção do trabalho desde a última Reunião Diária, e prevê o trabalho
que deverá ser feito antes da próxima Reunião Diária.
É realizada no mesmo horário e local.
Pontos da reunião:
▪ O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da
Sprint?
▪ O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint?
▪ Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no
atendimento da meta da Sprint?
EVENTOS NO SCRUM
Revisão da Sprint
Delimitada em 4 horas para uma sprint de 1 mês, é realizada ao final da Sprint para inspecionar o
incremento e adaptar o Backlog do Produto se necessário.

Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destina-
se a motivar e obter comentários e promover a colaboração. A Reunião de Revisão inclui os
seguintes elementos:

▪ Esclarece o que foi pronto e o que não foi

▪ Discute-se o que deu certo, o que não deu certo e como isso foi corrigido
▪ Quais são as coisas mais importantes a serem feitas a seguir
▪ Análise de linha de tempo e orçamento

Resultado da reunião: backlog revisado – o que define o provável backlog da próxima sprint
EVENTOS NO SCRUM
Retrospectiva da Sprint

Delimitada em 3 horas para uma sprint de 1 mês, é realizada entre a Revisão de

Sprint e a reunião de Planejamento da próxima sprint. O objetivo é o time
inspecionar a si próprio. Assim, o propósito da Retrospectiva é:

▪ Inspecionar como a última Sprint foi em relação às pessoas, aos

relacionamentos, aos processos e às ferramentas;
▪ Identificar e ordenar os principais itens que foram bem e as potenciais
melhorias; e,
▪ Criar um plano para implementar melhorias no modo que o Time Scrum faz seu
trabalho;
ARTEFATOS NO SCRUM
Backlog do produto
O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é
uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product
Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e
ordenação.

Backlog da sprint
O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint,
juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint.
O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade
estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade
em um incremento “Pronto”.

Incremento
O incremento é a soma de todos os itens do Backlog do Produto completados durante as
Sprints. Ao final da Sprint um novo incremento deve estar “Pronto”, ou seja, utilizável e
atender a definição de “Pronto” (independente do Product Owner decidir por liberá-lo
realmente ou não).
JUNTANDO TUDO...
SCRUM OVERVIEW
PILARES DO SCRUM
TRANSPARÊNCIA
▪ O que esperam de mim e o que eu espero dos outros ARTEFATOS
▪ A informação precisa ser a mesma, não importa quem perguntou
ou quem respondeu
▪ Todos devem entender claramente a informação

INSPEÇÃO
EVENTOS
▪ Os processos, práticas e tarefas devem ser
constantemente observados:
▪ O que posso fazer melhor? Daily
Review
▪ O que não fiz bem?
▪ O que posso deixar de fazer?

ADAPTAÇÃO EVENTOS
▪ Conhecendo os pontos críticos, o que preciso fazer para
Planning
melhorar?
Daily
▪ Como garantir que o que deu errado não aconteça Review
novamente? Retrospective
▪ Como garantir que o que deu certo volte a ocorrer?
REGRAS DO SCRUM
▪ Eventos timeboxed;
▪ Time desenvolvimento entre 3 e 9 pessoas;
▪ Não tem hierarquia no time;
▪ Sprints não podem ter mais de 1 mês;
▪ Só quem produz estima;
▪ Reuniões diárias no mesmo local e horário;
▪ Ciclos curtos de feedback.
EFICIÊNCIA vs EFICÁCIA
EFICIÊNCIA vs EFICÁCIA
Não adianta fazer bem feito o que não precisa ser feito! Ou quanto mais certo
fazemos a coisa errada, mais errado nos tornamos!
 TROCA DE CONTEXTO
RODADA 1 RODADA 2
ARÁBICO ROMANO ALFABETO ARÁBICO ROMANO ALFABETO
TROCA DE CONTEXTO

Número de Projetos Porcentagem do tempo Perda com a troca de

Simultâneos disponível por projeto contexto

1 100% 0%
2 40% 20%
3 20% 40%
4 10% 60%
5 5% 75%
A coluna "Perda com a troca de contexto" é puro desperdício. Isso mesmo: se você tem cinco
projetos, cerca de 75% do seu trabalho não vai a lugar algum - três quartos do seu dia são jogados
na lata de lixo. É por isso que você demora mais escrevendo as letras dos nomes do que o nome
completo.
OBRIGADO
Prof. MSc Marcus Gregório Serrano
marcusgregorio@fucape.br

linkedin.com/in/marcusgregorio

instagram.com/marcusgregorio