O documento discute os desafios de projetos de software e as vantagens das metodologias ágeis como Scrum e Extreme Programming. Menciona que apenas 20% dos projetos de software entregam valor real para os usuários e que as metodologias ágeis permitem entregas frequentes com feedback do cliente.

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