SCRUM
Desenvolvimento Ágil de Software
Jonas Flesch - me@jonasflesch.com
DESPERDÍCIO
Nunca Raramente ÀsVezes Frequentemente Sempre
Pesquisa do Standish Group nas maiores
empresas de projetos dos ...
12 PRINCÍPIOS ÁGEIS
01
Entrega contínua e desde cedo de
software com valor: satisfação do cliente
02
Mudanças são bem-vindas: vantagem
competitiva para o cliente
03
Produção em ciclos curtos: entrega
frequente de software funcionando
04
Pessoas de negócio e desenvolvedores
devem trabalhar em conjunto
05
Equipe de indivíduos motivados, com o
suporte e a confiança necessários
06
Conversação face a face é o método mais
eficaz de comunicação
07
Software em funcionamento é a medida
de progresso do projeto
08
Ritmo sustentável de trabalho, sem
correria e horas extras
09
Excelência técnica e bom design
10
Simplicidade:

A arte de maximizar o trabalho não
realizado é essencial
11
Equipes auto-organizadas:
empowerment!
12
Melhoria contínua: inspeção e adaptação
SCRUM
• Scrum é baseado em processos empíricos
• Processos definidos dizem como devem ser executados
• Quando os processos ...
SCRUM
• Transparência
• Inspeção
• Adaptação
PAPÉIS:A EQUIPE SCRUM
PRODUCT OWNER
- Responsável pelo backlog e pelo valor
- Assegura o valor do trabalho sendo
realizado pela equipe
- Assegur...
SCRUM MASTER
- Ensina Scrum e garante que ele é
seguido
- Remove impedimentos
- Facilita o gerenciamento do backlog
- Ajud...
TIME DE
DESENVOLVIMENTO
- Auto organizado;
- Multi-funcional;
- Não contém sub-equipes.
EVENTOS DO SCRUM
SPRINT
• Coração do Scrum;
• Tempo fixo (um mês ou menos);
• Nenhuma mudança que afeta os
objetivos da sprint é realizada;
...
PLANNING
• Responde duas perguntas:
• O que vai ser entregue no
incremento da próxima Sprint?
• Como o trabalho para alcan...
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 impe...
SPRINT REVIEW
• Inspeciona-se o resultado da Sprint e se
adapta o Product Backlog se necessário;
• Recomenda-se quatro hor...
RETROSPECTIVA
• Inspenciona-se como foi a Sprint quanto a:
• Pessoas
• Relacionamentos
• Processos
• Ferramentas
• Cria-se...
ARTEFATOS DO SCRUM
PRODUCT BACKLOG
• Ordenado: itens são ordenados de acordo com a prioridade de sua
implementação – de forma a maximizar o R...
PRODUCT BACKLOG
• Emergente: lista incompleta e dinâmica em constante evolução. O
ambiente evolui e clientes eTime de Dese...
DINÂMICA
Mitos e Fatos
MITOS E FATOS: PRODUCT OWNER
1. O P. O. é o “proxy” ou representante do cliente, transmitindo seus desejos ao Time de Dese...
MITOS E FATOS: PRODUCT OWNER
1. MITO: O P. O. é o “proxy” ou representante do cliente, transmitindo seus desejos ao Time d...
MITOS E FATOS: SCRUM MASTER
1. Para ser efetivo, o ScrumMaster já deve ter trabalhado como membro de um Time de Desenvolvi...
MITOS E FATOS: SCRUM MASTER
1. MITO: Para ser efetivo, o ScrumMaster já deve ter trabalhado como membro de um Time de Dese...
O QUE UMA USER STORY NÃO É
UMA MOCKUP
CASO DE USO
LEMBRETE
SIMPLES
AGRUPADOR DE
TAREFAS
O QUE É USER STORY
QUEM?
O QUÊ?
POR QUÊ?
Como um <PERFIL>, eu
posso/gostaria/devo
<FUNÇÃO> para
<VALOR>
Como um COMPRADOR,
eu posso PESQUISAR...
DINÂMICA
• Planejando um Hotel:
• Os membros do time representam os investidores que estão
construindo um hotel
• Os grupo...
PLANEJANDO UM HOTEL
• Agora imagine que durante a construção o dinheiro acabou assim
que o 5o Item ficou pronto.
• Mesmo co...
Eu, passageiro, gostaria de
adquirir passagens aéreas no
site da Gol, pois assim posso
economizar tempo na busca
pela melh...
COMPRAR PASSAGEM
AÉREA NO SITE DA GOL
USANDO MILHAS
SMILES
PROGRAMA
PARCEIROS
DELTA
AIR
FRANCE
USANDO DINHEIRO
PAGAMENTO
B...
COMPRAR
PASSAGEM AÉREA
SMILES
AIR
FRANCE
USANDO DINHEIRO
PAGAMENTO
BOLETO
PAGAMENTO
CARTÃO
VISA MASTER
A/V 5X A/V 5X
USAND...
COMPRAR
PASSAGEM AÉREA
USANDO MILHAS
SMILES
PROGRAMA
PARCEIROS
DELTA
AIR
FRANCE
USANDO
DINHEIRO
PAGAMENTO
BOLETO
PAGAMENT
...
CRITÉRIOS DE ACEITAÇÃO
• Qual é o formato de um alerta?
• Quais são os meios de emissão?
• Repetidamente implica em qual f...
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
• Os Critérios de Aceitação são adicionados às User Stories durante as
sessões de refinamento do Bac...
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 ...
RETROSPECTIVA
• “Independente do que descobrirmos, nós entendemos e
realmente acreditamos que todo mundo fez o melhor trabalho
que pode,...
TESTE DE SEGURANÇA
• 5 – Sem problema, eu vou falar sobre qualquer coisa.
• 4 – Eu vou falar sobre quase tudo; algumas coi...
TRÊS L`S
• Liked - Gostei - coisas que eu realmente gostei
• Learned - Aprendi - coisas que eu aprendi
• Leaked - Faltante...
me@jonasflesch.com
Jonas Flesch
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Treinamento Scrum - Português
Próximos SlideShares
Carregando em…5
×

Treinamento Scrum - Português

355 visualizações

Publicada em

Treinamento de Scrum/Métodos Ágeis realizado na CWI Software. Contém os princípios de métodos ágeis e os papéis do Scrum.

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
355
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
6
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Treinamento Scrum - Português

  1. 1. SCRUM Desenvolvimento Ágil de Software Jonas Flesch - me@jonasflesch.com
  2. 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
  3. 3. 12 PRINCÍPIOS ÁGEIS
  4. 4. 01 Entrega contínua e desde cedo de software com valor: satisfação do cliente
  5. 5. 02 Mudanças são bem-vindas: vantagem competitiva para o cliente
  6. 6. 03 Produção em ciclos curtos: entrega frequente de software funcionando
  7. 7. 04 Pessoas de negócio e desenvolvedores devem trabalhar em conjunto
  8. 8. 05 Equipe de indivíduos motivados, com o suporte e a confiança necessários
  9. 9. 06 Conversação face a face é o método mais eficaz de comunicação
  10. 10. 07 Software em funcionamento é a medida de progresso do projeto
  11. 11. 08 Ritmo sustentável de trabalho, sem correria e horas extras
  12. 12. 09 Excelência técnica e bom design
  13. 13. 10 Simplicidade:
 A arte de maximizar o trabalho não realizado é essencial
  14. 14. 11 Equipes auto-organizadas: empowerment!
  15. 15. 12 Melhoria contínua: inspeção e adaptação
  16. 16. 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
  17. 17. SCRUM • Transparência • Inspeção • Adaptação
  18. 18. PAPÉIS:A EQUIPE SCRUM
  19. 19. 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
  20. 20. 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
  21. 21. TIME DE DESENVOLVIMENTO - Auto organizado; - Multi-funcional; - Não contém sub-equipes.
  22. 22. EVENTOS DO SCRUM
  23. 23. 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;
  24. 24. 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?
  25. 25. 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?
  26. 26. 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;
  27. 27. 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
  28. 28. ARTEFATOS DO SCRUM
  29. 29. 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)
  30. 30. 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
  31. 31. DINÂMICA Mitos e Fatos
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. O QUE UMA USER STORY NÃO É
  37. 37. UMA MOCKUP
  38. 38. CASO DE USO
  39. 39. LEMBRETE
  40. 40. SIMPLES AGRUPADOR DE TAREFAS
  41. 41. O QUE É USER STORY
  42. 42. 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
  43. 43. 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
  44. 44. 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?
  45. 45. Eu, passageiro, gostaria de adquirir passagens aéreas no site da Gol, pois assim posso economizar tempo na busca pela melhor opção
  46. 46. 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
  47. 47. COMPRAR PASSAGEM AÉREA SMILES AIR FRANCE USANDO DINHEIRO PAGAMENTO BOLETO PAGAMENTO CARTÃO VISA MASTER A/V 5X A/V 5X USANDO MILHAS PROGRAMA PARCEIROS DELTA
  48. 48. COMPRAR PASSAGEM AÉREA USANDO MILHAS SMILES PROGRAMA PARCEIROS DELTA AIR FRANCE USANDO DINHEIRO PAGAMENTO BOLETO PAGAMENT O CARTÃO VISA MASTER 5X A/V 5XA/V
  49. 49. 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
  50. 50. 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;
  51. 51. 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;
  52. 52. 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.
  53. 53. RETROSPECTIVA
  54. 54. • “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”
  55. 55. 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
  56. 56. TRÊS L`S • Liked - Gostei - coisas que eu realmente gostei • Learned - Aprendi - coisas que eu aprendi • Leaked - Faltantes - Coisas que eu senti falta
  57. 57. me@jonasflesch.com Jonas Flesch

×