Agilidade: SCRUM e XP

Transcrição

1 Agilidade: SCRUM e XP

2 Facilitador Fernando Costa formado em Redes de Computadores Sócio da 3LJ Tecnologia Agenda SCRUM: Contexto de projetos Valores ágeis Princípios ágeis Scrum

3 Paradoxo de Cobb We know why projects fail, we know how to prevent their failure so why do they still fail? Martin Cobb Treasury Board of Canada Secretariat Nós sabemos porque os projetos falham, sabemos como previnir Porque eles continuam falhando?

4 Reflexão do Caranguejo Todos os caranguejos ficam amarrados a um barbante que fica solto. Não é preciso amarrar pois todos querem fugir mas cada um que ir para um lado diferente. Ficam no mesmo lugar

5 Valores do Manifesto Ágil Indivíduos e interações Processos e ferramentas Software que funciona Documentação abrangente ao invés de Colaboração do cliente Negociação de contrato Resposta à mudanças Seguir um plano

6 Princípios do Manifesto Ágil 1 - O principal compromisso é com a satisfação do cliente, por meio da entrega mais rápida e contínua de produto com valor 2 - Receba bem as mudanças de requisitos(mesmo em estágios tardios do projeto). Processos ágeis devem admitir mudanças que trazem vantagens competitivas ao cliente 3 - Libere produto frequentemente (de 2 a 4 semanas), dando preferência para uma escala de tempo curta

7 Princípios do Manifesto Ágil 4 - Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhandos juntos a maior parte do tempo do projeto 5 - Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado 6 - O método mais eficiente e efetivo para repassar a informação entre a equipe é pela comunicação face a face

8 Princípios do Manifesto Ágil 7 - Produto funcionando é a principal medida de progresso de um projeto 8 - Processos ágeis promovem o desenvolvimento sustentado. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente 9 - Atenção contínua para excelência técnica e bom projeto (planejamento) aprimoram a agilidade

9 Princípios do Manifesto Ágil 10 - Simplicidade é essencial e deve ser assumida em todos os aspectos do projeto 11 - As melhores arquiteturas, requisitos e projetos emergem de equipes autoorganizadas 12 - Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento

10 SCRUM

11 Em resumo... Imagem disponível em:

12 Cliente (ou Product Owner) Quem é o nosso cliente? Funcionalidades do produto Decide as datas e conteúdo Rentabilidade (ROI) Ajusta e prioriza funcionalidades e prioridades Aceita o rejeita resultados

13 Scrum Master Remove obstáculos Não tem autoridade Produtividade da equipe Conduz eventos Escudo da equipe

14 Equipe 5 a 9 pessoas Multi-funcional Auto-organizável Sugere funcionalidades do produto

15 Product Backlog Lista de funcionalidades desejadas no projeto Os itens que compõe a lista são chamados de histórias ou itens de backlog Todos podem incluir histórias Somente o Product Owner pode priorizá-las Product Owner pode priorizar novamente no início de cada Sprint

16 Nosso Product Backlog ID Nome 1 Catálogo de produtos 2 Cesta de compras 3 Cadastro do cliente 4 Boleto bancário 5 Cartão de crédito Importância Estimativa Observação

17 Planning Poker Vamos estimar os itens de Backlog?

18 Nosso Product Backlog ID Nome Importância Estimativa Observação 1 Catálogo de produtos 3 2 Cesta de compras 5 3 Cadastro do cliente 2 4 Boleto bancário 4 5 Cartão de crédito 3

19 Qual a importância dos itens de backlog para o Product Owner?

20 Must Should Could Want (tem que ter) (deveria ter) (poderia ter) (interessante) Catálogo de produtos Boleto bancário Controle de estoque Videos dos produtos Cadastro de clientes Cartão de crédito Regras de promoção Cesta de compras Fotos dos produtos Registro do Pedido e entrega

21 Nosso Product Backlog ID Nome Importância Estimativa Observação Catálogo de produtos Cesta de compras Cadastro do cliente Boleto bancário Cartão de crédito 3 3 BB e CEF Visa e Mastercard

22 Sprint Deve ter um objetivo Período de 2 a 4 semanas Nenhuma mudança no sprint Processo baseado em uma série de iterações Produto é desenvolvido no sprint

23 Product Burnup Chart

24 Planejamento do Sprint Cliente, ScrumMaster e Equipe Cliente seleciona itens do Product backlog O Sprint backlog Tarefas identificadas e estimadas (1 a 16 horas) De forma colaborativa (por todos) Equipe compromete-se a concluir as tarefas

25 Planejamento do Sprint ID 1.1 ID - 1 Catálogo de produtos Administrador dos Produtos 10 horas ID 1.2 ID 1.3 Front-end da Loja 15 horas Busca fonética de produtos 2 horas

26 Scrum diário Tempo de 15 minutos Todos em pé Não é para a solução de problemas Todos são convidados Apenas a Equipe, ScrumMaster e Product Owner podem falar Sincronização do conhecimento Atualização do burnup chart 1. O que fiz desde a última reunião? 2. O que farei até a próxima reunião? 3. Existe algum obstáculo?

27 Gerenciando o Sprint backlog Cada membro da equipe escolhe a tarefa que fará Trabalhos nunca são atribuídos Atualização diária da estimativa do trabalho restante Equipe pode adicionar, apagar ou mudar tarefas (não itens de backlog)

28 Scrum board

