extreme programming (xp) e scrum
DESCRIPTION
Trabalho desenvolvido para justificar comparação entre eXtreme Programming e XPTRANSCRIPT
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
Sempre7%
Frequentemente13%
Às vezes16%
Raramente19%
Nunca45%
Às vezes16%
Raramente19%
Nunca45%
80% das funcionalidades não são relevantes para o software produzido
Sempre7%
Frequentemente13%
Apenas 20% das funcionalidades produzidas realmente importam
• 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.
Para se fazer software bom, 95% do foco não é em coisas que tem haver com tecnologia e sim com a parte pessoal.
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.
Desafio
• 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 1 Release 2 Release 3 Release 4
Release - 4 Semanas
I 1 I 2 I 3 I 4 I 5 I 6Iteração - 1 Semana
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
Iteração – Ciclo semanal
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 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 SprintBurndown 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
Extreme Programming e ScrumCliente e equipe planejam prazo para entrega de releases
Não se usa modelo cascataFaz 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 melhoriasSe faz uso da programação em par
maximizar a quantidade de trabalho que não precisou ser feitoentrega adiantada e contínua de software de valor
Iterações são curtasUsa a refatoração, para deixar o código sempre mais claro, sem alterar a funcionalidade
Semelhanças entreExtreme Programming e Scrum
Extreme Programming ScrumVisa um rápido desenvolvimento Visa gestão e planejamento
O cliente não pode se afastar do projeto em nenhum momento
o Product Owner representa o cliente e stakeholders
Não há especificação de papéis Os papéis são claramente definidosNenhuma permissão é dada em nível de
hierarquiaProduct Owner e Scrum Master tem
privilégios em relação ao Scrum TeamSe descobre problemas com testes e
acompanhamento contínuoDescobre problemas principalmente por meio da reunião diária, de acordo com
perguntasPrima pela adaptabilidade, ouvindo sempre
o que o cliente tem a dizerO Product Owner toma as decisões do
cliente
Diferenças entreExtreme Programming e Scrum