1.
Quando a comunicação passa sucessivamente por mais pessoas, o número de falhas
na transmissão da mensagem aumenta na mesma proporção

2.
Quantidade, não traz qualidade

3.
• Apenas 74% dos projetos não são terminados nas condições
planejadas;
• 46% dos projetos sofrem alterações de prazo, escopo e orçamento
para poder continuar a existir;
• 20% dos projetos falham e não são entregues;
• Apenas 1 a cada 5 projetos conquista satisfação aceitável dos
usuários;
• 51% das implantações de software fracassam como solução;
• Um projeto já nasce com mais chance de dar errado do que certo;
• 61% dos usuários de sistemas se dizem frustrados em suas
expectativas em relação à funcionalidade do software

4.
Frequentemente
13%
Às vezes
Sempre 16%
7%
Raramente
19%
Nunca
45%

5.
80% das funcionalidades não são relevantes para o software produzido
Às vezes
16%
Raramente
19%
Nunca
45%

6.
Apenas 20% das funcionalidades produzidas realmente importam
Frequentemente
13%
Sempre
7%

7.
• A metodologia ágil vem sendo cada
vez mais aceita
• Esclarece para todos, que erros
acontecem, porém, nessa metodologia
eles serão revistos antes da entrega do
produto, para que lhe atenda
completamente.
• Ótima alternativa para, pois são mais fáceis de implantar e de
ter seus conceitos disseminados por toda a equipe
• Mais Indivíduos e iteração do que processos e ferramentas
• Mais software em funcionamento do que documentação
• Mais colaboração com o cliente do que negociação de contratos
• Mais respostas a mudanças do que seguir um plano fixo

8.
Modelo iterativo e incremental

9.
Mudar ?
Problema ou Oportunidade

10.
Extreme
Programming
O XP está sempre tentando fazer somente o que importa !

11.
• Todos participam do projeto
• O cliente e a equipe de desenvolvimento devem estar sempre
juntos, conduzindo de forma que seja gerado o que ele espera.
• O cliente não pode de forma alguma se separar ao longo do projeto.

12.
Desafio
Um dos maiores desafios
do XP, é que o cliente
dificilmente terá muito
tempo disponível para
estar junto com a equipe
de desenvolvimento, e ele
é essencial.
Para se fazer software bom, 95%
do foco não é em coisas que tem
haver com tecnologia e sim com
a parte pessoal.

13.
• Sem modelo cascata
• Cliente e equipe planejam prazo para entrega de
releases.
• Tempo para entrega não tem um valor de dias
específico.

14.
Release - 4 Semanas
Release 1 Release 2 Release 3 Release 4
Iteração - 1 Semana
I1 I2 I3 I4 I5 I6

15.
Iteração – Ciclo semanal
Jogo do Planejamento

16.
Iteração – Ciclo semanal
Cliente escreve estórias

17.
Iteração – Ciclo semanal
Desenvolvedores estimam

18.
Iteração – Ciclo semanal
Cliente prioriza

19.
Iteração – Ciclo semanal
Quadro de funcionalidades

20.
Iteração – Ciclo semanal
Reunião diária

21.
Iteração – Ciclo semanal
Cronograma

22.
Iteração – Ciclo semanal
Desenvolvimento da aplicação (em par)

23.
Iteração – Ciclo semanal
Acompanhamento do cliente

24.
Iteração – Ciclo semanal
Funcionalidades terminam

25.
Iteração – Ciclo semanal
Encerramento da iteração

26.
Iteração – Ciclo semanal
Retrospectiva da iteração

27.
Iteração – Ciclo semanal
Inicia nova iteração

28.
Cliente sempre pode ver retorno ao seu investimento

29.
Scrum
Todos estão alinhados e ‘atacam’ ao mesmo tempo!

30.
Papéis no Scrum
• O Scrum possui papéis bem definidos
• Papéis são diferentes de cargos

31.
Papéis no Scrum
Product Owner
• Define a visão do produto, esta visão vai nos dizer o que ele realmente quer
• Somente ele pode cancelar a sprint, não importando se por influência de alguém
• É responsável por garantir o retorno de investimento
• É responsável por conhecer as necessidades dos clientes
• Define os requisitos do produto, a data de release e o que será apresentado
• Pode alterar os requisitos e prioridades a cada Sprint
• Valida o resultado de cada Sprint

32.
Papéis no Scrum
Scrum Master
• O Scrum Master deve garantir que não haverá mudanças que possam afetar a meta da sprint
• Deve manter o time protegido de interferências externas
• Garante que o time esteja totalmente funcional e produtivo
• Garante que o processo esteja seguindo da forma esperada

