Scrum - Parte II - Processos Ágeis VIII

Olá sejam bem-vindos ao canal engenharia de software com ênfase M Eu sou professor de Denis getes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras de cursos técnicos com modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema sobre scram essa vai ser provavelmente a última aula sobre processos de desenv movimento ágeis e eu vou finalizar o tema sobre esse Framework Então vamos iniciar a nossa aula ah apenas Relembrando como foi

apresentado na aula anterior Este é uma figura genérica sobre o processo scrum então Inicialmente nós temos a etapa de produção do produto de backlog que gera o artefato produto de backlog que essencialmente é uma lista de elementos de requisitos de funcionalidades que deverão constar no produto depois se passa para o planejamento Sprint que é a primeira etapa do Sprint onde o product owner ele seleciona itens do Product backlog para constar no Sprint backlog Ou seja a lista de funcionalidades que deverão ser implementadas no no Sprint em questão Lembrando que sprints são as op ações do

scrum depois se passa para a execução do Sprint priamente dito que Poderá durar várias semanas até um mês Onde o produto será desenvolvido diariamente vai ser executado uma uma reunião diária uma a o scr diário onde os membros da equipe dirão o que fizeram No dia anterior o que pretendem fazer no dia atual e quais são as dificuldades que eles estão tendo E essas dificuldades elas devem ser sanadas pelo scrummaster Ah o resultado do Sprint é o incremento que é um conjunto de funcionalidades utilizáveis pelo cliente que deverão ser adicionadas ao produto isso não significa

que no Sprint só se faça a codificação são feitas atividades de engenharia de requisitos de projeto de modelagem de testes e tudo que for necessário para incluir o produto apenas como todo método ágil não se produz documentação inútil e burocrática apenas se produzem eh esse tipo de documentação quando ela auxilia a solucionar o problema ou a identificar a compreender o problema depois do Sprint é feita uma revisão do Sprint que basicamente se avalia o produto resultante daquele Sprint o incremento resultante e depois é feito feito uma retrospectiva Sprint que se avalia o Sprint propriamente dito

no sentido de melhorá-lo após isso se verifica se o produto foi concluído se ele é utilizável pelo cliente e pode-se então encerrar o processo ou caso contrário se passa a um novo planejamento Sprint se selecionam novos itens do produto backlog para serem implementados no Sprint Lembrando que a seleção de um ã dos elementos do produo backlog é função do Product owner do dono do produto que seleciona esses itens para constarem dentro do Sprint backlog para isso ele prioriza os requisitos prioriza as funcionalidades que ele considera mais importantes e isso é feito em conjunto com a

equipe em resumo Lembrando que os três artefatos do Sprint do scran São produto backlog o Sprint backlog e o incremento bom mas vamos dar continuidade ao nosso conteúdo Ah eu vou falar um pouco agora sobre os pilares scram que são transparência inspeção e adaptação então transparência todo o processo todo o trabalho todos os artefatos produzidos deve ser visível e compreensível tanto para Quem realiza como para quem irá receber o resultado do trabalho as decisões a maioria das decisões se não todas elas se baseiam no estado percebido a partir dos três artefatos do scran que Como

já foi dito são o product backlog o Sprint backlog e o incremento ah com relação à transparência os artefatos que tem baixa transparência eles podem levar a decisões errôneas falhas que vão acabar diminuindo o valor e aumentando o risco do projeto transparência deve permitir a inspeção inspeções são técnicas que examinam um determinado artefato em busca de anomalias determinam se o artefato Está correto se ele está seguindo os padrões se ele não possui erros ou falhas e uma inspeção sem transparência ela é inútil e enganosa é necessário que as duas caminhem juntas agora vamos falar sobre

inspeção como falei inspeção é um conjunto de técnicas em que um determinado artefato ele é inspecionado para ver se ele está correto para ver se ele não possui conflito se ele não possui falha se ele não possui anomalia se ele está seguindo os padrões etc Ah então os artefatos e o progresso em direção aos objetivos eles precisam ser inspecionados o mais frequente e mais diligentemente possível o objetivo disso como eu falei é para detectar anomalia erros variações que possam ser potencialmente indesejadas problemas em geral se esses problemas forem identificados é necessário fazerem adaptações nos artefatos

