Gestão de Projetos e Qualidade de Software - 24 04 25

Bem pessoal, boa noite. Estamos iniciando o nosso encontro então de gestão de projetos e qualidade de software. Então, sejam muito bem-vindos. Nós estamos aí, como é que é, já na terminando a terceira semana. Então, como é que é? Estamos chegando naquele momento em que a gente passa de, né, passando um pouquinho da metade da disciplina. E eu queria começar assim com nós vimos algumas coisas na aula passada aí e ficamos com algumas dúvidas, algumas situações aí, como é que ficamos. Então, vamos lá. Eu quero hoje eu tô não tô com vontade de abrir uma apresentação

aqui. Eu queria falar um pouquinho antes de abrir a apresentação e começar com um ponto inicial aqui. Se nós fizéssemos uma pergunta assim scr, retomando um pouquinho e e recompartilhando com vocês aqui. Hum. Aí fica de repente para deixar mais bonitinho o nosso encontro aí. B o o o o vou dizer uma coisa para você assim, ó. Hoje hoje o Danilo tá mais light, viu? Vocês precisavam ver ontem, ontem ele tava, né? Tava tava usando um, como é que é? Um terno daqueles. Ah, é, tava sombrio também. Tava sombrio. Mas, ô Luiz, pior que ele

esqueceu o teu nome, né? Isso eu me lembrei agora que ele esqueceu o nome do Luiz. Bom, então eu coloquei duas palavras ali, scran e objetivo, né? Então, scran, eles chamam de framework, né? Mas ele é um conjunto de boas práticas utilizado no gerenciamento de projetos que a gente diz que é complexo e em que não se conhece. todas as etapas ou necessidades. Então, focado nos membros da equipe, o SCR torna processos mais simples e claros, pois ele vai manter registros visíveis sobre o andamento de todas as etapas. Qual é o objetivo do Scrum? Ele

tem o objetivo de reduzir o tempo de entrega de produto e se adaptar à aquelas mudanças que podem ocorrer, sendo ela mais facilitada durante as etapas produtivas. Nós falamos um pouquinho da técnica, né? Então, que é ele é uma das formas de se usar a metodologia ágil nos projetos e o principal objetivo é auxiliar na gestão e desenvolvimento daquele projeto. Aquele projeto daí assim, ó, tem um prazo curto, né? Ele é um método popular e muito comum. E às vezes há uma confusão que se confunde, digamos assim, com scran, com a metodologia ágil em si.

Isso é uma uma situação que é comum, que a gente pode falar assim que acontece. O scram tem três pilares: transparência, inspeção e adaptação. E essa é a essência do negócio. Hum. Esses pilares eles servem de base para que a equipe possa desenvolver e alcançar lá os objetivos para entregar o valor pros seus parceiros, pros seus stakeholders. Esses são os pilares do escâo. Uma coisa que eu não falei para vocês, eh, mas o criador do do do Scrump, né, o Jeff junto com o Kap, eles criaram o Scron em 193. E a ideia deles já

era aquela coisa assim, ó, eles viam que o software tava sendo construído de um jeito e eles queriam mudar o de o a forma como era desenvolvida e gerenciado o software. Então, nós vimos terça-feira sobre a Daisy Cram, aquela reunião diária acompanhando cada um dos membros, né, que eles vão compartilhar o que que fez, né, o que que vai ser feito, o que que tá tá impedindo ele de fazer determinadas coisas, né? Mas é importante dizer assim, ó, para fazer essa reunião, ela tem que ser eficiente, ter foco em meta e resultado. E esses objetos

precisam ser eh realizados. E esse é um exemplo da situação em que a gente fala do scran. Por isso que eu deixei essa tela scran objetivo aqui. Nós nós nós temos um objeto. Bom, como eu comecei eh retornando a daily, eu queria explicitar algumas coisas sobre ela. Então, se nós quisermos um falar um pouquinho sobre esses detalhes assim. Então, nós fizemos a sprint review em que a gente iniciou o processo. Hoje é o segundo dia e hoje, no segundo dia a gente faz uma daily e essa é aquela com eh todos os eventos dentro do

scrambes chamam de cerimônia, né? E essa cerimônia ela é uma das mais conhecidas. Pode ser, pode ser o nome tradicional, Daily Scram, Daily ou até Daily Standup, alguns usam, né? Mas esse é o ponto, essa reunião de 10 a 15 minutos, esse é o dos motores da comunicação do desse dessa metodologia. Tem alguns que ficam pensando assim: "Ah, isso aí é um bate-papo rápido, mas a ideia é que se ele fosse bem feito, ele ia servir para a equipe colocar e verificar alguns problemas, alguns riscos cedos, né? aquela coisa de remover o impedimento, então pra

gente poder focar naquela atividade que a gente tá fazendo. Esse esse esse é o a essência daily. Então essa reunião lá de 15 minutos do time que vai se inspecionar o progresso e que todos vão ter a comunicação aberta do que tá acontecendo, né? Ideia é que ela aconteça sempre na mesma hora, no mesmo local, né? e cadenciando o ritmo do trabalho. Então, cerimônia voltada somente pros membros desse time. E o Scram Master, nesse caso, né, ele pode estar presente ali para garantir que as regras sejam seguindas, mas ele não vai comandar a reunião. Esse

é o ponto principal. Então, no formato clássico, cada participante vai responder aquelas perguntinhas. O que eu fiz ontem para ajudar a equipe a garantir a meta lá, atingir a meta do sprint? O que que eu vou fazer hoje para ajudar o time a atingir a meta, né? Então, eu, qual é o impedimento que eu vejo que me atrapalha? do meu progresso. Ah, eu tô com um problema numa ferramenta, eu tô com um problema no código. E isso vai servir, né, pra gente manter o foco, a a questão da sincronização e também da colaboração. Até porque

quando a gente responde essas perguntas do impedimento, talvez venha alguém com uma ideia, quem sabe tu faz assim. Então, olha só, nós estamos desenvolvendo aqui o nosso aplicativo de receitas. Deixa eu ver uma coisa aqui. Quem vai ser meu voluntário aqui? Ah, o Daniel. Pegar o Daniel hoje de voluntário aqui. Depois eu pego o Mateus. Vamos lá, né? Então o Daniel disse assim: "Ontem eu terminei o layout da tela de cadastro da receita. Hoje eu vou conectar essa tela com o banco de dados. Aí o Daniel diz assim: "Mas eu tô com dificuldade em configurar

