Rosa Mitsumasu Rebecca Wagner Jonathan Steffens Kevin Harvey.
Flávio Steffens de Castro - UFPEcin.ufpe.br/~ccb2/Engenharia de...
Transcript of Flávio Steffens de Castro - UFPEcin.ufpe.br/~ccb2/Engenharia de...
1
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
2
Problemas comuns nas empresas de TI
� Vamos identificar alguns problemas quevocê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?
3
Agilidade, by DilbertAgilidade
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”
4
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
5
Atores do SCRUM
� São três atores principais e mais um grupode secundários:
– PRODUCT OWNER
– SCRUM MASTER
– TEAM
� E os secundários:
– CHICKENS
Envolvimento x Comprometimento
6
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, auto-organizar-se.
SCRUM flow
7
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” ☺
8
Planejamento estratégico
� User stories
Escopo
Estimativas Importância
� E a qualidade?– Não é negociável. Nunca! … ou quase!
Product Owner
Team
Planejamento estratégico
� User stories (index cards)
9
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!”
10
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.
11
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.
12
Planejamento tático
� Product Backlog x Sprint Backlog
A
D
H
C
B
E
G
F
A
D
H
C
Total: 48 story points
Total: 22 story points
Planejamento tático
� Agenda típica da reunião
� Sim, a reunião dura uma tarde!
Quebra das user stories em tarefas. Preparação da taskboard. Definição de data
e local da daily scrum.16:30 – 17:30
Seleção das stories que farão parte do sprint. Estimativa da velocidade.
16:00 – 16:30
User stories são estimadas e repriorizadas, se necessário. Detalhamento das principais.
14:30 – 16:00
Definição do sprint goal, datas importantes, data e local da apresentação.
14:00 – 14:30
13
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
14
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
15
Taskboard (algum dia qualquer)
Taskboard (Erro de prioridades!)
16
Taskboard (Tarefas extras demais!)
Burndown
� O burndown traduz a taskboard graficamente
– X-axis: dias do sprint
– Y-axis: pontos ou horas restantes
“Precisamos diminuir o sprint backlog!!”
“Vamos acrescentar uma nova user story!”
“Beleza! Vamos manter assim!”
Sprint atrasadaSprint adiantadaSprint ideal
17
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 sidomelhor?
– Onde podemos melhorar?
� Coleta cronológica de fatos e eventos da sprint
� Lições aprendidas
– Identificação dos erros e aprendizado para nãorepetí-los.
18
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 empresaLições aprendidas
SCRUM flow
19
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…
20
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
DURAÇÃOATIVIDADESDATA
Daily scrum e desenvolvimento. Sprint Review e Retrospectiva, com a presença de todos, no fim do dia.
Daily scrum e desenvolvimento.
Daily scrum e desenvolvimento.
Preenchimento das index cards. Estimativas (planning poker). Definição de tarefas. [Desenvolvimento].
Definição de duas user stories em cada projeto. Priorização inicial das mesmas.
Dia6a-feira
25/04
Dia5a-feira
24/04
Dia4a-feira
23/04
30 min3a-feira22/04
15 min6a-feira18/04
21
Conclusão
� Dúvidas, sugestões, críticas?