TreinamentoScrum v01r00

Gerenciamento Ágil de
Projetos com Scrum

Vinic Gestão & Projetos
2007
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
© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br
1
Gerenciamento de Projetos
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.
Projetos de Desenvolvimento
de Software
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áticas de gerenciamento
de projetos. Apenas 34% dos projetos de
desenvolvimento de software
foram bem-sucedidos em
2002 (Standish Group)
Métodos Ágeis de
Desenvolvimento de
Software
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
Métodos Ágeis de
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
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
Métodos Ágeis de
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
Métodos Ágeis de
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”.
Projetos
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
Scrum
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.
Regras do Scrum
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) Não deve haver algum chicken como observador.
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
Projetos com Scrum
2007 © Vinic Gestão & Projetos
http://www.vinic.com.br
contato@vinic.com.br
Exercício
Parte 01 (30 min) :
- Dividir a equipe em dois grupos; Grupo Cliente e
Executor
- O Grupo de Clientes deve especificar 10 itens
necessários para se abrir um empreendimento. Vale
salientar que o grupo irá terceirizar todo o trabalho com
uma equipe externa.
• Loja de confecção; Autopeças ou Sorveteria
• Deve ser considerado todo o trabalho de reforma de um local,
financiamento para compra de estoque, reforma e capital inicial;
- O prazo para inauguração da loja é 90 dias
- Anotar os itens no “flip-chart”
35
Exercício
Parte 02 (60min):
- O grupo CLIENTE irá apresentar o Backlog de produto
para o grupo EXECUTOR realizar o trabalho de estimativa
e apresentação do sprint backlog. Nesta atividade a
equipe deverá tirar todas as dúvidas necessárias e
estimar o tamanho das atividades (empírico);
- O grupo EXECUTOR irá discutir a priorização com um
representante do grupo Cliente;
- Deve ser utilizado o esforço máximo de 160 horas por
mês par ao sprint, que será realizado por uma pessoa
somente;
36

TreinamentoScrum v01r00

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TreinamentoScrum v01r00

Enviado por

Direitos autorais:

Formatos disponíveis

Gerenciamento Ágil de

Projetos com Scrum

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

“Cerca de 2 milhões de pessoas estão

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Problemas Típicos dos Projetos

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

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

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

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

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

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

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

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Gerenciamento Ágil de Projetos

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Gerenciamento Ágil de Projetos

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Vantagens de ser ágil

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Visão geral do processo Scrum

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Sprint Burndown Chart

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Sprint Planning Meeting

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Sprint Planning Meeting

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

Daily Scrum Meeting

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br

© Vinic Gestão & Projetos | www.vinic.com.br | contato@vinic.com.br