um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO

Transcrição

1 um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO

2 Um pouco de história... Década de 50: a gestão de projetos é reconhecida como disciplina, nascida a partir da administração Henri Fayol: Seu trabalho é a base para a gestão de projetos tradicional O gestor possui 5 funções básicas: Planejar Organizar Comandar Controlar Coordenar O gráfico de Gantt é adotado como ferramenta para listar, acompanhar e controlar a execução das tarefas contidas em um projeto.

3 Um pouco de história... Até então a gestão de projetos é voltada para grandes projetos de engenharia e construção civil. Década de 60: o desenvolvimento de software começa a ganhar complexidade. Para gerenciar projetos de software, as empresas utilizam a medotologia tradicional antes aplicada a projetos de engenharia e construção civil. Winston Royce (1970): artigo criticando a abordagem tradicional para a gestão de projetos de software, que fica conhecida como waterfall.

4 Um pouco de história... Waterfall, por Winston Royce (1970)

5 Um pouco de história...

6 Um pouco de história... Waterfall segue o conceito Big Design Up Front (BDUF). Os defensores do BDUF acreditam que o tempo gasto revisando exaustivamente a especificação garante a ausência de mudanças críticas na fase de execução. McConnell (1996): corrigir erros ainda na fase de especificação gasta entre 50 e 200 vezes menos tempo do que se o erro fosse encontrado durante a execução do projeto.

7 Um pouco de história... DeGrace & Stahl (1990): Fatores que tornam questionável o uso de BDUF para projetos de software: Requisitos não são completamente compreendidos no início do projeto; Usuários só sabem exatamente o que querem após ver uma versão inicial do software; Requisitos mudam durante o processo de desenvolvimento; Novas ferramentas e tecnologias tornam a estratégia de desenvolvimento imprevisível. BDUF é considerado adequado apenas para projetos estáveis, com pouca ou nenhuma mudança.

8 Um pouco de história... Recente pesquisa no Brasil com gerentes de projeto aponta a mudança de escopo (71%) como o fator principal para insucesso em projetos de software. Meredith & Mantel: problemas de comunicação e entendimento do que deve ser feito são responsáveis por falhas nos projetos. Metodologias tradicionais sugerem que: Mudanças devem ser evitadas a todo custo. Se não for possível evitá-las, o gerente de projetos deve gerenciá-las. Para as metodologias tradicionais, a mudança tem um efeito devastador

9 Um pouco de história...

10 Um pouco de história... Ken Schwaber (2007): Não há mais soluções simples de software. Quando requisitos complexos encontram tecnologias complexas, a complexidade da solução cresce exponencialmente.

11 Um pouco de história...

12 Um pouco de história... Fonte: Standish Group

13 Agilidade

14 Manifesto Ágil representantes de processos leves de desenvolvimento de software se reuniram para discutirem o que seus processos possuíam em comum. O resultado foi o Manifesto Ágil: "Estamos descobrindo maneiras melhores de desenvolver software fazendoo nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda."

15 Princípios Ágeis Satisfação do cliente através da entrega rápida e frequente de produto funcional Produto funcional é a principal medida de progresso do projeto Mudanças são vistas como parte natural do processo e são bem-vindas Cooperação diária entre a equipe de projeto e o pessoal de negócios Comunicação aberta dentro da equipe

16 Princípios Ágeis Equipe de pessoas motivadas, com o suporte necessário e confiança Atenção contínua para o bom design e excelência técnica Simplicidade. Nada de desperdícios! Equipes autogerenciadas: Empowerment! Foco maior nas pessoas do que nos processos Melhoria contínua

17 Aplicação Métodos Ágeis não servem apenas para desenvolvimento de software!

18 Aplicação Métodos ágeis podem ser utilizados em projetos em que há: - Ambiente de mudanças frequentes - Requisitos - Tecnologia - Leis e regras - Ambiente de incertezas - Necessidade de entrar rapidamente no mercado - Oportunidades - Responder a uma ameaça

