TreinamentoScrum v01r00

©Alison Rabelo | twitter.
com\alisonrabelo
Programa
I. Gerenciamento de Projetos
II. Projetos de Desenvolvimento de Software
III. Métodos Ágeis de Desenvolvimento de Software
IV. Gerenciamento Ágil de Projetos
V. Scrum
VI. Regras do Scrum
©Alison Rabelo | twitter.com\alisonrabelo
1
Parte I
Motivação
 Cenário mundial
 Concorrência global
 Maior exigência por qualidade
 Menor tempo para desenvolvimento de produtos
 Recursos limitados
 Grandes redes de informação e fornecedores atuando
globalmente
2
Projetos
“Cerca de 2 milhões de pessoas estão
trabalhando em 300 mil projetos de
software nos Estados Unidos. Entre 1/3 e
2/3 destes projetos excederão seus
prazos e orçamentos antes de serem
concluídos. Dentre os mais caros projetos
de software, cerca de 1/2 eventualmente
serão cancelados por estarem
completamente fora de controle.”
Software Project Survival Guide
Problemas Típicos dos Projetos

Gerenciamento de projetos
 Atrasos no cronograma
Tarefa complexa e difícil!
 Custos além do previsto
Organizações reconhecem
 Falta de recursos relação entre o fraco
 Mudanças de requisitos Gerenciamento de Projetos e
os impactos nos negócios!
 Qualidade abaixo da esperada
 Produtos que não funcionam
 Projetos que são cancelados
 Ruídos na comunicação entre a equipe de
projeto e as partes interessadas no projeto
3
Projetos
 Projetos
 são únicos e finitos, isto é, tem início e fim.
 “Um projeto é um esforço temporário para criar um
produto ou serviço único.”
Projetos
 Características de um projeto:
 Elaboração Progressiva:
 característica de projetos que integra o conceito da
temporariedade e particularidade;
 conceito de elaboração do projeto por etapas ou incrementos
iterativos;
 distingue as fases de um projeto.
 Temporário
 significa possuir um início e um fim definido.
4
Projetos
 Exemplos de Projetos:
 Desenvolvimento de um novo modelo de veículo;
 Construção ou reforma de um prédio;
 Uma campanha para um cargo político;
 Organização de um evento, como uma feira de negócios,
um show, entre outros;
 Desenvolvimento ou aquisição de um Sistema de
Informação.
Operações
 Operações
 são corriqueiras e repetitivas;
 possuem atividades contínuas, não sendo limitadas a
tempo
 suportam o funcionamento normal de uma organização.
 são um conjunto de ações cujos resultados, em um dado
período, contribui para o atendimento de uma
necessidade administrativa ou operacional da
organização.
5
Projetos x Operações
 Possuem características semelhantes, apesar de
serem conceitos diferentes;
 Tanto os projetos como as operações são realizadas
por pessoas, restritos em recursos e são planejados,
executados e controlados;
 São realizados com um propósito definido e
possuem atividades inter-relacionadas.
 A finalidade de um projeto é atingir o objetivo e ser
finalizado.
 O objetivo de uma operação é normalmente
sustentar o negócio.
Parte II
6
Projetos de Desenvolvimento de
Software
 Estão inseridos em ambientes de negócio bastante
dinâmicos e complexos.
 São projetos de alta complexidade devido às mudanças
constantes de requisitos (escopo)
 Muitos projetos fracassaram ou estavam fadados ao
insucesso devido ao desconhecimento ou emprego
incorreto de práticasApenas
de gerenciamento de projetos.
34% dos projetos de
desenvolvimento de software
foram bem-sucedidos em
2002 (Standish Group)
Parte III
7
Métodos Ágeis de Desenvolvimento de
Software
 São uma resposta ao baixo desempenho dos projetos
de software.
 Visam atender às demandas crescentes por produtos e
serviços inovadores e à necessidade de mudanças
constantes de escopo nos projetos de desenvolvimento
de software.
 Uma reação aos métodos clássicos de desenvolvimento
de software, baseados no RUP, CMMi, PMBOK, etc.
 Fruto de um movimento da comunidade de analistas e
desenvolvedores

Software
 Mudança de paradigma: a aceitação das mudanças de
