[Música] de vendas o portfólio de tiex né de tecnologia comigo também tá o Alexandre Assis Ele é advisor consultation especialista também no portfólio de ESPM Hoje a gente vai falar um pouquinho com vocês sobre agilidade em escala e ele de novo né Ele é um capítulo adicional ali é o terceiro capítulo da nossa série de web na gspm que a gente vai abordar uma parte mais da execução propriamente dita né naquele nosso fluxo de O que é o SPM né de quais são as etapas ali que o SPM interessa já passamos né pelo primeiro web na parte de estratégias né de criar Road map estratégico maximização dos resultados na linha todas as iniciativas estratégicas da companhia e agora a gente vai partir para a parte de execução propriamente dita usando qualquer tipo de metodologia e a gente vai falar um pouquinho na parte ágil então quando a gente começa a conversar né com os clientes né servicinal sempre fala do daquele paradigma tradicional onde que a companhia está quando a gente está falando de transformação ágil então a gente sabe que nem toda nem todo o projeto dentro de uma companhia vai seguir metodologia ágil né muitas vezes a gente tem projeto estruturantes muitas vezes a gente tem projetos de infraestrutura em geral que precisa ter um pouco mais de controlar orçamentário que precisa ter mais de controle de prazo e tudo mais projeto tradicionais basicamente projetos usando abordagem de começo meio e fim então eu tenho uma parte mais projetizada da coisa né eu tenho grande foco e não estourar o orçamento né não estourar prazo também sem sacrificar a qualidade do produto a gente tem uma governança que normalmente a Centralizado em um escritório de projetos um escritório governança a gente tem muita preocupação na inimizar risco e e portanto né o escopo precisa ser sempre para definido e as mudanças o máximo possível ser evitadas E caso ocorra a mudança né muitas vezes ocorrem a gente tenta sempre ajustar recurso e custo para tentar manter o prazo e se não possível a gente vai e atualiza né o cronograma e gera a versões novas de cronograma né e as entregas acabam sendo em fases né ou em ondas de implementação né são geralmente entregas grandes e tal quando a gente fala de estratégia ágil aí a gente tá olhando um pouco mais para produto né a gente começa aí no cenário que não é tão escopo fechado né a gente tem entregas menores a gente tem um projeto que tem uma o simples de entrega né Muito mais vivo a gente começa a transicionar né esse esse foco e não só no projeto na redução de risco mas na necessidade que o cliente tem no alinhamento nas necessidades que o cliente tem né na qualidade da entrega do produto e acaba Tendo também equipes multidisciplinares Ou seja a gente tem equipes que saem um pouco daquele né viés de ti tradicional e vai para o viés muito mais autônomo na equipes que são muito disciplinares acabam tendo maior autonomia para tomada de decisão para execução das atividades e por aí vai e a entrega é sempre a preocupação principal né ou seja rápida entrega com o valor mais rápido possível a gente não tem muitas vezes o corpo para definir e sim é o escopo variável a cada interação a cada sprincho e que a gente consiga antecipar mudanças sempre ao final de cada Sprint né Para que tenha estratégia mais clara a cada Speed a cada execução de ciclo o trabalho também acaba sendo Time Box fixos e a gente tem entregas menores sucessivas frequentemente usando aquele termo como MVP e quando a gente faz o shift né para Agilidade de escala e aqui a gente Visa basicamente endereça equipes multidisciplinares em maior número né Ou seja a maior quantidade de equipes trabalhando também em metodologia elas continuam com bastante autonomia mas a gente tem que ter maior preocupação em sincronização das atividades e das independências entre essas equipes na orientação direta para estratégia organizacional para estratégia de produto evitando né enfim atritos entre essas equipes as características aqui são basicamente as mesmas Cadência que acaba sendo sob demanda quando a gente tem lançamento de produtos né muitas vezes a gente tem independências do produto da outra na equipe com essa então a gente tem que sempre sincronizar e tem credenciar as felizes E aí aonde que a gente vê né que a maior parte das equipes começa a entrar em desentendimento quando a gente tem uma equipe ou poucas equipes trabalhando usando metodologia ágil geralmente começa lá com a ti né começa com poucas equipes seguindo né metodologia Scan por exemplo a gente vê que a gente tem um ciclo de planejamento a gente vai para umas parte de interação né ciclos de entregas a gente tem lá as deles a gente tem os espinhos ou seja as equipes começam a entregar coisas mais rapidamente acabam tendo maior autonomia e acabam tendo né controle de produto propriamente dito Não tem aquela dependência né com escritório de projeto então acaba sendo a maior parte dos clientes que a gente costuma ver acabam começando assim quando a gente vai para uma para um cenário um pouco maior né ou seja várias equipes usando a mesma metodologia a gente vê que tem uma liberdade qualidade do produto geração de valor etc mas equipes começam a ter essas interdependências muitas vezes acabam tendo a abordagem diferentes que o qual metodologia utilizar qual o tipo de de interação utilizar duração das escritas acaba não sendo as mesmas né a frequência das ririzes ou seja não é ruim né que tenha esse esse essa realidade é até um pouco saudável porque a gente vê que as equipes estão tendo que melhorar né os modelos de ágio mas a gente vê que começa a ter atento né entre as felizes de uma determinada área com as outras e acaba tendo esses esses percalços aí só que o problema começa a ficar bem maior quando a gente acaba tendo que gerenciar né a parte de metodologiagem para todas as áreas de toda a companhia ou seja a gente começa a multiplicar né o problema e cada equipe começa a ter seu próprio direcionamento estratégico cada equipe começa a ter seu próprio processo de tomada de decisão né um momento independente e quando a gente tem né aquela questão de desviorizar e priorizar uma determinada característica do produto quando a gente tem interdependência né com as outras equipes a gente começa a ter continuidade de funcionalidade a gente começa a ter né enfim uma equipe continua uma funcionalidade a outra equipe precisa daquela funcionalidade para manter o produto que ela tinha evoluir o produto que ela tinha então agilidade em si traz velocidade traz autonomia Se todas as equipes que utilizam esse tipo de metodologia estão seguindo na mesma direção né caso contrário a gente começa a ter esse desgaste a gente começa a ter esse Impacto então o risco da abordagem ágil em escala né é esse a gente ter várias equipes rápidas várias equipes ágeis e em direções diferentes né e o que a gente não quer né quando a gente é saudosista né dessa dessa metodologia ágil é ela não se torna vilã da história né porque a gente acaba escutando muitos clientes né muitas companhias grandes falando com a gente Ah pô esse tal de ágio não funciona na verdade muito pelo contrário né a gente tem eh necessidades específicas que se deve utilizar a metodologia ágil caso contrário a gente não consegue né acompanhar o ultimate a gente não acaba acontecendo a evolução tecnológica propriamente dita os frameworks de agilidade em escala vieram para ajudar as organizações resolvam esse tipo de problema de crescimento digamos assim não só pela pela pela pela pelo crescimento organismo organizacional etc mas na abordagem né nas equipes utilizarem a metodologia mais ágil Então qual que é a questão né ela já eu escala é tentar organizar de uma maneira geral as realizas né as interações ali de todas as áreas ages alinhado a questão de estratégia do produto e Aquela nossa famosa na estratégia organizacional como um todo ou seja ter um plano estratégico ter o que acha né ter a parte de iniciativas estratégicas da companhia de uma maneira geral dessas estratégias a gente acaba caindo na parte de produtos e então nas interações nas várias execuções para o trabalho né alinhados aos dois níveis superiores aí então aonde que o serve sinal acaba entrando né nessa transição ali do mundo tradicional para o mundo ágil né justamente nessa parte mais de organização como um todo a gente tem várias maneiras de execução de trabalhos age sem do larges campo por exemplo seja Spotify ou acaba a gente vai falar bastante do 6 alinhando né o trabalho todas essas áreas de todas essas de todos esses times em relação uma estratégia para a gente definiu lá em cima né objetivos estratégicas estratégias e métricas né ouqans com a parte de execução e lembrando né que a Arsenal como é uma única plataforma uma única parte de dados o único sistema de registro não só o trabalho ágil como também o trabalho de projeto né o trabalho tradicional ou híbrido também né a gente tem características de um projeto estruturante dentro dele vai a gente tem várias iniciativas ágeis dentro desse projeto então a gente acaba tendo condições né de execução de ambos os mundos aí num único lugar também alinhar com aquela questão do intake todas as ideias e demandas que a gente passa pela ideia são pela gestão de demandas pelo demand WorkPad e tudo mais a gente transforma né esse em take em execução alinhado com as estratégias da companhia tá então esses três níveis visam resolver aquele atrito aquele problema de definição com a equipe grande usando ágil e todas as organizações né tá esse é só um paralelo do conceito né da transformação entre projeto e ágil e ágil escala então o ser sinal a gente sabe que dentro do serviço não a gente tem tanto o controle propriamente dito dos projetos como também a execução das atividades né No fim ali da da execução do projeto só que a gente sabe que muitas vezes as equipes que já utilizam né metodologia ágil tem lá só a sua predisposição né ela tem já selecionado né uma solução para execução projeto seja ele um gira ou um error ou qualquer outra solução o que que é legal né dentro do Service não a gente consegue integrar me direcionalmente né nativamente com essas duas soluções e outras mais para usar um certo sinal para controlar o plano de equipe por exemplo de execução ali do das atividades e sincronia com essa soluções de terceiro e todas as definições estratégicas todas as todo aquele trabalho que nós fizemos antes de abrir o projeto né tá em linha com execução propriamente dita da Estratégia né então trazer o trabalho do sistema dos de todas as equipes continua dentro da própria ferramenta mas a sincronização do status do da execução do trabalho dentro do serviço sinal a gente tem a visibilidade do Progresso fim a fim né do pai pelado em desenvolvimento fim a fim dentro do servo sinal independente da ferramenta que eu posso ter até mais ferramentas dentro das várias equipes de execução ágil e o certo sinal vai orquestrar e vai consolidar todo o trabalho sendo executado dentro de uma única solução Além disso eu tenho toda a parte né de backlog corporativo dentro do único lugar ou seja independente do de como que eu tô usando aqui metodologia que eu tô usando é tem um enterprise backlog dentro do server sinal ou de todas as tarefas todas as atividades ficam associadas ali a a épicos a a Elise trens a todas as as informações né necessárias ali para a condução de um projeto seja ele Station ou não e tudo dentro do único lugar onde eu posso Enfim repriorizar eu posso ter em sites sobre trabalho né Que tipo de de área tipo de pessoa que está executando eu tenho por exemplo wsjf para definir qual que é o peso né que eu vou atribuir em cada atividade né consigo ter visualmente numa única interface condição de definir que equipe vai fazer o quê em qual momento enfim eu consigo usar ações ali para colaboração né planejamento e por aí vai tá Além disso né na parte do Safe do Big eu tenho também condição de avaliar né Quais são as sprints quais são as testes né Quais são as dependências Qual que é o peso eu consigo ter toda essa visibilidade dentro de um único lugar eu consigo priorizar também a execução do trabalho em uma Sprint específica e ver qual que é o impacto que eu vou ter daquela Sprint né pelo peso da atividade eh em relação a toda a minha cadeia de interdependência né das atividades e consigo também validar o risco escalar né o trabalho planejar de uma maneira um pouco mais eficiente a execução de todas as sprints usando né Além disso né como tudo dentro do serve sinal eu tenho um set de relatórios analíticos né eu tenho o mesmo mecanismo de relatório e avaliação de performance dentro do Service sinal o SPM também utiliza né o mesmo as mesmas funcionalidades né eu já tenho uma série de relatórios prontos para não só trazer informações relacionadas a Scan a sprints felizes épicos de maneira fácil de maneira ágil e também flexível eu posso criar relatórios novos eu posso criar indicadores novos e associar nesses relatórios né então relatórios que já tem de barnabi relatório de forquece e todo trudal que eu faço eu acesso registro até o detalhe de todas as informações que estão sendo mostrados nesses países nesses relatórios em tempo real e como é a mesma plataforma né o acesso o relatório vivo né não é um relatório de menos um e por fim também a a capacidade da service não né em relação a gente mobile né eu tenho Capítulo específico ali de ESPM onde eu tenho Quais são as tarefas Quais são as sprints que estão acontecendo eu consigo agrupar por status eu consigo agrupar por uma equipes eu vejo o histórico de todas as tarefas as tarefas que são atribuídas a mim a minha equipe ou seja tenho condição bastante interação né digamos assim usando né o próprio o próprio aplicativo não só para leitura como também para execução trabalho adicionar notas na tarefa E por aí vai tá então também é um jeito fácil de interação né de acesso ali ao SPM do server sinal Vou passar o bastão agora para ler para fazer uma demo sobre Quais são as capacidades ali Quais são as telas e interfaces etc do servicinal do SPM focado em ajay e mais ainda focada já é escala esse é o morte da nossa discussão aqui beleza ali posso passar a bola para ti tranquilo cara vamos lá é só antes de começar tem uma uma questão aqui do Marcelo ele tá perguntando se os relatórios e as métricas estão disponíveis na versão Standard e Sim estão disponíveis na versão standar Marcelo a única coisa que a gente precisa deixar claro é que quando a gente fala de agilidade em escala Ou seja quando eu tô falando de Safe né ou de program na scream programs aí nós estamos falando da licença pro mas com relação a parte de dashboards de equipe ou seja tudo que tem a ver com agilidade em equipe incluindo os dashboards fica disponível na verdade não é nem disponível na versão stander a versão ele é disponível com a licença a giao teens que ela é Ela acompanha normalmente a versão Standard de forma gratuita entendeu então não é exatamente funcionalidade da estanda mas está disponível para quem tem a standar com a joyothings passando para nossa para nossa demo para nossa parte prática eu queria recapitular com vocês então né já que a gente tá falando de agilidade em escala e eu tô falando então em alinhar estratégia da companhia com a estratégia de produto com a execução Então vamos começar por aí né Relembrando né o que nós vimos na nossa primeira sessão na nossa primeira sessão a gente falou de estratégia e seguindo o mesmo Exemplo né eu tava falando dos objetivos estratégicos de Recursos Humanos eu tô aqui no meu portfólio de Recursos Humanos vendo os objetivos de recursos anos e esses objetivos esses okrs eles estão vinculados objetivos corporativos da empresa né então eu tenho três objetivos corporativos né inspirar os clientes colaboradores felizes e ser o líder na nossa indústria e com base nesses objetivos corporativos a área de recursos humanos criou seus okr e tem os dois objetivos aqui melhorar a satisfação dos colaboradores com os resultados chave de incluir inglês séries Fashion né engajamento e satisfação que tem os seus targets Então eu tenho aqui a base né porque é o ponto de partida a meta que é onde eu quero chegar o valor real é o último valor medido que me dá o progresso desse objetivo estratégico dessa esse objetivo não desculpa dessa meta né que depois vai ser alimentado ao objetivo vai Cascatinha para o objetivo alimentando aí esse esse percentual de de cumprimento dos objetivos em toda a cadeia né então partindo da Estratégia da organização Chegamos na estratégia de Recursos Humanos né tem uma outra questão aqui inclusive aproveitando da Viviane perguntando se a parte dos okr faz parte do estanda E aí não Viviane a parte d o KR né esta funcionalidade aqui tudo que tá aqui embaixo de gols que onde a gente tem objetivos e metas né Isso é pro e isso é parte da licença professional agora assim a gente falou também Marcelo tem mais uma pergunta eu já vou te responder daqui a pouquinho é a gente falou também né dos objetivos a gente falou dos objetivos então de recursos humanos que é o que eles planejam fazer e aí vem o backlog backlog é a lista de como eles estão se preparando para atingir aqueles objetivos ou seja uma série de ações uma série de iniciativas que estão sendo avaliadas com o objetivo de atingir aquelas metas né então aqui eles vão fazer né as avaliação por exemplo ordenar aqui por agrupar por objetivo estratégico Então eu tenho aqui várias iniciativas relacionadas a satisfação dos colaboradores outros em relação a a experiência mais mais simples de uso das soluções né então A ideia é que no backlog eu faço a análise de tudo que tá proposto né em relação a esses objetivos de RH e outros objetivos de outras áreas inclusive mas que sejam projetos e demandas vinculadas ao portfólio de Recursos Humanos priorizando essas informações eu vou montar um Road map né então aí eu passo da Estratégia da organização para estratégia do produto então de novo gols objetivos O que eu preciso fazer backlog como eu pretendo fazer isso e Road map quando estou planejando entregar esses resultados então aqui eu começo a montar o meu o meu Word map né eu tô fazendo aqui Aqui tá por iniciativa é pai mas eu vou fazer uma pequena mudança aqui só para a gente para a gente ter uma visão um pouco diferente eu vou colocar aqui o planeamento dentro dele vou colocar o objetivo estratégico né para vocês verem como tudo tá relacionado e vou botar aqui o estado no processo com benefício e custo muito bem então aqui eu fechei aqui as demandas né porque eu tô interessado agora em conversar com você sobre a parte de agilidade Então eu tenho demandas tenho épicos e tenho projetos tradicionais mas eu vou eu tô focando aqui nos épicos né então eu tô planejando épicos né eu tenho épicos que estavam propostos que eu priorizei e agora eu tenho esses épicos sequenciados ao longo do tempo uma primeira a primeira Estimativa de quando eu consigo entregar esses épicos aqui mesmo eu já consigo fazer avaliação de dependências né nesse nesse nível então eu por exemplo eu tenho aqui um Épico de automação do orkidei para folha de pagamento só que eu preciso do portal do gestor do work Day para fazer isso né então a desculpa é o contrário Na verdade o portal do gestor precisa dessa automação essa automação tá terminando em junho esse épico tá começando a a ser trabalhada em abril né então a gente precisa avaliar se isso é algo factível ou se eu deveria mover esse épico aqui para frente para conseguir vai para resolver essa dependência né então é claro que depois nos níveis de nos níveis de detalhamento aí do planejamento a gente vai ver se isso é um problema realmente ou não mas já é algo que você vai ter desde o início a preocupação em sequenciar esses épicos de uma forma que você consiga Minimizar ou se antecipar a problemas de interdependência tá muito bem então aqui temos o Road map do nosso do nosso dos nossos produtos de RH muito bem vamos agora trocar de perfil né Eu tô aqui no perfil executivo vou sair do perfil executivo vou para o perfil do gerente de produto que trabalha com Safe eu escolhi o Safe né o skate Framework porque ele tem mais vamos ele tem mais funcionalidade ele é um pouco mais abrangente então ele ele mostra mais os potenciais da agilidade em escala mas quem não usa Safe pode usar também para fazer essa mesma essa mesma esse mesmo tipo de trabalho que eu vou mostrar agora tá então tô pulando aqui para outra Persona né que Opa desculpa é para outra Persona que agora é que vai fazer a parte de do épico né do planejamento do épico para baixo Então ela começa aqui no portfólio Então ela tem aqui o mesmo portfólio de RH né eu tenho aqui um quadro do portfólio normalmente os épicos que estão sendo planejados eles vão caindo aqui no funil e eles vão sendo vão passar por um processo normalmente né um processo de revisão processo de análise até que eles estejam maduros estejam com informação suficiente para compor o backlog então quando o épico chega no ponto né de entrar no backlog eu já consigo fazer a análise aqui de backlog eu consigo priorizar esses épicos Então qual épico eu vou fazer primeiro qual eu vou fazer depois né então eu vou daqui decompor né os épicos decompor esses épicos em features né em características de solução as features por sua vez vão ser decompostas pelas equipes né em histórias que vão ser atribuídas as sprints então normalmente a gente não é uma regra Tá mas normalmente a gente mapeia o essas entidades né da agilidade com os níveis do próprio Safe então no Safe eu tô trabalhando em três níveis eu tenho 6 portfólio que é normalmente eu tô trabalhando em nível de épico né que tá alinhado a estratégia da organização como a gente viu no online planner workspace que onde eu tenho o roadmap de estratégia E aí eu desço para um segundo nível o segundo nível seria o Artur Easy train o trem de lançamento ágil né É melhor não traduzir essas coisas né então a RT ele é uma parte do Safe que ele vai me permitir primeiro da mesma forma que eu tava olhando o ciclo de vida dos épicos eu vou ver o ciclo de vida das features que estão sendo propostas para entregar aquele épico né então eu tenho features que estão entrando aqui né no funil elas estão sendo propostas né então elas vão ser analisadas elas vão ser uma vez analisadas elas vão compor o backlog de features aí eu vou conseguir monitorar aqui todo o ciclo de vida né do backlog para frente a implementação essas fases também são configuráveis né na sua na sua própria implementação a gente tem algumas coisas alguns facilitadores aqui nesse tipo de de visualização eu não preciso necessariamente abrir e Navegar para fazer mudanças né eu consigo fazer muita coisa aqui no próprio quadro né então vamos dizer que eu quero essa instalar novas ferramentas de desenvolvimento é algo que a minha colega Denise é quem vai fazer então eu posso facilmente atribuir essa ficha para análise da Denise né então é uma é uma ferramenta muito dinâmica para fazer essa Essa gestão do dia a dia da gestão do produto né muito bem então falamos do board onde a gente tem aí todo o ciclo de vida das features E aí a gente começa a montar da mesma forma que a gente tem um backlog de épicos eu começo a ter né No segundo nível de planejamento no release train eu tenho backlog de features né Tem alguns filtros aqui então eu posso avaliar por exemplo se tem features que alguém criou que não tá associada a nenhum épico então aqui na minha na minha base de demonstração tudo joia cities estão sendo derivadas dos épicos eu posso filtrar por épico para ver qual a situação das features né de cada um dos épicos ou eu posso né ver todas as features E aí eu tenho uma visão completa de como eu vou organizar e o meu o meu planejamento Normalmente quando eu tô falando nesse nível do RT né a gente tá falando em um time Box diferente né quando a gente fala de equipe a gente está falando de Sprint aqui eu tô falando de piá é um programment isso é uma definição do Safe né que é um é como se fosse a release quando a gente fala do scrum mas o Safe ele tem uma característica diferente não Obrigatoriamente um piai é lançado né o Safe tem um mantra em inglês se fala developen dance release on themend né desenvolver em Cadência lançar sob demanda então o ponto é a o desenvolvimento ele é cadenciado e contínuo né então eu tô lá desenvolvendo né tô na equipe desenvolvendo né Trabalhando as minhas sprints entregando o resultado das sprints eu tenho no nível das fichas sociais entregando features e isso é um trabalho contínuo mas eu tenho um gerente de produtos que vai tomar a decisão consciente de caso ele tenha validado que a quantidade de feixes entregues é suficiente para compor uma uma release aí ele toma a decisão de fazer um lançamento também cadenciado né então pode acontecer de a gente ter aí uma duas piadas um gerente de produto decide que não chegou num ponto suficiente para fazer o lançamento E aí ele vai esperar mais uma ou duas piais para depois fazer o lançamento Então não é necessariamente amarrado né que a piai vai ser uma release então o program increment até vou fechar o primeiro aqui então Programe increment ele é um time Box maior do que a Sprint normalmente aí a gente fala de seis seis sete sprints às vezes até 9 10 sprints por piai mas é um número Claro variável né Depende da de cada organização eu posso ter aqui o meu backlog eu tenho o meu backlog de features né como o Vitor tinha comentado a gente tem o método wsjf né que é working é water shortst que que é isso né é uma média ponderada de alguns fatores que vão fazer com que os menores trabalhos mais relevantes sejam é priorizados né então é uma é uma métrica do método Safe né E aí a gente coleta que essas informações né o valor gerado se é uma se é uma funcionalidade né uma Feet your crítica se ela né Tá reduzindo risco ou não E se ela e o tamanho da Fiat né normalmente a gente trabalha aqui em pontos né então tô usando aqui a sequência de Fibonacci para classificar o tamanho da ficha isto aqui né Tem uma fórmula e isso vai me dar o wsjf que é esse score aqui que é o score de vamos dizer prioridade da feature normalmente e eu digo normalmente porque nem sempre é possível né Mas normalmente você quer fazer as features com maior nota do discord wsjf antes né E aí você aqui no planejamento O que que você faz você vai colocando as features de forma sequencial aqui né Você pode priorizar as features com né arrastando para cima e para baixo e você vai preenchendo as suas piais com features que você espera que sejam entregues naquela piai normalmente o gerente produto faz o que ele pega todo o backlog de features e fala vamos fazer tudo nessas né dá para fazer tudo nessas piais mas nem sempre é verdade né Eu preciso ter uma uma conversa com as equipes de engenharia para saber se é factível né E aí entra o a pi planing né o programa isso aqui é um planejamento inicial do backlog E aí a gente passa para o piá e planning no piaip Planet né também chamada de Big room planning é o que a gente está fazendo é avaliando capacidade das equipes né capacidade de entrega e tá avaliando também interdependência mais detalhada ou seja interdependência em nível de história então eu tenho aqui cada cada linha né Cada faixa dessa dessa tela representa uma equipe então eu tenho uma equipe né no trem em Play Portal eu tenho a equipe de case Management eu tenho a equipe do portal eu tenho a equipe de front-end a equipe de interface e a equipe de banco de dados E aí eu vou ter histórias distribuídas por esse né De acordo com o backlog a especialidade de cada equipe né as features de cada eu vou ter histórias que vão estar distribuídas nas sprints aí começa o planejamento mais fino das equipes cada um vai fazer o seu Spring planing e o resultado né vai ser o primeiro quadro tá a RT o primeiro quadro do trem onde a gente vai olhar todos os problemas né então quem que tá estourado né se tem alguém estourado de capacidades tem problema de dependência aqui problema aqui por exemplo eu posso verificar um problema de independência né eu tenho uma integração com a gestão de casos e eu tenho uma história que é habilidade de criar um novo caso eu preciso desta história da Integração pronta para poder fazer essa criação só que as duas estão acontecendo na mesma Sprint Eu tenho um risco alto aqui de essa história não se entregue porque essa Demorou muito para ser executada então idealmente o que que nós vamos fazer ou eu posso trazer essa história né negociar isso e trazer essa história para esse para essa equipe né tendo em vista que é uma equipe multidisciplinar e dentro da própria equipe eles vão se resolver e vão fazer uma história antes da outra ou eu posso negociar entre as equipes que esta história ela não pode acontecer na Sprint 1 ela tem que acontecer na Sprint 2 então aqui é uma forma da gente refinar o planejamento inicial feito pelas equipes para que a gente elimine os problemas de dependência antes deles acontecerem né então a gente começa a ter e por isso a Cadência né de Safe a gente tem essa essa entrega cadenciada porque a gente tem muito menos bloqueio muito menos parada em função de uma dependência né do que quando eu tô trabalhando só com equipes ages quando eu trabalho com equipes ages você não faz normalmente esse tipo de análise cada equipe faz o seu planejamento né então eu não tenho nível do release trem eu venho aqui para equipe né a equipe tem o seu backlog Claro né tem as suas sprints da mesma forma que eu fiz lá o planejamento das features né a equipe vem aqui ela tem a sua capacidade Então ela ela tem aqui 10 pontos no total vocês já foram feitos Ainda faltam quatro essas print atual as próximas sprints eu tenho aqui seis pontos tô em 30% da capacidade então quando eu for fazer o planejamento na Spring planing da Sprint número 4 eu vou colocar aqui as outras histórias até ver né o que que acontece aqui com a minha capacidade né tudo que eu tenho se tudo que eu tenho para fazer vai caber na capacidade do grupo se eu vou ter um estouro de capacidade é essas duas histórias ainda não estavam como se diz estimadas eu tô com zero pontos então não mudou nada aqui na minha na minha Sprint né E na verdade eu vou primeiro eu vou avaliar a cada história né vou fazer uma uma estimativa em pontos né vou dizer aqui ah essa história vai ser é uma história de oito pontos sei lá e aí uma vez que eu coloque essa história na Sprint aí ela vai impactar aqui a entrega né a capacidade de entrega dessa dessa equipe Então as equipes normalmente vão fazer isso de forma separada de forma independente e elas vão ter o seu springtrack né o seu próprio board onde ela vai ver o ciclo de vida né Pode ser aqui das histórias ou das próprias tarefas que estão dentro de uma história né então para cada história você tem lá o desenvolvimento teste teste de com junto com usuário teste de aceitação com usuário né tarefas de análise enfim você tem uma série de de tarefas para entregar uma história aqui então é onde as equipes estão trabalhando né voltando né quando eu tenho as sprints que eu planejei né planejei fazer tudo isso aqui na mesma na mesma Sprint quando eu me juntar com outras equipes para fazer a pia e planer é que eu posso descobrir que o planejamento que eu fiz vai ter Impacto negativo em alguma em alguma equipe e eu preciso resolver esse problema né Então essa é a principal parte aí que o Safe tá agregando que o agilidade escala tá agregando né que são processos de controles e ferramentas para a gente poder sincronizar as equipes eliminar dependências diminuir risco e ter de desenvolvimento muito mais é muito mais assertiva se eu não tenho agilidade em escala normalmente eu vou ter uma equipe com tarefas ou histórias bloqueadas esperando outras equipes eu vou ter entre aspas atraso na entrega né eu digo entre aspas porque age eu não atrasa né eu tenho eu tenho [Música] Time Box fechado né a Sprint vai terminar queira você ou não se você o que pode acontecer que você não entregou aquela história e você tem que replanejar aquela história para a próxima Sprint Ou seja você muda o escopo não o tempo né então por isso que eu falo que é um atraso entre aspas porque a Sprint vai acontecer de qualquer jeito né só que você tem uma história bloqueada você vai ter que empurrar ela para a próxima Sprint vai ter que retrabalhar na próxima Sprint só que você já gastou tempo que você poderia ter entregue uma outra história na Sprint 1 e você acabou investindo tempo numa história que não pode ser entregue se quebra a Cadência de desenvolvimento Esse é um dos principais problemas que agilidade em escala quer ajudar a resolver então aqui a gente vai fazer o planejamento da piai resolver as dependências depois o time volta para casa né E aqui mesmo eles podem já fazer esse trabalho né então eu tenho capacidade sobrando porque eu passei uma história de uma de uma Sprint para outra de repente eu posso né se eu não estourei a capacidade eu posso puxar uma história do backlog para para compor essa outra Sprint né então aqui a gente vai fazer o planejamento fino né consolida integrado entre as equipes então uma vez feito o planejamento aí vai começar realmente a a execução E aí como como eu falei a gente vai passar aqui para o Spring tracking onde eu vou estar trabalhando em cada uma das histórias ou trabalhando nas tarefas de cada uma das histórias e dizendo a essa análise eu já fiz tá concluída essa esse teste já foi já vou começar a fazer E aí você vai avançando e movendo o trabalho e isso vai refletindo na história na feature e no épico chegando até o ponto em que eu tenho aqui no no nível executivo a visão de quanto de cada épico eu já consegui entregar a partir das informações que estão vindo diretamente da execução né e Finalmente né queria mostrar para vocês um pouco né os dashboards aqui eu tô com o perfil de uma product ouner e ela faz análise de performance também das das equipes né ela faz análise de como foi o release de como foi a Sprint como foi a Sprint em comparação a Sprint anterior e aí eu volto aqui né lembrando da pergunta do Marcelo ele perguntou se é partindo do pressuposto que ele tem a licença do ajayouting né se o plugin é qual plugin precisa ser instalado para usar os relatórios né E esses são os dashboards que vem com esse plugin tá ele é ele chama nível 2.0 alguma coisa dashboard e ele e o plugin ele é chamado ágil 2.0 performance Analytics pack Se não me engano tá mas se você for para a lista de plugins e procurar lá a dyel 2.0 você vai encontrar facilmente todos os plugins que que você tem disponíveis para trabalhar com Edge e com o PPM Standard tá bom vamos dar uma olhada Então vou pegar aqui o dashboard de uma release por exemplo então aqui no dashboard da release e o dashboard da Sprint ele é muito parecido tá só que ele tá filtrado por uma por time boxes diferentes né então eu tenho aqui o escopo dessa release eu tinha 594 histórias para entregar entreguei 68%, né tô vendo aqui que tem alguns pontos né de aceleração para um pouco acelera para um pouco normalmente vão ser as minhas sprints né eu paro um pouquinho para fazer a Spring planner review né então tô fazendo primeira Sprint planing acelera e entrego faça o Sprint review Sprint planing da segunda Sprint acelera entrega né Sprint review próximo Sprint planing Então a gente vai vendo aí a tendência de trabalho aqui na nesse percentual completado como comparação eu completei 68% das minhas features aqui e histórias mas eu tenho 87% da do tempo já passou né O time lapse é o tempo que o tempo que passou então preciso tomar cuidado né porque esta curva aqui ela tem que acompanhar mais ou menos isso aqui para a gente ter segurança aí eu tenho aqui e histórias que estão bloqueadas estimativas faltantes eu tenho aqui duas dois registros né duas histórias ou features com que não foram estimadas elas não têm os pontos né E aí eu tenho aqui a release Burn Down e a release burnap né que são as duas vai os dois conceitos né de tornap Burn que a gente usa muito em agilidade também com análise de tendência né então ele tá dizendo que a tendência se Tudo continuar como está é esta continuidade aqui Claro não se atenham os formatos dos gráficos tal os formatos dos gráficos não são os ideais Mas porque porque é uma base de demonstração então não tem ninguém efetivamente trabalhando e completando histórias e por isso a gente vai ver gráficos às vezes não tão não tão alinhados com a realidade a gente tenta fazer né resultados demo ficariam mais parecidos possível com a realidade mas nem sempre é possível então quando a gente olha um bundão por exemplo aqui eu tenho o Burn Down é ideal né que seria linear o bordão real né é o é o remanescente aqui né o é a linha verdinha e o escopo que é a quantidade de histórias né entregar que estão sendo medidas aqui ao longo do tempo né ou entregar e entregues né tem também uma visão de fluxo que é muito legal porque a gente consegue monitorar quanto né normalmente quanto a gente está gastando de tempo em cada em cada fase do processo né É para identificar gargalo para identificar capacidade disponível ou capacidade faltante né então é bastante interessante eu vejo aqui que no começo eu tenho muita coisa que tá pronto para começar né E no final eu não posso ter nada pronto para começar e tem que ter muita coisa completada né e normalmente né aqui o que que são essas esse saltos né são as sprints numa Sprint normalmente a gente não teria esse saltos né em teoria né se a gente tá seguindo a metodologia arrisca eu não tô colocando coisas novas na Sprint durante a execução da Sprint né Então essa linha normalmente é uma linha contínua né então eu tenho aqui tudo que tá pronto para começar no final da Sprint Eu já entreguei tá o completado aí vai começar a próxima Sprint eu faço o planejamento aqui eu tenho tudo que tá pronto para começar começo a entrega final da Sprint mesma coisa entreguei tudo aqui faço o planejamento tudo que eu tenho para entregar né então eu tô vendo aqui o como a as histórias estão fluindo ao longo do tempo e a gente consegue também fazer uma análise bem legal que a análise de ciclo né que é pelo Estado das histórias né quando tá pronta para teste né executando pronta para teste testando e eu vou analisar a história por história eu consigo ver quanto tempo eu fiquei em cada em cada fase aí eu consigo avaliar é velocidade né consigo avaliar a velocidade uma equipe consigam avaliar se se o equilíbrio de como se diz de funções na equipe multidisciplinar ele tá adequado ou se eu tô ficando muito tempo em teste eu tô ficando muito tempo em [Música] desenvolvimento né então algumas análises que como como product Manager são bastante interessantes para a gente fazer né então tem essa série de dashboards aqui disponíveis né para [Música] do ajayô 2.0 que a gente pode utilizar e eu acho que e uma uma outra talvez que seja interessante também é uma é uma visão aqui da performance das sprints né análise de equipe né então eu pego por exemplo para um determinado scream team eu pego consigo avaliar a performance aqui normalmente né o new screen dashboard né eu tô avaliando aqui equipes principalmente equipes iniciantes para as quais eu ainda não conheço a velocidade da equipe eu tô avaliando se elas estão cumprindo o planejamento Porque se ela não está cumprindo o planejamento preciso diminuir a capacidade dela né ela tem na verdade uma capacidade menor Então eu preciso ajustar e a gente vai comparando a performance dela Sprint é Sprint até a gente conseguir afinar a capacidade real que a velocidade de cada equipe e é isso acho que passamos até um minuto aqui da nossa agenda pessoal não temos nenhuma pergunta que que não foi respondida mas tiverem mais mais questões se tivesse surgido alguma dúvida fique à vontade aí para mandar para a gente a gente responde para vocês por e-mail E mais uma vez obrigado pela participação de todos muito obrigado pela atenção pessoal para todos um bom dia tchau tchau