Extreme Programming (XP) e Scrum

4.253 visualizações

Publicada em

Trabalho desenvolvido para justificar comparação entre eXtreme Programming e XP

Publicada em: Tecnologia
0 comentários
6 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
4.253
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
146
Comentários
0
Gostaram
6
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Extreme Programming (XP) e Scrum

  1. 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. 2. Quantidade, não traz qualidade
  3. 3. • Apenas 74% dos projetos não são terminados nas condiçõesplanejadas;• 46% dos projetos sofrem alterações de prazo, escopo e orçamentopara 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 dosusuá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 suasexpectativas em relação à funcionalidade do software
  4. 4. Frequentemente 13% Às vezesSempre 16% 7% Raramente 19% Nunca 45%
  5. 5. 80% das funcionalidades não são relevantes para o software produzido Às vezes 16% Raramente 19% Nunca 45%
  6. 6. Apenas 20% das funcionalidades produzidas realmente importam Frequentemente 13% Sempre 7%
  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 deter 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. 8. Modelo iterativo e incremental
  9. 9. Mudar ?Problema ou Oportunidade
  10. 10. Extreme ProgrammingO XP está sempre tentando fazer somente o que importa !
  11. 11. • Todos participam do projeto• O cliente e a equipe de desenvolvimento devem estar semprejuntos, 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. 12. DesafioUm dos maiores desafiosdo XP, é que o clientedificilmente terá muitotempo disponível paraestar junto com a equipede 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. 13. • Sem modelo cascata• Cliente e equipe planejam prazo para entrega dereleases.• Tempo para entrega não tem um valor de diasespecífico.
  14. 14. Release - 4 Semanas Release 1 Release 2 Release 3 Release 4Iteração - 1 Semana I1 I2 I3 I4 I5 I6
  15. 15. Iteração – Ciclo semanal Jogo do Planejamento
  16. 16. Iteração – Ciclo semanal Cliente escreve estórias
  17. 17. Iteração – Ciclo semanal Desenvolvedores estimam
  18. 18. Iteração – Ciclo semanal Cliente prioriza
  19. 19. Iteração – Ciclo semanalQuadro de funcionalidades
  20. 20. Iteração – Ciclo semanal Reunião diária
  21. 21. Iteração – Ciclo semanal Cronograma
  22. 22. Iteração – Ciclo semanalDesenvolvimento da aplicação (em par)
  23. 23. Iteração – Ciclo semanalAcompanhamento do cliente
  24. 24. Iteração – Ciclo semanalFuncionalidades terminam
  25. 25. Iteração – Ciclo semanal Encerramento da iteração
  26. 26. Iteração – Ciclo semanal Retrospectiva da iteração
  27. 27. Iteração – Ciclo semanal Inicia nova iteração
  28. 28. Cliente sempre pode ver retorno ao seu investimento
  29. 29. ScrumTodos estão alinhados e ‘atacam’ ao mesmo tempo!
  30. 30. Papéis no Scrum• O Scrum possui papéis bem definidos• Papéis são diferentes de cargos
  31. 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. 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. 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. 34. Processo Sprint
  35. 35. Processo Sprint Product Backlog• É o coração do Scrum• Lista inicial de requisitos criada pelo Product Owner, com tudo que precisa serproduzido 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. 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 deimplementar durante esse sprint• Define o objetivo da Sprint• Montando assim o Sprint Backlog
  37. 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. 38. Processo Sprint Sprint• O produto é de fato desenvolvido• O Scrum Team se dedica a produzir e entregar incrementos funcionais do produto
  39. 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. 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 clientepossa avaliar e validar a nova funcionalidade implementada.• A funcionalidade não precisa estar totalmente finalizada neste processo, mas sim tertodas as funções que foram estabelecidas para este sprint.
  41. 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 tenhavalor e uso para seus investidores, o produto então é entregue.
  42. 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 comoesperado, 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. 43. Processo Sprint Burndown ChartÉ um gráfico atualizado a cada Daily Scrum, projetando a conclusão das tarefas doSprint Backlog, uma forma simples e clara de representar o ritmo do desenvolvimento
  44. 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ávelNo 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. 45. Diferenças entre Extreme Programming e Scrum Extreme Programming Scrum Visa um rápido desenvolvimento Visa gestão e planejamentoO 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 perguntasPrima pela adaptabilidade, ouvindo sempre O Product Owner toma as decisões do o que o cliente tem a dizer cliente

×