Palestra de introdução a SCRUM para a Faculdade Pitágoras

1. SCRUM

2. SOBRE MIM
• Márcio Youji Oya
• Comecei como programador em 1997, depois me tornei DBA na Telemar, desenvolvedor web,
gerente de TI, diretor de TI da Lazo Digital, fundador e ex-sócio da Plan B Comunicação Online e
consultor pela Oya Solutions.
• Desde 2006 faço parte da Assessoria de Informática da Fundep, desenvolvendo sistemas web e
treinando equipes em Agile usando SCRUM. Treinamos e coordenamos mais de 6 equipes, mais de
40 pessoas no projeto de migração de plataforma dos softwares da Fundação nos últimos 2 anos.
• Formado em Ciência da Computação pela PUC-MG em 2000.
• Certified Scrum Master pela Teamware com Boris Gloger.
• Fascinado por pessoas, tecnologia, inovação e empreendedorismo.

3. ESTA PALESTRA
• Visão Geral sobre Gestão Ágil e SCRUM
• Minha experiência
• Despertar a curiosidade

4. MOTIVADORES
• Gestão De Projetos 1.0
• Software x Engenharia Civil
• Pessoas, comportamentos e criatividade
• Alto índice de falhas
• Honestidade e Transparência

5. PREMISSAS

6. PREMISSAS
• Lei de Ziv

7. PREMISSAS
• Lei de Ziv
• “Especificações nunca serão completamente compreendidas.”

8. PREMISSAS
• Lei de Ziv
• “Especificações nunca serão completamente compreendidas.”
• Lei de Humphrey

9. PREMISSAS
• Lei de Ziv
• “Especificações nunca serão completamente compreendidas.”
• Lei de Humphrey
• “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem
assim).”

10. PREMISSAS
• Lei de Ziv
• “Especificações nunca serão completamente compreendidas.”
• Lei de Humphrey
• “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem
assim).”
• Lei de Wegner / Teorema de Godel

11. PREMISSAS
• Lei de Ziv
• “Especificações nunca serão completamente compreendidas.”
• Lei de Humphrey
• “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem
assim).”
• Lei de Wegner / Teorema de Godel
• “Um sistema interativo nunca estará completamente especificado e/ou
testado.”

12. PREMISSAS
• Lei de Ziv
• “Especificações nunca serão completamente compreendidas.”
• Lei de Humphrey
• “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem
assim).”
• Lei de Wegner / Teorema de Godel
• “Um sistema interativo nunca estará completamente especificado e/ou
testado.”
“É típico adotar a abordagem de modelagem teórica quando todos os fatores
pelos quais um processo opera estão razoavelmente bem entendidos. Quando
o processo é complicado demais para a abordagem teórica, uma abordagem
empírica é a melhor escolha.” Process Dynamics, Modeling, and Control, Ogunnaike e Ray, Oxford University Press, 1992

14. MANIFESTO ÁGIL
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à
esquerda.

15. PRINCÍPIOS
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor
agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das mudanças visando vantagem competitiva para o cliente.
3. Entregar freqüentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor
escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles
para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de
conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser
capazes de manter um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
10.Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial.
11.As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
12.Em intervalos regulares, a equipe reflete sobe como se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.

16. O QUE É O SCRUM?
• Modo empírico de gerenciar projetos de desenvolvimento de software
• Feito de um conjunto simples de regras e garante que todos os membros da equipe sintam a
responsabilidade de um projeto
• Inspeção e adaptação com base em feedback
• Usado para gerenciar projetos complexos desde 1990
• Entrega de funcionalidades de negócio em 30 dias
• Escalabilidade na distribuição de projetos grandes e longos
• Compatível com CMM Level 3 e ISO 9001
• Extremamente simples mas de difícil implementação

18. PRINCÍPIOS
• Time responsável e comprometido
• Honestidade
• Transparência
• Partes potencialmente entregáveis
• Timebox

19. HONESTIDADE X
CONFORMIDADE

20. SCRUM ROLES
•Product Owner
•Scrum Master
•Team

21. PAPÉIS NO SCRUM
Atividade Papel Responsabilidade
Gerencia a Product O Product Owner estabelece, mantem viva e comunica a visão do produto. Ele demonstra que o
visão Owner projeto é alcançável e o financia criando a visão dos releases e do Product Backlog inicial.
Product O Product Owner monitora o projeto, mantém de acordo com o ROI estabelecido. Ele atualiza as
Gerencia o prioridade do Product Backlog para assegurar-se que as tarefas de maior valor funcional sejam
Owner
ROI produzidas primeiro. Ele prioriza o Product Backlog and mede o sucesso para assegurar que o
projeto está no caminho certo.
Gerencia as Team
Durante uma iteração o time seleciona e desenvolve os requisitos de maior prioridade do Product
iterações de Backlog. Coletivamente, o time expande os itens do Product Backlog para tarefas mais explícitas no
Sprint Backlog e gerenciam o trabalho e a sua própria organização para entregar os itens desejados
desenvolvimento naquela iteração. O time se gerencia para cumprir o compromissos.
Scrum
Master O Scrum Master é responsável por ajustar a equipe acima tentando assegurar o sucesso do projeto
Gerencia o e otimizar a cultura organizacional para encontrar os objetivos no projeto. Isto envolve organizar a
processo Sprint Planning Meeting, a Sprint Review Meeting, protegendo a equipe dos distúrbios externos,
realizando as Daily Scrum Meetings, e removendo impedimentos para o progresso do projeto.
Product
Owner O Product Owner toma decisões sobre quando criar um release oficial. Por uma série de razões não
Gerencia os é desejável liberar um realease a cada incremento. O Product Owner toma esta decisões de
releases maneira consistente com base na visão de investimento que foi estabelecida para o projeto.