o mais car ideia. Quantos segundos ocorreu esse compartilhamento, né? o progresso, o plano e o bloqueio. Então agora pode vir ali algumas colaborações, houve uma adaptação, colaboração e a gente pode seguir em frente. Algumas coisas comuns na daily que podem ser causadas erros assim, né? Então assim, a daily não é uma reunião de status pro gerente, digamos assim, ó. Digamos que o que o Mateus tá com um problema crítico, né? Tá com problema crítico lá, não vai se resolver naqueles 15 minutos. Então esse esse nesse momento o escromass disse assim: "Daniel, olha eh Mateus, seguinte,

nós vamos fazer, nós vamos pegar o teu problema e vou repassar já o Daniel, o Danilo conseguiu resolver o problema dele rapidamente, né? Então esse problema complexo vai ser tratado depois. Digam assim, ó, não tem como fazer uma apresentação longa, é rapidinho. Então, assim, ó, qual é que é a ideia? Alguns chamam de daily standup, porque a ideia muitas vezes é fazer essa reunião em pé para ser objetivo. Aí vocês podem usar um quadro mural, um aí tem lá giro, trela, excelível para todos. Aqueles postit muito bom, não tem problema. A reunião começa num horário,

se começa 8 horas, 8:15 ela tem que acabar. Não é 8:16, não é 8:17, é 8:15. Os impedimentos foram anotados, né? Alguém é o o anotador lá das questões, de repente o próprio Scrammaster. Os impedimentos foram anotados. aquilo que foi rápido foi tratado ali. Aquilo que é mais demorado vai para depois. Porque a ideia é assim, se ela passou de 15 minutos, ela já não é mais daily. Essa daily elas ela foi enraizada, ela veio lá daquela filosofia Link Camban, né, que que tem esse pressuposto, reunião curta, frequente, focada num fluxo contínuo. É, então assim,

ó, por exemplo, ó, startups, algumas agências lá dentro do Vale dos Silícios, lá nos Estados Unidos, eles evitavam, por exemplo, que as eh reuniões longas e improdutivas, então as reuniões todas eram em pé. Eu estive na Alemanha um tempo atrás e até o almoço é em pé para o pessoal não ficar muito tempo na no refeitório. Então a o pessoal almoçava rapidamente, liberava o refeitório e aí ia fazer o espaço de descanso dele. Mas ali para almoçar era 10, 15 minutos para não ficar muito tempo. Refeitório pequeno, mesinha pequena, quatro pessoas comendo em pé e

depois tinha os espaços de descanso. A coisa que eu que eu fiquei mais impressionado, que até achei que podia ter em todos os lugares lá, tinha uma máquina lá com bebidas, todos os tipos de cerveja, refrigerante, tudo disponível lá. A pessoa só ia lá e pegava como um cafezinho. Bom, é outro mundo, né? Outro mundo. É outra cultura. É outra cultura. Mas e também e também tem aquela coisa eh uma coisa que eu acho interessante que eles têm aquela coisa a o horário de trabalho é até às 17 horas. 17 horas eles largam o ponto

de trabalho como ele tava ali e vai embora. Se tinha que fazer uma limpeza, ele fazia lá um tempo antes, mas às 17 horas ele saía do posto de trabalho. Não tem que sair, né? Senão não dá problema. É, eles não têm essa questão. Até nas nas nos cargos mais altos lá não tem. É 17 horas. E que que tu fala da Espanha que tem a cesta aquela cesta de 4 horas a cesta, né? [Risadas] Já pensou nisso? Pois é. Tu larga a meio-dia às 4 horas da tarde, tu volta a trabalhar depois tem o

horário da cesta, tudo fecha, né? Ah, que cesta, hein? Deus. Depois vai até às 8, né? Claro, mas claro, mas tem um horarzinho da sesta, cara. Isso aí, isso aí não, não dá. Uhum. Mas já tá mudando já, né? É, algumas coisas tem que mudar, né? É. Eh, diga, e até, por exemplo, essas metodologias que a gente tá falando aí, elas também têm aquela questão assim, ó, se tu tem um uma atividade X para fazer, né, tu tem uma meta, sabe que tu tem que entregar naquela meta, né? Sim. Bom, então voltando aí, essa daily

então ela é fundamental no Scram para manter esse time funcionando aí, que nem vocês viram, né? Então a ideia também tá ser tudo transparente, né? Então aquela questão assim de transparência, adaptação, inspeção, que são os pilares do escrito estão ali. Então, esses 15 minutos por dia podem salvar lá no futuro semanas de trabalho. Então, esse é o ponto fundamental daily, né? Bom, aí acontece o sprint, né? Então, se se nós olhamos assim, a daily fala, vê um detalhezinho sobre o sprint, né? Então, aquele aquele momento em que tá acontecendo, né, o o processo em si.

Então, se a equipe do Scram é o corpo humano, a Sprint é o coração. Ela que vai ser o vai dar o ritmo do trabalho. Então ali eu tenho a cadência de entrega que eu vai manter o foco dali, né? Então essa sprint, né, é o ciclo de trabalho, né, com duração fixa. Então vai ser de uma a 4 semanas. né? Então, e nesse momento o time sabe assim, ó, que ele tem que entregar um incremento de produto pronto e utilizável, pelo menos potencialmente. Então tudo vai acontecer dentro da splint. o planejamento, desenvolvimento, a revisão,

a retrospectiva, todas essas fases vão se repetir a cada novo ciclo. Então, esse período de uma a 4 semanas depende muito do contexto do projeto e da equipe. Então, uma coisa que eu tenho que dizer assim, o escopo da sprint não muda depois que ela começa. a equipe se comprometeu com aquela meta e trabalha para cumprir. Então aquele aquela ideia assim que eu tenho uma sprint, eu tenho que entregar um produto, né, virreal pro meu cliente, esse é o fato. E lembrando que a cada sprint eu vou ter um incremento funcional nesse negócio. Então aquilo

que e esse produto ele pode ser demonstrado, testado, usado. Então se eu desenvolvi uma, nós estamos desenvolvendo um aplicativo de delivery, a Sprint vai ter uma meta de entregar o, por exemplo, o cadastro dos restaurantes funcionando. Daí na próxima entrega vai ser o carrinho. Aí depois o pagamento. Então como é que funciona a sprint? Como é que é o processo? Ela tem cinco cerimônias. O planejamento, que a gente chama de sprint planning. Então a equipe vai dizer assim, ó, o que que vai ser feito, como vai ser feito, né? Vai escolher lá os itens do

backlog. e vai definir a meta. Escolhemos lá fazer o cadastro dos restaurantes. Estabeleceu a meta. Ah, vai ser entregue em 4 semanas. Vai acontecer as dailes depois diárias. Os trabalhos vão ser executados, construindo, né? Então vai ter programação, design, teste, tudo aqui. Depois vai ter a revisão da sprint, que a gente chama de Sprint Review. Então a equipe vai apresentar o que foi feito lá pros parceiros, pro stakeholder, né? Então eles vão receber um feedback. Depois disso, a equipe faz a sprint retrospective, que é retrospectiva. A equipe, então, vai analisar o que que funcionou, vai

