O documento aborda o método Scrum como uma abordagem ágil para o desenvolvimento de software, enfatizando a importância da colaboração entre as partes interessadas e a entrega contínua. Apresenta 12 princípios ágeis, papéis dentro do Scrum (Product Owner, Scrum Master e Time de Desenvolvimento), eventos, artefatos e mitos comuns relacionados ao Scrum. Através de práticas como sprints e retrospectivas, o Scrum busca otimizar a comunicação e a eficiência, garantindo que o produto final atenda às necessidades do cliente.

1. SCRUM
Desenvolvimento Ágil de Software
Jonas Flesch - me@jonasflesch.com

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

7. 12 PRINCÍPIOS ÁGEIS

8. 01
Entrega contínua e desde cedo de
software com valor: satisfação do cliente

9. 02
Mudanças são bem-vindas: vantagem
competitiva para o cliente

10. 03
Produção em ciclos curtos: entrega
frequente de software funcionando

11. 04
Pessoas de negócio e desenvolvedores
devem trabalhar em conjunto

12. 05
Equipe de indivíduos motivados, com o
suporte e a confiança necessários

13. 06
Conversação face a face é o método mais
eficaz de comunicação

14. 07
Software em funcionamento é a medida
de progresso do projeto

15. 08
Ritmo sustentável de trabalho, sem
correria e horas extras

16. 09
Excelência técnica e bom design

17. 10
Simplicidade:
A arte de maximizar o trabalho não
realizado é essencial

18. 11
Equipes auto-organizadas:
empowerment!

19. 12
Melhoria contínua: inspeção e adaptação

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

23. SCRUM
• Transparência
• Inspeção
• Adaptação

25. PAPÉIS:A EQUIPE SCRUM

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

29. TIME DE
DESENVOLVIMENTO
- Auto organizado;
- Multi-funcional;
- Não contém sub-equipes.

31. EVENTOS DO SCRUM

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

37. ARTEFATOS DO SCRUM

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

42. DINÂMICA
Mitos e Fatos

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

47. O QUE UMA USER STORY NÃO É

48. UMA MOCKUP

49. CASO DE USO

50. LEMBRETE

51. SIMPLES
AGRUPADOR DE
TAREFAS

52. O QUE É USER STORY

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

58. 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

59. 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

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.

64. RETROSPECTIVA

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

69. me@jonasflesch.com
Jonas Flesch