Métodos Ágeis e Melhoria de Processos

Prévia do material em texto

§ O QUE É PROCESSO E POR QUE MELHORIA DE PROCESSOS;
§ PENSAMENTO ENXUTO (LEAN);
§ DESPERDÍCIOS;
§ ESTRUTURA DO LEAN;
§ GERENCIAMENTO DE PROJETOS DE FORMA PREDITIVA;
§ GERENCIAMENTO DE PROJETOS DE FORMA ITERATIVA E
INCREMENTAL;
§ GERENCIAMENTO DE PROJETOS COM MÉTODOS ÁGEIS (SCRUM);
§ DETALHAMENTO DOS MÉTODOS ÁGEIS (SCRUM);
§ APANHADO: VANTAGENS E DESVANTAGENS DA ADOÇÃO DE CADA
MÉTODO EM TERMOS DE MELHORIA DE PROCESSOS.
Sumário
68
Desenvolvimento de projetos com métodos ágeis
(SCRUM)
Especialista do NEGÓCIO que representa todos os STAKEHOLDERS, 
responsável por comunicar a VISÃO DO PRODUTO, por levantar, especificar, 
detalhar e priorizar CONTINUAMENTE os REQUISITOS do projeto, 
assegurando que os requisitos mais importantes sejam produzidos primeiro. 
Cria o PLANO DO PROJETO e APOIA O TIME para sanar dúvidas sobre 
requisitos.
Responsável por LIDERAR O TIME, fazendo papel de COACH, REMOVENDO 
IMPEDIMENTOS (questões, problemas) que surgem durante o projeto, 
EVITANDO INTERRUPÇÕES externas, GARANTINDO que os eventos e 
reuniões necessárias para desenvolver o projeto estejam sendo realizados 
(PROCESSO SCRUM). 
Conjunto de pessoas com as especializações necessárias para 
IMPLEMENTAR OS RESULTADOS DO PROJETO, gerenciando seu próprio 
trabalho e participando de todos os eventos e reuniões obrigatórias do 
Scrum. Espera-se que seja uma equipe AUTOGERENCIÁVEL, coletivamente 
responsável pelo sucesso do projeto, que se organiza em torno de uma 
meta comum..
As funções de gestão do projeto são divididas 
entre os três papéis! 
Res
IMP
EVIT
reu
(PR
Desenvolvimento de projetos com métodos ágeis
(SCRUM)
B) No início do projeto, o 
Product Owner (PO) passa a 
visão, com informações sobre 
os objetivos do projeto e 
onde se deve chegar. 
A) O PO cria uma lista de todos os requisitos dos stakeholders
que ele representa. Esses requisitos são chamados normalmente 
no Scrum de histórias de usuário. Eles devem ser priorizados por 
ordem de importância – aqueles que geram mais valor devem 
ser desenvolvidos primeiro e estar em um nível de detalhe 
maior. Uma estimativa de alto nível do tamanho de cada 
requisito pode ser feita. 
Desenvolvimento de projetos com métodos ágeis
(SCRUM)
C) O projeto é desenvolvido por sprints, que consistem de fases 
ou etapas de duração fixa (time-boxed). Todos os sprints devem 
ter a mesma duração, normalmente 2 a 4 semanas. Com base na 
velocidade e capacidade do time, são definidos os requisitos 
prioritários que podem ser completamente desenvolvidos no 
próximo sprint. 
Desenvolvimento de projetos com métodos ágeis
(SCRUM)
E) Durante o andamento do sprint, diariamente o Time se reúne (Daily 
Meeting) para responder a 3 perguntas:
• O que foi feito ontem?
• O que será feito hoje?
• Existe algum impedimento?
D) No início do sprint, uma reunião de planejamento (Sprint 
Planning) é realizada com algumas ações importantes:
• PO explica cada requisito que deve ser desenvolvido no sprint;
• É estabelecida a meta do sprint;
• Time decompõe os requisitos em atividades e cria estimativas 
para essas atividades.
F) Ao final do sprint, é 
realizada a Sprint Review
onde um incremento do 
produto é apresentado ao 
PO, que fornece feedback 
se a meta do sprint foi 
atingida. 
G) Após a Sprint 
Review, é realizada 
uma reunião de 
Retrospectiva da 
Sprint, quando o time 
registra as lições 
aprendidas do 
processo de 
desenvolvimento do 
projeto, e adaptações 
podem ser feitas. 
Desenvolvimento de projetos com métodos ágeis
(SCRUM)
H) Durante todo o desenvolvimento do projeto, o PO é 
responsável por detalhar, estimar e redefinir a ordem de 
prioridade dos requisitos. Itens novos podem ser adicionados à 
pilha de requisitos com a prioridade desejada.
Desenvolvimento de projetos com métodos ágeis
(SCRUM)
I) Esse processo é repetido enquanto houver itens a serem 
desenvolvidos em sprints até o encerramento do projeto, quando o 
produto completo foi desenvolvido.
Desenvolvimento de projetos com métodos ágeis
(SCRUM)
Múltiplos PDCAs: Plan - Do – Check – Act
Cada etapa é uma iteração que segue o ciclo PDCA e entrega incremento pronto – cada 
reunião diária é um PDCA menor.
Etapa 1 Etapa 2 Etapa n
Etapa x
Dia1 Dia2 Dia n
…
75
Quando Usar Abordagens Ágeis:
A aplicação dos métodos ágeis é recomendada para cenários
complexos, em que existem incertezas com relação a requisitos,
recursos e/ou tecnologia.
http://www.hiflex.com.br
52
Desenvolvimento Iterativo e 
Incremental - Estimativas
Planos evolucionários
trazem maior possibilidade
de acerto quando
requisitos ainda não são
conhecidos, mudanças
acontecem e onde ainda há
alto grau de incertezas que 
vão se dissipando com o 
tempo, e informações que 
são acumuladas.
Conhecimento melhor do 
escopo, do cliente, da 
tecnologia.
Melhoria de previsão de 
custo/prazo com a 
experimentação de 
algumas iterações.
77
§ Admitindo a imprevisibilidade inerente ao desenvolvimento de
produtos complexos, utilizar uma abordagem preditiva não
garante a previsibilidade desejada;
§ O gerenciamento de projetos, com base em frameworks ágeis,
aceita que requisitos mudem com frequência e, por isso, devem
possuir forma de trabalho iterativa e incremental.
Princípios do Desenvolvimento Ágil de Projetos
ITERATIVO E INCREMENTAL
51
§ Manifesto (2001):
▫ Apesar de reconhecer que há valor nos itens da direita, valorizamos mais os 
itens da esquerda:
▫ Indivíduos e interação entre eles mais do que processos e ferramentas;
▫ Produto em funcionamento mais do que documentação abrangente;
▫ Colaboração com o cliente mais do que negociação de contratos;
▫ Responder a mudanças mais do que seguir um plano.
Também é importanteMaior valor
O Manifesto Ágil
O Manifesto Ágil, bem como os principais frameworks ágeis, 
como SCRUM, se baseiam em projetos de software, mas 
podem se aplicar a diversos tipos de projetos. 
56
Abordagem Tradicional
§ Escopo fechado;
§ Definem-se custo e prazo;
§ Se necessário, manipular a qualidade.
Por que não...
§ Prazo definido;
§ Custo fixo, em função do prazo;
§ Manter os níveis de qualidade;
§ Manipular o escopo?
Qualidade
CustoPrazo
Princípios da Agilidade
Escopo
CustoPrazo
Qualidade
Escopo
57
81
APLICAÇÃO DOS CONCEITOS – EXEMPLOS DE CASOS REAIS
Organização de eventos
Desenvolvimento de software
Área de Comunicação
O Que é o Scrum?
§ Scrum é um framework de processo ágil que permite manter
o foco na entrega do maior valor de negócio, no menor tempo
possível. Isso permite a rápida e contínua inspeção do produto
em produção;
§ As necessidades do negócio é que determinam as prioridades
do desenvolvimento do projeto. As equipes se auto-organizam
para definir a melhor maneira de entregar as funcionalidades
de maior prioridade;
§ Entre cada duas a quatro semanas todos podem ver um
incremento do produto, decidindo se o mesmo deve ser
liberado ou continuar a ser aprimorado por mais um “Sprint”.
Fonte: http://www.mountaingoatsoftware.com
65
Métodos ágeis (SCRUM) - DETALHAMENTO
A) O PO cria uma lista de todos os requisitos dos stakeholders
que ele representa. Esses requisitos são chamados normalmente 
no Scrum de histórias de usuário. Eles devem ser priorizados por 
ordem de importância – aqueles que geram mais valor devem 
ser desenvolvidos primeiro e estar em um nível de detalhe 
maior. Uma estimativa de alto nível do tamanho de cada 
requisito pode ser feita. 
Priorização do Backlog
§ O objetivo da priorização do backlog é tentar entregar valor maior nas
primeiras iterações;
§ No caso do software, 80% do valor de um software vem de 20% das
funcionalidades.
Fonte: http://www.softhouse.se/
84
§ Na primeira etapa de priorização, devem-se classificar os itens de maior
valor para o mercado, ou seja, maior business value (BV);
§ Business Value (BV) reflete a importância estratégica de uma
funcionalidade do produto para o mercado;
§ Podemos estabelecer uma escala arbitrária para BV (ex.: 1 a 10);
§ Outra variável que deve ser inserida na fórmulade priorização dos itens
que irão compor o escopo do projeto é a facilidade de implementação
do requisito. Quanto maior a facilidade, menor deve ser seu esforço de
implementação;
§ A segunda etapa de refinamento da priorização de requisitos leva em
consideração o tamanho do requisito;
§ Dado isso, a fórmula sugerida deve ser a seguinte:
▫ Priorização final da pilha = BV/ Tamanho do requisito
Priorização do Backlog
85
§ Como critério de desempate, a criticidade deve ser considerada,
uma vez que ela determina o momento atual e pode ser utilizada
como “alteração manual” dentre a pilha de requisitos:
▫ 1 – Baixa
▫ 3 – Normal
▫ 5 – Alta
▫ 7 – Urgência
▫ 9 – Emergência
§ A fórmula final sugerida de priorização para desempate deve ser
representada como:
▫ (BV/Tamanho do requisito) * criticidade.
Priorização de Backlog
86
Priorização de Backlog
Gaste 60% do tempo 
detalhando os 20% de 
itens no "topo da pilha"
Gaste outros 30% 
estimando os 20% próximos
Gaste 10% para o restante
20%
20%
60%
87
Métodos ágeis (SCRUM) - DETALHAMENTO
B) No início do projeto, o Product Owner (PO) passa a visão, 
com informações sobre os objetivos do projeto e onde se 
deve chegar. 
Métodos ágeis (SCRUM) - DETALHAMENTO
C) O projeto é desenvolvido por sprints, que consistem de 
fases ou etapas de duração fixa (time-boxed). Todos os 
sprints devem ter a mesma duração, normalmente 2 a 4 
semanas. Com base na velocidade e capacidade do time, 
são definidos os requisitos mais prioritários que podem 
ser completamente desenvolvidos no próximo sprint. 
Release Planning – Planejamento do Projeto
§ A release planning consiste de um planejamento de alto nível do
projeto (release);
§ O PO apresenta para a alta gestão sua proposta preliminar para
uma nova Release (projeto) e obtém alinhamento;
§ Após a elaboração de um plano de alto nível para o projeto, o
PO realiza uma reunião de kick-off para apresentar essse plano à
equipe, com treinamentos necessários, número de sprints,
escopo, Release Goal, riscos, etc.
90
§ O Release Goal (objetivo do projeto) é um objetivo estabelecido
pelo Product Owner (PO) para determinar a meta sobre o escopo
do projeto e orientar o time na condução e entrega correta de
maior retorno de valor;
§ Deve estar coerente aos itens de backlog – requisitos do projeto;
§ Deve ser comunicado durante a reunião de Release Planning –
Planejamento do Projeto;
§ É sempre verificado na reunião de Release Review – Revisão do
Projeto, confrontado com a demonstração do Time e os backlogs
planejados.
Release Goal – Objetivo do Projeto
91
Métodos ágeis (SCRUM) - DETALHAMENTO
D) No início do sprint, uma reunião de planejamento (Sprint 
Planning) é realizada com algumas ações importantes:
• PO explica cada requisito que deve ser desenvolvido no sprint;
• É estabelecida a meta do sprint;
• Time decompõe os requisitos em atividades e cria estimativas 
para essas atividades.
Estimativas Ágeis
§ Estimativas já fazem parte de nosso dia a dia:
▫ Tempo de chegada ao trabalho;
▫ Tempo para fazer atividade em aula;
▫ Tamanho do prato em um restaurante.
§ Realizar estimativas significa fazer cálculos aproximados de
tamanho, esforço, prazo, custo e qualidade no desenvolvimento
de um produto do projeto;
§ Esses indicadores são utilizados para comparar com
desempenhos observados no passado e então criar previsões de
desempenho futuro.
71
Estimativas Ágeis
§ Estimativas sofrem influências diversas e carregam riscos inerentes:
▫ Tecnologia;
▫ Equipe (velocidade, domínio no negócio e tecnologia, etc.);
▫ Tamanho e tipo do projeto;
▫ Maturidade dos requisitos – instáveis ou estáveis.
§ Estimativas podem ser auxiliadas por:
▫ Experiência;
▫ Utilização de informações históricas;
▫ Disposição para comprometimento.
§ Ou seja, os inputs (variáveis) e outputs (estimativa) que são utilizados
têm que ser bem definidos e utilizar uma técnica de estimativa
adequada.
72
§ Projetos ágeis de desenvolvimento de produtos costumam tratar
estimativas simplesmente como estimativas.
§ Para que seja possível ser previsível sem ser exato, estimativas ágeis
utilizam-se de duas ferramentas:
1. Conhecimento prévio de negócio e tecnologia de um time que já
trabalhou junto em, pelo menos, 1 projeto.
2. Um método de pontuação de requisitos famoso por não se
preocupar com a exatidão, e sim com o consenso conseguido por
meio da experiência de um grupo de profissionais: Story Points,
baseados nos números de Fibonacci (0, 1, 1, 2, 3, 5, 8, 13, 21...).
http://blog.addtech.com.br/post/Fibonacci-com-pimenta-Parte-1.aspx
Estimativas Ágeis
73
Medida de Tamanho - Story Point
§ Story points consistem de uma escala arbitrária aplicada a requisitos
fornecidos pelo PO para definir o tamanho relativo e complexidade de
cada requisito quando comparado a outros.
§ Story points SÃO:
▫ Uma medida de tamanho e complexidade relativos;
▫ São válidos para comparar requisitos dentro de um mesmo time;
▫ Estimar em story points encoraja todos a participarem do processo de estimativa,
inclusive pessoas de negócio;
▫ Estimar em story points é rápido e fácil, mas é preciso ter referência do que seja 1
SP para estimar os requisitos;
▫ Story points podem ser usados para gerar a velocidade do time e prever a
capacidade de trabalho futura.
http://myagilemind.wordpress.com/2011/10/18/story-points-vs-development-hours/
74
§ Story points NÃO são:
▫ Story points não são relacionados diretamente a horas de execução (desenvolvimento
do produto);
▫ Story points não refletem qual pessoa será usada para desenvolver e entregar a história
(requisito);
▫ Story points não refletem diretamente o número de membros que participarão do time
para completar a história (requisito).
§ Por que usar Fibonacci?
▫ Segundo Mike Cohn, em seu livro Agile Estimating and Planning, estudos mostram que
somos melhores estimando coisas dentro de uma determinada ordem de magnitude. No
seu bairro, provavelmente, você é capaz de estimar razoavelmente bem a distância
relativa de coisas, como a padaria mais próxima. A escola pode estar duas vezes mais
longe do que a padaria, por exemplo. Suas estimativas serão muito menos assertivas se
você tiver que estimar a distância relativa para a capital de outro país. Porque somos
melhores dentro de uma determinada ordem de magnitude, seria melhor se
pudéssemos basear nossas estimativas sempre dessa forma.
▫ Os números de Fibonacci (0,1,1,2,3,5,8,13,21...) são muito úteis nesse tipo de
estimativa. Os intervalos entre os números se tornam apropriadamente longos à medida
que os números crescem.
http://blog.addtech.com.br/post/Fibonacci-com-pimenta-Parte-1.aspx
Medida de Tamanho - Story Point
Story Point – Exemplo 1
CÁLCULO DE STORY POINTS PARA PINTAR OS CÔMODOS DE UMA CASA
http://myagilemind.wordpress.com/2011/10/18/story-points-vs-development-hours/
76
§ Comece o processo escolhendo o menor cômodo e atribuindo o menor valor
de story point a ele (1 SP);
§ A partir dessa referência, verifique os outros cômodos a serem pintados e
compare com o tamanho do cômodo usado como referência. Comece pelos
cômodos que aparentam ser duas vezes maior que a referência, atribuindo a
eles 2 SP;
§ Os cômodos restantes são estimados com base na referência inicial e nas
estimativas anteriores até que toda casa seja estimada;
§ O total de story points para o projeto de pintar a casa é 8 + 5 + 13 + 8 + 3 + 5 +
1 + 2 + 3 = 48 SPs;
§ Observe que não foram incluídas informações a respeito do nível de
experiência dos pintores nem da quantidade de pintores. Simplesmente
estimamos o tamanho relativo e complexidade de cada quarto comparando
com outros para determinar o tamanho total do escopo.
http://blog.addtech.com.br/post/Fibonacci-com-pimenta-Parte-1.aspx
77
Story Point – Exemplo 1
CÁLCULO DE STORY POINTS PARA PINTAR OS CÔMODOS DE UMA CASA
Story Point – Exemplo 1
http://myagilemind.wordpress.com/2011/10/18/story-points-vs-development-hours/
O método genérico de 
estimativa usando story points 
é semelhanteao usado neste 
exemplo: escolha uma unidade 
de referência e estime todas as 
histórias comparando-as com a 
referência.
100
Técnica de Estimativa Ágil
PLANNING POKER
http://en.wikipedia.org/wiki/Planning_poker
§ Planning Poker é uma técnica de estimativa ágil com as seguintes
características:
▫ Envolvimento de todo o Time;
▫ Evita influência nas opiniões;
▫ Aprendizado nos requisitos até que haja consenso.
101
§ Usada durante a reunião de planejamento de uma Release ou Sprint
para estimar tamanho dos requisitos;
§ Cartas são distribuídas ao time com a sequência de Fibinacci como
sendo os possíveis pontos a serem atribuídos (1, 1, 2, 3, 5, 8, 13, 21…);
§ Cartas extras com o número 0 (zero), uma “?” interrogação e um
desenho de uma xícara de café são incluídas:
▫ 0 – é colocado pelo membro da equipe que considera a história
pronta;
▫ ? – para história que o membro da equipe desconhece
completamente;
▫ café – apresentado quando um membro precisa de uma pausa. (use
com moderação).
Técnica de Estimativa Ágil
PLANNING POKER
102
§ A prática do Planning Poker é a seguinte:
▫ 1. O item do Backlog deve ser lido e discutido por todos. Após, devem
apresentar ao mesmo tempo as cartas com a previsão que julgam de maior
aproximação.
▫ 2. Caso não haja uma convergência óbvia, deve-se rediscutir o requisito,
principalmente ouvindo-se os argumentos daqueles que votaram com
maior desvio, para baixo ou para cima.
▫ Em função da discussão, pode-se:
– Melhorar a especificação do item do Backlog;
– Decompor o item do Backlog, mantendo a rastreabilidade entre eles;
– Simplesmente prestar mais esclarecimentos aos votantes.
▫ Por fim, deve-se proceder a uma nova votação e retornar ao passo 2, até
que todos entrem em um consenso sobre o valor.
Técnica de Estimativa Ágil
PLANNING POKER
103
§ Velocidade do time é a quantidade de esforço (horas, dias,
pontos) realizado pela equipe por iteração (sprint)
▫ Exemplo: suponha uma sprint com 5 requisitos selecionados:
▫ 1) 13 pontos
▫ 2) 8 pontos
▫ 3) 2 pontos
▫ 4) 5 pontos
▫ 5) 3 pontos
§ No término do prazo, os 3 primeiros foram feitos, o 4º foi
50% concluído e o 5º não foi concluído.
§ Velocidade = 13+8+2 = 23 pontos/sprint
Estimativas Ágeis –Velocidade do Time
104
§ Para equipes que os membros ainda estão se conhecendo, a
velocidade pode variar bastante nas primeiras sprints. Após
algumas iterações, estabiliza. Com a estabilização, é possível
prever melhor quanto falta para o término do projeto.
▫ Exemplo: equipe realizou 5 sprints com velocidades: 38, 42,
40, 37 e 43. Faltam 520 pontos para completar o projeto.
Quanto falta para completar?
▫ Resposta: Média de velocidade por sprint: 40
▫ Sprints faltantes: 520/40 = 13
§ Importante não comparar velocidades de equipes
diferentes. Cada equipe tem sua métrica de esforço.
Estimativas Ágeis –Velocidade do Time
105
§ Realizada todo início de Sprint, com duração de 2 a 4 (duas a
quatro) horas;
§ Participação do Product Owner (PO), Scrum Master (SM) e Time.
Alguns stakeholders podem ser convidados;
§ Passagem de entendimento sobre cada item do Backlog pré-
selecionado do PO para o Time;
§ O Time realiza a estimativa inicial de tamanho, para cada item do
Backlog;
§ O PO estabelece o Sprint Goal e, em conjunto com a equipe,
estabelece a definição de pronto.
Sprint Planning – Parte 1
106
§ Cada um tem sua concepção do que é concluir a tarefa, mas é
preciso respeitar e, principalmente, conhecer essa definição do
Product Owner.
▫ Desenvolvedor: quando terminou a codificação.
▫ Analista de Teste: quando encerrou o teste e não encontrou nenhum bug.
▫ Product Owner: quando a entrega da Sprint estiver em produção.
▫ Usuário final: quando estiver devidamente capacitado para utilizar o que
foi entregue.
§ Essas definições devem estar claras para todos e em comum
acordo;
§ Cada organização pode ter uma visão de pronto um pouco
diferente. Essa visão deve estar definida antes de entrar no
Sprint.
Definição de Pronto
107
§ O Sprint Goal é uma meta "visionária" do Sprint
estabelecido pelo Product Owner ao final da reunião de
Sprint Planning – Parte 1;
§ É sempre verificado durante a reunião de Sprint Review,
confrontado com a demonstração do Time e os itens de
backlog planejados e comprometidos.
Sprint Goal
108
§ Realizada após o Sprint Planning 1, com duração de 2 a 4 (duas a
quatro) horas, sem a participação do PO e stakeholders;
§ Auto-organização: planejamento do Time para seu próprio
trabalho: ele refina a análise de cada item do Backlog, criando a
lista de tarefas que irão implementar cada item;
§ O time finaliza a estimativa iniciada no SP1 (ela pode ser
reavaliada durante a reunião), reportando ao PO qualquer ajuste;
§ Artefato: Agile Radiator ou task board, usado para retratar o
Sprint corrente.
Sprint Planning – Parte 2
109
§ Exemplo: a história: “Precisamos registrar a solicitação de serviço
e informar o número do protocolo de atendimento” pode ser
quebrada nas seguintes atividades:
1. Levantar com o PO a relação de serviços a serem disponibilizados
no sistema.
2. Verificar se existe essa estrutura no banco de dados.
3. Fazer a carga dos serviços.
4. Levantar com o PO as informações que devem ser contempladas
no atendimento.
5. Design da interface do sistema.
6. Elaboração e execução dos planos de testes.
http://www.profissionaisti.com.br/2013/12/artefatos-e-ferramentas-scrum/
Sprint Planning - Parte 2
110
Agile Radiator Ou Task Board ou KanBan
http://www.profissionaisti.com.br/2013/12/artefatos-e-ferramentas-scrum/
111
Métodos ágeis (SCRUM) - DETALHAMENTO
E) Durante o andamento do sprint, diariamente o Time se reúne (Daily 
Meeting) para responder a 3 perguntas:
• O que foi feito ontem?
• O que será feito hoje?
• Existe algum impedimento?
§ Realizada diariamente, no início ou no final do dia (deve ser
determinado pelo próprio time);
§ Tem a duração de 15 minutos – deve ser respeitado!
§ Participação do Time e Scrum Master;
§ Três únicas perguntas:
1. O que você fez neste projeto desde a última reunião diária?
2. O que você planeja realizar neste projeto até a próxima reunião
diária?
3. Que impedimentos existem para que você cumpra seus
compromissos para esta Sprint?
§ Atualização do Agile Raditor ou Task Board ou KanBan.
Daily Scrum – Reunião Diária
113
Agile Radiator Ou Task Board ou KanBan
§ Quadro de acompanhamento de atividades tipicamente dentro de um
sprint – com atividades não iniciadas (previstas), atividades em
andamento e atividades concluídas;
§ Auxilia no monitoramento de um projeto real. Eles garantem
visibilidade do projeto a todos os envolvidos;
§ É atualizado diariamente durante as reuniões de Daily Scrum;
§ É também onde os impedimentos devem ser anexados, além dos itens
de lições aprendidas;
§ O goal fica afixado e os requisitos e atividades – por meio de Post-its -
são posicionados na situação em que se encontram;
§ Eles devem ser posicionados de acordo com a prioridade. Post-its
localizados no topo nos dizem ser de maior prioridade que os
posicionados no rodapé do quadro.
114
Agile Radiator Ou Task Board ou KanBan
http://stackoverflow.com/questions/2243438/tools-to-be-aware-of-time-in-a-development-team
115
Início da Sprint
Task Board 
adaptado
com coluna
de testes
http://www.profissionaisti.com.br/2013/12/artefatos-e-ferramentas-scrum/
116
Durante o Sprint – Itens não Planejados e 
Impedimentos
http://www.profissionaisti.com.br/2013/12/artefatos-e-ferramentas-scrum/
Não planejado em verde
Impedimento
em vermelho
117
Gráfico de Burndown
§ O gráfico de burndown é considerado um dos mais úteis para monitorar
o progresso de um time ágil;
§ O gráfico representa a quantidade de trabalho que falta ser feito no
eixo vertical (y) versus o tempo no eixo horizontal (x).
§ Sprint burndown:
▫ Gráfico que exibe a quantidade de trabalho restante dentro de um Sprint,
baseado na pilha de Sprint Backlog;
▫ É atualizado diariamente, após a reunião diária, pelo Scrum Master, pararefletir o progresso do Time naquele dia.
§ Release burndown:
▫ Gráfico que demonstra a quantidade de trabalho restante dentro de um
projeto;
▫ Normalmente no eixo y a medida de tamanho (story points etc.);
▫ É atualizado ao final de cada Sprint pelo Product Owner/Scrum Master e
Time.
118
“Burndown por horas e burndown por pontos tem 
propósitos diferentes.
Ninguém espera que um burndown por horas diga o 
quanto de valor foi entregue, mas apenas o 
acompanhamento do ritmo diário do time. Os dois são
importantes!”
Alexandre Magno
Gráfico de Burndown
119
Gráfico de Burndown
120
Gráfico de Burndown
https://www.scrumalliance.org/community/articles/2010/may/managing-myopia-with-release-burndowns
121
Gráfico de Burndown
https://www.scrumalliance.org/community/articles/2010/may/managing-myopia-with-release-burndowns
122
Gráfico de Burndown
http://www.infoq.com/br/news/2010/02/deciphering-burndown-charts
123
Artefatos Scrum – Pilha de impedimentos
§ A pilha de impedimentos contém eventos que impedem o
progresso do Time em atingir o Sprint Goal;
§ Mantido pelo Scrum Master, responsável por agir e remover
cada impedimento dentro de uma meta de 24 horas;
§ O Scrum Master pode, para remover impedimentos, pedir
auxílio ao PO e/ou levar o problema ao gerenciamento da
empresa.
124
Métodos ágeis (SCRUM) - DETALHAMENTO
F) Ao final do sprint, é realizada a Sprint Review onde um 
incremento do produto é apresentado ao PO, que fornece 
feedback se a meta do sprint foi atingida. 
Sprint Review
§ Realizada após cada Sprint, com duração de 2 a 4 horas e
participação do PO;
§ O Time demonstra o trabalho realizado no Sprint e é avaliado
pelo PO;
§ A demonstração deve ser do produto funcionando e comprovar
que os itens de Backlogs prioritários (e associados ao Sprint Goal)
foram realizados com o objetivo de maximizar o ROI.
126
Métodos ágeis (SCRUM) - DETALHAMENTO
G) Após a Sprint Review, é realizada uma reunião de 
Retrospectiva da Sprint, quando o time registra as lições 
aprendidas do processo de desenvolvimento do projeto, e 
adaptações podem ser feitas. 
Sprint Retrospective Meeting
§ Realizada após o Sprint Review, com duração de 1-2 horas ->
lições aprendidas.
§ Duas perguntas:
▫ “O que foi bem?” (WWW-What Went Well?)
▫ “O que pode ser melhorado? (WCBI - What Can Be Improved?)
128
2h
Time-boxed
Time
§ Pontos positivos;
§ Oportunidades de 
melhoria.
Product Owner
§ Pode participar ou 
não, dependendo do 
que foi combinado 
com o time.
Scrum Master
§ Participação intensa;
§ Facilitador.
O que foi bom (WWW)? O que pode melhorar (WCBI)?
Sprint Retrospective Meeting
129
Métodos ágeis (SCRUM) - DETALHAMENTO
H) Durante todo o desenvolvimento do projeto, o PO é 
responsável por detalhar, estimar e redefinir a ordem de 
prioridade dos requisitos. Itens novos podem ser adicionados à 
pilha de requisitos com a prioridade desejada.
Métodos ágeis (SCRUM) - DETALHAMENTO
Release Review – Revisão do Projeto
§ Reunião de validação do projeto como um todo;
§ Funciona como a Sprint Review, mas, nesse caso, o PO conduz a
reunião para apresentação à Alta Gestão dos trabalhos que a
equipe realizou;
§ Pode-se também, neste momento, apresentar os indicadores
sumarizados.
132
Diferentes nomes para o Backlog
133
REQUISITOS 
DO PROJETO
REQUISITOS DE 
UMA SPRINT (ETAPA)
ATIVIDADES DECOMPOSTAS 
PELO TIME A PARTIR DOS REQUISITOS
§ Ter o cliente sempre por perto e fazê-lo um participante ativo. É
importante que ele entenda suas responsabilidades e sua grande
parcela de contribuição para o sucesso do projeto;
§ Iterações curtas levam ao feedback real e imediato dado pelo cliente,
e, como resultado, auxiliam nos possíveis ajustes que não acontecem
mais tardiamente e garantem a entrega de software de valor;
§ Atendimento ao goal (objetivo) x Controle da WBS;
§ Não existe gerenciamento dos riscos, mas tratamento de
impedimentos em taxas diárias (por meio de reuniões curtas e diárias)
e durante toda a iteração, impedindo que se propaguem;
§ O controle da qualidade dos trabalhos é avaliado continuamente por
meio de, por exemplo, testes, revisão por pares, inspeção contínua e
acompanhamento pelo cliente.
Gerenciamento Ágil - Características
134
§ Impedimentos são levantados, e esses devem ser resolvidos no prazo
máximo de 24 horas para garantir que ações de resolução rápidas
sejam executadas, e para que todos conheçam os impedimentos que
podem se tornar potenciais riscos para o projeto;
§ Mudanças no projeto são bem aceitas, pois elas existem e irão
acontecer. É por isso que o comprometimento de todos os envolvidos
é tão importante em um projeto. Caso o cliente queira mudar algo que
solicitou ou o mercado peça neste momento algo diferente, pode-se
mudar o rumo rapidamente sem afetar todo o projeto, pois o
planejamento é refeito a todo momento;
§ E se uma iteração não ocorreu conforme o esperado pelo cliente,
pode-se mudar a abordagem de levantamento de dados, os recursos
envolvidos, a forma de troca de informações e corrigir o rumo ainda a
tempo do final do projeto.
Gerenciamento Ágil - Características
135
1. Nossa maior prioridade é satisfazer o cliente por meio da
entrega contínua e adiantada do produto com valor
agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo
tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das mudanças visando à vantagem competitiva
para o cliente.
3. Entregar frequentemente produto funcionando, de poucas
semanas a poucos meses, com preferência em menor
escala de tempo.
4. Pessoas de negócio e desenvolvedores (equipe) devem
trabalhar diariamente em conjunto por todo o projeto.
Princípios da Agilidade
59
5. Construa projetos em torno de indivíduos motivados.
Dê a eles o ambiente e o suporte necessário
e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir
informações para e entre uma equipe de desenvolvimento
é por meio de conversa face a face.
7. Produto funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento
sustentável. Os patrocinadores, desenvolvedores (equipe)
e usuários devem ser capazes de manter um
ritmo constante indefinidamente.
Princípios da Agilidade
60
9. Contínua atenção à excelência técnica e bom design
aumentam a agilidade.
10. Simplicidade - a arte de maximizar a quantidade de
trabalho não realizado - é essencial.
11. As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como
se tornar mais eficaz, e então refina e ajusta seu
comportamento de acordo.
Princípios da Agilidade
61
“Ágil foi feito para expor os problemas o quanto antes. 
Entenda: as práticas Ágeis são mecanismos de exposição 
de problemas! Encontrar os obstáculos no momento em 
que eles acontecem e tratá-los imediatamente para 
mitigar riscos futuros desnecessários – que levam a 
desperdícios.” 
http://www.tiespecialistas.com.br/2014/10/agile-verdade-por-tras-metodo/
139
§ O QUE É PROCESSO E POR QUE MELHORIA DE PROCESSOS;
§ PENSAMENTO ENXUTO (LEAN);
§ DESPERDÍCIOS;
§ ESTRUTURA DO LEAN;
§ GERENCIAMENTO DE PROJETOS DE FORMA PREDITIVA;
§ GERENCIAMENTO DE PROJETOS DE FORMA ITERATIVA E
INCREMENTAL;
§ GERENCIAMENTO DE PROJETOS COM MÉTODOS ÁGEIS (SCRUM);
§ DETALHAMENTO DOS MÉTODOS ÁGEIS (SCRUM);
§ APANHADO: VANTAGENS E DESVANTAGENS DA ADOÇÃO DE CADA
MÉTODO EM TERMOS DE MELHORIA DE PROCESSOS.
Sumário
140