ver aqueles dados lá do do review, né, e vai ver assim, ó, o que que pode melhorar no próximo ciclo. Esse é o princípio básico da da sprint, né? Então agora imagina assim, ó. Tem seis pessoas desenvolvendo um sistema de biblioteca. Num sprint de duas semanas, eles definiram que vão entregar o módulo de cadastro de livros. Aí eles disseram assim, ó, no planejamento eles definiram as tarefas e quem vai fazer o quê. Todos os dias eles fazem a da, no final eles apresentam o cadastro funcionando na Sprint Review. Depois eles fazem a retrospectiva e percebem

lá que precisam melhorar o tempo de integração do código. Um exemplo, aí eles partem exatamente para isso. Que quais são as boas práticas que nós temos no modelo desses, né? Então, se para ela funcionar bem, uma sprint funcionar bem, a meta dela deve ser clara, objetiva e alcançável. O backlog deve estar refinado e priorizado. O time precisa ser autogerenciado e corpo prometido. A comunicação com o product owner tem que ser aberta e frequente. Nunca se interrompe uma sprint sem um motivo muito sério. Importante dizer, sprint não é maratona improviso. É um ciclo de entrega com

foco em valor e melhoria contínua. Isso é a sprint. Então assim, ó, é mais do que aquele bloco de tempo lá que a gente tava pensando. É o compromisso, equipe com a entrega de valor, fazendo expressão constante e adaptação inteligente. A ideia é que a equipe ela não ela não é ela não tá só entregando um software, ela tá evoluindo. E aí que dizem assim: "Ah, o Scrum é tão poderoso", né? Então, na Sprint nós conseguimos transformar uma ideia e uma entrega. Esse esse esse foi o ponto fundamental. Nós temos uma questão relacionada ao productor.

Então, se nós pegarmos o o se nós temos o o coach no Scram, o Scram Master, nós temos o técnico, o Producter, ele não entra em campo, mas ele define estratégia, escolhe escalação, aponta para onde o time deve mirar. Então assim, algumas empresas não às vezes não nomeiam o cliente com o product, eles estabelecem lá o próprio gerente de projetos ou um líder para fazer esse papel, porque ele vai saber muitas vezes maximizar esse valor do produto, né, e garantir que a equipe esteja construindo a coisa certa. Então, às vezes eles transformam o cliente num

stakeholder e colocam um product owner, né, que talvez ajude a ter algumas dúvidas que você estava, ah, como é que o product owner vai dizer determinadas coisas? Então, eu posso colocar o papel dessa pessoa lá. Então, essa pessoa dentro da empresa, ele pode estar representando dos interesses dos clientes ou do negócio ou dos usuários finais. Algum ponto ele vai fazer ali. Ele não pode digitar o trabalho que o trabalho será feito, né? Isso aí é da equipe, mas ele sabe o que que deve ser feito e por quê. Professor, esse esse personagem ele pode ser

um membro da equipe mesmo ou tem que ser fora da equipe? É fora da equipe, porque geralmente ele tá ele tá ele tá num papel assim, ah, ele é um analista de negócios, ele é um porque se ele entrar na equipe, ele pode interferir porque muitas vezes ele pode ter algum poder gerencial, tá? Então a gente bota ele fora do time, né? Até porque daí, digamos assim, ó, e ele vai eh ele vai manter inicialmente vai priorizar, vai refinar o product, né, para garantir que aquelas histórias mais importantes estejam claras, né, e prontas paraa equipe

de desenvolvimento entender ela. Então, vamos lá. Se o Scram fosse a viagem, o product owner escolhe o destino. A equipe decide, escolhe o caminho, mas o product owner escolhe o destino. E o scran é viagem. Então assim, ó, eh esse essa pessoa muitas vezes ele pode ser um gerente de projetos, tá? eh ele vai ter que gerenciar esse produto de backlog. Então ele vai adicionar, remover, reordenar conforme as necessidades vão mudando e da própria equipe, né? Então aquela coisa de valor, dizer o que que é mais importante, o que que causa mais impacto para aquele

negócio, pros usuários, ele vai ter que esclarecer dúvidas, né? Porque a equipe durante o sprint pode precisar dele para tirar dúvidas, porque às vezes o cliente, digamos assim, uma ideia de colocar o cliente como prodotion, ele pode ser um problema, porque às vezes o cliente tá tão ocupado que ele não tem tempo de atender. Então ele pode deslocar uma pessoa e ter um product owner dentro da nossa própria empresa para fazer isso, porque eu preciso, a equipe precisa ter informações para poder fazer aquela entrega e ele vai ser o responsável por aceitar as entregas. Então

ele vai revisar, vai validar os incrementos lá do Sprint View, ele vai validar e ele que vai fazer a comunicação com os stakeholders, né? para garantir a visão, a estratégias, funcionais paraa equipe. Então assim, olha só, diferenças. O Scram Master cuida do processo, ele remove os impedimentos e protege o time. A ideia dele é proteger o time. O time de desenvolvimento constrói o produto e o product o decide o que que o time vai construir, em que ordem. Ele não vai cobrar prazo, ele não vai distribuir a tarefa, né? Ele tá liderando só pelo valor,

o foco no resultado e não no controle. Ah, eu tenho lá uma equipe e tá desenvolvendo um aplicativo de educação. Então, o product owner analisou os dados e descobriu que 70% dos usuários abandonam o curso por falta de lembretes. Ele então tá priorizando o quê, né, que uma história de notificação push lá, por exemplo, né? Eh, mesmo que isso seja mais complexa que outras, né, mas ele vai gerar um valor maior. Mas agora a equipe vai dizer assim, como é que ela vai construir? Mesmo que o o o product diga assim, ó, por que que

essa entrega é importante? A equipe vai dizer, mas para nós chegarmos lá, nós temos que fazer isso, isso, e isso? né? Então, se nós considerássemos boas práticas dele, ele precisa estar acessível durante toda sprint, entender o produto e o mercado, saber dizer não quando algo não gera o valor real. Foco no resultado, não em gerenciar tarefas. alguns erros que acontecem, né? Ele não responde dúvidas, ele se ausenta, ele tenta impor tarefa pro time, não é papel dele, né? Então, ou ele diz assim, ó, tudo é prioridade máxima. Hum, tem como fazer isso, né? E ele

