extreme programming (xp) e scrum

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


Desenvolvedores estimam


Cliente prioriza


Quadro de funcionalidades


Reunião diária


Cronograma


Desenvolvimento da aplicação (em par)


Acompanhamento do cliente


Funcionalidades terminam


Encerramento da iteração


Retrospectiva da iteração


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 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)


• 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


• 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

extreme programming (xp) e scrum

Technology

product owner

scrum master

scrum team

todos participam

sprint

para

produto

cliente