Agile e Scrum

Treinamento interno Pinuts Studios

 Pauta do dia
• O porquê do treinamento
• Waterfall
• Agile
• Waterfall vs Agile
• Scrum
• Práticas em Agile
 O porquê do treinamento?
• Pinuts sofreu cronicamente com a gestão dos
projetos
• Melhoramos, mas ainda falta bastante
• É importante conhecer técnicas
• Seria legal se vocês entendessem como
funciona gestão, para que participar melhor
do processo (tanto ajudando com sugestões
quanto compreendendo seus papéis)
 O que é tradicional?

Waterfall
 Waterfall é errado?

O modelo funciona muito bem quando:

• O projeto é simples
• Você conhece bem a tecnologia
• Não haverá mudanças no escopo
• O processo é repetitivo
• Está rolando legal, então para que mudar?
 Mas quando Waterfall É errado?
• Principalmente quando há alguma indicação
de que o projeto pode sofrer alterações
• Quando você precisa entregar valor
constantemente, não podendo esperar até o
final do projeto para ter algo pronto
 E Agile?

“Agile é uma descrição de muitos sistemas,

processos, frameworks e práticas usadas para
desenvolver software e gerenciar projetos”

Engloba muita coisa que vai de

encontro com Waterfall
 Agile manifesto
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Collaboration with the client over negotiation
of contracts
• Responding to change over following a plan
 E o que é Scrum?
• Scrum é a parte de “gerenciamento de
projetos” dentro do Agile
• Ótimo quando você tem dúvidas quanto aos
requisitos ou quanto à tecnologia
• Três papéis / Quatro reuniões / Três artefatos
 E o que NÃO é Scrum?
• Não é uma solução mágica para problemas em
projetos
• Não é algo novo – por isso muitos que
conhecem chegam à conclusão: “Ei, isso é
bom senso”
• Não é idiot-proof – e pode evidenciar se há
idiotas na sua equipe
 Por que Scrum é legal?
• É interessante do ponto de vista de negócio e
de desenvolvimento:
– Mantém stakeholders a par do que está rolando
– Permite adaptações com muito menos stress
– Mantém o foco em criar valor
 3 papéis, 3 artefatos e 4 reuniões
• Papéis
– Scrum Master, Product Owner, Scrum Team
• Artefatos
– Product backlog, Sprint backlog, Burndown chart
• Reuniões
– Sprint planning, Daily scrum, Sprint review, Sprint
retrospective
 Papéis
O Product Owner gerencia o produto em si, em
termos de negócio. Ele representa os
usuários/clientes e guia a equipe a criar o
produto correto.
O Scrum Master gerencia o processo. Ele é o
“treinador” da equipe, ajudando a utilizar o
Scrum corretamente.
A Equipe se autogerencia. Sim, isso mesmo. E esse
é um dos pilares do Scrum.
 Artefatos
O Product backlog é uma lista das funcionalidades
mais importantes de um produto, ordenado pela
importância em termos de negócio. É tarefa do
PO.
O Sprint backlog é uma lista das funcionalidades a
serem feitas no Sprint. Deve estar descrito muito
bem pelo time, tanto em termos de user stories
quanto critérios de aceite.
O Burndown chart é um quadro em que é possível
avaliar o desempenho da equipe.
Burndown chart
 Reuniões
A Sprint planning é uma reunião em que o Product
Backlog é avaliado, para planejamento do Sprint. O
resultado do Sprint é o Sprint backlog.
Daily scrum é a reunião (em pé) de 10 minutos.
Perguntas da reunião são “o que você fez”, “o que
você fará” e “há algo te impedindo”.
No Sprint review, é hora de mostrar o resultado do
Sprint para o PO e para os outros stakeholders.
A Sprint retrospective é o momento da equipe sentar e
pensar no que foi feito errado e como é possível
melhorar.
 Algumas práticas em Agile
• Planning poker
• Pair programming
• Code refactoring
• Test Driven Development (TDD)
• KanBan
 Planning Poker

Processo sem planning poker

Processo com planning poker
Pair programming
Driver Navigator
Revisa o código

Pensa estrategicamente
Escreve o código da em possíveis problemas no
funcionalidade futuro

Imagina melhorias para a

funcionalidade

Aprende!
Code refactoring

… is like trying to deconstruct a

sweater into independent
and usable separate colored
balls of yarn.
 Indícios para refatoração
• Código duplicado
• Método longo
• Classe grande
• Lista de parâmetros longa
• Má indentação
 Test Driven Development

1. Pense no que você quer fazer.

2. Pense em como testar isso.
3. Escreva um pequeno teste. Pense na API desejada.
4. Escreva apenas código suficiente para falhar o teste.
5. Execute e veja o teste falhar.
6. Escreva apenas código suficiente para passar no teste.
7. Rode e veja todos os testes passarem.
8. Se você tem lógica duplicada ou código inexpressivo, refatore.
9. Faça testes globais de novo, tudo deve estar certo. Se der errado, você
cagou ao refatorar o código.
10. Repita os pontos acima até não conseguir pensar em mais testes que te
levem a escrever novo código.
 KanBan

• Visualize workflow
• Limit WIP
 E agora?
• Há espaço para a utilização do Scrum em
gerenciamento de projetos na Pinuts? Com
toda a certeza.
• Será usado em todos os projetos? De modo
algum.
• Quando for usado, será usado em sua
totalidade? Provavelmente não.
• E as práticas em Agile? Ah, essas têm futuro!
 Referências
http://www.mountaingoatsoftware.com/topics/scrum
http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf
http://www.scrumalliance.org/pages/scrum_artifacts
http://blogs.danube.com/scrum-webinars
http://blogs.danube.com/scrum-video-series
http://www.scrumsense.com/wp-content/uploads/2009/12/DoBetterScrum-v2.pdf
http://martinfowler.com/articles/newMethodology.html
http://en.wikipedia.org/wiki/Planning_poker
http://en.wikipedia.org/wiki/Agile_software_development#Agile_practices
http://xprogramming.com/articles/bigvisiblecharts/
http://www.scrumalliance.org/pages/scrum_student_resources
http://www.cs.usfca.edu/~parrt/course/601/lectures/refactoring/refactoring.html
http://www.artima.com/articles/defining_done.html
http://www.youtube.com/watch?v=Q5k7a9YEoUI
http://dojofloripa.wordpress.com/2006/11/03/top-5-desculpas-de-quem-nao-quer-programar-orientado-a-test
es/
http://www.slideshare.net/rodrigorm/tdd-test-driven-development
http://blog.crisp.se/mattiasskarin/files/pdf/converting_a_scrum_team_to_kanban.pdf
http://www.crisp.se/kanban
 Recomendações
http://blogs.danube.com/scrum-webinars
http://blogs.danube.com/scrum-video-series
http://www.youtube.com/watch?v=Q5k7a9YEo
UI
http://www.scrumsense.com/wp-content/uploa
ds/2009/12/DoBetterScrum-v2.pdf
 Próximos passos?
• Papéis no Scrum
• Artefatos no Scrum
• Reuniões no Scrum