não tem clareza sobre o que o cliente realmente precisa. Esse esses são alguns problemas. Então esse é um papel de liderança, né? É estratégico e ainda tem comunicação e ainda tem visão de produto. Digamos assim, se eu não tiver um bom product o, o time ele pode estar altamente produtivo, mas ele vai entregar coisa errada porque o produto owner não é bom. Então assim, ó, ele não é um anotador de tarefas, ele é o guardião do valor, vamos dizer assim. Esse é o nome dele, né? Então ele não ele não vai entregar código, ele entrega

aquela questão da direção, do propósito, do valor. É isso que ele vai entregar. Bom, o nosso backlog nós falamos ontem, mas que ainda tava com algumas dúvidas, né? Então, essa é a lista viva do valor. Eu tenho lá um quadro de ideias vivas que está crescendo. Elas mudam, amadurecem e vão se transformar com o tempo. Isso é o produto de backlog. Aqui a gente chama de coração estratégico do scramb. Se eu tenho, se o Scram fosse uma máquina de entregar valor, o product backlog é o combustível que vai alimentar essa máquina. Então, uma lista ordenada

de tudo que pode ser necessário no produto. Esse é a única fonte de requisitos do time scram. De novo, lista ordenada de tudo que pode ser necessário no produto, mas não é só uma lista de tarefas, ela representa o que que o produto precisa entregar para gerar valor para aquele usuário ou negócio. E essa essa essa lista ela não é fixa, ela é dinâmica, porque ela pode evoluir, ela ela precisa ser priorizada, digamos assim, que durante esse processo ela não tá pronta, ela nunca tá pronta completa, né? porque o produto e esse mercado muda constantemente.

Então o product o é o responsável por manter e priorizar o backlog, mas é aquela coisa, ele não trabalha sozinho. O time lá vai, né, não só pode, como deve colaborar para refinar os itens, né, estimar o esforço, sugerir melhoria. Então esse backlog é do time todo, mas a responsabilidade final é do PIO, né? Nós temos que cobrar de alguém, então cobramos do PIO. Então esse esse eh backlog, então ele é ele é composto por itens que nós chamamos de product itens. E aí eles podem ser assim, ó. Alguns podem dizer assim: "Ah, que é

uma história de usuários, né? Pode ser bug, pode ser requisito técnico, pode ser melhoria de performance, pode ser funcionalidade futura. E cada um desses itens, ele pode ter assim, ó, um título e uma descrição clara, critério de aceitação, prioridade e uma estimativa que pode ser em C points ou horas, as dependências e os riscos. Importante dizer assim, aquilo que tá no topo do backlog são aqueles mais claros e prontos para serem desenvolvidos. Os do final ainda tá em estágio de ideia. Então, ah, eu quero fazer um aplicativo de leitura para celular. E aí eu vou

fazer assim, ó, um processo assim, ó. Usuário pode marcar livros como favoritos. Eu quero prioridade alta para isso. O sistema envia notificação de novos orçamentos. prioridade média, eh, integração com sistema de audibook, uma ideia pro futuro. Então, agora, né, o PIO, ele priorizou os itens de acordo com o valor do negócio. Então, teve feedback dos dos usuários, foi feita a viabilidade técnica, o time fez a estimativa, refinou para que os itens estejam prontos para entrar exatamente no sprint. Então, se nós falarmos em boas práticas, ele tem que ser ordenado. Os mais importantes primeiro, ele precisa

ser detalhado do nível certo, né? Os itens estão bem claros, né? Os distantes ainda estão um pouco mais frágeis. Então, ele precisa ser construído em diálogo, né, com o time, com os stakeholders. transparente. Ele tem que ser acessível a todos. Ele pode ser atualizado, mas todos podem enxergar lá o o backlock. E ele tem o valor, né? O que que ele vai entregar, né? Eh, isso realmente vai agregar valor pro usuário. Então, assim, ó, não adianta criar um backlog monstruoso para que não foi que tem ideias que não foram validadas. né? Ele não é o

cemitério dos desejos, ele é a ferramenta de estratégica. Se eu não vou, não pretendo fazer aquilo, não validei, não coloca ali esse termo que eu falei para vocês de refinamento, né? Esse é o processo de revisão, de melhoria dos itens, né? Então, às vezes eu preciso esclarecer melhor essa história. Se tem uma tarefa muito grande, eu preciso dividir ela. Eu tenho que fazer uma estimativa de tempo em conjunto, tirar o que, né, dio aqui não é necessário. Então, muitas vezes a gente faz assim, ó, o time precisa gastar de 5 a 10% do tempo da

sprint. refinando o backlog para garantir que as histórias estão bem preparadas pro próximo ciclo. Então assim, ó, esse backlog é um mapa estratégico desse produto, né? Então ele ele tá fazendo ali, ele tá conectando visão, necessidade do usuário, capacidade de entrega e tá fazendo tudo isso. Então ele, se ele for bem cuidadinho, ele vai ajudar esse esse esse esse time para focar realmente no que importa. A gente podia dizer assim, ó, o backlog não é só o que vamos, mas o porquê, né? Então ele tem um valor que a gente quer entregar. Ajudou a entender

um pouco mais o backlog agora. Daniel tava com mais dúvidas no último encontro aí. Deu, deu uma melhoradinha um pouquinho agora. Agora detalhando todo o processo fica mais fácil. É, a gente a gente a gente vai trabalhando assim. Agora a gente consegue chegar num num num modelo mais palpável de alguma coisa, né? A gente tava distatiando muito, agora a gente já consegue fazer e a gente consegue fazer algumas práticas também semana que vem. Sim. Então, olha só, digamos que vocês foram contratados para fazer um um aplicativo. Vou chamar esse aplicativo de estuda fácil. né, que

é voltado para aqueles estudantes do ensino médio que tem que organizar as rotinas de estudo, revisar conteúdo, acompanhar desempenho por matéria. E então assim, vamos vamos pensar assim, ó. Quem seria o no grupo de vocês aí o product, quem seria o Scram Master e depois teremos os times. Deixa eu ver quantos nós estamos aqui. O Scram Master é o Danilo, né? Não tem, é claro. É o master, é o master. É o master. E quem vai ser o produt? Então o o pessoal aí todo vai ser o tímido aí. Então, ninguém me fez uma pergunta

ainda. Tem tem uma pergunta que é estratégica ainda, mas ninguém me falou ainda. Eu tenho uma pergunta que é estratégica que ninguém me fez ainda sobre isso. Nós já temos o produto que nós vamos trabalhar, né, que é o Não, tudo bem. Mas mas tem uma coisa assim, ó. Vocês já pensaram assim qual é o tamanho desse time? E ela não pagou pelo que eu tô vendo uma regra, tem uma regra sobre isso, né? Pelo que eu tô vendo que vão ser 18 pessoas, né? Que eu sei, eu sei, mas digamos assim, ó, nos times

