Upload
phamkhanh
View
222
Download
2
Embed Size (px)
Citation preview
“um framework para desenvolver produtos
complexos em ambientes complexos”
Rafael Sabbagh, CSM, CSP
Marcos Garrido, CSPO
Um pouco de história...
• Década de 50: a gestão de projetos é reconhecida
como disciplina, nascida a partir da administração
• Henri Fayol:
– Seu trabalho é a base para a gestão de projetos
tradicional
– O gestor possui 5 funções básicas:
• O gráfico de Gantt é adotado como ferramenta para
listar, acompanhar e controlar a execução das tarefas
contidas em um projeto.
Planejar Organizar Comandar Controlar Coordenar
Um pouco de história...
• Até então a gestão de projetos é voltada para grandes projetos de engenharia e construção civil.
• Década de 60: o desenvolvimento de software começa a ganhar complexidade.
• Para gerenciar projetos de software, as empresas utilizam a medotologia tradicional antes aplicada a projetos de engenharia e construção civil.
• Winston Royce (1970): artigo criticando aabordagem tradicional para a gestão de projetos de software, que fica conhecida como waterfall.
Um pouco de história...
• Waterfall, por Winston Royce (1970)
Um pouco de história...
Um pouco de história...
• Waterfall segue o conceito Big Design Up Front (BDUF).
• Os defensores do BDUF acreditam que o tempo gasto revisando exaustivamente a especificação garante a ausência de mudanças críticas na fase de execução.
• McConnell (1996): “corrigir erros ainda na fase de especificação gasta entre 50 e 200 vezes menos tempo do que se o erro fosse encontrado durante a execução do projeto”.
Um pouco de história...
• DeGrace & Stahl (1990): Fatores que tornam questionável o uso de BDUF para projetos de software:
– Requisitos não são completamente compreendidos no
início do projeto;
– Usuários só sabem exatamente o que querem após ver
uma versão inicial do software;
– Requisitos mudam durante o processo de
desenvolvimento;
– Novas ferramentas e tecnologias tornam a estratégia
de desenvolvimento imprevisível.
• BDUF é considerado adequado apenas para projetos estáveis, com pouca ou nenhuma mudança.
Um pouco de história...
• Recente pesquisa no Brasil com gerentes de projeto aponta a mudança de escopo(71%) como o fator principal para insucesso em projetos de software.
• Meredith & Mantel: “problemas de comunicação e entendimento do que deve ser feito são responsáveis por falhas nos projetos”.
• Metodologias tradicionais sugerem que:
– Mudanças devem ser evitadas a todo custo.
– Se não for possível evitá-las, o gerente de projetos deve gerenciá-las.
• Para as metodologias tradicionais, a mudança tem um efeito devastador
Um pouco de história...
Um pouco de história...
• Ken Schwaber (2007):
• Não há mais soluções simples de software.
• Quando requisitos complexos encontram tecnologias complexas, a complexidade da solução cresce exponencialmente.
Um pouco de história...
Um pouco de história...
Fonte: Standish Group
Agilidade
Manifesto Ágil
"Estamos descobrindo maneiras melhores de desenvolver software fazendo-
o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho,
passamos a valorizar:
Indivíduos e interação entre eles 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."
2001 - representantes de processos leves de
desenvolvimento de software se reuniram para discutirem o
que seus processos possuíam em comum.
O resultado foi o Manifesto Ágil:
Princípios Ágeis
• Satisfação do cliente através da entrega rápida e frequente de produto funcional
• Produto funcional é a principal medida de progresso do projeto
• Mudanças são vistas como parte natural do processo e são bem-vindas
• Cooperação diária entre a equipe de projeto e o pessoal de negócios
• Comunicação aberta dentro da equipe
Princípios Ágeis
• Equipe de pessoas motivadas, com o suporte necessário e confiança
• Atenção contínua para o bom design e excelência técnica
• Simplicidade. Nada de desperdícios!
• Equipes autogerenciadas: Empowerment!
• Foco maior nas pessoas do que nos processos
• Melhoria contínua
Aplicação
Métodos Ágeis não servem apenas para desenvolvimento de software!
Aplicação
Métodos ágeis podem ser utilizados em projetos em que há:
- Ambiente de mudanças frequentes- Requisitos
- Tecnologia
- Leis e regras
- Ambiente de incertezas
- Necessidade de entrar rapidamenteno mercado- Oportunidades
- Responder a uma ameaça
Aplicação
Exemplos:
• Alexandre Magno (CST): Scrum
Executivo – mudança organizacional
• Projetos de Marketing
• Projetos de Hardware
• Infra-estrutura
• Jogos olímpicos, Copa do mundo…
O que é Scrum?
Scrum...
• ...é um framework para desenvolvimento de produtos complexos em ambientes complexos;
• ...não é um processo ou técnica: dentro de Scrum podem-se empregar diversos processos e técnicas;
• ...utiliza abordagem iterativa e incremental para melhorar a predizibilidade e o controle de riscos;
• ...gera entrega frequente de valor para o cliente;
• ...torna transparentes problemas das práticas de desenvolvimento, para que se possa melhorá-las;
• ...utiliza inspeção e adaptação para melhoria contínua, em ciclos de feedback.
Scrum: Origens
• Ken Schwaber: www.controlchaos.com
• Jeff Suttherland: jeffsutherland.com
• Mike Beedle: www.mikebeedle.com
• “The New New Product Development
Game”, de Takeuchi e Nonaka
• Sistema de Produção da Toyota: modelo
enxuto e just-in-time
Processos Definidos X Empíricos
• Processo definido
– Ambientes controlados – ex: linhas de produção
• Processo empírico:
– Complexos e imprevisíveis
• Scrum é embasado na teoria de controle de
processos empíricos
• Três pilares sustentam a teoria de controle
de processos empíricos: Transparência,
Inspeção e Adaptação
Pilares
Os Pilares do Scrum
• #1: Transparência
– Aspectos que afetam o resultado do
projeto devem ser visíveis para os
que gerenciam estes resultados
– O que é visto deve ser compreendido:
se quem inspeciona o processo
acredita que está pronto, isso deve
corresponder à definição de pronto
utilizada
Os Pilares do Scrum
• #2: Inspeção
– Deve haver inspeção no processo
com frequência suficiente para se
detectar variações inaceitáveis
Os Pilares do Scrum
• #3: Adaptação
– Ao se detectar variações
inaceitáveis, o processo deverá ser
ajustado o tão rápido quanto
possível para se minimizar desvios
ainda maiores
Introdução ao
Ciclo do Scrum
O Ciclo do Scrum
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
O representante do cliente, o PRODUCT
OWNER, levanta com o cliente requisitos
mais prioritários no momento
Ele então insere estes requisitos
em uma lista priorizada, chamada
BACKLOG DO PRODUTO
A equipe então se reúne com o
representante do cliente e decide, a partir
dessa lista de requisitos, o que será feito
no próximo ciclo de desenvolvimento:
o BACKLOG DA SPRINT
A equipe faz o trabalho no ciclo de
desenvolvimento, chamado de SPRINTEm cada dia, a equipe faz uma reunião de
15 minutos para promover visibilidade e
comunicação
Ao final do ciclo de desenvolvimento, a
equipe terá produzido um incremento no
produto, que significa valor para o cliente
A equipe então se reúne com o
representante do cliente na REUNIÃO DE
REVISÃO e apresenta o que foi feito
E, em seguida, se reúne para a
RETROSPECTIVA, onde verifica o que
funcionou bem e o que pode melhorar no
próximo ciclo de desenvolvimento
Papéis
Papéis no Scrum
• ScrumMaster:
– responsável por garantir que o processo
é entendido e seguido
• Product Owner:
– responsável por maximizar o valor, para
o cliente, do trabalho que o Time de
Scrum faz
• Time de Scrum:
– é a equipe, que faz o trabalho
propriamente dito
Papéis no Scrum: O ScrumMaster
• Garante a adesão do time aos valores do Scrum, práticas e regras
• Ajuda o Time de Scrum e a organização a adotarem o Scrum
• Remove os impedimentos que atrapalham o trabalho do Time de Scrum
• Ajuda o Time de Scrum a usar o auto-gerenciamento e a multidisciplinaridade, a ser mais produtivo e a ter mais qualidade
• O ScrumMaster não gerencia o Time de Scrum: o Time de Scrum é auto-organizável
Papéis no Scrum: O Product Owner
• Gerencia a lista de requisitos (Backlog do Produto) através do contato frequente com o(s) cliente(s), e garantir sua visibilidade a todos
• Assegura o valor do trabalho realizado pelo Time de Scrum: garante o ROI do cliente
• Gerencia a visão do produto: estabelece, mantém e comunica
• Gerencia as entregas do produto para o cliente
• É sempre uma pessoa, e não um comitê. Mas pode ser aconselhado/influenciado por outras pessoas
• Suas decisões devem ser respeitadas: ninguém mais pode mudar as prioridades
Papéis no Scrum: O Time de Scrum
• É a equipe de desenvolvimento do projeto, com 5 a 9 membros, que:
• Transformam a lista de requisitos (Backlog do Produto) em incrementos de funcionalidades potencialmente entregáveis em cada iteração
• São multidisciplinares: todo conhecimento necessário para gerar o incremento
• Não há títulos no Time de Scrum
• Gerenciam a iteração de desenvolvimento
• São auto-organizáveis: ninguém diz ao Time de Scrum como transformar o Backlog do Produto em incrementos entregáveis.
O Ciclo do
Scrum
Backlog do Produto
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Product Owner levanta com o(s)
cliente(s) os requisitos mais prioritários
naquele momento
Backlog do Produto
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Product Owner levanta com o(s)
cliente(s) os requisitos mais prioritários
naquele momento
O Product Owner insere estes
requisitos no BACKLOG DO
PRODUTO
O que é o Backlog do Produto?
• É uma lista incompleta e dinâmica dos requisitos do produto, ordenados por prioridade de desenvolvimento
• A prioridade é determinada por: valor que gerará ao cliente naquele momento, risco e necessidade
• Contém funcionalidades, correções de bugs, tecnologias e melhorias que constituem a mudança que será implementada no produto
• O Product Owner é o responsável por atualizar, priorizar e dar visibilidade ao Backlog do Produto
• Nunca está completo – evolui à medida que o produto e o ambiente evoluem
• Seus itens possuem descrição e estimativa em pontos de esforço. Itens do alto da lista são de menor granularidade e mais detalhados
O que é o Backlog do Produto?
• É uma lista incompleta e dinâmica dos requisitos do produto, ordenados por prioridade de desenvolvimento
• A prioridade é determinada por: valor que gerará ao cliente naquele momento, risco e necessidade
• Contém funcionalidades, correções de bugs, tecnologias e melhorias que constituem a mudança que será implementada no produto
• O Product Owner é o responsável por atualizar, priorizar e dar visibilidade ao Backlog do Produto
• Nunca está completo – evolui à medida que o produto e o ambiente evoluem
• Seus itens possuem descrição e estimativa em pontos de esforço. Itens do alto da lista são de menor granularidade e mais detalhados
Reunião de Planejamento da Sprint
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Time de Scrum então se reúne com o
Product Owner e decide, a partir do
Backlog do Produto, o que será feito no
próximo ciclo de desenvolvimento:
o BACKLOG DA SPRINT
O que é a Reunião de Planejamento da Sprint?
• Planejamento da iteração:– Time de Scrum e Product Owner defininem que
itens do Backlog do Produto serão implementados na Sprint e os quebram em tarefas - Backlog da Sprint
• 1a. Parte: O quê?– Escolha de itens mais prioritários do Backlog do
Produto a serem implementados
– Definição da Meta da Sprint
• 1a. Parte: Como?– Time de Scrum quebra itens em tarefas e estima
o tempo que levará para realizar cada tarefa
O que é o Backlog da Sprint?
• Composto por uma lista dos itens que serão desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas
• Os itens são selecionados do Backlog do Produto na Reunião de Planejamento da Sprint
• Cada item é quebrado em tarefas. Parte das tarefas é definida no Planejamento da Sprint, parte ao longo do Sprint
• O Backlog da Sprint é modificado ao longo da Sprint –estimativas são atualizadas, tarefas podem surgir para os itens já existentes
• Deve ter alta visibilidade
• Pertence ao Time de Scrum
O que é o Backlog da Sprint?
• Composto por uma lista dos itens que serão desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas
• Os itens são selecionados do Backlog do Produto na Reunião de Planejamento da Sprint
• Cada item é quebrado em tarefas. Parte das tarefas é definida no Planejamento da Sprint, parte ao longo do Sprint
• O Backlog da Sprint é modificado ao longo da Sprint –estimativas são atualizadas, tarefas podem surgir para os itens já existentes
• Deve ter alta visibilidade
• Pertence ao Time de Scrum
A Sprint
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Time de Scrum faz o trabalho no ciclo
de desenvolvimento, a SPRINT
O que é a Sprint? (1/2)
• Sprint é a iteração (ciclo) de desenvolvimento– Reunião de Planejamento da Sprint
– Trabalho de Desenvolvimento
– Revisão e Retrospectiva da Sprint
• Cada Sprint deve ter uma Meta
• Tem duração fixa (de 2 semanas a 1 mês) e ocorrem uma atrás da outra– Duração deve contemplar horizonte curto suficiente
para que mudanças não alterem a Meta
• ScrumMaster deve assegurar que não seja feita nenhuma mudança que afete a Meta da Sprint
O que é a Sprint? (2/2)
• Cada Sprint deve ter como saída um
incremento do produto
potencialmente entregável
• A Sprint pode ser cancelada se a
Meta da Sprint perder o sentido –
somente Product Owner pode decidir
• É muito raro a Sprint ser cancelada
A Reunião Diária
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
Em cada dia, o Time de Scrum faz uma
reunião de 15 minutos para promover
visibilidade e comunicação
O que é a Reunião Diária?
• Reunião de 15 minutos realizada todo dia no mesmo local, à mesma hora. – Visibilidade
– Comunicação
– Decisão rápida
• Cada membro do Time de Scrum detalha:
– O que ele completou desde a última reunião diária;
– O que ele vai fazer antes da próxima reunião diária;
– Quais obstáculos estão em seu caminho.
• O ScrumMaster deve remover os obstáculos encontrados
• O gráfico de BURNDOWN deve ser atualizado!
O que é o Burndown da Sprint?
• É um gráfico que mostra a soma dos tempos estimados restantes das tarefas da Sprint pelo tempo
– Y: tempos estimados restantes
– X: dias da Sprint
• Serve para acompanhar o progresso em direção ao final de um sprint
• É feito inicialmente no Planejamento da Sprint e deve ser atualizado a cada dia da Sprint
O que é o Burndown da Sprint?
• É um gráfico que mostra a soma dos tempos estimados restantes das tarefas da Sprint pelo tempo
– Y: tempos estimados restantes
– X: dias da Sprint
• Serve para acompanhar o progresso em direção ao final de um sprint
• É feito inicialmente no Planejamento da Sprint e deve ser atualizado a cada dia da Sprint
Incremento no Produto
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
Ao final da Sprint, o Time de Scrum terá
produzido um incremento PRONTO no
produto, que significa valor para o cliente
O que significa Pronto?
• Ao final da Sprint, o trabalho desenvolvido deve estar pronto
• Mas o que significa “pronto”?
• O Time de Scrum e o Product Owner devem definir o que significa “pronto”
• Quando alguém diz que algo está “pronto”, todos devem entender o que isso significa
• Ex. de software: codificado, testado e documentado
A Reunião de Revisão da Sprint
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Time de Scrum então se reúne com o
Product Owner e apresenta o que foi feito
na REUNIÃO DE REVISÃO DA SPRINT
O que é a Revisão da Sprint?
• Reunião onde o Time mostra aos
stakeholders o que foi feito durante a Sprint:
– Product Owner presente
• Time de Scrum demonstra o que fez e
responde a perguntas
• Product Owner verifica o que foi e o que não
foi feito na Sprint
• Deve prover entradas para a Reunião de
Planejamento de Sprint seguinte
A Reunião de Retrospectiva
BACKLOG DO
PRODUTO
BACKLOG DA SPRINT
REUNIÃO DIÁRIA
INCREMENTO DO PRODUTO
POTENCIALMENTENTREGÁVEL
2-4 SEMANAS
24 HORAS
E, em seguida, o Time de Scrum se reúne
para a RETROSPECTIVA, onde verifica o
que funcionou bem e o que pode melhorar
na próxima Sprint
O que é a Retrospectiva da Sprint?
• Reunião para inspecionar como correu a
Sprint com relação às pessoas,
relacionamentos, processos e ferramentas:
– Product Owner não deve estar presente
• Identificar e priorizar:
– O que foi bem?
– O que pode melhorar?
• Identificar ações para melhorias - adaptação
E o ciclo recomeça...
BACKLOG DO
PRODUTO
2-4 SEMANAS
Scrumvs.
Métodos Tradicionais
Desperdício
Metodologias não-ágeis afirmam que devem ser gerados
inúmeros documentos para o sucesso do projeto
Termo de
Abertura
Declaração
Preliminar
de Escopo
Plano de
Gerenciamento
do Projeto
Pedidos de
Mudança
Relatório de
Progresso
Relatório de
Desempenho
Relatório de
Aceite
Relatório de
Encerramento
Cronograma
Detalhado
Análise de
Earned Value
Documento de
Lições
Aprendidas
Diagramas de
SequênciaDiagrama de
Componentes
Diagrama de
Colaboração
Diagrama
de Estados
Diagrama de
Casos de Uso
Diagrama
de Pacotes
Diagrama de
Atividades
...algo
mais?
Desperdício
Metodologias não-ágeis afirmam que devem ser gerados
inúmeros documentos para o sucesso do projeto
Termo de
Abertura
Declaração
Preliminar
de Escopo
Plano de
Gerenciamento
do Projeto
Pedidos de
Mudança
Relatório de
Progresso
Relatório de
Desempenho
Relatório de
Aceite
Relatório de
Encerramento
Cronograma
Detalhado
Análise de
Earned Value
Documento de
Lições
Aprendidas
Diagramas de
SequênciaDiagrama de
Componentes
Diagrama de
Colaboração
Diagrama
de Estados
Diagrama de
Casos de Uso
Diagrama
de Pacotes
Diagrama de
Atividades
...algo
mais?
O custo de produção e manutenção
destes documentos compensa?
Quantos destes documentos se
manterão atualizados?
Quantos serão realmente úteis para o
desenvolvimento do projeto?
Desperdício
Fonte: Standish Group CHAOS Report
Em projetos típicos, 50% do tempo é gasto
com requisitos, arquitetura e especificação
Análise de Requisitos Especificação / Arquitetura Implementação Testes Manutenção
e isso tudo é feito antes de se
construir qualquer funcionalidade!
Desperdício
Fonte: Standish Group CHAOS Report
• 35% dos requisitos mudam
• 65% das funcionalidades nunca ou
raramente serão utilizadas
Em projetos típicos, 50% do tempo é gasto
com requisitos, arquitetura e especificação
Análise de Requisitos Especificação / Arquitetura Implementação Testes Manutenção
e para
piorar...
Desperdício
Afinal, o objetivo do projeto é o
produto, e não a documentação!
Com Scrum, o projeto deve ter somente a
documentação suficiente e necessária.
Ou seja, adote somente o que será usado.
Desperdício
Com Scrum, o Product Backlog é
dinâmico, pois ele deve sempre
acompanhar as necessidades do cliente, que
mudam ao longo do projeto.
Assim, o que for entregue, deverá ser usado pelo cliente.
Sempre serão feitas as funcionalidades que
são de maior importância para o cliente no
momento anterior ao início de cada sprint.
Maior Valor Primeiro
Em metodologias não-
ágeis, o cliente só percebe
retorno ao investimento no
final do projeto.
Entrega
Maior Valor Primeiro
No Scrum, O Product
Owner deve sempre
alimentar e reordenar o
Product Backlog,
priorizando os itens de
maior valor para o cliente.
Assim, Scrum garante que
os itens de maior valorsejam entregues primeiro,
gerando ROI para o
cliente frequentemente.
Maior Valor Primeiro
• A priorização do Product Backlog pelo maior
valor permite à organização:
– entregar resultados para seu cliente mais
rápido que a concorrência
– colocar em produção funcionalidades que
agregam maior valor a seu negócio mais
rapidamente
– lançar produtos e novas versões no mercado
mais rapidamente
Mudanças Frequentes
Como as metodologias tradicionais lidam
com a mudança?
Mudança é
indesejada!
Mudança é
arriscada!
Mudança é
cara!
Mudança
deve ser
negociada!
Como quase todo o planejamento é feito
no começo do projeto, há pouquíssimo
espaço para mudanças!
Mudanças Frequentes
Como as metodologias tradicionais lidam
com a mudança?
O contrato com escopo amarrado deve nos
defender! O cliente vai querer mudar tudo!
Cada mudança deve ser negociada com o
cliente! Seu impacto deve ser quantificado!
Cada mudança deve ser revista, aprovada,
planejada, documentada e gerenciada!
Mudanças Frequentes
Gerenciamento da mudança é fonte de
estresse em projetos que utilizam
metodologias não-ágeis.
Estresse no relacionamento de longo
prazo com o cliente.
Estresse no dia-a-dia da equipe de
desenvolvimento.
Mudanças Frequentes
Como o Scrum lida com a mudança?
Scrum encara a mudança como parte naturaldo processo de desenvolvimento
Manifesto ágil: “responder às mudançasmais que seguir um plano”
Mudanças Frequentes
Como o Scrum lida com a mudança?
...e assim, mudanças já podem ser
introduzidas no produto na sprint seguinte!
A resposta rápida à mudança pode se
transformar em vantagem competitiva!
O Product Backlog é constantemente
atualizado pelo Product Owner...
Comunicação
O cliente percebe o projeto como
uma grande caixa preta, cujo
conteúdo será revelado apenas no
final do processo
Em um projeto waterfall, quando o cliente
é encorajado a participar?
Análise de Requisitos Especificação / Arquitetura Implementação ManutençãoTestes
Testes de Aceitação
Comunicação
Assim, ao final do
projeto, o resultado
dificilmente atenderá às
necessidades do cliente
naquele momento!
Comunicação
Como o Scrum lida com a comunicação?
O Product Owner está em frequente
contato com o cliente para
levantar suas necessidades...
...e assim manter o Product Backlog
constantemente atualizado e
priorizado.
Comunicação
Como o Scrum lida com a comunicação?
O cliente recebe frequentemente
novas versões...
...e assim pode mais rapidamente
dar feedback para a equipe, via
Product Owner.
Comunicação
Como o Scrum lida com a comunicação?
Desta forma, o cliente se sente
envolvido em todo o processo...
...compartilhando com a equipe a
responsabilidade sobre o projeto...
...aumentando seu grau de
confiança na equipe e no processo.
Comunicação
A relação com o cliente deixa de ser
meramente comercial, e passa a contemplar:
Parceria Cumplicidade Satisfação Fidelidade
E assim, cria-se uma relação de longo
prazo com o cliente.
Comunicação
Em metodologias não-ágeis, como se
promove a visibilidade no projeto
para seus stakeholders?
de Estados
Principalmente através de documentação...
...que dá
muito
trabalho
...que não é
eficiente
...que não
se mantém
atualizada
...que acaba
deixada de
lado
Comunicação
No Scrum, a visibilidade no projeto é
constantemente promovida!
Reuniões
diáriasKanban
Equipe em
um mesmo
ambiente
Envolvimento
do cliente
Gráficos de
Burndown
Entregas
frequentes
Reunião de
Revisão
Retros-
pectiva
...são alguns exemplos.
Comunicação
Manter comunicação aberta entre os
stakeholders do projeto é a melhor forma de
garantir que todos saibam o que deve ser
feito e o que está sendo feito.
Isso gera aumento de
produtividade!
Scrum na Petrobras
Case de Sucesso
Material para estudo
• Acesse: http://public.me.com/mgarridobr
• Material Disponível:
– Esta apresentação
– Guia do Scrum em Português
– Artigo sobre waterfall de Winston Royce
– Artigo “The New New Product Development
Game”, de Takeuchi e Nonaka
– CHAOS Report
– Scrum Executivo, por Alexandre Magno
– PPT: Por que Scrum é a melhor opção em
tempos de crise
• Material ficará disponível para download
durante a semana.