33.
Papéis no Scrum
Time Scrum
• Multidisciplinar
• Auto organizado, o time e o trabalho entre os membros e organizado de forma participativa
• Estima as estórias
• Produz produto com qualidade e valor para o cliente
• Responsável pelo cumprimento das atividades do Sprint.

34.
Processo Sprint

35.
Processo Sprint
Product Backlog
• É o coração do Scrum
• Lista inicial de requisitos criada pelo Product Owner, com tudo que precisa ser
produzido para que a visão do produto seja alcançada
• Fornece valor do negócio ao cliente
• Manter as funcionalidades a serem implementadas pelo Time Scrum
• Dinâmico, tem sempre novos itens, e evolui à medida que o produto se desenvolve

36.
Processo Sprint
Reunião de planejamento
• Todos participam (Product Owner, Scrum Master e Scrum Team)
• Define se a prioridade dos requisitos e quais o Scrum Team se julga capaz de
implementar durante esse sprint
• Define o objetivo da Sprint
• Montando assim o Sprint Backlog

37.
Processo Sprint
Sprint Backlog
• Lista contendo apenas os requisitos que serão a serem executados nesse sprint
• Evolui de acordo com o trabalho do Scrum Team nesse sprint
• As atividades que entram na sprint, são “congeladas” no Product Backlog

38.
Processo Sprint
Sprint
• O produto é de fato desenvolvido
• O Scrum Team se dedica a produzir e entregar incrementos funcionais do produto

39.
Processo Sprint
Daily Meeting (Reunião diária)
• Diariamente se faz uma reunião, com média de 15 minutos, com todos em pé
• Através dela o Time Scrum ganha visibilidade do andamento do processo
• São respondidas as 3 questões de extrema importância para o projeto:
• O que você fez desde a última reunião de equipe até este momento?
• Que obstáculos você esta enfrentando?
• O que você planeja fazer até a próxima reunião?
• Nessa reunião se descobre os problemas antes mesmo que haja perca de tempo
• As respostas não são relatórios e sim compromisso com os seus pares.

40.
Processo Sprint
Sprint Review Meeting (Reunião de revisão)
• Todos participam (Product Owner, Scrum Master e Scrum Team)
• Entrega-se o incremento de software definido na sprint Backlog, para que o cliente
possa avaliar e validar a nova funcionalidade implementada.
• A funcionalidade não precisa estar totalmente finalizada neste processo, mas sim ter
todas as funções que foram estabelecidas para este sprint.

41.
Processo Sprint
Incremento do produto
• Ao final de cada sprint cria-se um incremento do produto, assim o produto irá
ficando pronto de acordo com a prioridade definida ainda no Product Backlog.
• Quando já tiverem sido criados incrementos suficientes para que o produto tenha
valor e uso para seus investidores, o produto então é entregue.

42.
Processo Sprint
Sprint Retrospective
• Todos participam (Product Owner, Scrum Master e Scrum Team)
• Acontece ao final de um sprint
• Mostra resultados visíveis de tudo que foi feito, mostrando o que funcionou como
esperado, o que ainda pode melhorar e o que será feito para se alcançar tal melhora.
• Somente após a Sprint Retrospective a equipe parte para o início da próxima Sprint

43.
Processo Sprint
Burndown Chart
É um gráfico atualizado a cada Daily Scrum, projetando a conclusão das tarefas do
Sprint Backlog, uma forma simples e clara de representar o ritmo do desenvolvimento

44.
Semelhanças entre
Extreme Programming e Scrum
Extreme Programming e Scrum
Cliente e equipe planejam prazo para entrega de releases
Não se usa modelo cascata
Faz uso do planejamento iterativo e incremental
Equipe auto-organizável
No contrato se deixa o escopo solto, deixando claro que este pode ser facilmente alterado
Ao final das iterações se faz retrospectiva, para avaliar melhorias
Se faz uso da programação em par
maximizar a quantidade de trabalho que não precisou ser feito
entrega adiantada e contínua de software de valor
Iterações são curtas
Usa a refatoração, para deixar o código sempre mais claro, sem alterar a funcionalidade

45.
Diferenças entre
Extreme Programming e Scrum
Extreme Programming Scrum
Visa um rápido desenvolvimento Visa gestão e planejamento
O cliente não pode se afastar do projeto em o Product Owner representa o cliente e
nenhum momento stakeholders
Não há especificação de papéis Os papéis são claramente definidos
Nenhuma permissão é dada em nível de Product Owner e Scrum Master tem
hierarquia privilégios em relação ao Scrum Team
Se descobre problemas com testes e Descobre problemas principalmente por
acompanhamento contínuo meio da reunião diária, de acordo com
perguntas
Prima pela adaptabilidade, ouvindo sempre O Product Owner toma as decisões do
o que o cliente tem a dizer cliente