Metodologias ágeis
Flávio Steffens de Castro
Projetos … ?
Quais são as características de
um projeto?
– Temporário (início e fim)
– Objetivo (produto, serviço e resultado)
– Único
– Recursos limitados
– Planejados, executados e controlados
1
Problemas comuns nas empresas de TI
Vamos identificar alguns problemas que
vocês já vivenciaram no trabalho?
Problemas comuns nas empresas de TI
Pessoas
Clientes
Processos
- Quantos dos problemas citados se
enquadram nestas “variáveis globais”?
- Como resolver isso?
2
Agilidade,
Agilidade
by Dilbert
Agile Manifesto (2001)
Princípios para agilidade em projetos de
software
– “Individuals and interactions over
processes and tools”
– “Working software over comprehensive
documentation”
– “Customer collaboration over contract
negotiation”
– “Responding to change over following a
plan”
3
Metodologias ágeis
Agilidade para projetos:
SCRUM;
Agilidade para produtos:
XP, FDD, TDD, etc.
Agilidade para ambos (framework):
OpenUP.
SCRUM
Criado por Ken Schwaber e Jeff Sutherland em
1996;
Surgiu para recuperar um projeto problemático;
Ciclo PDCA;
Foco em valor e nas interações;
Mudanças são incentivadas;
“Time boxed”;
Processo empírico.
– Não sabemos ao certo onde queremos chegar
– Desenvolvemos baseados nas experiências
4
Atores do SCRUM
São três atores principais e mais um grupo
de secundários:
– PRODUCT OWNER
– SCRUM MASTER
– TEAM
E os secundários:
– CHICKENS
Envolvimento x Comprometimento
5
Atores do SCRUM (obrigações)
PRODUCT OWNER
– Levantar requisitos, gerenciar e priorizar o
product backlog (lista de funcionalidades),
aceitar o software ao final de cada iteração.
SCRUM MASTER
– Cuidar da equipe, trabalhar com o product
owner, remover impedimentos, manter o
processo funcionando.
TEAM
– Estimar o tamanho dos itens do backlog,
assumir compromisso com a entrega, autoorganizar-se.
SCRUM flow
6
Planejamento estratégico
Product Owner e Cliente
Visão do produto
– Definição das primeiras user stories
e constraints
Criação do primeiro product
backlog
– Conjunto de user stories do sistema
– Priorização inicial das user stories
Planejamento estratégico
User stories
– Funcionalidades
– Identificação dos atores
– I.N.V.E.S.T. (independente, negociável,
valorizável, estimável, small e testável)
– Linguagem de negócio
“Criar indexes nas tabelas” “Aumentar a velocidade da busca” ☺
7
Planejamento estratégico
User stories
Escopo
Product Owner
Team
Estimativas
Importância
E a qualidade?
– Não é negociável. Nunca! … ou quase!
Planejamento estratégico
User stories (index cards)
8
Planejamento tático
Product Owner, Scrum Master e Equipe
Análise e organização do Product
Backlog
– Definição do objetivo (goal) do sprint
– Estimativas
– Formalização do sprint backlog
– Identificação das tarefas
– Organização da taskboard
Planejamento tático
Sprint Goal
– Definido pelo Product Owner
– Norteia e auxilia em decisões
“Por que estamos fazendo isso?”
– Sempre em nível de negócio
– DEVE EXISTIR EM CADA SPRINT!
“Antes um objetivo meia-boca, do que
nenhum!”
9
Planejamento tático
Importância
– Prioridade da user story
– Valor entre 1 e 150
1 : menos prioritária
150: mais prioritária
– Definida pelo Product Owner, com base
nas necessidades do cliente
Planejamento tático
Estimativas
– Tempo e/ou complexidade?
– Conceito de PONTOS (story points)
– Fibonacci
1, 2, 3, 5, 8, 13, 21…
– Planning poker
– Tarefas:
1-day tasks
Considerar tarefas como teste,
pesquisas, documentação, etc.
10
Planejamento tático
Planning poker
– Técnica para estimar user stories
– Força todos a participarem e evita influências
– Induz ao debate de estimativas
– Agiliza e torna a estimativa algo divertido
Planejamento tático
Product Backlog x Sprint Backlog
– O PB é o repositório do projeto
– O SB são as user stories selecionadas
para o sprint
– O tamanho do SB é definido por:
Velocidade (em story points)
Gut feel (“achismo”)
– Previsto x realizado
User story não finalizada volta para o
Product Backlog.
11
Planejamento tático
Product Backlog x Sprint Backlog
A
D
A
H
D
C
H
B
C
E
Total: 22 story points
G
F
Total: 48 story points
Planejamento tático
Agenda típica da reunião
14:00 – 14:30
Definição do sprint goal, datas importantes,
data e local da apresentação.
14:30 – 16:00
User stories são estimadas e repriorizadas,
se necessário. Detalhamento das principais.
16:00 – 16:30
Seleção das stories que farão parte do
sprint. Estimativa da velocidade.
16:30 – 17:30
Quebra das user stories em tarefas.
Preparação da taskboard. Definição de data
e local da daily scrum.
Sim, a reunião dura uma tarde!
12
Planejamento operacional
Scrum Master e Equipe
Dia-a-dia do SCRUM
– Sprint
2, 3 ou 4 semanas
– Daily meetings
– Impedimentos
Obstáculos ao trabalho da equipe
– Manutenção do taskboard
Burndown
Tarefas e estimativas
Tarefas não-planejadas
Planejamento operacional
Daily Meetings (daily scrum)
– Reunião diária de 15 minutos
– Mantém equipe informada e integrada
O que você fez ontem?
O que pretende fazer para amanhã?
Quais são seus impedimentos?
– Questões técnicas
No final da reunião
– Rápida identificação do problema e atraso
13
Planejamento operacional
Impedimentos
– Algo que esteja fora do alcance da equipe
– Deve ser reportado ao Scrum Master e
também na daily scrum
– Impedimento x pró-atividade:
☺
“Preciso instalar um software e preciso da
autorização da FACIN”
☺
“Eu não sei programar em Java”
“Preciso comprar um novo componente”
“Eu não sei o que tenho que fazer!”
Taskboard
Por que ter uma taskboard física?
– Contém todas as informações essenciais
– Fisicamente ela é visível o tempo todo
– Sabemos rapidamente:
Estágio atual do sprint
Responsáveis
Objetivos
Problemas e impedimentos, e suas causas
14
Taskboard (algum dia qualquer)
Taskboard (Erro de prioridades!)
15
Taskboard (Tarefas extras demais!)
Burndown
O burndown traduz a taskboard graficamente
– X-axis: dias do sprint
– Y-axis: pontos ou horas restantes
Sprint ideal
Sprint adiantada
Sprint atrasada
“Beleza! Vamos manter assim!”
“Vamos acrescentar uma nova
user story!”
“Precisamos diminuir o sprint
backlog!!”
16
Sprint review (demo)
Cliente, PO, SM e Team
Apresentação do produto
– Cliente pode (e deve)
testar o sistema
Foco no QUE foi feito e
não COMO foi feito
Pode ser um evento social
Evita os 99,9% finalizados
Aceite formal e feedback do cliente
RELEASE x RELEASABLE
Retrospective
PO, SM e Team
Avaliação da sprint
– O que foi bom?
– O que poderia ter sido
melhor?
– Onde podemos melhorar?
Coleta cronológica de fatos e eventos da sprint
Lições aprendidas
– Identificação dos erros e aprendizado para não
repetí-los.
17
Próximo sprint
Lições aprendidas
– Alimentam o próximo sprint
Velocidade da equipe
Erros x acertos
Previsto x realizado
– Repositório de lições
– Disseminação na empresa
Lições aprendidas
SCRUM flow
18
O que eu aprendi com SCRUM
Agente motivador
– Cliente e empresa
Baixíssima resistência à mudança
– Em curto prazo, todos já praticam
Comunicação maximizada
– O “status” era discutido diariamente
Planejamento facilitado
– Impossível planejar tudo antes
O que eu (também) aprendi com SCRUM
Capacitação de equipe
– Teste e qualidade
Motivação x comprometimento
– Maturidade da equipe deve ser
considerada
Buy-in da direção
– Direção precisa dar suporte
Conceitos conservadores perduram
– Waterfall, fases, equipes distintas…
19
Próximos passos
Simulação de um sprint (zero)
– Praticar SCRUM com os seus projetos
– Duração de uma semana
– Atores para esta experiência:
Product owner: Flávio
Scrum master: Leonardo Amaral
Team: as respectivas equipes
Clientes: coordenadores
Próximos passos
DATA
ATIVIDADES
DURAÇÃO
6a-feira
18/04
Definição de duas user stories em cada projeto.
Priorização inicial das mesmas.
15 min
3a-feira
22/04
Preenchimento das index cards. Estimativas (planning
poker). Definição de tarefas. [Desenvolvimento].
30 min
4a-feira
23/04
Daily scrum e desenvolvimento.
Dia
5a-feira
24/04
Daily scrum e desenvolvimento.
Dia
6a-feira
Daily scrum e desenvolvimento. Sprint Review e
Retrospectiva,
com a presença de todos, no fim do dia.
25/04
Dia
20
Conclusão
Dúvidas, sugestões, críticas?
21