escopo durante o projeto.
 Agilidade: “a habilidade de criar e responder a
mudanças, buscando a obtenção de lucro num
ambiente turbulento”(HIGHSMITH).
 A ausência de estrutura pode levar ao caos, mas
estrutura em demasia pode levar a rigidez.
(HIGHSMITH).
 Os modeladores ágeis encampam a mudança nos seus
projetos (AMBLER)
8
Métodos Ágeis de
Desenvolvimento de Software
 Métodos adaptativos e não preditivos.
 O planejamento é refeito, levando em considerações as
mudanças de requisitos e no ambiente de negócios.
 Diferença entre duas abordagens:
Métodos Clássicos (PMBOK) Métodos Ágeis

Planejamento total do Planos elaborados e
escopo no inicio do projeto e adaptados ao longo do
um controle rígido de projeto, possibilitando a
mudanças. incorporação de mudanças
solicitadas pelo cliente

Software
 Exemplos desses métodos:
 XP (Extreme Programming);
 Scrum;
 DSDM (Dynamic Systems Development Method);
 ADM (Adaptative Development Method);
 Crystal Methods;
 FDD (Feature-Driven Development);
 Lean Development.
9
Software
 Em 2001, um grupo inicial de 17 metodologistas formou a Aliança Ágil
e publicou um manifesto, chamado Manifesto Ágil composto por
quatro simples declarações de valores:
“Nós estamos descobrindo melhores maneiras para desenvolver software,

praticando e auxiliando os outros a fazê-lo. Através deste trabalho, nós
acreditamos que:
Indivíduos e interações valem mais que processos e ferramentas;

Um software funcionando valem mais que documentação extensa;
A colaboração do cliente vale mais que negociação de contrato;
Resposta a mudanças vale mais que seguir um plano.
Ou seja, embora haja valor nos itens à direita, nós valorizamos mais os
itens à esquerda”.
Parte IV
10
Gerenciamento Ágil de Projetos
 Surgiu a partir dos valores e princípios do Manifesto
Ágil.
 O movimento de desenvolvimento ágil ampliou a sua
abrangência, sendo estendido ao gerenciamento de
projetos.
 O Gerenciamento Ágil de Projetos aparece, então,
como uma nova plataforma de gerenciamento de
projetos aplicável a ambientes voláteis e desafiadores,
sujeitos a freqüentes mudanças, em que o processo
prescritivo e padronizado não mais funciona.

 Fluxo do Gerenciamento Ágil de Projetos:
Planejamento a cada iteração

Incrementos de funcionalidades
Mudanças de escopo
Aceitação da entregas ao final de cada iteração
Nível de Atividade
Planejamento Controle contínuo

Preliminar do projeto
Tempo
Início Iteração 1 Iteração 2 Iteração 3 Iteração 4 Encerramento
11
 Fases do Gerenciamento Ágil de Projetos:
Visão
Visão
Escopo
Comunidade do projeto Plano de
Equipe do projeto entregas
Especulação Exploração
Ações de Funcionalidades
adaptação complementares
Adaptação
Lista de
funcionalidades
Encerramento
Produto final

 Visão:
 Determinação da visão do produto e do escopo do projeto;
 Identificação da comunidade do projeto (clientes, gerente de
projetos, equipe de projeto e outras partes interessadas);
 Especulação:
 Identificação dos requisitos iniciais para o produto;
 Definição das atividades;
 Desenvolvimento de um plano de projeto (contendo entregas,
marcos, várias iterações, cronograma de trabalho);
 Elaboração de estratégias para mitigar riscos;
 Estimativas de custo e outras informações financeiras relevantes.
 Planejamento preliminar
12
 Exploração:
 Entrega dos produtos planejados;
 Estas entregas são feitas sob a forma de incrementos de
funcionalidades do produto e são divididas entre os ciclos do
projeto;
 Adaptação:
 Revisão dos resultados entregues;
 Análise da situação atual e avaliação do desempenho da equipe e
do projeto, para eventual adaptação;
 Esta revisão objetiva não apenas uma comparação entre o
realizado e o planejado, mas principalmente entre o realizado e
as informações e os requisitos atualizados do projeto, para
identificação de mudanças necessárias.

 Encerramento:
 Finalização das atividades do projeto;
 Transferência de aprendizado;
 Celebração do fim do projeto.
