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?