22. CHICKENS AND PIGS

23. CENOURAS E CHICOTES

24. FASES

25. FLUXO DO SCRUM

26. O QUE É UM BACKLOG ITEM?
Como <user role> eu quero <feature> para
que <business value>

27. PRODUCT BACKLOG
• Lista de funcionalidades, tecnologia a ser aplicada, issues
• Issues são situações/assuntos do projeto que terão o trabalho definido mais tarde
• Itens priorizados e estimados
• Maior detalhamento sobre os itens de maior prioridade
• O Product Owner é responsável pela priorização
• Qualquer um da equipe pode contribuir
• Mantido e fixado em local visível
• Derivado do plano de negócio e da visão estabelecida, que tem que ser criada em conjunto com o
cliente
• Estimation Meeting

28. ESTIMATIVA
PLANNING POKER
• Chile
• Argentina
• Venezuela
• Brasil
• Uruguai
• Paraguai
• Egito
• Itália
1, 2, 3, 5, 8, 13, 21

29. SPRINT PLANNING 1
• Definir o Sprint Goal e o Selected Product Backlog

30. SPRINT PLANNING 2
• Define as tarefas para realizar o Sprint Backlog e alinha ao
Sprint Goal
• Junta a estimativa com a realidade da equipe e do projeto
• Design é detalhado nesta sessão
• Vamos ao quadro!

31. KANBAN

32. MÉTRICAS
• Sprint Burndown
• Product Burndown
• Velocity per Sprint
• Business Value Evolution

33. DAILY MEETING
• Objetivo: Sincronizar a equipe
- Quais as tarefas foram realizadas ontem?
- Quais as tarefas serão desempenhadas hoje?
- Quais os impedimentos encontrados durante o seu trabalho?
• Mover as tarefas dentro do quadro de acordo com a sua execução
• Resultados
- Atualização do Impediment Backlog
- Atualização do Sprint Backlog
- Atualização dos gráficos Burndown
• Novas funcionalidades que surgirem serão armazenadas para avaliação ao final do Sprint

34. DONE!
• Quando uma tarefa esta realmente concluída?

35. IMPEDIMENTS BACKLOG
• Recursos
• Skills
• Prazo Impossível
• Infra-estrutura
• Ausência de feedback do cliente
• Escopo não definido
• Problemas Contratuais
• Falta de Prioridade
• Falte de unidade entre equipes
• Burocracia

36. ABNORMAL TERMINATION
• Sprints podem ser cancelados antes do final do Sprint

37. SPRINT REVIEW
•O team deve apresentar os resultados do Sprint e as novas
funcionalidades desenvolvidas
• Se surgirem novas funcionalidades ou alteração, os novos itens
irão para o Backlog para serem estimados e priorizados
• O team deve reportar os impedimentos durante o
desenvolvimento
• Ao final todos envolvidos no projeto devem entender a
evolução do projeto e os impedimentos

38. SPRINT RETROSPECTIVE
•O processo é aprimorado ao final de cada Sprint
• Facilitado pelo ScrumMaster
•O que aconteceu de bom que nós podemos utilizar
como melhoria?
• ScrumMaster basea a prioridade de acordo com o team
•A equipe planeja a solução dos problemas de sua
responsabilidade

39. RETROSPECTIVA
“Independente do que nós descubramos, nós
compreendemos e acreditamos verdadeiramente que todos
fizeram o melhor trabalho que poderiam, deram o que sabiam
naquele momento, seus conhecimentos e suas habilidades, os
recursos disponíveis, e a situação disponível.”

40. ESCALABILIDADE COM
SCRUM

41. RESUMO
• Roles: Product Owner, Team, ScrumMaster
• Artifacts: Product
Backlog, Selected Product Backlog, Sprint
Backlog, Impediment Backlog
• Scrum Meetings: Daily Scrum Meeting, Estimation Meeting,
Sprint Planning 1, Sprint Planning 2, Sprint Review Meeting,
Retrospective

42. COMEÇANDO
• Ensine os conceitos, teoria e práticas do SCRUM
• Apresente a Visão do Projeto, Objetivos e timelines
• Ensine o Sprint Planning
• Defina o Product Backlog para pelo menos 3 sprints
• Faça um brainstorm dos possíveis impedimentos
• Faça um brainstorm sobre o próximo Sprint - aceite da
equipe
• A equipe define o Sprint Backlog
• Ensine Daily Meeting, Sprint Review e auto-organização
• Discuta sobre ferramentas, práticas e arquiteturas.

43. INDO ALÉM
• XP
• Pair Programming
• BDD - TDD
• Lean
• Kanban
• etc

44. DÚVIDAS?
• marciooya@gmail.com
• Twitter @marciooya
• (31) 9722-7170