29 Revisão do Sprint Informal Todos participam Hora do feedback Resultados do Sprint Comunicação eficaz: (bala / bombom)

30 Retrospectiva do Sprint Feita após cada Sprint Periodicamente observe pontos positivos e negativos Tipicamente de 15 a 30 minutos Todos participam

31 Inicia, Pára, Continua A equipe discute o que gostaria de: Iniciar a fazer Parar de fazer Esta é uma das várias maneiras de se conduzir uma retrospectiva do Sprint Continuar fazendo

32 Agora vocês explicam!!!

33 Resumo: Gerenciamento ágil Tópico Características Objetivo principal Orientado ao produto e centrado nas pessoas Tipo do projeto Projetos com mudanças constantes e que necessitam de respostas rápidas Tamanho Mais efetivo em projeto pequenos(5 a 9 pessoas) Gerente do projeto Papel de facilitador ou coordenador Equipe do projeto Atuação colaborativa em todas as atividades do projeto Cliente Essencial. Deve ser parte integrante da equipe do projeto Planejamento Curto e com a participação de todos os envolvidos na elaboração do planejamento Arquitetura Aplicação de design simples. Evolui junto com o projeto e baseia-se na refatoração Modelo de desenvolvimento Iterativo e Incremental Comunicação Informal Tópico Características

34

35 Dúvidas? Fernando Costa Patrocínio: Agradecimento:

36

37 Agenda do XP Desenvolvimento tradicional Valores Princípios Práticas

38 Fazer software é dureza

39 Boa notícia Cases de sucesso: Google Microsoft Philips FAB (BR) Oi Paggo Má notícia Seus colegas não vão acreditar O seu chefe não vai aceitar O chefe do seu chefe não pode nem pensar

40 Não é assim que se faz software Principais falhas: a) Não entregam o acordado b) Orçamento c) Prazo d) Todas alternativas

41 Utilização de funcionalidades Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group

42 64% de desperdício Podem gerar algumas horas extras para a equipe Cliente paga por lixo

43 Utilização de funcionalidades Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group

44 20% muito útil Geram pelo menos 80% do valor do produto 20%? desconhecido no início do projeto XP é a arte de maximizar a quantidade de software que você não vai fazer Vinícius Manhães Teles

45 Análise Pai(cliente): 1 dia de projeto Mãe(desenv.): 9 meses de projeto

46 Análise Cliente: Não era nada disso que eu queria...

47 Mentalidade

48 Cascata

49 Custo da Mudança por Barry Bohem

50 Problemas e mudanças Patente do VELCRO: em 1941 por Georges de Mestral

51 Meio digital Fluidez Maleabilidade Invisibilidade Complexibilidade (elementos distintos) Baixo custo de manufatura Rapidez evolução

52 Nova mentalidade Chef Escritor

53 extreme Programming

54

55 Valores do XP o ã ç a c i un m o C m e g a r o C Respeito e d a d i il c p m Si k c a b d e Fe

56 Uma pergunta Como você programaria se tivesse tempo suficiente? Kent Beck

57 Possíveis respostas Mais testes? Mais projeto e arquitetura? Menos pessoas? Mais qualidade?

58 Programando ao Extremo Testar toda hora!! Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! Integrar a maior quantidade de vezes possível! Iterações realmente curtas!

59 Práticas Cliente Presente Código Coletivo Testes de Aceitação Test-Driven Development Programação em pares Integração Contínua Coding Standard Refactoring Design Simples Planning Game Ritmo Sustentável Metáfora Releases Curtas Adaptado de xprogramming.com

60 Jogo do Planejamento Reunião semanal onde todos participam Escopo reavaliado Cliente prioriza e seleciona as histórias que serão desenvolvidas Ao fim da semana o cliente recebe produto funcionando

61 Reunião em pé 10/15 minutos Todos em pé Não é para a solução de problemas Todo mundo é convidado Apenas a Equipe pode falar Sincronização do conhecimento 1. O que fiz desde a última reunião? 2. O que farei até a próxima reunião? 3. Existe algum obstáculo?

62 Cliente presente e envolvido Responsabilidade do projeto: Equipe Cliente Comprometimento

63 Ritmo sustentável Semana de 40 horas (8hr/dia) Sem hora extra: Baixa produtividade Código de má qualidade Aumento de BUGs

64 Programação em par Forneça suporte e ferramentas Experimente, você vai se surpreender Alterne os pares para não ficar cansativo e nivelar o time Respeite a individualidade das pessoas

65 Código Padronizado

66 Código Coletivo Inibe ilhas de conhecimento Padrão de codificação Membro da equipe pode ter férias Direito de ficar doente

67 Integração Contínua Divergências aparecem antes de virar um problema Isso funcionava na minha máquina

68 Projeto Simples Faça o essencial Tudo pode mudar

69 Refatoração Time que está ganhando não se mexe FALSO Ex.: Empresas estáveis quebram se não mudarem Melhoria contínua

70 Desenvolvimento Orientado a Testes (TDD) Início é um pouco demorado Primeiro o teste, depois a funcionalidade para passar no teste Testes automatizados: Unitários, Interface e Aceitação RETORNO: Salvação no FIM do projeto

71 Releases curtos

72 Papéis Coach Goal Donnor Tracker Manager Gold Owner Programador Analista de Testes

73 Equipe nivelada

74

75 Dúvidas? Fernando Costa 3LJ Tecnologia Agradecimento: Vinícius Manhães Teles Improve It