O documento discute os desafios de projetos de software e as vantagens das metodologias ágeis como Scrum e Extreme Programming. Menciona que apenas 20% dos projetos de software entregam valor real para os usuários e que as metodologias ágeis permitem entregas frequentes com feedback do cliente.
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
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.
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