19 Aplicação Exemplos: Alexandre Magno (CST): Scrum Executivo mudança organizacional Projetos de Marketing Projetos de Hardware Infra-estrutura Jogos olímpicos, Copa do mundo

20 O que é Scrum?

21 Scrum......é um framework para desenvolvimento de produtos complexos em ambientes complexos;...não é um processo ou técnica: dentro de Scrum podem-se empregar diversos processos e técnicas;...utiliza abordagem iterativa e incremental para melhorar a predizibilidade e o controle de riscos;...gera entrega frequente de valor para o cliente;...torna transparentes problemas das práticas de desenvolvimento, para que se possa melhorá-las;...utiliza inspeção e adaptação para melhoria contínua, em ciclos de feedback.

22 Scrum: Origens Ken Schwaber: Jeff Suttherland: jeffsutherland.com Mike Beedle: The New New Product Development Game, de Takeuchi e Nonaka Sistema de Produção da Toyota: modelo enxuto e just-in-time

23 Processos Definidos X Empíricos Processo definido Ambientes controlados ex: linhas de produção Processo empírico: Complexos e imprevisíveis Scrum é embasado na teoria de controle de processos empíricos Três pilares sustentam a teoria de controle de processos empíricos: Transparência, Inspeção e Adaptação

24 Pilares

25 Os Pilares do Scrum #1: Transparência Aspectos que afetam o resultado do projeto devem ser visíveis para os que gerenciam estes resultados O que é visto deve ser compreendido: se quem inspeciona o processo acredita que está pronto, isso deve corresponder à definição de pronto utilizada

26 Os Pilares do Scrum #2: Inspeção Deve haver inspeção no processo com frequência suficiente para se detectar variações inaceitáveis

27 Os Pilares do Scrum #3: Adaptação Ao se detectar variações inaceitáveis, o processo deverá ser ajustado o tão rápido quanto possível para se minimizar desvios ainda maiores

28 Introdução ao Ciclo do Scrum

29 O Ciclo do Scrum O representante Ele então A equipe insere do E, em cliente, então faz estes seguida, o o trabalho requisitos PRODUCT reúne se reúne no com ciclo para o de a OWNER, em representante levanta uma desenvolvimento, Em Ao lista cada final A equipe com priorizada, do dia, ciclo do o a então cliente equipe chamado de chamada desenvolvimento, requisitos e faz reúne decide, uma com SPRINT a reunião o a partir de RETROSPECTIVA, onde verifica o que mais dessa BACKLOG representante equipe prioritários 15 lista minutos terá de DO produzido no requisitos, para PRODUTO do cliente momento promover um na incremento REUNIÃO o que visibilidade DE no será feito e funcionou bem e o que pode melhorar no produto, REVISÃO que e significa no próximo ciclo comunicação apresenta valor o que para foi o feito cliente próximo ciclo de desenvolvimento: o BACKLOG DA SPRINT REUNIÃO DIÁRIA BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

30 Papéis

31 Papéis no Scrum ScrumMaster: responsável por garantir que o processo é entendido e seguido Product Owner: responsável por maximizar o valor, para o cliente, do trabalho que o Time de Scrum faz Time de Scrum: é a equipe, que faz o trabalho propriamente dito

32 Papéis no Scrum: O ScrumMaster Garante a adesão do time aos valores do Scrum, práticas e regras Ajuda o Time de Scrum e a organização a adotarem o Scrum Remove os impedimentos que atrapalham o trabalho do Time de Scrum Ajuda o Time de Scrum a usar o auto-gerenciamento e a multidisciplinaridade, a ser mais produtivo e a ter mais qualidade O ScrumMaster não gerencia o Time de Scrum: o Time de Scrum é auto-organizável

