Retrospectivas e Scrum

Transcrição

1 Retrospectivas e Scrum Rodrigo de Toledo (Cenpes, Petrobras) Junho 2009 Agile Brazil 2009 Rio de Janeiro

2 Objetivos 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 Plano Scrum Flow Empirismo Inspeção/Adaptação Melhoria Contínua Preparando uma boa Retrospectiva Invertendo Retrospectiva-Review Siviep Conclusão / Agradecimentos

5 Scrum Flow + Review

6 Estatísticas Quantos praticam Scrum? Quantos fazem retrospectivas regulares? Por que é importante fazer retrospectivas a cada iteração?

7 Modelos de gestão Métodos determinísticos X Métodos empíricos

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 Cenário dinâmico

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 Não tem copiar-colar Padrões se repetem

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. [Sutherland et al. 08]

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 Controle obssesivo? Caótico Goal: ficar para cá do edge of chaos Criatividade organizada

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 (aproximação sucessiva)

18 Matematicamente Função do 2º grau: F(x) = ax²+bx+c Raízes da equação : ax²+bx+c = 0 x= b± Δ 2a Vértice da parábola (min/max): b, -Δ 2a 4a Aproximação sucessiva (iterativamente) i

19 Matematicamente (ainda pode ficar pior) Equação do 4º grau: 1ª lição: Quanto maior a complexidade, mais vantajoso resolver iterativamente

20 Matematicamente (ainda pode ficar pior) 2ª lição: Cuidado para não ficar preso ao mínimo local (ou ótimo local) Solução: Breaktrough

21 Matematicamente (ainda pode ficar pior MESMO!) Condições mudam com o tempo Mais de uma variável? 3ª lição: Quanto mais variáveis, mais complexo, especialmente se forem dependentes Mais complexo ITERATIVO 4ª lição: Não existe zona de conforto Melhoria contínua

22 Chega de matemática!

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 Objetivo: Melhoria contínua!!!

24 Inspeção / Adaptação

25 Empirismo Inspeção/adaptação Melhoria contínua Retrospectiva

26 Scrum Cycle São 6 diferentes meetings Daily meetings... Sprint i Estimation (planning poker) Review Retrospective Daily meetings Sprint i +1 Estimation (planning poker) Sprint Planning 2 Sprint Planning 1...

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 Retrospectiva

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 ) (*) Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

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! FAÇA RETROSPECTIVAS!!!

32 Invertendo RetrospectiveReview Burn Down Re v ie w

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 i+1 Planning 1 i+1 Planning 2 1 dia 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 Review Retrospective Daily meetings... Sprint i 1 day Daily meetings Sprint i +1 Estimation (planning poker) Estimation (planning poker) Retrospective Review Sprint Planning 2 Sprint Planning 1...

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 Plataforma (PNA-I) Plataforma (PNA-II) Poços Reservatório Falhas da Superfície

40

41 2008

42 2009

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? Não é a Review, mas a Retrospective

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

45 Perguntas???