SlideShare uma empresa Scribd logo
1 de 45
Quando a comunicação passa sucessivamente por mais pessoas, o número de falhas
           na transmissão da mensagem aumenta na mesma proporção
Quantidade, não traz qualidade
• 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
Frequentemente
               13%
                           Às vezes
Sempre                       16%
  7%




                                      Raramente
                                         19%


  Nunca
   45%
80% das funcionalidades não são relevantes para o software produzido



                                             Às vezes
                                               16%




                                                        Raramente
                                                           19%


                Nunca
                 45%
Apenas 20% das funcionalidades produzidas realmente importam

                    Frequentemente
                         13%
           Sempre
             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
Modelo iterativo e incremental
Mudar ?
Problema ou Oportunidade
Extreme
 Programming
O XP está sempre tentando fazer somente o que importa !
• 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.
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.
• Sem modelo cascata


• Cliente e equipe planejam prazo para entrega de
releases.


• Tempo para entrega não tem um valor de dias
específico.
Release - 4 Semanas
    Release 1         Release 2   Release 3        Release 4



Iteração - 1 Semana
    I1          I2           I3   I4          I5          I6
Iteração – Ciclo semanal




  Jogo do Planejamento
Iteração – Ciclo semanal




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




 Desenvolvedores estimam
Iteração – Ciclo semanal




     Cliente prioriza
Iteração – Ciclo semanal




Quadro de funcionalidades
Iteração – Ciclo semanal




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




      Cronograma
Iteração – Ciclo semanal




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




Acompanhamento do cliente
Iteração – Ciclo semanal




Funcionalidades terminam
Iteração – Ciclo semanal




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




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




   Inicia nova iteração
Cliente sempre pode ver retorno ao seu investimento
Scrum
Todos estão alinhados e ‘atacam’ ao mesmo tempo!
Papéis no Scrum




• O Scrum possui papéis bem definidos

• Papéis são diferentes de cargos
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
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
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.
Processo Sprint
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
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
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
Processo Sprint




                                      Sprint
• O produto é de fato desenvolvido


• O Scrum Team se dedica a produzir e entregar incrementos funcionais do produto
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.
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.
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.
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
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
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
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

Mais conteúdo relacionado

Mais procurados

Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Sérgio Souza Costa
 

Mais procurados (20)

Introdução básica ao JavaScript
Introdução básica ao JavaScriptIntrodução básica ao JavaScript
Introdução básica ao JavaScript
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Aula 07 - Visualg e Pseudocódigo
Aula 07 - Visualg e PseudocódigoAula 07 - Visualg e Pseudocódigo
Aula 07 - Visualg e Pseudocódigo
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
 
Aula01-JavaScript
Aula01-JavaScriptAula01-JavaScript
Aula01-JavaScript
 
Comparativo Método Tradicional e Método Ágil
Comparativo Método Tradicional e Método ÁgilComparativo Método Tradicional e Método Ágil
Comparativo Método Tradicional e Método Ágil
 
01 php - introdução ao php
01   php - introdução ao php01   php - introdução ao php
01 php - introdução ao php
 
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento Engenharia de Software - Conceitos e Modelos de Desenvolvimento
Engenharia de Software - Conceitos e Modelos de Desenvolvimento
 
Aula javascript
Aula  javascriptAula  javascript
Aula javascript
 
Documentação de Arquitetura de Software Aplicando o C4 Model
Documentação de Arquitetura  de Software Aplicando o C4 ModelDocumentação de Arquitetura  de Software Aplicando o C4 Model
Documentação de Arquitetura de Software Aplicando o C4 Model
 
Scrum
ScrumScrum
Scrum
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Apostila Lógica de Programação
Apostila Lógica de ProgramaçãoApostila Lógica de Programação
Apostila Lógica de Programação
 
Métodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - IntroduçãoMétodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - Introdução
 
Analise e Projeto de Sistemas
Analise e Projeto de SistemasAnalise e Projeto de Sistemas
Analise e Projeto de Sistemas
 