de desenvolvimento, o mínimo é três pessoas e o máximo no scrub é nove. Ah, mas se eu precisar, vamos dar um exemplo assim, ó, eu vou ter o Scan, vou ter o over e vou ter a equipe que vai trabalhar comigo. Eu vou precisar de no mínimo agora. Agora não, mas olha só, eh nós temos ainda o PO e o Scram Master. Claro. Então, só eu ten eu vou fechar em 11 pessoas ou Então v vamos te dar um exemplo assim, ó. Tenho os meus os meus cinco cargos, meus cinco chefes ali, seria os meus

cinco organizadores, tá? E depois eu vou ter que ter assim no nesse nesse nesse produto que nós vamos fazer para entregar, eu vou precisar de no mínimo uns quatro desenvolvedores. Uhum. Já tenho nove, né? É, mas digamos assim, ó. Tem tem uma situação que talvez tu tem que criar dois times. Ah, legal. É legal, porque por isso que por isso que ele, digamos assim, ó, eh, porque se tu tiver um time maior com mais de nove, eu posso ter problema de comunicação, ela vai ficar mais complexa, pode ter gargalo, o time pode perder a questão

da autonomia. Então, talvez aí eu tenha que fazer alguma subdivisão, né? Eu vou ter que dividir o projeto daí, duplicar, fazer dois times. Eh, é, e cada um vai pegar uma parte específica, né? Mas uma pessoa sendo responsável pelos dois times. É, eu vou ter um um product owner, posso ter um scram master também pros dois. É, pros dois ou pros três ou pros quatro. Mas vai ter que saber de tudo, de todo o conteúdo de todos. É, senão dá muita confusão da Claro, claro. É, e vai começar a dar problema aí, então, digamos assim,

ó. Ah, então, ah, eu posso ter o meu product o isso, né? E esse modelo, assim, quando a gente tem, eh, a gente pode chamar ele de scram em escala, né? que que é o o Scalis Scram, tem um processo para isso, né? Então esse esse é o modelo para esses para essa questão aí, né? Né? Então a gente a gente pode ter uma situação, ah, que nem nós estamos aqui, estamos em 18 pessoas. Bom, então o ideal seria fazer uma divisão, ter dois times e cada time pegaria um desses desses processos aí. Bom, e

eu ainda acho que nove pessoas para compor todo o conjunto de de, né? É, é muita gente ainda. Não, mas esse esse é o número máximo, né? É, é de, é de, mas ainda nove pessoas dá muita diferença de, de, de de informação. É que dependendo do projeto, vamos lá, dependendo do projeto, tu tem que ter um testador. Tu tem que ter, por exemplo, dois eh desenvolvedor back end, dois front end. Aí tu tem um designer aí trabalhando em conjunto, não o time é é trabalhando em conjunto, mas a às vezes eh eh são vários

vários eh eh clientes separados, né? Então, dá dá muita muita confusão da Por isso que eles têm aquela questão da Dav para fazer de definir lá o backlog. Então, ah, se eu se eu tenho um designer assim, por exemplo, dentro do grupo, ele tem uma função lá de fazer uma determinada preparação, eu posso ter dentro do projeto um administrador de banco de dados. Pode ser que ele não seja exclusivo para aquele projeto, mas ele faz parte do time, porque isso é uma coisa comum, tá? Eles eles dividem as pessoas, tem que dedicar determinadas uma quantidade

de horas por dia no projeto A e metade no projeto B, né? Esse não é o ideal, mas é o que acontece. por empresas maiores de desenvolvimento fazem isso e as menores também. Aí eu preciso colocar o segundo projeto, vamos espremer o time, né? Essas são as também são as realidades do mercado, né? E o SCRAM vem como uma forma de organizar isso aí, porque daí eu trabalho realmente com um com o objetivo. Eu sei que eu tenho aquele prazo de entrega lá, né? Eu tenho que fazer aquele processo ali. Se eu acomodar um outro

projeto ali, eu tenho que fazer. Hã, pelas empresas que eu já passei ali, eu nunca tinha visto isso, esse sistema assim, claro que, eh, tem reuniões diárias, tem tudo isso aí, mas não tinha visto isso. Às vezes a reunião não é 15 minutos, é a manhã toda. Pois é, mas daí ela já não é mais uma daily, é, ela deixa de ser uma daily e já virou uma outra coisa, sabe? É uma coisa maçante, sabe? Bá, demora e e fala a mesma coisa e continua falando a mesma coisa. E é é que é que digamos

assim, ó, uma das coisas daí o pessoal fica procrastinando e isso esse é o problema desse desse desse desse modelo, né? dig assim, as pessoas teriam que seguir as regras de forma adequada e daí às vezes daí o pessoal, né, se se não tem alguém com com, por exemplo, nesse momento de interferência do Scram, Scram Master ali para, né, para organizar o foco novamente, acontece isso. Daí a reunião que era de 15 minutos virou 4 horas. Aí tu, se tu olhar, tu fica metade do tempo só em reunião e o projeto vai atrasando, vai atrasando,

vai atrasando, né? Então, eh, mudar o pensamento ainda demora um pouco, sabe? As pessoas precisam ser a mesma coisa é as influências externas, né? Todas as influências externas ou vem pelo product owner ou pelo Scram Master. Scrammaster procura blindar isso aí porque, ah, digamos assim, poderia vir um gerente da de vendas e interpelar alguém do time, ó, como é que tá indo o projeto, não sei o quê, né? Não, não. Ele teria que falar direto pelo canal, que seria ou product owner ou o Scram Master, né? O escramer tem que agir nesse momento e é

complicado, né? Nós temos que quebrar alguns paradigmas culturais. Algumas indústrias, né, eh, e outros segmentos estão usando essa metodologia. A área de marketing, por exemplo, tá usando muito essa metodologia porque ela é muito boa, mas ela, essa questão aí da de transformar em de 15 minutos em 4 horas é o problema. E também por isso que deve ser cortada a participação na daily de pessoas fora do time. Na daily é só o time. Não pode na daily não pode tal piou. Não pode ter o gerente, não pode ter nada. É só o time. Eu vejo

que é para não contaminar o projeto, né? Claro. É, é também para te blindar, porque no momento em que começam a vir pressões de determinadas áreas, né, tentando interagir com a equipe, tu tira o foco, né? E a ideia é manter o foco, né? Então esse esse é o é o ponto que nós temos aí de principal nesse projeto aí, manter o foco. E por que que a reunião tem que ser sempre de manhã, não pode ser no finalzinho da tarde? Não. O o horário tu não não precisa, tu tem que normalmente é sempre de

