2. DESPERDÍCIO
Nunca Raramente ÀsVezes Frequentemente Sempre
Pesquisa do Standish Group nas maiores
empresas de projetos dos EUA, revelou
que 64% das features pedidas pelos
clientes são pouco ou nunca utilizadas
22. SCRUM
• Scrum é baseado em processos empíricos
• Processos definidos dizem como devem ser executados
• Quando os processos são muito complicados para se definir como,
processos empíricos são recomendados
27. PRODUCT OWNER
- Responsável pelo backlog e pelo valor
- Assegura o valor do trabalho sendo
realizado pela equipe
- Assegura que a equipe entende os itens
do backlog
28. SCRUM MASTER
- Ensina Scrum e garante que ele é
seguido
- Remove impedimentos
- Facilita o gerenciamento do backlog
- Ajuda na comunicação
- Facilita eventos do Scrum quando
necessário
32. SPRINT
• Coração do Scrum;
• Tempo fixo (um mês ou menos);
• Nenhuma mudança que afeta os
objetivos da sprint é realizada;
• Não se mexe na equipe;
• O escopo pode ser renegociado
quando mais é aprendido;
33. PLANNING
• Responde duas perguntas:
• O que vai ser entregue no
incremento da próxima Sprint?
• Como o trabalho para alcançar este
incremento vai ser feito?
34. DAILY SCRUM
• O que foi alcançado desde a última
reunião?
• O que vai ser feito até a próxima
reunião?
• Quais são os impedimentos?
35. SPRINT REVIEW
• Inspeciona-se o resultado da Sprint e se
adapta o Product Backlog se necessário;
• Recomenda-se quatro horas para uma
Sprint de um mês;
• O Product Owner se inteira do que foi
feito e do que não foi feito;
• O grupo colabora sobre o que fazer
em seguida;
36. RETROSPECTIVA
• Inspenciona-se como foi a Sprint quanto a:
• Pessoas
• Relacionamentos
• Processos
• Ferramentas
• Cria-se um mapa dos pontos fracos e um
plano de melhoria
38. PRODUCT BACKLOG
• Ordenado: itens são ordenados de acordo com a prioridade de sua
implementação – de forma a maximizar o ROI do cliente
• Estimável: julgar e formar uma opinião sobre o tamanho do Product
Backlog ou de uma parte relevante dele (ex. próxima Sprint ou
Release)
39. PRODUCT BACKLOG
• Emergente: lista incompleta e dinâmica em constante evolução. O
ambiente evolui e clientes eTime de Desenvolvimento aprendem sobre
o produto
• Gradualmente refinado: de acordo com a ordenação
• itens do alto: menor granularidade, maior detalhe
• itens de baixo: maior granularidade, menor detalhe
43. MITOS E FATOS: PRODUCT OWNER
1. O P. O. é o “proxy” ou representante do cliente, transmitindo seus desejos ao Time de Desenvolvimento
2. Embora deva ser influenciado por diferentes pessoas, o P. O. é o único que pode modificar o Product Backlog
3. O P. O. deve balancear necessidades e desejos dos diferentes stakeholders do projeto
4. O melhor P. O. é o próprio cliente ou alguém escolhido por ele
5. O P. O. deve ser apenas uma pessoa – deve haver apenas um ponto de decisão sobre o produto para o Time de Desenvolvimento
6. O P. O. em geral pode acumular o papel do ScrumMaster sem problemas
7. O P. O. deve colaborar de perto com o Time de Desenvolvimento para maximizar o valor entregue ao cliente
8. O P. O. deve cobrar do Time de Desenvolvimento o compromisso de que todos os itens escolhidos para o Sprint sejam desenvolvidos
9. A presença do P. O. não é obrigatória na reunião de Sprint Planning – basta o Time de Desenvolvimento escolher os itens do alto do
Product Backlog
10. O P. O. é responsável por definir o produto certo a ser desenvolvido
44. MITOS E FATOS: PRODUCT OWNER
1. MITO: O P. O. é o “proxy” ou representante do cliente, transmitindo seus desejos ao Time de Desenvolvimento
2. Embora deva ser influenciado por diferentes pessoas, o P. O. é o único que pode modificar o Product Backlog
3. O P. O. deve balancear necessidades e desejos dos diferentes stakeholders do projeto
4. MITO: O melhor P. O. é o próprio cliente ou alguém escolhido por ele
5. O P. O. deve ser apenas uma pessoa – deve haver apenas um ponto de decisão sobre o produto para o Time de Desenvolvimento
6. MITO: O P. O. em geral pode acumular o papel do ScrumMaster sem problemas
7. O P. O. deve colaborar de perto com o Time de Desenvolvimento para maximizar o valor entregue ao cliente
8. MITO: O P. O. deve cobrar do Time de Desenvolvimento o compromisso de que todos os itens escolhidos para o Sprint sejam
desenvolvidos
9. MITO: A presença do P. O. não é obrigatória na reunião de Sprint Planning – basta o Time de Desenvolvimento escolher os itens do alto
do Product Backlog
10. O P. O. é responsável por definir o produto certo a ser desenvolvido
45. MITOS E FATOS: SCRUM MASTER
1. Para ser efetivo, o ScrumMaster já deve ter trabalhado como membro de um Time de Desenvolvimento
2. O ScrumMaster trabalha para que o Scrum seja corretamente utilizado, ensinando-o e reforçando seus valores e regras
3. O ScrumMaster deve trabalhar para remover impedimentos ao trabalho do Time de Desenvolvimento, mas apenas aqueles que não
exigem mudanças organizacionais
4. ScrumMaster é o papel mais importante em um projeto que usa Scrum
5. O ScrumMaster deve ter boas habilidades interpessoais para facilitar a resolução de conflitos e promover a boa comunicação
6. O ScrumMaster deve proteger o Time de Desenvolvimento de interferências externas
7. O ScrumMaster o deve gerenciar o trabalho do Time de Desenvolvimento
8. O ScrumMaster trabalha em direção a se tornar cada vez mais necessário
9. Os ScrumMasters que trabalham o expediente inteiro nesse papel realizam melhor o seu trabalho
10. Ao opinar, impor ou interferir nas decisões de trabalho do Time de Desenvolvimento, o ScrumMaster torna-se menos eficiente
46. MITOS E FATOS: SCRUM MASTER
1. MITO: Para ser efetivo, o ScrumMaster já deve ter trabalhado como membro de um Time de Desenvolvimento
2. O ScrumMaster trabalha para que o Scrum seja corretamente utilizado, ensinando-o e reforçando seus valores e regras
3. MITO: O ScrumMaster deve trabalhar para remover impedimentos ao trabalho do Time de Desenvolvimento, mas apenas aqueles
que não exigem mudanças organizacionais
4. MITO: ScrumMaster é o papel mais importante em um projeto que usa Scrum
5. O ScrumMaster deve ter boas habilidades interpessoais para facilitar a resolução de conflitos e promover a boa comunicação
6. O ScrumMaster deve proteger o Time de Desenvolvimento de interferências externas
7. MITO: O ScrumMaster o deve gerenciar o trabalho do Time de Desenvolvimento
8. MITO: O ScrumMaster trabalha em direção a se tornar cada vez mais necessário
9. Os ScrumMasters que trabalham o expediente inteiro nesse papel realizam melhor o seu trabalho
10. Ao opinar, impor ou interferir nas decisões de trabalho do Time de Desenvolvimento, o ScrumMaster torna-se menos eficiente
53. QUEM?
O QUÊ?
POR QUÊ?
Como um <PERFIL>, eu
posso/gostaria/devo
<FUNÇÃO> para
<VALOR>
Como um COMPRADOR,
eu posso PESQUISAR
LIVROS para ESCOLHER
O QUE VOU COMPRAR
54. DINÂMICA
• Planejando um Hotel:
• Os membros do time representam os investidores que estão
construindo um hotel
• Os grupos tem 5 minutos para decidir qual será o diferencial do hotel
• Depois serão 10 minutos para priorizar um backlog com 14 requisitos
do hotel
55. PLANEJANDO UM HOTEL
• Agora imagine que durante a construção o dinheiro acabou assim
que o 5o Item ficou pronto.
• Mesmo com apenas 5 dos 14 itens, o hotel atende aos objetivos
propostos no início do exercício?
56. Eu, passageiro, gostaria de
adquirir passagens aéreas no
site da Gol, pois assim posso
economizar tempo na busca
pela melhor opção
57. COMPRAR PASSAGEM
AÉREA NO SITE DA GOL
USANDO MILHAS
SMILES
PROGRAMA
PARCEIROS
DELTA
AIR
FRANCE
USANDO DINHEIRO
PAGAMENTO
BOLETO
PAGAMENTO
CARTÃO
VISA MASTER
A/V 5X A/V 5X
60. CRITÉRIOS DE ACEITAÇÃO
• Qual é o formato de um alerta?
• Quais são os meios de emissão?
• Repetidamente implica em qual frequência?
• Qual é o critério para determinar um atraso?
UM ALERTA DEVERÁ SER
REPETIDAMENTE EMITIDO ASSIM QUE O
SISTEMA DETECTAR ATRASO EM UM
PEDIDO
61. CRITÉRIOS DE ACEITAÇÃO
• Tem como objetivo definir os limites do que deve ser feito no
desenvolvimento da User Story;
• Os Critérios de Aceitação guiam oTime para evitar a adição de
características sem valor nas funcionalidades, ao mesmo tempo em
que garante o mínimo necessário para entregar o valor proposto;
• São expressos por frases curtas e simples;
62. CRITÉRIOS DE ACEITAÇÃO
• Os Critérios de Aceitação são adicionados às User Stories durante as
sessões de refinamento do Backlog;
• Eles devem ser escritos pelo Product Owner em conjunto com o
Time, visando obter um conhecimento compartilhado sobre o que
deve ser feito;
63. CRITÉRIOS DE ACEITAÇÃO
• Os Critérios de Aceitação também guiam oTime na definição dos
Testes de Aceitação;
• Critérios de Aceitação são parte da Definição de Pronto.
65. • “Independente do que descobrirmos, nós entendemos e
realmente acreditamos que todo mundo fez o melhor trabalho
que pode, dado o conhecimento que tinha no momento, as suas
habilidades, os recursos disponíveis, e a situação”
66. TESTE DE SEGURANÇA
• 5 – Sem problema, eu vou falar sobre qualquer coisa.
• 4 – Eu vou falar sobre quase tudo; algumas coisas serão difíceis.
• 3 – Eu vou falar sobre algumas coisas, mas as outras será difícil
• 2 – Eu não vou falar muito, vou deixar o grupo trazer as coisas
• 1 – Eu irei sorrir, dizer que tudo está bem e concordar com os chefes
67. TRÊS L`S
• Liked - Gostei - coisas que eu realmente gostei
• Learned - Aprendi - coisas que eu aprendi
• Leaked - Faltantes - Coisas que eu senti falta