Retrospectivas e Scrum

(1)

Retrospectivas e Scrum

Rodrigo de Toledo

(Cenpes, Petrobras)

Junho 2009

Agile Brazil 2009 – Rio de Janeiro

(2)

• Explicar a importância da Retrospectiva

– Do ponto de vista teórico – Do ponto de vista prático

• Dicas para uma boa Retrospectiva • Mostrar uma possível adaptação:

– Review  Retrospectiva

• Caso de sucesso

• Levantar algumas estatísticas

(3)

Estatísticas

• Quem está tendo o primeiro contato com métodos ágeis?

• Quantos conhecem Scrum? • Quantos não são de TI?

• Quantos são de fora do Rio? • ...

(4)

• Scrum Flow

• Empirismo

• Inspeção/Adaptação • Melhoria Contínua

• Preparando uma boa Retrospectiva

• Invertendo Retrospectiva-Review

• Siviep

• Conclusão / Agradecimentos

(5)

Scrum

Flow

(6)

Estatísticas

• Quantos praticam Scrum?

• Quantos fazem retrospectivas regulares?

• Por que é importante fazer

(7)

Modelos de gestão

Métodos determinísticos

X

(8)

Métodos determinísticos

(definidos ou prescritivos)

• Apropriados para: – Trabalhos repetitivos, previsíveis – Linha de produção • Planejamento / Execução • Controle:

execução de acordo com o plano? • Modelo cascata

(9)

Administração

Moderna

• Peter Drucker

“A maioria das discussões sobre tarefas dos trabalhadores do conhecimento (Knowledge Worker) começa com o conselho para que o indivíduo planeje seu trabalho.

Parece muito plausível. A única coisa errada é que raramente funciona. Os planos permanecem no

papel, sempre ficam como boas intenções. Raramente se tornam conquistas.”

(10)

Métodos Empíricos

• Apropriados para:

– Desenvolvimento criativo – Não repetitivo

– Pouco (ou nada) previsível

(11)

Métodos Empíricos

• Desenvolvimento criativo

– Trabalho igual ao do pintor!

• Trabalho criativo:

– Não linear – Não braçal

(intelectual) – 24/24h

(12)

Métodos Empíricos

• Não repetitivo

(13)

Métodos Empíricos

• Pouco (ou nada) previsível

– Princípio da Incerteza de Ziv:

Incerteza é inerente e inevitável em desenvolvimento de software.

– Princípio da Incerteza de Requisitos de Humphrey:

Em um novo sistema os requisitos não serão completamente conhecidos até que os usuários o tenham usado.

– Lema de Wegner:

Não é possível especificar completamente um sistema interativo.

(14)

Métodos Empíricos

• Cenário dinâmico

– Decorrentes da imprecisão do levantamento de requisitos

– Decorrentes das mudanças de necessidades do negócio

– Mudanças de tecnologia

• maiores em impacto • e frequência

(15)

Controlando o caos

• Cuidado com o caos

• Goal: ficar para cá do “edge of chaos”

– Criatividade organizada

Controle obssesivo

Caótico

(16)

Métodos Empíricos

• Evitam o BDUF (Big-Design Up Front) • Iterativo

– Iterações curtas com feedback constante

• Baseados em:

– Inspeção / Adaptação – Aproximação sucessiva

– Melhoria contínua (inerente)

• Do produto • Do processo

(17)

Matematicamente

Solução Analítica

X

Solução Iterativa

(18)

Matematicamente

• Função do 2º grau:

F(x) = ax²+bx+c

• Raízes da equação :

ax²+bx+c = 0

• Vértice da parábola (min/max):

• Aproximação sucessiva (iterativamente) Δ = b 2 – 4ac x = – b ± √ Δ 2a –b -Δ 2a 4a, i+1+2+3+4+5

(19)

Matematicamente

(ainda pode ficar pior)

• Equação do 4º grau:

1ª lição:

• Quanto maior a complexidade,

(20)

2ª lição:

• Cuidado para não ficar preso ao mínimo local (ou ótimo local)

• Solução: Breaktrough

Matematicamente

(21)

• Condições mudam com o tempo

4ª lição:

• Não existe zona de conforto

 Melhoria contínua

• Mais de uma variável

3ª lição:

• Quanto mais variáveis, mais complexo, especialmente se forem dependentes Mais complexo  ITERATIVO

Matematicamente

(ainda pode ficar pior MESMO!)

(22)

(23)

Inspeção / Adaptação

• Inspeção – Minuciosa – Não é controle – É monitoramento • Adaptação – Adaptar o que? • O produto • O planejamento • A documentação • O processo • ... – Democraticamente