manhã. A chegada chegou na empresa, pronto. A primeira coisa é a reunião lá de 10, 15 minutos. Por que que por que que é mais fácil fazer de manhã? Distribuir as tarefas para todos. Eu faço assim, pelo menos. Por que que é mais fácil? Mã cedo já distribuo para todo mundo ali. Pronto. E aí vou pro meu canto. É porque por que que é bom de manhã cedo? Porque ao chegar, tu diz o que que tu fez, o que que tu vai fazer e o que que tá te atrapalhando. Esse é o princípio, princípio básico,

tá? Esse esse é o princípio básico do modelo, né? a gente precisa ver esses e daí assim essas esse esses modelos diferentes que a gente tem aí, a gente visualiza bem nesse processo aí de como é que a gente pode melhorar, como é que a gente pode ajustar, como é que a gente pode pensar. Mas a gente tava ali naquele modelo ali de falando ali do nosso do nosso projeto aí, né? E eu queria que vocês pensassem assim, eu queria que vocês colocassem aí no nosso, deixa eu fazer uma coisa aqui, no nosso quadro aqui.

Eu acho que a gente consegue usar, deixa eu ver se a gente consegue fazer uma coisa aqui mais bacaninha. Cadê meu quadro? Deixa eu encerrar meu compartilhamento aqui e eu quero pedir para compartilhar. Danilo tá com uma cadeira de balança, ele tá se mexendo para cima e para baixo, para cima. Aham. Ele tá ali. Eu tô vendo, tô vendo, tô vendo. Tá ali só, viu? Uhum. Uhum. Depois de uma certa idade, a gente tem que ter uma cadeirinha assim, né? Se balançando. Não consegue ficar parado, né? Ah, nós podemos usar o mentímeter. Poderia ser uma

alternativa. Mentímetro. Eu vou usar o o o mentímetro pra gente organizar. Ah, já fiz um. Deixa eu sair desse usuário aqui então. Que eu já usei quase tudo que eu podia usar, mas eu acho que dá pela quantidade de pessoas aí que nós vamos fazer. Então vamos lá. Eu quero fazer aqui um, deixa eu fazer um login com a minha conta Google. Sabia, professor, que na outra faculdade que eu fazia, eh, eu ganhava 20% da nota, era aparecer na na no form, né? Ah, é mesmo isso. 20% da nota, mano. É, tem chamada, tem tudo.

Vai, é uma, é uma escolhação, né? Mas tem 20% já garantia. Hum. Estando lá presente lá. Que legal. Olha só, eu vou eu vou vou lançar para vocês aqui. Eu vou usar um ã vou usar esse template aqui mesmo. Aqui eu pedi para escrever um item. Bom. Uhum. Deixa eu botar ele aqui para apresentar. Uhum. Copiei o link. Deixa eu só puxar ele aqui pro lado para deixar visível para vocês aqui que Google Chrome ajuda aqui aqui. Mementímeter. Deixa eu pedir para apresentar ele. Vou exibir para vocês ele agora aqui. Bacaninha. Deixa eu compartilhar a

minha tela de novo. Diga aí, Mateus, enquanto isso aí. Boa noite, senhor. Aproveitando a pausa aí, tirar uma dúvida em relação ao backlog que a gente vai fazer da atividade integradora. Uhum. sobre atividade ali, na última aula o senhor comentou que a gente pode fazer no Excel, enfim, modelo que a gente for fazer, a gente pode fazer do jeito que a gente quiser. Mas tem algum requisito em questão de de layout, assim, de modelo, tipo ter aluno da Não, layout não. O que tu tem que fazer é a lista e colocar a prioridade lá, o

que que é a prioridade alta, média, intermediária. Ah, beleza. Não, tranquilo. Porque eu não vi ali nenhum modelo ali. mais para saber se tem algum modelo, um layout assim, mas daí tranquilo, daí é só fazer tudo organizadinho ali, tá? Legal. Olha só, esse aqui, não sei se vocês já usaram o mentímeter. O mentímeter é uma ferramenta que a gente pode usar para brainstorming, né? E digamos que a gente quer construir o nosso backlog, né? Então, nós estamos lá na nossa, nós queremos montar o nosso aplicativo [Música] de educação, né, educa fácil lá. E eu pensei

o seguinte, eu tenho um cenário, digamos assim, ah, para fazer isso, eu tenho para montar aquele modelo, eu tenho essas necessidades aqui. Uhum. Hum. Deixa eu compartilhar aqui no chat com vocês os dados para todo mundo ficar com eles ali. Então, o que que o que que se deseja? Vejam, não é o backlog ainda, mas o que que se deseja? que tem um cadastro de disciplinas, que se possa se criar um cronograma de estudos, notificações de lembretes, um ranking de desempenho, integração com Google Agenda, um sistema de revisões semanais. Bom, olha só, agora eu vou

criar uma regra. Eu eu preciso escrever como se fosse uma historinha. Eu tô nesse modelo aqui, tá? Não precisa ser isso. Eu poderia botar assim, ó, como estudante, eu quero receber notificações eh diárias para não esquecer de estudar. Essa seria a minha observação, né? Então, a ideia é que eu colocasse esses itens aí para aqueles para aqueles tópicos que estão ali, cadastro de disciplinas, notificações, eu queria fazer assim, ó, como estudante, eu quero isso. Como professor eu quero o sistema de revisões semanais. Professor, o senhor tá digitando alguma coisa? O senhor tá escrevendo alguma coisa

aí? Não, não tô escrevendo nada. Ah, tá, tá, tá, né? Então, eu poderia escrever exatamente isso aqui, ó. Como estudante, eu quero receber notificações ao estudar, né? Então, eu poderia escrever aqui conforme vocês forem escrevendo. Ou vocês preferem fazer só a lista. Vamos fazer só a lista, é mais simples, não vou complicar. Só uma lista para conseguir fazer esse projeto aí. Eu quero que vocês escrevam um tópico que vocês acham importante para eu escrever esse projeto de acordo com aqueles itens que eu coloquei lá. Vocês podem dizer assim: "Ah, eu preciso fazer o controle de

notificação". Escreva lá: Controle de notificação. Não se preocupem se repete ou não. É só clicar. Eu mandei o link para vocês já, né? É só clicar no link lá, acho que tem que fazer um cadastrinho rápido e escrever a mensagem. Aí tudo que vocês vão escrevendo vai aparecer aqui na minha tela, tá? Então, há controle de controle de notificação de mensagens, cadastro de estudantes, é o nosso brainstorming. Nós não estamos fazendo produt o backlog ainda. É o nosso brainstorming pra gente colocar lá. O que que vocês acham? Aí conseguiram acessar? Eu aco para escrever. Ué,