33 Papéis no Scrum: O Product Owner Gerencia a lista de requisitos (Backlog do Produto) através do contato frequente com o(s) cliente(s), e garantir sua visibilidade a todos Assegura o valor do trabalho realizado pelo Time de Scrum: garante o ROI do cliente Gerencia a visão do produto: estabelece, mantém e comunica Gerencia as entregas do produto para o cliente É sempre uma pessoa, e não um comitê. Mas pode ser aconselhado/influenciado por outras pessoas Suas decisões devem ser respeitadas: ninguém mais pode mudar as prioridades

34 Papéis no Scrum: O Time de Scrum É a equipe de desenvolvimento do projeto, com 5 a 9 membros, que: Transformam a lista de requisitos (Backlog do Produto) em incrementos de funcionalidades potencialmente entregáveis em cada iteração São multidisciplinares: todo conhecimento necessário para gerar o incremento Não há títulos no Time de Scrum Gerenciam a iteração de desenvolvimento São auto-organizáveis: ninguém diz ao Time de Scrum como transformar o Backlog do Produto em incrementos entregáveis.

35 O Ciclo do Scrum

36 Backlog do Produto O Product Owner levanta com o(s) cliente(s) os requisitos mais prioritários naquele momento REUNIÃO DIÁRIA BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

37 Backlog do Produto O Product O Product Owner Owner levanta insere com estes o(s) cliente(s) requisitos requisitos no BACKLOG mais prioritários DO naquele PRODUTO momento REUNIÃO DIÁRIA BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

38 O que é o Backlog do Produto? É uma lista incompleta e dinâmica dos requisitos do produto, ordenados por prioridade de desenvolvimento A prioridade é determinada por: valor que gerará ao cliente naquele momento, risco e necessidade Contém funcionalidades, correções de bugs, tecnologias e melhorias que constituem a mudança que será implementada no produto O Product Owner é o responsável por atualizar, priorizar e dar visibilidade ao Backlog do Produto Nunca está completo evolui à medida que o produto e o ambiente evoluem Seus itens possuem descrição e estimativa em pontos de esforço. Itens do alto da lista são de menor granularidade e mais detalhados

39 O que é o Backlog do Produto? É uma lista incompleta e dinâmica dos requisitos do produto, ordenados por prioridade de desenvolvimento A prioridade é determinada por: valor que gerará ao cliente naquele momento, risco e necessidade Contém funcionalidades, correções de bugs, tecnologias e melhorias que constituem a mudança que será implementada no produto O Product Owner é o responsável por atualizar, priorizar e dar visibilidade ao Backlog do Produto Nunca está completo evolui à medida que o produto e o ambiente evoluem Seus itens possuem descrição e estimativa em pontos de esforço. Itens do alto da lista são de menor granularidade e mais detalhados

40 Reunião de Planejamento da Sprint REUNIÃO DIÁRIA O Time de Scrum então se reúne com o Product Owner e decide, a partir do Backlog do Produto, o que será feito no próximo ciclo de desenvolvimento: o BACKLOG DA SPRINT BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

41 O que é a Reunião de Planejamento da Sprint? Planejamento da iteração: Time de Scrum e Product Owner defininem que itens do Backlog do Produto serão implementados na Sprint e os quebram em tarefas - Backlog da Sprint 1a. Parte: O quê? Escolha de itens mais prioritários do Backlog do Produto a serem implementados Definição da Meta da Sprint 1a. Parte: Como? Time de Scrum quebra itens em tarefas e estima o tempo que levará para realizar cada tarefa

42 O que é o Backlog da Sprint? Composto por uma lista dos itens que serão desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas Os itens são selecionados do Backlog do Produto na Reunião de Planejamento da Sprint Cada item é quebrado em tarefas. Parte das tarefas é definida no Planejamento da Sprint, parte ao longo do Sprint O Backlog da Sprint é modificado ao longo da Sprint estimativas são atualizadas, tarefas podem surgir para os itens já existentes Deve ter alta visibilidade Pertence ao Time de Scrum