no Sprint Então as inspeções elas permitem a adaptação inspeção sem adaptação não faz sentido com relação a adaptação se algum aspecto de um processo se algum aspecto de um produto se desviar dos limites considerados aceitáveis ou se o produto não for considerado aceitável então o processo ou os materiais que foram produzidos precisam ser ajustados adaptados e esse ajuste essa adaptação ela precisa ser feita muito rapidamente para minimizar novos erros novos desvios no caso se a equipe ela não é suficientemente empoderada ou áv essa adaptação pode se tornar bastante difícil e complexa uma equipe no Scan

ela precisa ser empoderada e autogerenciável no sentido em que ela decide Quem fará o qu como e quando e que e de que forma isso será feito Ah vou falar um pouquinho sobre os valores de scram os valores de scram São cinco são compromisso foco abertura respeito e coragem compromisso a equipe scran ela precisa ser comprometida Isso significa que ela se compromete a atingir seus objetivos e a se apoiar mutuamente Então deve haver muita Comunicação na equipe eles devem informar suas dificuldades e devem se auxiliar foco a equipe deve se concentrar totalmente no trabalho a

equipe deve ter somente um objetivo a cada itação e se focar nele ela precisa estar comprometida a fazer o melhor Progresso possível em direção a esse objetivo e o foco Implica também que não Devem haver distrações e que a equipe deve se concentrar manter sua atenção no que é mais importante para o projeto não é aceitável que o membro da equipe possa trabalhar em outras funções em outras equipes em outros projetos abertura A equipe e as partes interessadas precisam estar abertas ao trabalho e aos desafios respeito deve haver respeito na equipe os membros da equipe

eles devem respeitar uns aos outros senão isso prejudica a equipe como um todo a o respeito mútuo faz com que os membros da equipe se tornem pessoas capazes e independentes e também deve haver respeito entre as pessoas que interagem com a equipe com as pessoas com as partes interessadas a equipe deve respeitá-las e ser respeitadas por elas coragem os membros da equipe eles precisam ser Corajosos em termos que eles devem fazer a coisa certa eles não podem tentar desvios ou fazer algo rápido mas de forma malfeita ou que não preze pela qualidade que não siga

os padrões que deixe ma cheiros de código por exemplo e eles devem ter a coragem de trabalhar com problemas difíceis agora nós vamos falar sobre os eventos scran que basicamente são o Sprint propriamente dito o Sprint planning ou planejamento Sprint o Daily scran o scran diário o o Sprint review ou revisão do Sprint e o Sprint retrospective ou retrospective Sprint Na verdade o Sprint engloba todos esses eventos bom vamos falar um pouco sobre Sprint primeiramente os sprints eles são o núcleo do scran É nos sprints que as ideias se transformam em valor é onde o

produto realmente é desenvolvido e cada Sprint ele é considerado um projeto curto porque diferente do que algumas possam algumas pessoas possam pensar um scran assim como todos os processos ágeis ele não se resume a codificação é feito engenharia de requisitos é feito projeto é feito teste não somente codificação algumas pessoas confundem os métodos ágeis e o scran em particular a ao método clássico de desenvolver e testar isso não é ágil o método ágil ele desenvolve outras atividades além de codificação desde que isso seja considerado necessário para compreender o problema ou solucionar o problema ã Sprint

ele costuma durar entre poucas semanas a um mês no início de cada Sprint é feito o planejamento do Sprint essa é uma reunião conhecida como Sprint plan meeting ou reunião de planejamento Sprint nessa reunião são priorizados os os itens do produto de backlog que deverão fazer parte do Sprint backlog Como já foi ensinado antes na aula anterior um produto back log contém todas as funcionalidades que o software deverá suportar e o Sprint backlogs contém as funcionalidades que foram selecionadas pelo produto para serem implementadas em um determinado Sprint [Música] ã então todo o trabalho necessário para

atingir o objetivo do produto incluindo outros eventos Como já foi citado como del scran como a retrospectiva Sprint eles ocorrem dentro dos sprints eventualmente ã se o objetivo do Sprint se tornar obsoleto seja por mudanças seja por algum evento externo H Então ele pode eventualmente ser cancelado mas isso só só pode ser feito pelo produo aer durante o Sprint não são aceitas não são permitidas mudanças que ponham em risco o objetivo do Sprint também nenhuma nova funcionalidade pode ser adicionada a de print e a qualidade não pode diminuir existe o valor de coragem Como já