13
Vantagens de ser ágil
 Cria um ambiente propício para definição de requisitos
e inovação durante o ciclo de desenvolvimento do
produto.
 Cria um ambiente mais colaborativo e produtivo entre
desenvolvedores e clientes, resultando em entregas
mais rápidas de produtos, melhor adaptados à
realidade do cliente e com a qualidade esperada.
 O Gerenciamento de Projetos é facilitado pela maior
integração e comprometimento da equipe com as
entregas do projeto.
Vantagens de ser ágil

 Reforça o planejamento constante do projeto,
minimizando riscos.
 Valoriza a satisfação do cliente em primeiro lugar,
através do desenvolvimento de requisitos que mais
agreguem valor a ele.
14
Parte V
Scrum
 Baseado no controle
empírico de processos
químicos industriais, usado
para controlar processos
complexos, de
comportamento
imprevisível.
Tem como objetivo lidar com a complexidade do
desenvolvimento de software, em que requisitos surgem e
mudam rapidamente.
Estabelece conjuntos específicos de regras e práticas
gerenciais que devem ser utilizadas para o sucesso de um
projeto.
15
Scrum
 Pode ser aplicado de forma variada, adaptando-se as
suas práticas.
 Recomendado para projetos de outras áreas e
principalmente para projetos de Implantação, pesquisa
e inovação.
Características do Scrum
 Simples;
 Fácil de aprender;
 Aplicável a projetos cujos requisitos são pouco estáveis
ou desconhecidos;
 Aplicável a equipes pequenas de nove pessoas, no
máximo;
 Valoriza o envolvimento das partes interessadas no
planejamento do projeto;
16
Características do Scrum
 Iterações ou ciclos de 30 dias;
 Auto-gestão do trabalho de desenvolvimento por parte
da equipe;
 Dá prioridade aos requisitos que mais agregam valor ao
software.
Benefícios do Scrum
 Participação mais efetiva da equipe quanto à definição
das atividades, gerando maior comprometimento,
motivação e confiança.
 Maior visibilidade do desempenho da equipe e de cada
membro.
 Maior participação e satisfação do cliente.
 Estimula a colaboração e a integração entre os
membros da equipe.
 Incentiva o compartilhamento e a disseminação do
conhecimento.
 Fortalece o trabalho em equipe.
17
Práticas Gerenciais do Scrum
Prática Descrição
Product Backlog Lista de atividades do projeto
Daily Scrum Meeting Reunião diária de 15 minutos para
monitoramento do projeto
Sprint Iteração de 30 dias.
Sprint Planning Meeting Reunião de planejamento do Sprint.
Sprint Backlog Lista de funcionalidades a serem
desenvolvidas durante o Sprint
Sprint Review Meeting Reunião para apresentação, revisão
e avaliação das entregas realizadas
durante o Sprint.
Visão geral do processo

Scrum
18
Papéis do Scrum
 Product Owner
 ScrumMaster
 Equipe Scrum
Product Owner
 Representante do patrocinador no projeto.
 Define os requisitos dos produtos, decide as datas das
releases de software e o que deve conter em cada uma
delas.
 É responsável pelo retorno financeiro (ROI) do
produto.
 Prioriza os requisitos de acordo com as necessidades
de negócio ou seu valor de mercado.
 Pode mudar os requisitos e prioridades a cada Sprint
Planning Meeting.
 Aceita ou rejeita o resultado de cada Sprint
19
ScrumMaster
 Responsável pelo processo Scrum, isto é, garante que
todos sigam as regras e práticas do Scrum, conduzindo
as reuniões diárias, de planejamento e revisão do
Sprint.
 Tem um papel mais próximo ao de um facilitador do
que de um Gerente de Projetos.
 Facilita a colaboração entre as funções e áreas.
 Elimina os impedimentos da equipe.
Equipe Scrum
 Multifuncional
 Deve possuir de 5 a 9 membros.
 É responsável por selecionar, entre os itens priorizados
pelo Product Owner, os que irão ser implementados
durante o Sprint.
 Auto-organizada: o trabalho entre os membros é
organizado de forma participativa.
 Ao final de cada Sprint, a equipe realiza a apresentação