43 O que é o Backlog da Sprint? Composto por uma lista dos itens que serão desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas Os itens são selecionados do Backlog do Produto na Reunião de Planejamento da Sprint Cada item é quebrado em tarefas. Parte das tarefas é definida no Planejamento da Sprint, parte ao longo do Sprint O Backlog da Sprint é modificado ao longo da Sprint estimativas são atualizadas, tarefas podem surgir para os itens já existentes Deve ter alta visibilidade Pertence ao Time de Scrum

44 A Sprint O Time de Scrum faz o trabalho no ciclo de desenvolvimento, a SPRINT REUNIÃO DIÁRIA BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

45 O que é a Sprint? (1/2) Sprint é a iteração (ciclo) de desenvolvimento Reunião de Planejamento da Sprint Trabalho de Desenvolvimento Revisão e Retrospectiva da Sprint Cada Sprint deve ter uma Meta Tem duração fixa (de 2 semanas a 1 mês) e ocorrem uma atrás da outra Duração deve contemplar horizonte curto suficiente para que mudanças não alterem a Meta ScrumMaster deve assegurar que não seja feita nenhuma mudança que afete a Meta da Sprint

46 O que é a Sprint? (2/2) Cada Sprint deve ter como saída um incremento do produto potencialmente entregável A Sprint pode ser cancelada se a Meta da Sprint perder o sentido somente Product Owner pode decidir É muito raro a Sprint ser cancelada

47 A Reunião Diária Em cada dia, o Time de Scrum faz uma reunião de 15 minutos para promover visibilidade e comunicação REUNIÃO DIÁRIA BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

48 O que é a Reunião Diária? Reunião de 15 minutos realizada todo dia no mesmo local, à mesma hora. Visibilidade Comunicação Decisão rápida Cada membro do Time de Scrum detalha: O que ele completou desde a última reunião diária; O que ele vai fazer antes da próxima reunião diária; Quais obstáculos estão em seu caminho. O ScrumMaster deve remover os obstáculos encontrados O gráfico de BURNDOWN deve ser atualizado!

49 O que é o Burndown da Sprint? É um gráfico que mostra a soma dos tempos estimados restantes das tarefas da Sprint pelo tempo Y: tempos estimados restantes X: dias da Sprint Serve para acompanhar o progresso em direção ao final de um sprint É feito inicialmente no Planejamento da Sprint e deve ser atualizado a cada dia da Sprint

50 O que é o Burndown da Sprint? É um gráfico que mostra a soma dos tempos estimados restantes das tarefas da Sprint pelo tempo Y: tempos estimados restantes X: dias da Sprint Serve para acompanhar o progresso em direção ao final de um sprint É feito inicialmente no Planejamento da Sprint e deve ser atualizado a cada dia da Sprint

51 Incremento no Produto Ao final da Sprint, o Time de Scrum terá produzido um incremento PRONTO no produto, que significa valor para o cliente REUNIÃO DIÁRIA BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

52 O que significa Pronto? Ao final da Sprint, o trabalho desenvolvido deve estar pronto Mas o que significa pronto? O Time de Scrum e o Product Owner devem definir o que significa pronto Quando alguém diz que algo está pronto, todos devem entender o que isso significa Ex. de software: codificado, testado e documentado

53 A Reunião de Revisão da Sprint O Time de Scrum então se reúne com o Product Owner e apresenta o que foi feito na REUNIÃO DE REVISÃO DA SPRINT REUNIÃO DIÁRIA BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

54 O que é a Revisão da Sprint? Reunião onde o Time mostra aos stakeholders o que foi feito durante a Sprint: Product Owner presente Time de Scrum demonstra o que fez e responde a perguntas Product Owner verifica o que foi e o que não foi feito na Sprint Deve prover entradas para a Reunião de Planejamento de Sprint seguinte