foi falado a equipe tem que ter a coragem de fazer a coisa certa mantendo o nível de qualidade não adianta querer entregar um produto rápido com uma qualidade uma qualidade baixa o produto de backlog ele é refinado sempre que for considerado necessário e eventualmente o escopo ele pode ser clarificado e eventualmente renegociado com produto owner no momento em que se adquire mais conhecimento sobre o produto sobre as funcionalidades que precisam ser desenvolvidas os sprints eles permitem previsibilidade ou seja Eles garantem que seja possível inspecionar e adaptar o progresso em direção ao objetivo do produto eu

consigo verificar o que já foi feito o que falta fazer o que e precisa ser revisado Isso deve ser feito pelo menos mensalmente mas quanto antes menor melhor H os sprints eles não devem ser longos demais por quê Porque quando o Sprint ele é longo demais o objetivo do Sprint ele pode se tornar inválido ele pode se tornar obsoleto e a complexidade e o risco podem aumentar é recomendado que os sprints sejam mais curtos por quê Porque eles geram mais ciclos de aprendizagem e eles limitam o risco de custo e esforço no momento que existe

um período menor de desenvolvimento é a função do Product owner atualizar o Sprint backlog de tal forma que se demonstre Quais tarefas já foram concluídas e quais ainda precisam ser feitas eh eu vou falar um pouquinho sobre planejamento Sprint ou Sprint planning eh ele inicia o Sprint é a primeira atividade do Sprint onde se estabelece o que precisa ser feito o plano resultado que se resultante dessa atividade ele é criado por um trabalho colaborativo de toda equipe scran então eventualmente a equipe pode convidar outras pessoas a participarem do planejamento Sprint como por exemplo especialistas do

domínio pessoas que tenham bastante conhecimento sobre o assunto que possam eh fornecer informações sobre requisitos necessários a aquele Sprint Ah o produto de aer ele deve garantir que os participantes eles estejam preparados para discutir os itens mais importantes do produto de backlog e que eles sejam capazes de mapear esses itens do produto de backlog para os objetivos do produto Ahã o o planejamento Sprint ele deve responder a três perguntas por que este Sprint é valioso o que pode ser feito nesse Sprint e como será feito o trabalho escolhido Vamos responder por esse Sprint é valioso

para responder essa pergunta o product owner ele propõe como o produto pode melhorar se valor e a utilidade no Sprint atual a equipe inte ela deve colaborar para definir um objetivo de Sprint que comunique por aquele Sprint é valioso para as partes interessadas o que vai ser agregado ao produto o objetivo do Sprint ele precisa ser finalizado antes do término do planejamento sprint com relação à pergunta o que pode ser feito neste Sprint ainda o product owner ele através de diversas discussões ele auxilia os desenvolvedores a selecionar os itens do produto backlog que serão incluídos

que serão implementados no Sprint atual mas é importante destacar que a Palavra Final de quais itens constarão no Sprint backlog é do produ owner a equipe scran ela pode e deve refinar esses itens durante esse processo Como já foi explicado no aula anterior o refinamento se caracteriza por dividir melhorar a compreensão dos itens e agregar novas informações a eles como nível de dificuldade importância para o cliente ah descrições do que é necessário fazer descrição de como a aqueles itens serão validados para garantir que eles atingiram a definição de de de pronto esse tipo de coisa

e nós temos a pergunta como será feito o trabalho escolhido então para responder essa pergunta ah para cada item do produt backlog tenha sido selecionado os desenvolvedores irão planejar Qual será o trabalho necessário para criar um incremento que atenda a definição de feito Como já foi falado na aula anterior a definição de feito estabelece o que se espera daquela funcionalidade e do produto como um todo com determinados níveis de qualidade então [Música] ah para determinar eh para fazer esse planejamento de trabalho eh os desenvolvedores eles vão decompor os itens do produto de backlog em itens

de trabalho menores que isso ocupando cerca de um dia ou menos essa decomposição faz parte do refinamento dos itens Ahã o Sprint backlog ele vai ser então formado pelo objetivo Sprint é o objetivo que se espera atingir naquela iteração os itens do produto de backlog que deverão ser implementados naquele Sprint ou seja o Sprint backlog e o plano para que eles possam ser realmente concluídos que eles possam ser realmente feitos que eles possam ser realmente considerados prontos Ah o planejamento Sprint deve ocupar no máximo 8 horas para um Sprint de 1 mês Ah aqui de