do software desenvolvido para o Product Owner na
reunião de revisão do Sprint.
20
Artefatos do Scrum
 Product Backlog
 Sprint Backlog
 Burndown Chart
Product Backlog
 Os requisitos do software estão listados no Product
Backlog.
 O Product Owner é responsável pelo conteúdo e pela
priorização dos itens do Product Backlog.
 Nunca está completo.
 É uma mera estimativa inicial dos requisitos.
 É alterado assim que as necessidades de negócios
mudam.
21
Product Backlog
Sprint Backlog
 Lista de atividades ou requisitos a serem desenvolvidos
no Sprint, ou seja, é o plano de trabalho da equipe
durante o Sprint.
 São itens selecionados do Product Backlog que a
equipe acredita e se compromete que pode realizar
durante o Sprint.
 A equipe escolhe e estima as tarefas durante a reunião
de Planejamento (Sprint Planning Meeting).
 Apenas a equipe pode alterar o Sprint Backlog.
22
Sprint Backlog
Sprint Burndown Chart

 Gráfico que exibe o progresso diário do time em função
do total de horas estabelecido pela soma de horas das
tarefas do Sprint Backlog:
23
Burndown Chart
 O Burndown Chart também pode ser usado para medir o
progresso do projeto.
Parte V - Final
24
Regras do Scrum
 O Scrum pode ser considerado um jogo com regras
claras e definidas.
 O ScrumMaster é responsável por assegurar que todos
os participantes do projetos, sigam as regras do Scrum.
 A experiência mostra que estas regras têm funcionado
com sucesso em muitos projetos de diversas
organizações.
 É importante que todos que participam de um projeto
gerenciado com Scrum conheçam e sigam as regras de
modo a evitar mal-entendidos, perda de tempo e baixo
comprometimento com metas.
Sprint Planning Meeting
1) Possui tempo fixo de 8 horas, divididos em duas partes:

 A primeira parte é dedicada à seleção do itens do Product
Backlog;
 A segunda, é dedicada à preparar o Sprint Backlog.
2) Participantes:
 ScrumMaster
 Product Owner
 Equipe Scrum
3) Outras pessoas podem participar apenas para fornecer
informações sobre aspectos técnicos do projeto. Assim
que estas informações forem fornecidas, elas serão
dispensadas da reunião.
4)©AlisonNão
Rabelo | deve haver algum chicken como observador.
twitter.com\alisonrabelo
25
5) O Product Owner deverá preparar o Product Backlog

antes da reunião.
6) Na ausência de ambos o Product Owner e Product
Backlog, o ScrumMaster deverá elaborar o Product
Backlog antes da reunião e fazer o trabalho do Product
Owner.
7) O objetivo da primeira parte (4 horas) é que a equipe do
projeto selecione os itens do Product Backlog que eles
acreditam que possam desenvolver no Sprint
8) A equipe pode fazer sugestões, mas a decisão de quais
itens do Product Backlog vão constituir o Sprint é de
responsabilidade do Product Owner.
9) A equipe é responsável por determinar a porção do

Product Backlog, escolhido pelo Product Owner, que
ela tentará desenvolver durante o Sprint.
10) A segunda parte da reunião é deve acontecer
imediatamente após a primeira parte e também
possui um tempo fixo de 4 horas.
11) O Product Owner deve ficar disponível para
responder questionamentos da equipe sobre o
Product Backlog durante a segunda parte.
26
12) A equipe é responsável por determinar como trabalhará