(24)

(25)

Empirismo

Inspeção/adaptação

Melhoria contínua

(26)

Scrum Cycle

Sprint i Sprint i +1 _...

...

Review Retrospective

Daily meetings Daily meetings

Sprint Planning 2 Sprint Planning 1 Estimation (planning poker) Estimation (planning poker)

(27)

Retrospectiva

• Objetivo:

– Rediscutir o processo propondo melhorias

• Informações Gerais:

– Apenas o time participa (existe exceção) – Ambiente seguro

(28)

Procedimento

• Repassar a sprint cronologicamente

– Coletivamente – Scrum Master

• Levantar melhorias

– 5 min de WWWs em post-it

What Went Well? (o que aconteceu de bom?) What Went Wrong? ( “What can be improved?”)

• Discutir os itens

– Quem é responsável por cada item? Scrum Master ou time?

• Hansei / Kaizen • Fechamento

(29)

Realizando uma boa

(30)

Minha experiência

• PPT para conduzir reunião

• Começando por:

“Independente do que será discutido, nós entendemos e acreditamos que todos fizeram o seu melhor, dado o que sabiam naquele momento, suas habilidades e competências, os recursos disponíveis e as circunstâncias da situação” (*)

• Ou seja, vamos evitar acusações: “no names” 

• Slide com resumo da sprint (goal, stories, points, burn-down)

• WWWs

• Compromisso time • Preparar Review

• Levantamento das infos práticas para a próxima sprint (pessoas…)

(31)

Outras Dicas

• Proponha uma retrospectiva da retrospectiva

• Continuem lendo e estudando...

• Mesmo para times altamente eficazes:

– Melhoria contínua!!!

• Não faça várias mudanças ao mesmo tempo (exceto se for um Breaktrough)

– Priorize!

(32)

Invertendo

Retrospective-Review

Rev iew _Rev iew Bu rn Dow n

(33)

Invertendo

Retrospective-Review

• Período de Transição de SPRINT

Sprint Meeting tempo Product Owner i Review 4h

i Retrospective 4h i+1 Planning 1 4h i+1 Planning 2 4h

(34)

Invertendo

Retrospective-Review

• Agrupando participação do PO

Sprint Meeting tempo PO i Retrospective < 2h i Review 1 dia i+1 Planning 1 i+1 Planning 2 Participação contínua do Product Owner

(35)

Prós e Contras

• OBS:

– Time-box das reuniões alterados

– Funciona bem para 1 time com PO cliente

• Pontos positivos:

– Participação do Prod. Owner em 1 único dia – É natural emendar Review com Planning

– Apenas 1 dia sem produção

– Pode-se preparar a Review com o time

– Pode-se discutir impedimentos levantados na Retrospective

• Ponto negativo:

– Retrospective sem informações da review

Burn Down

(36)

Scrum Cycle

alterado

Sprint i Sprint i +1 _...

...

Retrospective Review

Daily meetings Daily meetings

Sprint Planning 2 Sprint Planning 1 Estimation (planning poker) Estimation (planning poker) • Review  Retrospective 1 day

(37)

SiVIEP

Sistema de Visualização Integrada para o E&P

(38)

SiVIEP

• Alta complexidade de requisitos:

– Multi-plataforma – Realidade Virtual

• Renderização distribuída

• Interação com dispositivos 3D

– Suporte a grafo de cena – Som 3D

– Cluster

– Colaborativo

– Acesso às funcionalidades via script – Arquitetura de componentes

– Sistema de Plug-in’s – Open source

– Plataforma de desenvolvimento para outras universidades – Browser 3D

(39)

Poços

Plataforma (PNA-I) Plataforma (PNA-II)

Reservatório

(40)

(41)

(42)

(43)

Conclusão

• Vamos criar um novo método ágil? • Retrospectiva:

– Inspeção e adaptação do processo

• Review:

– Inspeção e adaptação do produto

• Inverter review e retrospectiva é apenas uma sugestão

• Qual a meeting mais importante do Scrum?

(44)

Agradecimentos

• Petrobras

– Ismael Santos, Luciano Reis, Mauro Becker – turma ESBR08, ADS-TI, SNEP, CENPES

• Tecgraf

– Thiago Bastos, Börje, Alberto, Gattass, Luciano Soares, Pedro Mário, time Siviep

• Referências usadas na apresentação

– Boris Gloger, Ken Schwaber, TeamWare, Sprintit, Clark & Vizdos, Paulo Caroli

Retrospectivas e Scrum