novo eu estou apresentando uma figura retirada do livro do professor Raul vats slav de engenharia de software que mostra um exemplo de Sprint backlock onde ele contém as histórias selecionadas ou seja cada um dos itens que foram selecionados para o Sprint backlog as tarefas que precisam ser feitas com relação a essas histórias o que está em andamento que precisa ser ainda verificado e o que já foi terminado então ele é visível e transparente para a equipe e eu vou falar agora sobre o Daily scran o Daily scran ou scran diário é uma reunião dos desenvolvedores

ela deve ocorrer em pé não deve ser muito extensa se recomenda que ela dure cerca de 5 minutos 15 minutos Justamente por isso ela deve ser feita em pé para que as pessoas não ficam Não fiquem perdendo muito tempo ela ocorre sempre no mesmo horário e local todos os dias com objetivo de reduzir a complexidade e geralmente ela é realizada depois do almoço se recomenda que ela seja realizada depois do almoço para que as pessoas eh se concentre um pouco mais afasta um pouco o cansaço o sono que o almoço traz e é o momento

que se acredita que elas estejam mais focadas no trabalho o Daily scram ele determina o progresso em direção ao objetivo Sprint ele tenta adaptar o Sprint backlog se for necessário ã se o product owner ou scrummaster estiverem trabalhando ativamente em algum item do Sprint back log eles deverão participar como desenvolvedores do Daily scran e nesse Daily scran cada membro irá declarar o que ele fez no dia anterior o que ele está fazendo no dia atual e quais as dificuldades que ele está enfrentando essas dificuldades ou impedimentos elas devem ser sanadas pelo scram é dever do

scram tentar auxiliar cada desenvolvedor a superar essas dificuldades ou impedimentos os deles Scans ou os Scans diários eles melhoram as comunicações eles identificam endimentos promovem rápida tomada de decisão eliminam a necessidade de outros encontros é importante destacar que o scran diário ele não é a única reunião diária dos desenvolvedores eventualmente os desenvolvedores eles podem se reunir para ajustar o plano em outros momentos então eles podem discutir fazer discuções mais detalhadas sobre como adaptar ou replanejar o resto do trabalho do Sprint e agora vou falar sobre a revisão de Sprint ou o Sprint review então o

propósito dessa revisão é inspecionar a saída do Sprint e determinar possíveis adaptações futuras então basicamente se analisa o resultado daquele Sprint Ah então a equipe scran ela apresenta os resultados do seu trabalho para as partes interessadas chave ou seja partes interessadas que têm bastante conhecimento sobre o produto ou determinado setor onde o onde o software deverá ser instalado eh eventualmente também inclui o cliente que paga pelo produto e em conjunto com as partes interessadas eles discutem O Progresso em direção ao objetivo do produto ah a equipe as partes interessadas elas revisam o que já foi

desenvolvido no Sprint e o que foi alterado no ambiente em termos de novas funcionalidades que foram adicionados e com base nessa informação se discute sobre o que se deve Dev fazer levando em consideração o que já se tem feito levando em consideração o cronograma mudanças Eh orçamento pode-se decidir se o que já está desenvolvido é suficiente ou se um novo Sprint deve ser realizado se novas melhorias devem ser feitas se novas funcionalidades devem ser adicionadas ã o produto de backlog ele também pode ser ajustado para atender a novas situações ou novas mudanças e a revisão

do Sprint ela deve ser encarada como uma sessão de trabalho e não deve ser simplesmente uma apresentação e nós temos depois o Sprint retrospective ou retrospective Sprint que basicamente tenta analisar o Sprint como um todo eh tenta permitir a melhoria contínua permitir que o Sprint que a forma como o Sprint é realizado por equipe seja melhorado seja evoluído Ah então a equipe scran ela questiona como o último Sprint foi desempenhado levando em consideração os indivíduos os membros da equipe as partes interessadas as interações os processos as ferramentas e a definição de pronto eh se forem