para desenvolver os requisitos selecionados do Product
Backlog em incrementos de funcionalidade de software.
Nesta atividade, a equipe não deverá sofrer interferências
de pessoas de fora da equipe.
13) O resultado da segunda parte da reunião é uma lista
chamada Sprint Backlog, que contém tarefas com suas
estimativas e atribuições.
14) A lista poderá não estar completa, mas deve estar pronta
o suficiente para refletir o comprometimento de todos os
membros da equipe com os requisitos selecionados pelo
Product Owner.
Sprint
1) Tempo fixo de 30 dias consecutivos.
2) O time pode procurar orientação, ajuda, informação e
suporte de pessoas externas durante o Sprint.
3) Ninguém pode dar conselhos, instruções ou direções
sobre as atividades da equipe durante o Sprint. A equipe
deve fazer a auto-gestão das suas atividades.
4) A equipe se compromete com o Product Backlog durante
a Sprint Planning Meeting. Ninguém possui permissão
para mudar o Sprint Backlog durante o Sprint. O escopo
estará “congelado” até o final do Sprint.
27
Sprint
5) Se provar-se que o Sprint não é viável, o ScrumMaster
pode encerrar o Sprint e iniciar uma nova Sprint Planning
Meeting de modo a iniciar um novo Sprint.
6) O ScrumMaster pode interromper o Sprint sem
consentimento das equipe ou do Product Owner ou à
pedido destes.
7) O Sprint pode se tornar inviável quando:
 A tecnologia utilizada no desenvolvimento provar-se não ser
capaz de atender os requisitos.
 As necessidades de negócio mudarem de maneira que o
requisitos desenvolvidos no Sprint não possuem mais valor para a
organização.
 O time recebe interferência externa durante o Sprint.
Sprint
8) Se a equipe se sentir impossibilitada de completar
todo o Sprint Backlog durante o Sprint, pode
consultar o Product Owner sobre quais itens remover
do Sprint em curso.
9) Se houver muitos itens a serem removidos de
maneira que o Sprint perca seu valor e significado no
projeto, o ScrumMaster pode terminar o Sprint.
10) Se a equipe identificar que pode desenvolver mais
requisitos do que os relacionados no Sprint Backlog,
ela poderá consultar o Product Owner para incluir
itens adicionais para o Sprint em curso.
28
Sprint
11) Os membros da equipe têm duas responsabilidades
administrativas durante o Sprint:
 Comparecer ao Daily Scrum Meeting.
 Manter o Sprint Backlog atualizado e visível para
todos.
Daily Scrum Meeting

1) Tempo fixo de 15 minutos.
2) Participantes: todos podem participar, mas os
chickens não podem interferir na reunião. Estes
devem participar apenas como ouvintes.
3) Deve ser feito no mesmo no horário e local, todos os
dias.
4) Recomenda-se realizar no inicio do dia de maneira
que a primeira coisa que os membros da equipe
façam é pensar no que fizeram no último dia de
trabalho e no que vão fazer hoje, ou seja, planejar as
atividades do dia.
29
Daily Scrum Meeting
5) Todos o membros da equipe devem participar.
6) Se alguém não puder comparecer pessoalmente, deve
participar por telefone ou pedir que alguém relate o
status da suas atividades no seu lugar.
7) O ScrumMaster deverá começar a reunião na hora
marcada, sem levar em conta que está presente.
8) Quem chegar atrasado na reunião deverá pagar um
dinheiro pra caixinha de fim de ano ao ScrumMaster
imediatamente.
Daily Scrum Meeting

9) O ScrumMaster começa a reunião conversando com
a pessoa posicionada à sua esquerda e depois
prossegue conversando com os outros membros
numa seqüência horária.
10) Cada membro deverá responder apenas a três
questões:
 O que você fez no projeto desde a última reunião
diária?
 O que você vai fazer no projeto até a próxima reunião
diária?
 O que impede você de realizar seu trabalho da
maneira mais eficiente possível?
30
Daily Scrum Meeting
11) Os membros da equipe devem manter o foco nas
respostas à aquelas três questões.
12) Devem ser evitados outros assuntos, como questões
técnicas, discussões sobre problemas, fofocas, etc.
13) Uma pessoa deve falar pode vez e relatar o status das
suas tarefas. Todos devem ouvi-lo. Não é permitido
conversas paralelas.
14) Se um membro de equipe relata algo de interesse de
outros ou alguns membros necessitam ajuda de
outros membros, estas questões deverão ser tratadas
após o final da reunião.
Sprint Review Meeting