Curso CSS 3 - Aula Introdutória com conceitos básicos
Curso CSS 3 - Aula Introdutória com conceitos básicosCurso CSS 3 - Aula Introdutória com conceitos básicos
Curso CSS 3 - Aula Introdutória com conceitos básicos
 
Aula 06 softwares
Aula 06   softwaresAula 06   softwares
Aula 06 softwares
 
Introdução a Linguagem Java
Introdução a Linguagem JavaIntrodução a Linguagem Java
Introdução a Linguagem Java
 
PMBOK
PMBOKPMBOK
PMBOK
 

Destaque

Gestao de projetos_-_exercicio_1._com_gabarito_doc
Gestao de projetos_-_exercicio_1._com_gabarito_docGestao de projetos_-_exercicio_1._com_gabarito_doc
Gestao de projetos_-_exercicio_1._com_gabarito_doc
neyfds
 

Destaque (7)

Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - KanbanMetodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban
 
Desenvolvimento Ágil com Scrum e XP
Desenvolvimento Ágil com Scrum e XPDesenvolvimento Ágil com Scrum e XP
Desenvolvimento Ágil com Scrum e XP
 
Entendendo Scrum, Kanban e Programação Extrema
Entendendo Scrum, Kanban e Programação ExtremaEntendendo Scrum, Kanban e Programação Extrema
Entendendo Scrum, Kanban e Programação Extrema
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
 
Desenvolvimento Ágil de Software: uma abordagem com SCRUM e XP
Desenvolvimento Ágil de Software: uma abordagem com SCRUM e XPDesenvolvimento Ágil de Software: uma abordagem com SCRUM e XP
Desenvolvimento Ágil de Software: uma abordagem com SCRUM e XP
 
Comparativo entre Processos Ágeis
Comparativo entre Processos ÁgeisComparativo entre Processos Ágeis
Comparativo entre Processos Ágeis
 
Gestao de projetos_-_exercicio_1._com_gabarito_doc
Gestao de projetos_-_exercicio_1._com_gabarito_docGestao de projetos_-_exercicio_1._com_gabarito_doc
Gestao de projetos_-_exercicio_1._com_gabarito_doc
 

Semelhante a Extreme Programming (XP) e Scrum

Scrum apresentação
Scrum apresentaçãoScrum apresentação
Scrum apresentação
Armando Couto
 

Semelhante a Extreme Programming (XP) e Scrum (20)

Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Introdução ao desenvolvimento ágil com Scrum
Introdução ao desenvolvimento ágil com ScrumIntrodução ao desenvolvimento ágil com Scrum
Introdução ao desenvolvimento ágil com Scrum
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
Método Ágil Scrum
Método Ágil ScrumMétodo Ágil Scrum
Método Ágil Scrum
 
Palestra sobre Fundamentos do Scrum e Kanban.
Palestra sobre Fundamentos do Scrum e Kanban.Palestra sobre Fundamentos do Scrum e Kanban.
Palestra sobre Fundamentos do Scrum e Kanban.
 
Agile
AgileAgile
Agile
 
Scrum
ScrumScrum
Scrum
 
Scrum em 1h.
Scrum em 1h.Scrum em 1h.
Scrum em 1h.
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Scrum apresentação
Scrum apresentaçãoScrum apresentação
Scrum apresentação
 
Scrum agil
Scrum agilScrum agil
Scrum agil
 
Introdução ao scrum
Introdução ao scrumIntrodução ao scrum
Introdução ao scrum
 
Scrum
ScrumScrum
Scrum
 
Lista de Práticas Ágeis
Lista de Práticas ÁgeisLista de Práticas Ágeis
Lista de Práticas Ágeis
 
Netshoes metodologia
Netshoes metodologiaNetshoes metodologia
Netshoes metodologia
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
 
SCRUM
SCRUMSCRUM
SCRUM
 
Workshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUMWorkshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUM
 
Netshoes metodologia
Netshoes metodologiaNetshoes metodologia
Netshoes metodologia
 
Scrum workshop
Scrum   workshopScrum   workshop
Scrum workshop
 

Extreme Programming (XP) e Scrum

  • 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
  • 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.
  • 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