identificado suposições que desencaminhar desencaminhar atrapalharam prejudicaram de alguma forma o Sprint Então vai tentar determinar as suas origens e vai tentar evitar com que que elas ocorram novamente e a equipe scran ela irá discutir o que foi bem durante Sprint Quais problemas foram encontrados e como esses problemas foram ou não foram resolvidos ah a equipe vai identificar Quais foram as mudanças Quais foram as práticas que foram consideradas mais úteis para melhorar a efetividade do Sprint e as melhoras mais impactantes Elas serão abordadas o mais breve possível e podem eventualmente ser adicionadas ao Sprint backlog no

próximo Sprint a retrospectiva Sprint é atividade final do Sprint ela deve durar em torno de 3 horas para um Sprint de um mês após a retrospectiva Sprint se inicia um novo planejamento Sprint ou se conclui o processo agora nós vamos falar sobre as vantagens do scran o scran ele fornece maior flexibilidade Ele oferece uma abordagem flexível para o desenvolvimento de projetos Ah ele permite Auto adaptação e resposta às mudanças durante o desenvolvimento e isso é útil para requisitos que estão em constante evolução Uma Outra vantagem é a entrega de valor incremental ao final de cada

Sprint ou ainda durante um Sprint uma parte de um produto incremento é desenvolvido e entregue o cliente tem acesso a funcionalidades Logo no início devido essa prática Então a partir do primeiro Sprint ele já pode ter código funcionando e já pode utilizar esse código isso permite que ele forneça pareceres ou seja feedback sobre o produto isso permite maior transparência e maior adaptação permite que o produto seja ajustado e como os requisitos mais importantes com maior nível de priorização São definidos pelo produto de aer para constar nos primeiros sprints os os itens mais arriscados eles recebem

pareceres mais eh Breves e isso evita eh riscos e problemas para o projeto eh essa constante entrega de valor costuma satisfazer o cliente tornar um cliente mais satisfeito Uma Outra vantagem é a colaboração e comunicação eficazes a colaboração e comunicação é fortemente incentivada no scran os membros da equipe precisam colaborar e se comunicar e se comunicar constantemente então por exemplo durante as reuniões diárias todos os membros compartilham o que eles estão fazendo o que já foi concluído o que eles pretendem fazer Quais são as dificuldades que eles estão tendo isso permite a identificação de possíveis

problemas e o scram mester tem a a função de tentar resolver esses problemas essas dificuldades Além disso essa constante comunicação e colaboração permite que a equipe tome decisões rápidas e eficazes melhoria contínua graças à retrospectiva Sprint ah os experientes estão em constante melhoria a equipe analisa o que funcionou bem e o que não funcionou também que precisa ser melhorado então a equipe ela consegue aprender com seus erros produzir um processo de desenvolvimento cada vez mais eficiente e eficaz Uma Outra vantagem é a visibilidade e transparência o scran é muito transparente Então os membros da equipe

eles podem acompanhar as tarefas que ainda estão em andamento as tarefas que foram concluídas as tarefas que precisam ser revisadas o que ainda falta fazer então isso permite a transparência e facilita o monitoramento do Progresso do projeto por todos os envolvidos agora Existem algumas desvantagens com relação à definição de prazos Isso é uma desvantagem comum há vários processos ágeis incluindo o scram como o scram é um processo ágil que tende a ser flexível e aceita mudanças nos requisitos isso pode dificar definir prazos rígidos para conclusão do projeto éo difícil estabeler prazos no momento que existem

requisitos que são muito voláteis que podem sofrer muitas mudanças e que o cliente é incentivado a ter ideias e a sugerir requisitos ao longo do projeto Então como esses requisitos eles podem mudar ao longo do projeto é muito difícil estimar com exatidão quando o projeto será concluído se os requisitos não mudam é fácil ou ainda fácil ou não é mais fácil estimar agora quando os requisitos eles mudam muito a estimativa de tempo é bastante complexa e isso pode ser problemático quando se lida com clientes que exigem prazos bem estabelecidos Claro existem técnicas que auxiliam a

estimar prazos mas com relação a requisitos muito flexíveis Isso é muito difícil ela Exige uma equipe altamente autogerenciável isso já isso já foi destacado na aula anterior e Nesta aula também a equipe ela tem que ser capaz de autogerir determinar Quem fará o que quando e como então para isso é necessário uma equipe madura e com certo grau de experiência ela precisa ter ser capaz de se autogerir e tomar decisões de maneira dependente isso pode ser bastante difícil para equipes que não têm experiência ou não tem maturidade nesse tipo de eh atividade se houver falta