1) Possui tempo fixo proposto de 4 horas.
2) O time não deve gastar mais que 1 hora se preparando
para a reunião.
3) O objetivo da revisão do Sprint é que a equipe apresente
ao Product Owner e às partes interessadas as
funcionalidades dos software que foram concluídas.
4) Embora o significado de “concluída” possa variar de uma
organização para outra, para o Scrum significa que a
funcionalidade foi completamente desenvolvida e poder
ser colocada em produção.
5) Funcionalidade que não foi concluída não poderá ser
apresentada.
31
6) Artefatos e documentação não devem ser apresentados, a
menos que sirvam para esclarecer o entendimento das
funcionalidades apresentadas.
7) Artefatos não devem ser mostrados como produtos de
trabalho e seu uso deve ser minimizado de forma a evitar
deixar confusas as partes interessadas ou a requerer que
eles entendam como o desenvolvimento de sistemas
funciona.
8) Funcionalidades devem ser apresentadas nos
computadores dos membros da equipe a partir do
servidor mais próximo da produção, usualmente um
servidor de QA (Quality Assurance)

9) A revisão do Sprint começa com a equipe
apresentando os objetivos do Sprint, todos os itens
do Sprint Backlog e os itens que foram concluídos.
10) Os membros da equipe podem então discutir o que
foi bem e que não foi bem no Sprint.
11) A maior parte da reunião é gasta com a equipe
apresentando as funcionalidades, respondendo
questões das partes interessadas relativas a
apresentação e anotando as mudanças desejadas.
32
12) No fim da apresentação, as partes interessadas são
consultadas, uma por uma, para dar as suas
impressões, seus desejos de mudança e a prioridade
dessas mudanças.
13) O Product Owner discute com as partes interessadas
e a equipe a reordenação do Product Backlog a partir
do feedback dado.
14) As partes interessadas são livres pra fazer quaisquer
comentários, observações e críticas a respeito dos
incrementos de funcionalidade do produto.

15) As partes interessadas podem identificar o que não
foi entregue ou que não foi entregue como esperado
e solicitar que tal funcionalidade seja colocada no
Product Backlog para priorização.
16) As partes interessadas podem identificar qualquer
nova funcionalidade não prevista e solicitar que esta
seja incluída no Product Backlog para receber uma
prioridade.
17) Ao final da reunião, o ScrumMaster anuncia o lugar e
a data da próxima revisão ao Product Owner e às
partes interessadas.
33
Sprint Retrospective Meeting
 Tem tempo fixo de 3 horas.
 Participantes:
 Equipe Scrum
 ScrumMaster
 Product Owner (opcional)
 A reunião começa com os participantes respondendo a
duas questões:
 O que foi bem no último Sprint?
 O que pode ser melhorado no próximo Sprint?
 O ScrumMaster anota as respostas dadas pelos
participantes em um formulário.
Sprint Retrospective Meeting

 O time realiza comentários sobre as respostas.
 O ScrumMaster não tem permissão para responder as
duas perguntas. Ele deve apenas ajudar o time na
busca por melhorias no trabalho com o processo
Scrum.
 Itens que podem ser adicionados no próximo Sprint
devem ser listados como requisitos não-funcionais de
alta prioridade no Product Backlog.
34

TreinamentoScrum v01r00

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TreinamentoScrum v01r00

Uploaded by

Copyright:

Available Formats

©Alison Rabelo | twitter.

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

Problemas Típicos dos Projetos

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

Métodos Ágeis de Desenvolvimento de

©Alison Rabelo | twitter.com\alisonrabelo

Métodos Clássicos (PMBOK) Métodos Ágeis

©Alison Rabelo | twitter.com\alisonrabelo

Métodos Ágeis de Desenvolvimento de

©Alison Rabelo | twitter.com\alisonrabelo

“Nós estamos descobrindo melhores maneiras para desenvolver software,

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

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

Gerenciamento Ágil de Projetos

Planejamento a cada iteração

Planejamento Controle contínuo

Início Iteração 1 Iteração 2 Iteração 3 Iteração 4 Encerramento

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

Gerenciamento Ágil de Projetos

Gerenciamento Ágil de Projetos

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

Vantagens de ser ágil

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

Visão geral do processo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

Sprint Burndown Chart

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

©Alison Rabelo | twitter.com\alisonrabelo

Sprint Planning Meeting

1) Possui tempo fixo de 8 horas, divididos em duas partes:

5) O Product Owner deverá preparar o Product Backlog

Sprint Planning Meeting

9) A equipe é responsável por determinar a porção do

©Alison Rabelo | twitter.com\alisonrabelo

12) A equipe é responsável por determinar como trabalhará