Extreme Programming (XP) e Scrum
Upcoming SlideShare
Loading in...5
×
 

Extreme Programming (XP) e Scrum

on

  • 2,399 views

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

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

Statistics

Views

Total Views
2,399
Views on SlideShare
2,399
Embed Views
0

Actions

Likes
3
Downloads
49
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Extreme Programming (XP) e Scrum Extreme Programming (XP) e Scrum Presentation Transcript

  • 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çõ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
  • Frequentemente 13% Às vezesSempre 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 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
  • Modelo iterativo e incremental
  • Mudar ?Problema ou Oportunidade
  • Extreme ProgrammingO XP está sempre tentando fazer somente o que importa !
  • • 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.
  • 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.
  • • Sem modelo cascata• Cliente e equipe planejam prazo para entrega dereleases.• Tempo para entrega não tem um valor de diasespecífico.
  • Release - 4 Semanas Release 1 Release 2 Release 3 Release 4Iteraçã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 semanalQuadro de funcionalidades
  • Iteração – Ciclo semanal Reunião diária
  • Iteração – Ciclo semanal Cronograma
  • Iteração – Ciclo semanalDesenvolvimento da aplicação (em par)
  • Iteração – Ciclo semanalAcompanhamento do cliente
  • Iteração – Ciclo semanalFuncionalidades 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
  • ScrumTodos 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 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
  • 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
  • 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 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.
  • 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.
  • 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
  • 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
  • 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
  • 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