de autogerenciamento isso pode levar a atrasos e problemas na qualidade do produto outra possível desvantagem não necessariamente uma desvantagem mas existe uma necessidade de colaboração intensa Isso é uma característica muito exigida no scran e em geral isso é benéfico mas em algumas situações pode não ser possível atingir essa colaboração não po pode não ser possível atingir essa colaboração pode não ser possível haver comunicação e portanto a produtividade pode ser judicado existem situações que são bastante inadequadas ao scram em geral onde pode haver equipes distribuídas geograficamente com membros que T horários diferentes ou simplesmente que com

membros que não saibam colaborar tenham dificuldade de comunicação então numas situações assim isso pode ser desvantajoso para o o processo scram uma outra desvantagem é o risco de sobrecarga de trabalho o scram se baseia em sprints curtos e movimento e isso pode ser bastante PR pode ter uma pressão muito grande nos membros da equipe como se exige essa entrega de incrementos constantes com alta qualidade que agreguem valor em prazos relativamente curtos isso pode sobrecarregar a equipe e deixar ela esgotada então é preciso garantir que haja um ritmo constante de trabalho um equilíbrio adequado entre a

produtividade e o bem-estar dos membros da equipe de repente pode se quer se criar sprints tendo um sprint backlog com menos itens por exemplo para não deixar a equipe tão sobrecarregada uma outra desvantagem requer um comprometimento total da equipe a equipe precisa ser comprometida ela todo membro precisa estar disponível e está dedicado ao projeto durante toda a a duração do print não pode acontecer de um membro de equipe trabalhar em mais de um projeto se houver falta de comprometimento por algum membro isso vai afetar negativamente o progresso e eficácia da equipe Ainda vamos falar sobre

quando não usar scran não se deve usar scran quando o problema é muito simples porque o scran ele foi explicitamente projetado para solucionar problemas complexos se o problema não é complexo seria muito simples o scram pode não ser adequado para aquele problema uma outra situação pressão por entregas muito rápidas Como já foi falado o Sprint ele os sprints eles agregam valor ao cliente mas isso deve ser feito a um ritmo sustentável e um Sprint deve durar algumas semanas até um mês ao longo de um Sprint pode se gerar vários incrementos mas o incremento só pelo

menos só será finalizado ao fim do Sprint então não deve haver uma pressão por muitas entregas em tempos mais curtos do que algumas semanas ao mês porque isso poderá sobrecarregar a equipe e ela talvez não consiga atender a definição de pronto ou seja não vai atender a qualidade estabelecida para aquele produto para os incrementos se há necessidade de muitas entregas ráp Talvez um outro processo seja mais adequado como por exemplo XP uma outra situação quando não usar esran quando há dependências externas Ou seja a equipe Depende de eventos externos Depende de pessoas ã externas que

se tornem disponíveis como pessoas especialistas no domínio depende Que materiais se tornem disponíveis esse tipo de coisa isso pode deixar a equipe ociosa e desmotivada e pode estender demais o scr e os Scans muito longos aumentam o risco e a incerteza do projeto outra situação várias equipes o ideal é que haja apenas uma equipe scran Mas se for necessário então é recomendável que não hajam mais do que três equipes trabalhando no mesmo projeto e cada equipe precisa ser capaz de compartilhar o produ backlog e o produ se as equipes aumentarem muito isso pode aumentar a

interdependência umas das outras elas podem ter que ficar esperando o resultado de uma outra equipe para poder fazer o seu próprio trabalho e Isso poderá sobrecarregar o produto de então muitas equipes não é o ideal para um processo scram outra situação é quando há necessidade de produzir vários produtos no scram a equipe trabalha em um produto só por vez ela precisa ser focada é um dos valores do scram necess trabalhar em vários produtos isso vai contra os preceitos do scran e vai tirar o foco e vai sobrecarregar a equipe Então scran não é adequado para

essa situação e nós terminamos essa segunda aula sobre o scran eu espero que essa aula tenha sido útil para vocês se vocês consideraram ela útil se ela agregou o valor para vocês eu peço que vocês curtam esse vídeo e compartilhem com queem se interessar por esse assunto obrigado pela atenção nós nos vemos nas próximas aulas [Música]