55 A Reunião de Retrospectiva E, em seguida, o Time de Scrum se reúne para a RETROSPECTIVA, onde verifica o que funcionou bem e o que pode melhorar na próxima Sprint REUNIÃO DIÁRIA BACKLOG DO PRODUTO BACKLOG DA SPRINT 24 HORAS INCREMENTO DO PRODUTO POTENCIALMENT ENTREGÁVEL 2-4 SEMANAS

56 O que é a Retrospectiva da Sprint? Reunião para inspecionar como correu a Sprint com relação às pessoas, relacionamentos, processos e ferramentas: Product Owner não deve estar presente Identificar e priorizar: O que foi bem? O que pode melhorar? Identificar ações para melhorias - adaptação

57 E o ciclo recomeça... BACKLOG DO PRODUTO 2-4 SEMANAS

58 Scrum vs. Métodos Tradicionais

59 Desperdício Metodologias não-ágeis afirmam que devem ser gerados inúmeros documentos para o sucesso do projeto Diagrama de Estados Cronograma Detalhado Diagramas de Sequência...algo mais? Termo de Abertura Diagrama de Atividades Relatório de Desempenho Declaração Preliminar de Escopo Diagrama de Componentes Diagrama de Pacotes Pedidos de Mudança Plano de Gerenciamento do Projeto Relatório de Encerramento Relatório de Progresso Diagrama de Colaboração Relatório de Aceite Análise de Earned Value Documento de Lições Aprendidas Diagrama de Casos de Uso

60 Desperdício Metodologias não-ágeis afirmam que devem ser gerados inúmeros documentos para o sucesso do projeto Diagrama de Estados Cronograma Detalhado Diagramas de Sequência...algo mais? O custo de produção e manutenção destes documentos compensa? Termo de Abertura Diagrama de Atividades Relatório de Desempenho Declaração Preliminar de Escopo Diagrama de Componentes Diagrama de Pacotes Pedidos de Mudança Plano de Gerenciamento do Projeto Quantos destes documentos se Relatório de Encerramento Relatório de Progresso manterão atualizados? Quantos serão realmente úteis para o desenvolvimento do projeto? Diagrama de Colaboração Relatório de Aceite Análise de Earned Value Documento de Lições Aprendidas Diagrama de Casos de Uso

61 Desperdício Em projetos típicos, 50% do tempo é gasto com requisitos, arquitetura e especificação Análise de Requisitos Especificação / Arquitetura Implementação Testes Manutenção e isso tudo é feito antes de se construir qualquer funcionalidade! Fonte: Standish Group CHAOS Report

62 Desperdício Em projetos típicos, 50% do tempo é gasto com requisitos, arquitetura e especificação Análise de Requisitos Especificação / Arquitetura Implementação Testes Manutenção e para piorar... 35% dos requisitos mudam 65% das funcionalidades nunca ou raramente serão utilizadas Fonte: Standish Group CHAOS Report

63 Desperdício Com Scrum, o projeto deve ter somente a documentação suficiente e necessária. Ou seja, adote somente o que será usado. Afinal, o objetivo do projeto é o produto, e não a documentação!

64 Desperdício Com Scrum, o Product Backlog é dinâmico, pois ele deve sempre acompanhar as necessidades do cliente, que mudam ao longo do projeto. Sempre serão feitas as funcionalidades que são de maior importância para o cliente no momento anterior ao início de cada sprint. Assim, o que for entregue, deverá ser usado pelo cliente.

65 Maior Valor Primeiro Em metodologias nãoágeis, o cliente só percebe retorno ao investimento no final do projeto. Entrega

66 Maior Valor Primeiro No Scrum, O Product Owner deve sempre alimentar e reordenar o Product Backlog, priorizando os itens de maior valor para o cliente. Assim, Scrum garante que os itens de maior valor sejam entregues primeiro, gerando ROI para o cliente frequentemente.

67 Maior Valor Primeiro A priorização do Product Backlog pelo maior valor permite à organização: entregar resultados para seu cliente mais rápido que a concorrência colocar em produção funcionalidades que agregam maior valor a seu negócio mais rapidamente lançar produtos e novas versões no mercado mais rapidamente

