4. O cerne das metodologias ágeis
Manifesto Ágil
“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”
5. O que é o Scrum?
É uma metodologia ágil
desenvolvida para atender a
necessidade de times pequenos
e de projetos que podem sofrer
mudanças a qualquer momento.
6. Scrum vs. (o tradicional) Waterfall
Waterfall
Requisitos Desenvolvimento Teste Entrega
Scrum
Requisitos
1º Semana
Arquitetura
2º Semana
Desenvolvimento
3º Semana
Teste
4º Semana
Entrega
5º Semana
1º Semana
2º Semana
4º Semana
3º Semana
Arquitetura
8. Transparência
“Um processo transparente revela
problemas antes mesmo que a sprint
sofra impacto.”
A transparência melhora a
comunicação, isso faz com que todos
os envolvidos saibam qual é o status
da sprint a qualquer momento.
9. Adaptação
“Não é raro e mais cedo ou mais tarde vai
acontecer! No meio da sprint vai aparecer
uma nova User Story com maior
prioridade. E ai? O que fazer?“
Em situações como esta todos os
envolvidos com o processo precisarão se
adaptar a mudança. Afinal de contas uma
US com maior prioridade (geralmente)
trás mais retorno ao cliente.
10. Inspeção
“A Daily Meeting e a Retrospectiva
têm o objetivo de inspecionar o
processo.”
O Scrum Master deve estar sempre
atento para encontrar e sanar os
problemas que a equipe vier a relatar.
12. Product Owner (PO)
•Definir a visão do produto;
•Gerenciar e priorizar o Product Backlog;
•Definir metas (claras) para a sprint;
•Aceitar ou rejeitar o produto entregue no fim da sprint;
•Facilitar o relacionamento entre a empresa contratante
e a contratada.
13. Time (Team)
•Agir de forma transparente;
•Atingir a meta da sprint;
•Atuar no micro-gerenciamento da sprint;
•Gerenciar os problemas e reportar
impedimentos;
•Realizar a Daily Meeting;
•Possuir uma formação multidisciplinar.
14. Scrum Master
•Garantir o uso de todas as práticas do Scrum;
•Remover impedimentos;
•Proteger o time de interferências externas... e internas;
•Preparar as próximas sprints junto ao Product Owner;
•Reciclar o conhecimento do time com relação ao Scrum;
•Atuar como um facilitador em todas as reuniões.
•Scrum Master não é cargo
17. Quadro Branco
“TO DO, DOING e DONE”
Geralmente o quadro é dividido com
três colunas, a primeira é TO DO, a
segunda DOING e a última DONE.
As tarefas (post-it) começam do lado
esquerdo e são movimentadas pelo
time de acordo com o andamento da
sprint.
18. Planning Poker
“O que deve ser levado em
consideração é complexidade e não
dificuldade.”
O time discute sobre as tarefas e
cada integrante baixa uma carta, o
valor dessa carta corresponderá a
complexidade da tarefa.
19. Burn Down
“Qualquer pessoa que passa na
frente do Burn Down consegue
ver o status atual da sprint”
Burn Down é um gráfico que da
visibilidade ao processo. Esse
gráfico é administrado pelo time
que deve atualizá-lo durante a
Daily Meeting.
22. Visão
A visão é definida pelo Product Owner, ela representa o desejo do cliente com
relação ao produto final.
23. Product Backlog
Administrado pelo PO, o product backlog é onde ficam as user stories que irão
complementar o software. O PO deve manter as user stories organizadas e
priorizadas de acordo sua importância e necessidade. Em alguns casos o PO pode
pedir a ajuda ao Scrum Master a fim de amadurecer um US.
24. Planning Meeting - I
A planning meeting é a reunião onde o PO apresenta ao Time a meta da sprint. Com
a meta definida o PO e o time selecionam as user stories relacionadas a ela. Depois
de selecioná-las o time usa o Planning Poker para estimá-las, e a partir dai
conseguirão saber quais tarefas irão entrar ou não na sprint.
É importante salientar que a meta nunca deverá ser “Entregar todas as tarefas”! É
responsabilidade do Scrum Master proteger o time contra isso.
25. Planning Meeting - II
Na planning meeting – II o time “quebra” as user stories em tarefas (tasks) e cada
uma delas deverá levar no máximo um dia pra ficar pronta. Isso dá maior visibilidade
ao time com relação ao andamento da sprint.
Importante: Antes do termino da reunião o time deve estabelecer uma definição de
Done que deverá ser respeitada para o resto da Sprint.
26. Sprint Backlog
O sprint backlog é onde as tarefas da sprint ficam armazenas, geralmente ele é
representado por um quadro branco com vários post-it. Esse backlog é administrado
pelo time, os integrantes vão pegando as tarefas de acordo com sua prioridade.
27. Daily Meeting
A daily meeting é uma das cerimônias mais importante do Scrum, é onde time
prática o micro gerenciamento da sprint. Os integrantes do time reportam “o que foi
feito ontem”, “o que será feito hoje” e “se há algum impedimento”. Durante a
reunião o time deve atualizar o quadro e o Burn Down.
28. Sprint
É recomendado que a sprint tenha entre duas e quatro semanas, durante esse
período o time não deverá ser interrompido. Qualquer impedimento deverá ser
reportado ao Scrum Master.
29. Review
Ao termino da sprint é feita a review onde o time apresenta ao PO o que foi feito
durante a sprint. Nessa reunião o PO tem total liberdade para aceita ou rejeitar
qualquer user story.
30. Retrospectiva
Na retrospectiva os integrantes do time devem responder três perguntas referente a
sprint:
1. O que aconteceu de bom?
2. O que aconteceu de ruim?
3. O que pode ser melhorado?
31. Incremento do Produto
O incremento do produto é basicamente um pacote com tudo que foi feito e
aprovado pelo Product Owner. As user stories que não foram aceitas ou que não
foram finalizadas deverão retornar ao product backlog, lá serão re-priorizadas pelo
Product Owner.
33. Evolução
“Scrumbut existe e é necessário!”
Muitos têm preconceito e por isso
criticam a simples menção do
termo, porém ignoram o fato de que
é quase impossível implantar os
Scrum, com todos os seus
elementos, de uma hora pra outra.
34. Framework Scrum
“Um dos pontos forte do Scrum é
apresentar os pontos fracos do
processo da empresa.”
Após algum tempo trabalhando com
o Scrum, os envolvidos sentirão a
necessidade de implementar outros
elementos para complementar o
processo. Esses elementos são como
“plugins“ instalados do Scrum.