esquisito. Eu vou tentar entrar de novo ali. Deixa eu ver uma coisa aqui. Ele abre o site mente. Ele até abre aquela, mas ele vai direto para essa mesma tela que o senhor tá aí. Um item. Não, para mim, pelo menos você não tá abrindo para escrever. Deixa eu ver uma coisa aqui se ele não tá não. Aqui apareceu para mim escrever. Escreva um item. Ah, tá. É que ele tá atrás do vídeo. Tá. Tá aí mais embaixo tem ali escreve um item. Digite uma palavra, né? É, tu pode digitar até três palavras. Aham. Tá.

E nós vamos fazer com relação a esse a esse a esse a esse educa fácil ali, aqueles tópicos que eu coloquei ali. Que que vocês acham que precisa ser feito primeiro? O senhor colocou três três tópicos, né? Livro, escola e estudo, né? Isso. Tá. Não educa fácil. Isso. Eu acredito que a primeira coisa dele, o senhor quer saber a primeira, né? Ah, senhor botou. Não, pode colocar as três coisas que tu acha que precisa ser feito primeiro e é a tua ideia. E cada um coloca a sua ideia que acha. Ó, já comecei a aparecer

ali, ó. Eu já tenho ali cola. Não, Colorado. Ah, os cara tá muito futebolista hoje. Ah, mas nós temos ali livro, escola, estudo. Nesse momento o Scram Master encostava no futebolista e e conversava com ele. Ô, meu filho, tu vai achar aí uma demissão direto, tá? Apesar de eu gostar da da das das duas palavras, n demitido esse infeliz aí. Bom, então assim, ó, isso aqui é muito bom pro próprio time se se descontrair e e colocar assim, ó, bom, o cliente colocou isso, ó. Ah, ele foi lá, colocou livros, as escolas, mas de repente

eu poderia botar assim, ó. Ah, eu cadastrar alunos. Eh, deixa eu, deixa eu colocar uma, algumas palavras aqui também, criar uma [Música] notificação. Não me veio muita ideia aqui, mas eu cliquei aqui no submit e coloquei lá, ó. Ah, eu quero colocar no Google Agenda. Eu quero cadastrar alunos, eu quero criar notificação. E daí, digamos assim, ó, se mais pessoas colocarem cadastrar aluno, nós poderíamos verificar que ele vai aumentando. Se alguém mais escrever, cadastrar aluno ali, ele vai aumentando o tamanho da palavra. E depois eu tenho um relatório que eu consigo ver quantos votos teve

aquele item, né? Então a gente pode ver se ele realmente é prioritário depois fazer uma análise refinada, né? Isso aqui é mais é só para fazer o pensamento inicial. Pelo que por enquanto que nós temos aqui são todas palavras diferentes que cada um colocou, né? Mas que ainda, digamos assim, ó, ninguém repetiu um tópico específico para ele ficar, digamos assim, destacado, digamos. E eu também não fiz o bloqueio, tá? Eu poderia bloquear a quantidade de de vezes que a pessoa pode colaborar, digamos assim. Olha só, o cadastrado aluno teve mais informações, ó, teve mais votos.

Ah, entendi. Aí ela entra como uma prioridade, né? Exatamente. Aí a gente começa a observar assim, ó. Ó, se essa palavra aqui já teve eh mais informações, eu posso pegar ela e fazer uma análise refinada. Se esse cadastrar alunos pode ser a nossa prioridade maior. E aqui a gente tá porque aqui a gente poderia fazer do time, né? Ah, então o time resolveu assim, ó. A nossa prioridade um é cadastrar os alunos. Então aí nós podemos a partir dali tirar ele do backlog e trazer pro do sprint, definir as regras, tudo direitinho e começar o

processo. Aí nesse caso, tu teria que mandar esse link para todos os todos os colaboradores do time e eles iriam trabalhando isso e todos iriam ver a mesma coisa. Isso. Legal. Essa é uma ideia. Esse aqui o mentímet pra gente fazer essa essa primeira captação. Depois a gente coloca dentro de um Excel lá direitinho. Deixa eu mostrar para vocês agora como é que fica o o modelo aqui. Essa aqui é a tela de gerenciamento, ó. E aqui eu tenho os resultados, ó. Ah, quatro cadastraram alunos, dois escola. Então eu tenho um destaque aqui, ó, dentro

do meu time. Esse poderia ser minha prioridade. Quer dizer, essa ferramenta é mais é para te ajudar a achar as prioridades do grupo. Isto legal, né? Quer dizer, fica uma coisa mais automatizada, não fica tão travada ali e não dá e acelera e acelera o a reunião do dia. É, digam assim, essa essa aqui é a review. A review, a a a inicial de abertura, geralmente ela dura 2 horas. Sim, o senhor falou na outra aula. Isso. Mas é uma ideia assim que a gente pode utilizar para fazer alguma O único problema dessa ferramenta aqui

que ela tem esse limite aqui na versão gratuita, sim. Mas se tu vai numa empresa a gente não tinha isso enquanto enquanto ele estava testando. Mas para tu vai estar numa empresa tu vai comprar isso aí, né? É, mas é aquela coisa assim, se se você tem um time de 10 pessoas, tá legal. né? Então, um um um exemplo de como poderia ser, né? Uma várias ferramentas a gente pode usar como apoio tecnológico para para esses processos aí, né? Então essa essa é uma uma ferramenta, uma uma coisa importante assim, ó, até eu vou colocar

ela no espaço do do do resumo e eu acho que aqui também ela cai bem direitinho, né? Eh, tinha um colega de vocês que tinha me perguntado esses tempos sobre o PDCA. Vocês lembram disso? o planejar fazer, eu vou colocar ele aqui na na nossa tela resumo aqui, mas eu vou falar sobre PDCA e vou exibir para vocês uma imagem de PDCA. Que que é o PDCA? Vocês vão ver que ele é muito parecido com a ideia desse clube, né? O que que é o PDSA? Plano do correct. Então ele é um ciclo que a

gestão usa para trabalhar melhoria de processo, planejamento, execução, verificação e agir, padronizar e corrigir. Plano do Check Act. Bem simples. E é as perguntas que basicamente a gente faz no scram. Qual é o problema que eu quero usar? Qual é o objetivo? Quais são as causas? E o que que eu preciso fazer? Isso é o planejamento. Eu preciso levantar dados, definir metas, prazos, indicadores. O do eu faço. É, é parecido com o que acontece dentro da sprint. Eu tô fazendo, tô construindo. Aí vem a etapa do cheque. Eu vou ver o resultado, vou comparar, vou