68 Mudanças Frequentes Como as metodologias tradicionais lidam com a mudança? Mudança é indesejada! Mudança é arriscada! Mudança é cara! Mudança deve ser negociada! Como quase todo o planejamento é feito no começo do projeto, há pouquíssimo espaço para mudanças!

69 Mudanças Frequentes Como as metodologias tradicionais lidam com a mudança? O contrato com escopo amarrado deve nos defender! O cliente vai querer mudar tudo! Cada mudança deve ser negociada com o cliente! Seu impacto deve ser quantificado! Cada mudança deve ser revista, aprovada, planejada, documentada e gerenciada!

70 Mudanças Frequentes Gerenciamento da mudança é fonte de estresse em projetos que utilizam metodologias não-ágeis. Estresse no relacionamento de longo prazo com o cliente. Estresse no dia-a-dia da equipe de desenvolvimento.

71 Mudanças Frequentes Como o Scrum lida com a mudança? Scrum encara a mudança como parte natural do processo de desenvolvimento Manifesto ágil: responder às mudanças mais que seguir um plano

72 Mudanças Frequentes Como o Scrum lida com a mudança? O Product Backlog é constantemente atualizado pelo Product Owner......e assim, mudanças já podem ser introduzidas no produto na sprint seguinte! A resposta rápida à mudança pode se transformar em vantagem competitiva!

73 Comunicação Em um projeto waterfall, quando o cliente é encorajado a participar? Análise de Requisitos Especificação / Arquitetura Implementação Testes Manutenção Testes de Aceitação O cliente percebe o projeto como uma grande caixa preta, cujo conteúdo será revelado apenas no final do processo

74 Comunicação Assim, ao final do projeto, o resultado dificilmente atenderá às necessidades do cliente naquele momento!

75 Comunicação Como o Scrum lida com a comunicação? O Product Owner está em frequente contato com o cliente para levantar suas necessidades......e assim manter o Product Backlog constantemente atualizado e priorizado.

76 Comunicação Como o Scrum lida com a comunicação? O cliente recebe frequentemente novas versões......e assim pode mais rapidamente dar feedback para a equipe, via Product Owner.

77 Comunicação Como o Scrum lida com a comunicação? Desta forma, o cliente se sente envolvido em todo o processo......compartilhando com a equipe a responsabilidade sobre o projeto......aumentando seu grau de confiança na equipe e no processo.

78 Comunicação A relação com o cliente deixa de ser meramente comercial, e passa a contemplar: Parceria Cumplicidade Satisfação Fidelidade E assim, cria-se uma relação de longo prazo com o cliente.

79 Comunicação Em metodologias não-ágeis, como se promove a visibilidade no projeto para seus stakeholders? Principalmente através de documentação......que dá muito trabalho...que não é eficiente...que não se mantém atualizada...que acaba deixada de lado

80 Comunicação No Scrum, a visibilidade no projeto é constantemente promovida! Reuniões diárias Kanban Equipe em um mesmo ambiente Envolvimento do cliente Gráficos de Burndown Entregas frequentes Reunião de Revisão Retrospectiva...são alguns exemplos.

81 Comunicação Manter comunicação aberta entre os stakeholders do projeto é a melhor forma de garantir que todos saibam o que deve ser feito e o que está sendo feito. Isso gera aumento de produtividade!

82 Scrum na Petrobras Case de Sucesso

83 Material para estudo Acesse: Material Disponível: Esta apresentação Guia do Scrum em Português Artigo sobre waterfall de Winston Royce Artigo The New New Product Development Game, de Takeuchi e Nonaka CHAOS Report Scrum Executivo, por Alexandre Magno PPT: Por que Scrum é a melhor opção em tempos de crise Material ficará disponível para download durante a semana.

84 Rafael Sabbagh Obrigado! Marcos Garrido