apresentar pro pro Duty owner. E depois do cheque eu tenho o act, que é como se fosse lá no final a retrospectiva muito parecida com com a ideia do scram. Então a ideia é assim, ó. Se tudo funcionou corretamente, tá padronizado, vai embora. O que não funcionou, a gente planeja de novo, ajusta e manda embora. E o símbolo que se vocês procurarem aí na internet, o símbolo de PDCA, a imagem que representa o PDCA, é um círculo. Planejar, fazer, checar e agir. P DCA. Eu vejo que ele não tem ele não tem um um lado

certo para começar. Tu começa por onde tu achar melhor. Não, tu começa pelo planejamento. Sempre pelo planejamento. Sempre o planejamento. Porque que acontece? Se tu teve algum problema, tu volta pro planejamento. Essa essa essa é a ideia. Por isso esse C, esse esse exemplo contínuo aqui, eu vou deixar esse esse link aqui para vocês, mas eu tinha que trazer essa, eu tinha esquecido, daí eu tava revisando lá o os vídeos, os materiais lá, disse: "Ah, o colega tinha pedido uma uma coisa sobre o PDCA e a ideia é basicamente isso. Eu planejo, aí eu faço,

aí eu verifico e daí eu faço a ação em cima dele. Ah, é como se eu fizesse a retrospectiva. Ah, deu problema, eu preciso melhorar. Então eu volto pro planejamento e torno a fazer de novo, né? Então eu posso fazer isso. Se tá tudo OK, projeto tá pronto, concluído, né? Ele é muito usado em modelos de qualidade PDCA, né? Então, por exemplo, poderia fazer assim, ó, ah, eu vou eu vou fazer o planejamento, né? Eh, e faço lá uma uma verificação, por exemplo, ah, eh, eu tenho uma biblioteca e eu quero reduzir a o atraso

da devolução de livros. Aí eu lá no planejamento eu identifico 40% dos usuários atrasam. Então eu crio um plano, ah, um sistema de lembrete por e-mail e mensagem automática. Esse é o plano. Aí no na etapa D, eu vou colocar esse plano em prática por 30 dias. Na etapa C, que é o cheque, eu vou verificar se os se os atrasos caíram. Ah, de repente eles c, eu tinha planejado que eles deveriam cair para 15%, né? E se tudo deu certo, eu vou padronizar isso, então, um sistema de alertas e vou definir que todo empréstimo

terá esse lembrete. Caso não contrário, eu volto pro planejamento, né? Então, ah, se a melhoria foi comprovada e vai ser mantida, né? senão ela volta pro planejamento. É bem simples, né? Baseado em melhoria, baseado em dados, né? Envolve a equipe, né? E a ideia que a gente vê naquela imagem ali é como se ele fosse um sistema de engrenagem, né? Quanto mais gira, melhor o processo se torna. Esse é um exemplo que nós temos em relação ao PDCA, né? Ele é o nosso apoio aí nesse processo aí. Bem, então que que vocês gostariam de falar,

aproveitar esses minutos aí para falarmos algumas coisas aí? Ó, depois que o que o Daniel falou que o Danilo tava fazendo um movimento na cadeira, o Danilo parou ali de fazer o movimento da cadeira, ficou magoado, viu, Daniel? Ele nem vai dormir essa noite. Tão magoado que ele ficou contigo. Eu tô careca de saber que o Daniel tá pegando meu pé. Uhum. Uhum. Eu notei isso aí. Eu notei isso aí. queria falar faz três semestres que ele tá ele tá falando de mim já. Uhum. Qual é o Mas então essas, digamos assim, são várias ferramentas

que a ideia é usar, eh, colocar qualidade no processo. Ah, que nem eu falei para vocês, o 5W2H é uma ferramenta, pode ser usado dentro do Scrom, pode. Tá lá bem simples. Quem faz o quê? De repente é a evolução do processo, né? Eu já defini. Agora eu vou pegar lá naquela planha e vou dizer assim, ó. Ah, o Mateus vai fazer a interface gráfica, né? O o Jeancarlos vai fazer o banco de dados. E aí a gente vai definindo todo esse processo aí de quem faz o quê, né? De repente a gente pode pegar

lá o o Henrique vai fazer o back end, né? O o Micael poderia ficar com front end, né? O o Alan poderia pegar a parte do design gráfico, já que nós já temos o PO e o e o e o Scram Master. nós já temos aí, né? Então esse esse é o exemplo, né? Então, ah, claro que o time vai fazer as atividades que estão mais afins. E pode acontecer que, por exemplo, a gente olhar assim: "Ah, eu preciso fazer o projeto, né? Eu tenho que fazer o produto X, mas ninguém da equipe domina aquela

ferramenta que precisa ser feita. Aí tem que tem que se tomar uma decisão. Ou vai se capacitar membros da equipe para aprender aquilo, ou vai trazer alguém de fora para fazer esse processo. Aí tem que ver o que que vale a pena pra empresa. Mas são situações que podem acontecer. Bem, pessoal, era isso. Quero agradecer a presença de vocês aí. Vamos aproveitar o final de semana, vamos descansar aí na E até segunda, né, professor? Hã, até segunda. Não, nós é terça, né? Não, segunda oportunidade da gente conversar. Ah, bom. É isso aí. tem a segunda

oportunidade. Tá, [Música] professor, uma boa noite. Hoje ele tá cheio de historinha. Ontem ele tava carro todo, né? Tava lá para casar ontem, mais ou menos. É, eu tô achando que que foi foi algo batrimonial ontem. É, ontem tava diferente ontem o negócio. Tava tava. Ô, professor. Oi, só uma perguntinha. Semana que vem a aula. Então é só terça. Só terça. Ah, é semana, quinta-feira, feriado. Eu a gente marca uma uma aula extra. Daí de repente na outra semana a gente faz três dias. Daí tranquilo. Tinha esquecido esse detalhe de quinta-feira feriado. Eu acho tão

horrível esse dia do trabalhador e o trabalhador não trabalha. É verdade, né? Tinha que trabalhar, né? Quanto feriado trabalhador tinha que trabalhar. É um absurdo, né? É que o país, o Brasil é um país rico, né? Brasil é um país rico, milionário, então pode fazer um monte de feriado e tá tudo certo. É depois que o nosso nosso presidente da República que nós ia comer picanha e tomar muita cervejinha, brasileiro tá realizado. [Música] [Risadas] Não entendi o que é do sorriso. Eu não entendi o porque do sorrisinho assim sarcástico. Não, mas é nós ainda temos

moranga para comer. Nós temos moranga. É, eu fui na fruteira hoje. A moranga tava R$ 4 o quilo. É, exatamente. Mas então, tá, muito obrigado. Boa noite para vocês aí. Bom descanso. Bom feriado. Ah, não, feriado não, né? Feriado semana que vem.