Treinamento Agile | Parte 01

Ok ão conseguindo ver a tela compartilhada sim sim vamos lá ah a ideia pessoal o objetivo desse treinamento é fazer uma Fundação sobre metodologias ágeis e a gente discorrer um pouco sobre o que que é a a principais que a gente utiliza como que isso se diferencia eh de uma uma metodologia tradicional como um Cascata Em quais situações a gente deve utilizar uma ou qual deve utilizar outra de acordo com os critérios que que a gente vai acompanhar e principalmente também uma Fundação mais focado em ajai ou mais focado em scrum Então a gente vai

falar um pouco da cerimônias das dos artefatos dos papéis dentro do scrum a gente vai falar um pouco sobre também casos de sucesso estratégias de implementação e dificuldades de implementação e o objetivo principal no final de cada uma dessas sessões vai ser principalmente abrir para dúvidas ou alguma eh sugestão ou algo que vocês queiram compartilhar eh a Minha experiência é mais executando o scran não uma uma formação mesmo didática não uma formação de certificação a certificação que eu fiz é a scr fundamentals do scren study é mais básica inclusive vocês vão ver no final da

do último dia eu vou compartilhar com vocês o link para quem se interessar em fazer eu acho que é é bem válido ajuda bastante nisso mas a ideia principalmente para aqueles que vão ter o primeiro contato agora com a metodologia e já ter essa essa base pavimentada para depois um treinamento mais completo um treinamento mais eh didático digamos assim no stio mesmo da metodologia como ela funciona daí sim por um agilista por alguém que tenha a a devida certificação então tenham isso em mente pro pros próximos slides também e de novo não precisa esperar os

últimos 5 10 minutos da reunião para fazer dúvidas comentários ou até mesmo contribuir com alguma coisa do assunto Tá fiquem à vontade para eh colocarem a abordagem de vocês durante a conversa também Então como que ficou a separação vão ser quatro dias né Quatro agendas de uma hora cada na de hoje a gente deve cobrir a parte de definição e princípios fundamentais do ágil eh O que é o Manifesto ágil Quais são os valores a uma comparação entre ágil e e Cascata que é a a metodologia da gente que vem do rp tá mais habituado

Quais são as outras metodologias ágeis que não é apenas scrum e principalmente os critérios pra gente poder escolher cada uma dessas essas metodologias né quando utilizar uma e quando utilizar outra dia dois é uma visão geral aí mais específico do scrum Quais são os papéis e quais são os artefatos o dia trê a gente vai focar nas cerimônias então Sprint planning a Daily a review e retrospective e no dia 4ro estratégias desafios cases de sucesso e falar também sobre as certificações que que tem na área dando sequência Então pessoal Qual que é a definição de

ao né ao até gera um pouco de discussão se é uma metodologia se é um Framework se é uma maneira de eh gerenciar projetos como é por exemplo eh o pmbx se é uma alguma coisa assim então mais elaborada ou até mesmo alguma coisa mais mais travada mais definida que temha um dono o o ágil ele vai fugir um pouco desse formato mais tradicional porque ele é mais orientado por princípios e Valores do que por eh um livro ou alguma algum corpo de agilistas que tenha feito essa definição então mais do que uma metodologia de

desenvolvimento de software é uma abordagem para gerenciamento de projetos e aí vale um parênteses que não são só projetos de ti eu posso ter um projeto de engenharia rodando num formato ágil eu posso ter um projeto de construção eu posso ter um projeto de RH rodando no formato ágil mas o nosso foco aqui vai ser obviamente os projetos de ti então a priorização é de uma adaptação rápida é de uma colaboração contínua e uma entrega incremental de valor ao cliente e ele desafia um pouco os métodos tradicionais porque ele foca na flexibilidade e no cliente

capacitando as equipes para poder chegar nos objetivos estão vendo que o texto é bem bonito e rebuscado né com destaque pro autor que sugeriu frasear dessa maneira mas brincadeiras a parte é uma definição que foge um pouco das definições dos livros que cada autor busca colocar aquilo que cobre o que ele deseja cobrir Então acho que esse aqui reflete bem como o ágil ajuda e aporta pros projetos de te como a gente vem Trabalhando dentro do Manifesto ágil que é assim o guarda-chuva que cobre eh todos os frameworks que vão existir ali dentro todas as

variações todas as aplicações deles e esses são os três principais Pilares adaptabilidade flexibilidade entrega contínua de valor e colaboração e comunicação de maneira resumida qualquer item que vá surgir dentro do projeto ou qualquer ação ou qualquer esforço que vá ser colocado dentro do projeto deveria est fazendo o projeto evoluir em favor de um ou mais desses Pilares Então se é algo que não tá favorecendo a flexibilidade não tá favorecendo a entrega contínua de valor não não favorece a colaboração isso muito provavelmente não tá indo de eh encontro com os valores do do ágio do Manifesto

áudio então foram um grupo de eh gerentes de projeto um grupo de pessoas que começou o desenvolvimento dessa parte do ágil que criou esse Manifesto eu vou disponibilizar o link na no final da apresentação para para vocês para quem quiser acessar e ler O Manifesto inteiro mas em resumo ele pode ser agrupado nessas quatro definições indivíduos e interações mais do que processos e ferramentas então processos e ferramentas são importantes mas os indivíduos e a interações entre eles são mais importantes do que processos e ferramentas o software em funcionamento é mais importante do que uma documentação

abrangente Então já colocando um pouco em perspectiva com a metodolog Cascata eh a Cascata sempre foca bastante na construção de documentos para quem já fez projeto na Cargil principalmente sabe bastante da especificação funcional da especificação técnica de uma BRD de uma ifd Então são vários documentos que às vezes a gente investe quase tanto tempo quanto construindo a documentação quanto trabalhando na solução e pro ágil e Isso muda um pouco mais de figura é mais importante que o software funcione do que esteja com uma documentação detalhada bem abrangente não quer dizer que não precise de documentação

ou que precise de zero documentação então a ideia nesse ponto específico é sempre buscar um equilíbrio importa que o software funcione sim mas sem uma documentação a gente sabe o quanto isso vai afetar o suporte depois vai afetar a manutenção desse sistema ou novas funcionalidades então é importante que exista uma documentação mas o software funcionando é mais importante do que uma documentação bonitinha eh e esse ponto agora próximo aqui ele é bem crítico principalmente pra gente na consultoria Na parte de negociação a colaboração com o cliente é mais importante do que a negociação de contratos

o que que quer dizer que é melhor você ouvir o teu cliente entender o que ele quer e atender o que ele quer do que se preocupar na seguimo de um contrato ao pé da letra Lógico que isso faz muito mais sentido quando você tá falando de uma de um projeto ou de uma execução a jaio Eh vamos supor com a gente aqui dentro da goom fazendo um projeto interno por quê Porque os clientes somos nós o cliente é nosso Então esse relação essa relação fica um pouco mais tranquila quando a gente tá lidando numa

prestação de serviço e isso depende de um contrato com um cliente que tá atrelado a uma cobrança é um pouco mais complicado a gente deixar a colaboração ultrapassar o nível da negociação de contrato porque envolve custo envolve horas envolve esforço então é um pilar do ágil que é importante é parte dos princípios do ágil por outro lado é algo que a gente precisa também dosar bastante porque eh somos uma consultoria e dependemos muito forte da negociação de contratos e o último Pilar é responder mudanças responder a mudanças é mais importante do que seguir um plano

então grande parte da diferenciação do ágil vai muito mais eh naquilo que é flexível naquilo que é adap ável do que um plano pré-definido que a gente tenha antes não quer dizer que áo seja melhor ou pior do que outra metodologia a gente vai ver isso na comparação com com o Cascata mas que o foco do ágil É principalmente você tá apto a responder a mudanças a ter um um escopo menos definido a trabalhar com mais incertezas do que eh seguir 100% ao pé da risca um plano que foi traçado no início do projeto dúvidas

até aqui pessoal tranquilo adiante aqui a gente procurou trazer Quais são as principais diferenças entre a metodologia ágil e metodologia Cascata né o Waterfall que como normalmente a gente trabalha dentro da parte de de um projeto em em RP e inclusive vai ficar claro aqui quais são os motivos porque que esse formato é tão mais mais popular num num RP né o formato cascata do que um formato ágil além de outros pontos que a gente vai ver mais no no final dessa apresentação então a abordagem de desenvolvimento né a maneira com que a gente entrega

o software dentro de uma metodologia ágil ela é iterativa e incremental não confundir iterativo com interativo iterativo quer dizer que é cíclico que é repetível e incrementar porque você tá sempre trabalhando em cima da uma entrega inicial então no ágil é normal você ter vários ciclos repetitivos por exemplo vou obter requerimentos com a área de negócio a gente faz isso e a gente começa a desenvolver e entrega e volta a repetir a falar com área de negócio a capturar requerimentos e entregar e fica repetindo dentro desse ciclo tem um desenho bastante clássico do do ágil

Mais especificamente do do scrum que a gente vai ver na na próxima sessão que deixa bem claro essa ciclicidade digamos assim desse modelo de desenvolvimento enquanto no Cascata é sequencial e até por isso que é chamado de cascata né você executa uma fase completa Você move paraa próxima fase move paraa próxima fase isso dentro de um gráfico gigante no modelo de gerenciamento de projetos tradicional fica bem claro ali uma fase terminando para começar a próxima a flexibilidade dentro do modelo ágil ela é considerada alta Ou seja eu posso ter Incerteza de requerimentos eu posso me

adaptar muito mais do que no modelo Cascata que já começa com um escopo fechado que já começa com prazos fechados e com uma equipe pré-determinada isso no ágil permite que ele seja mais adaptável a mudanças enquanto no modelo Cascata se eu iniciei o projeto se eu tenho o escopo definido após essa fase de planejamento inicial se adaptar a mudanças é bem mais difícil normalmente vai envolver uma ch request vai envolver um replan ento uma repriorização de atividades então é um pouco menos flexível do que o modelo ág a entrega de valor é contínua incremental isso

quer dizer que eu posso dentro do ágil assim que eu terminar de desenvolver uma funcionalidade eu já poderia fazer com que o negócio utilizasse ela e e absorvesse o valor que essa entrega fez enquanto no Cascata normalmente eu tenho uma única entrega de valor no final do projeto e é bem comum quando a gente tem um projeto eh ágil você Fazer Entregas parciais e você não tem assim um grande bive você normalmente tem várias releases menores Cada uma com um grupo de funcionalidades enquanto num Cascata a gente pegando o exemplo de várias eh projetos RP

que a gente faz fallouts implementações você tem um grande dia para poder fazer uma uma entrega dessas o o envolvimento do cliente no ágil ele é colaborativo e participativo então é necessário que o cliente esteja envolvido durante todas as etapas tanto de validação de escopo quanto priorização de escopo quanto teste daquilo que tá sendo entregue enquanto no cascato a gente envolve o usuário em algumas fases pontuais por exemplo vou levantar os requerimentos Eu preciso da área do negócio depois eu vou passar uma fase grande desenvolvendo e fazendo os meus testes para depois na fase de

teste de aceitação de usuário eu voltar a envolver o negócio então no ágil tem essa eh Esse envolvimento do cliente maior número de Fases e um com uma maior participação eh o próximo ponto de visibilidade transparência ele é mais voltado no sentido do usuário e do gerenciamento do projeto porque no ágil você consegue perceber mais eh facilmente mais de maneira visível a situação de um projeto porque as entregas são parciais as entregas são contínuas então se um determinado momento é esperado que você tenha o número de funcionalidades entregues e você não tem você consegue perceber

nessa hora enquanto num projeto Cascata a visibilidade é menor Porque você só vai descobrir que tá atrasado quando um grande bloco de Fases ou de entregas que deveriam ser disponibilizadas para testar não estão sendo entregues eh o controle de qualidade no a normalmente ele tá envolvido com testes contínuos e integrados não que isso seja uma regra não que a metodologia obrigue Isso é só sugerido como uma boa prática você ter esses testes contínuos e integrados principalmente se você envolve área de usuário e vai seguir no scrum por exemplo um Sprint review Sprint retrospective o usuário

só vai dar o aceite da entrega dessa Sprint se a qualidade tiver de acordo com aquilo que foi pedido lá no início da Sprint enquanto o controle de qualidade no Cascata existe também mas é um teste realizado no final de Fases específicas terminei o desenvolvimento Faço o teste unitário terminei de fazer o teste unitário Vou para um teste de eh garantia de qualidade terminei isso vou para um teste de aceitação de usuário Então são testes específicos em fases específicas também sequenciais o risco no ágil ele é considerado que é gradualmente reduzido Por quê eu começo

com grandes incertezas eh grandes requerimentos que eu não tenho ideia de como isso ficaria mapeado de maneira completa no início do projeto Então à medida que o projeto vai executando e você vai fazendo essas entregas parciais e vai obtendo as definições e vai obtendo o feedback dos usuários esses riscos vão diminuindo por qu o usuário Vai vendo aquilo que tá sendo construído Vai vendo aquilo que ele já tá pedindo e tem mais tempo de conseguir se ajustar Então se é alguma tela se alguma funcionalidade não tá de acordo com o que o usuário pede dentro

do áo pela característica interativa dele a gente consegue fazer esses ajustes antes de uma grande entrega enquanto no Cascata eh a gente tem que tentar identificar e mitigar os principais riscos no início do projeto por se surgiu no meio do projeto Cascata que já é sequencial que já é com uma flexibilidade mais baixa um risco muito grande isso vai colocar eh algum problema para prazo do projeto para ade ou Budget do projeto falando em complexidade o ágil é muito mais adequado para projetos que T uma complexidade mais alta e um volume maior de incerteza por

se eu tiver certeza de todos os requerimentos mesmo que seja de alta complexidade faz mais sentido eu utilizar um modelo Cascata por quê Porque eu já sei os requerimentos eu já conheço que vai ser desenvolvido eu não vou ter surpresa no meio eu consigo planejar el antecipadamente mas se é com uma área de negócio com quem não tem ainda domínio Total daquilo que tá sendo solicitado ou é alguma área nova mesmo para paraa consultoria o ágil permite que você tenha esse esse aprendizado e esse mapeamento mais eh aos poucos das dos requerimentos do projeto por

outro lado né e tinha que ter algum ponto em que eh não que seja um ponto negativo mas que seja um ponto que faz a gente precisar considerar muito a adoção de ágil e não casc cata em um projeto é que justamente por ter menor previsibilidade né Eu não tenho certeza do tempo que eu vou precisar para desenvolver tudo que tá sendo pedido ao longo do projeto os custos e prazos dele vão tender a ser maior Ou seja existem projetos e a gente pode citar exemplos de projetos na parte de cases ali principalmente com com

a Cargil e a gente sabe que entre aspas viram projetos eternos por quê Porque sempre surgem requerimentos porque sempre surgem eh eh às vezes um detalhamento maior de um requerimento que já existia que era considerado mais mais simples então isso muda até mesmo o formato de venda ou formato de precificação que esse projeto pode ter com o cliente não faz sentido Por exemplo eu vender um projeto ágil com o preço fechado por quê Porque eu não sei quantos requerimentos ou qual nível de requerimentos ou quanto isso de esforço vai fazer num projeto RP para eu

rodar ele dentro do formato ágil então se eu já tiver esse nível de certeza de requerimentos de prazo de orçamento de equipe de complexidade eu não preciso fazer isso de uma maneira em que eu vá entregando e testando eu posso fazer um projeto cascato por tem maior previsibilidade tem menos flexibilidade para ajusto Mas pelo para ajustes mas pelo menos o custo e o prazo já é conhecido desde o início do projeto dúvidas comentários eu queria fazer uns comentários do Bard pode ser claro fica à vontade eh vou pegar esse último ponto que você eh falou

eh um complemento se me permitir é isso que você falou né de de negociação às vezes comercial de de projetos eh ajo eu acho que é que é importante a gente tomar em conta que no ajai em qualquer um das das variantes que ele tenha é muito improvável que a gente consiga fazer um preço um projeto de preço fechado com o escopo e o prazo fechado tem tem possibilidades que que tem que ser muito bem conversado com o cliente muito bem negociado e muito bem destacado nas propostas que é a gente vender um projeto de

preço fechado com sprints fechadas então a gente vende a sprint com a Squad né que é o que é o time que o Bard com certeza vai falar isso esses termos um pouco mais paraa frente mas dizendo Tipo olha eu tenho tenho esse tempo esse time dedicado por esse tempo para você e eu entendo que o escopo que a gente tem hoje cabe aqui for variando a gente pode ter que mudar o time a composição do time ou o tempo de dedicação desse desse time né então e obviamente isso depende do começo do do projeto

nas primeiras etapas que o bardel também vai vai falar da importância das primeiras etapas das primeiras sprints do do projeto eh então ele ele tem essa entre aspas variação de projeto de preço fechado que ela é mais difícil de amarrar comercialmente falando porque o cliente às vezes não escuta o que ele o que ele não quer Eh enxergar e eu acho que uma uma observação né uma opinião na verdade importante para compartilhar é eh pra gente não ficar com a sensação de que a flexibilidade ela é só ela é só boa né na nos dois

projetos exige muito eh cuidado o bardel falou que vai citar alguns exemplos Onde isso foi um um problema né se a gente não controla o backlog e nenhum dos dois projetos não controla o Av se nenhum dos dois metodologias a gente vai ter problema no no final do do mesmo jeito então só para não ficar uma falsa sensação de que o risco do do ajai ele é menor por ele ter realmente mais vantagens com a flexibilidade não se a gente não controlar o projeto o trabalho do scur master ele é tão ou mais importante do

que o gente do projeto eu diria exato e junto a gente vai ver também mais para frente e muito bom se aporte Fabrício a parte também do da figura do Product owner que é a pessoa do negócio que fica envolvido aqui dentro que acaba tendo que normalmente por ser uma pessoa do negócio colocar um pouco o chapéu de ti para poder priorizar os requerimentos até dentro da própria execução do ágil é flexível é é negociável é mas eh existem as compensações então eu quero esse requerimento eu quero com essas funcionalidades e eu quero na próxima

entrega ok a equipe pode se comprometer com a isso mas em paralelo você vai ter que abrir mão de outros reer você vai ter que postergar outras entregas e entender o qual que é a capacidade de execução da equipe dentro daquela ou daquelas sprints então isso também influencia bastante justamente porque como Fabrício falou tem essa questão da da flexibilidade não é que pode tudo dar tudo dentro do prazo não é flexível no sentido de acomodar é flexível no sentido da gente poder eh fazer trocas ou fazer adaptações mas também eh não adianta querer colocar 1

milhão de requerimentos novos e continuar com o mesmo custo com a mesma equipe ou com o mesmo eh prazo das entregas que já tinha sido combinado anteriormente acho que o resumo dessa fala é Não existe um formato mágico não existe um formato que sirva para todos e um formato que seja melhor e tudo depende muito do caso a caso de cada um dos projetos a gente vai falar disso na no final da sessão de hoje mas é an saber que ah olhando nessa comparação o ágil é superior ou o cascato é superior não felizmente não

existe uma uma conclusão dessa né que vai existir é a necessidade de de cada um dos casos seguindo adiante eh Normalmente quando a gente fala em metodologia ágil a gente pensa no scrum eh mas não é o único única metodologia que existe a gente tem o canan a gente tem o Extreme programing A gente tem o Lin tem o fdd tem o Crystal e existem vários outros alguns menos conhecidos mas existem várias maneiras de aplicar metodologia ágil dentro de um projeto de acordo com a necessidade cada um dessas metodologias vai servir para uma eh determinado

tipo de projeto ou um determinado tamanho de projeto e a gente procurou trazer aqui uma comparação para tentar exemplificar quando cada um deles eh pode ser utilizado ou faz mais sentido e alguns são bem específicos de de áreas ou de indústria enquanto outros são mais padrões assim como o scram é para ti mas para ti para projetos maiores e com mais incertezas eh num fluxo de suporte ou num fluxo de tarefas contínuas que não vão ter um começo meio e fim como por exemplo um suporte faz muito mais sentido um modelo cban uma uma tabelinha

um pouco extensa a gente não vai passar por todos os casos depois compartilhando o material vocês podem e ler no detalhe o treinamento vai se enfocar mais no no scran que é o que a gente vai utilizar para pra maior parte dos projetos Mas eu procurei trazer para vocês que existem outras metodologias existem Outras aplicações de ágio se a gente faz um scram por exemplo para um projeto Pequeno ou para um projeto mais simples a própria estrutura e cerimônias e eventos que ele pede vai fazer com que esse projeto fique um pouco engessado não faz

sentido se às vezes é um projeto uma equipe com uma duas pessoas você fazer por exemplo uma um Daily scrum fazer uma reunião diária com duas pessoas dentro do projeto muito mais fácil essas pessoas irem se falando ao longo do dia não faz sentido você nomear eh uma pessoa como product owner outra como scas E sobrou uma pessoa para ser da da equipe de desenvolvimento então de acordo com o tamanho do projeto com tamanho da equipe é recomendável um uma metodologia diferente de ágil para aplicação aí falando de de exemplos de desenvolvimento né quando eu

usaria vamos dizer scrum vou desenvolver um aplicativo vamos dizer um aplicativo móvel Mas eu ainda não tenho certeza do detalhe de todos os requerimentos que eu quero dentro dele então como a gente vai ter um lançamento vai ter um momento que a gente chega e vai querer fazer uma eh uma disponibilização desse aplicativo faz sentido que eu tenho o scrum por ele é interativo É incremental mas ele vai ter um fim vai chegar o momento que eu vou considerar esse desenvolvimento concluído eu vou ter partes envolvidas diferentes eu vou ter alguém e do negócio de

uma área eu vou ter do negócio de Outra área eu vou ter ti então é um formato que comporta bem essas esses papéis diferentes e ele permite que eu faça várias entregas e pegando o exemplo do canan né como eu falei suporte suporte faz bastante sentido para canan ou por exemplo uma implementação de um 5S ou alguma coisa assim o canan normalmente é aquele board mais simples e não tem papéis fixos não tem um exas não tem um product owner e não tem Eventos você pode instituir uma dele você pode fazer alguma coisa assim mas

não tem nada do cban que Dite isso ele é muito mais flexível e muito mais recomendável para projetos ou menores ou contínuos dentro do lim ele por focar mais na parte de redução de desperdício ele é para funcionalidades mais enxutas funcionalidades em que você precisa entregar um MVP então ele é muito utilizado por startups Justamente por isso ele foca naquilo de dar prioridade para o que tem valor então os artefatos que ele gera são fluxo de valor o mapa de fluxo de valor também não tem papel fixo a equipe é auto-organizada então ele faz muito

mais sentido dentro de uma estrutura essa de e Startup Sem falar que ele é altamente escalável Ou seja eu posso ter uma equipe trabalhando num projeto LM com 20 com 30 com 40 pessoas enquanto no scrum não é recomendado trabalhar com equipe tão grande assim você perde o controle você começa a ter que ter o tal do scrum dos scrums E aí começa a ficar um pouco não gerenciável e o último né o XP Extreme programming é uma metodologia ágil também mas 100% focada no no desenvolvimento de software então entram algumas técnicas de per programming

de coach com desenvolvedor mais Senior eh utilizam eventos como planejamento do jogo e programação em par gera histórias de usuário testes automatizados então é uma metodologia também que pode ser utilizado em conjunto com scram eu posso ter uma equipe No scram trabalhando e dentro do scram eh desenvolvedores na Equipe técnica tá usando o XP eh de novo também é ável mas tem as limitações do scrum posso ter uma equipe grande mas isso começa a ficar mais difícil de gerenciar e pode exigir uma adaptação aliha e a última linha ali ficou de proposta assim mesmo porque

mostra reforça um dos valores do a qual que é o foco de todos os desenvolvimentos é no cliente o foco principal é o cliente dúvidas uma dúvida bardell exceto kamban que a gente de certa forma a gente acaba usando aqui pontualmente esses dois essas duas outras metodologias L software e Extreme program você comentou bom mais para jogo e tal mas de qualquer forma você vê alguma utilização para nós aqui ou você acha que de fato não é aderente olha carão do que a gente tem hoje no no Pipe de projetos Talvez o XP ele chama

ali planejamento de jogo mas ele não é para desenvolvimento só de jogo tá é é só o nome el pode ser usado para para software corporativo também eh eu acho que a gente pode se beneficiar de alguns processos do XP eu acho que a gente conseguiria colocar algumas coisas em práticas principalmente dentro da das equipes de desenvolvimento ali de outras linguagens né do pessoal de web de backend consegui utilizar bastante coisa disso no LM eu sou honesto em te dizer que eu não conheço implementações eh práticas dele ou cases de projeto de link que justifiquem

a a diferença de utilizar ele e não eh o scrum e um dos casos da enfim da dos livros sobre isso dos casos mais acadêmicos eles falam para poder fazer para utilizar o link numa migração de sistema legado para um novo sist tema por como L enfoca na na parte de entrega de valor e de redução de desperdício normalmente nessas migrações você tem a oportunidade de identificar processos que não agregam valor então Eh utilizando o Lim você eliminaria esses processos e não migrar eles para uma nova solução se a gente tivesse alguma algum Case assim

eu acho que seria interessante eh ver a bibliografia do LM para ver se tem Fit com uma com o desenvolvimento dessa mas eh infelizmente Minha experiência nisso é zero Ah mas legal de deu para responder bem mordan obrigado imagino trabalhei já com XP É bem parecido com com ess grp né aqui uhum beleza eu tenho uma na experiência né na verdade eu eu eu assumi uma equipe num passado que tinha que usava ali o o liin e a única coisa que eu vejo a única não assim uma aqui de bate pronto vejo pr pra gente

principalmente por essa por um pedaço dessa parte de não poder não possuir papéis fixos e se tem uma equipe auto-organizada é quando a gente precisa ter equipes mais enxutas para chegar ali no num preço no limite do no perto do orçamento que o cliente tem E aí vou pegar um papel específico tem obviamente seus riscos eu acho que precisa de muita maturidade de muito treino para conseguir funcionar isso no longo prazo no médio longo prazo que é você utilizar por exemplo um perfil que hoje a gente chama de funcional né que que na nas novas

tecnologias a gente tem um um nome mais chique que o Pedro sugeriu né que é product Manager que é o cara fazer ali o papel funcional mesmo mas ele também fazer um papel perto do do do screw master um pouquinho do po ou o seu par do Poo dentro do cliente Então eu acho que para projetos de orçamento mais curto o cara fazer mais de um de um papel o front que faz um papel de ex também Então nesse caso ser um um time um pouco mais multidisciplinar eu vejo não tão multidisciplinar não tão eh

até para não criar criatividade a gente já tem demais né aqui na na GO então para não dar espaço muito para paraa criatividade bardel eu só senti falta aqui uma crítica construtiva Eu senti falta da que mais se usa no mercado que é a cascá vi Cadê a Ah sim ess você vai ter lá nos desafios de implementação Fabrício tem lá o nosso famoso cascajo do ágil e jogar dentro da da cascata é pegar o Cascata e colocar um escur master e dizer que que é ágil eu achei que você fosse sentir falta aqui Fabrício

daquela outra metodologia ágil chamada Extreme go Horse é essa essa existe bastante também essa existe bastante essa é mais utilizada né Essa bastante utilizada né carão ela é a famosa bastante variação da programação orientada a gambiarra né a POG só que ela não é POG porque POG tem que pensar essa não então vamos evitar o o horor aqui pessoal e pessoal eh Outro ponto interessante também é que como Fabrício falou a gente costuma ser criativo Então por um lado existe a bibliografia existe a a a metodologia canônica digamos assim de cada um desses itens por

outro lado a gente sempre procura adaptar ele dentro da nossa realidade então ah o scrum pede que a gente faça reunião de Sprint review e de Sprint retrospective a gente vai ver isso no detalhe Qual que é a diferença e para que que serve cada um desses eventos na prática e até pela audiência e pelo objetivo a gente costuma executar em um evento só de novo Eh Se você pegar o smb ele vai falar lá que o ideal é que isso seja separado na prática Poxa vou separar a equipe No final de cada Sprint para

poder fazer duas reuniões separadas não é tão produtivo assim eh como Fabrício falou vou ter que ter uma pessoa de product owner outra pessoa dis PR Master o restante da equipe de desenvolvimento que que eu posso fazer poxa se o projeto é um pouco menor não vale a pena eu colocar o o o po ali o product owner já para tocar algumas tarefas do scr master também e se for alguém que tenha tempo e que tenha disponibilidade que saiba desenvolver eu não posso colocar essa pessoa para desenvolver também então assim de novo existe o que

é a metodologia existe o que que é a a bibliografia dela e existe o que que a gente acaba aplicando dentro da da prática Estamos fazendo mais certo Estamos fazendo mais adequado Eh estamos fazendo aquilo que tá dando para entregar então a ideia eh sempre assim para poder colher os objetivos que a metodologia se propõe que a gente siga ela o máximo possível perto daquilo que ela foi desenhada perto do que ela foi proposta por outro lado as adaptações são inevitáveis a gente sabe que a gente tem uma realidade eh cada cliente cada projeto cada

enfim Cada pessoa tem a sua realidade Então são necessárias vezes adaptações daquilo que a gente tem aqui dentro um dos Desafios que a gente vai ver e que daí sim pode inviabilizar adoção de alguma metodologia dessa é quando a consultoria ou a equipe de projeto vai seguir essa metodologia e o cliente não segue aí começa a ficar um pouco mais complicado porque a gente vai estar falando duas línguas diferentes a gente vai trabalhar com expectativas diferentes e o resultado E invariavelmente vai frustrar algum dos dois lados acho bom até B pegar um exemplo prático né

E quando você vai fazer a a PL né da da Sprint a Sprint plan o o ajo em si eh pensa muito em capacidade né do do que o time pode produzir Esse é um dos conceitos super básicos o bardell obviamente Vai vai detalhar isso e tem uma uma coisa que quando você é criativo né quando você faz essas adaptações ou qu do time é multidisciplinar se leva em conta Qual é a capacidade que aquele membro da equipe consegue executar então se eu tenho uma pessoa que ela é um funcional e que ele pode atuar

em alguma coisa de desenvolvimento Você pode considerar que a capacidade daquela pessoa não é de 8 horas por dia porque ele não é exatamente um desenvolvedor ele vai atuar em algumas atividades você pode dizer que Apesar dele estar alocado 8 horas a capacidade dele é de 2 horas são adaptações que você faz na na plen né Então esse é é um conceito por exemplo que o Cascata nem nem imagina isso ele nem isso simplesmente não existe no cascata no ajai ele tem essa capacidade de você essa possibilidade de você considerar capacidade e não o tempo

dedicado né que são duas coisas de diferentes Exatamente isso depois vai est bastante vinculado a gente vai ver também na parte da planning não em muito detalhe até por conta de tempo mas eh a parte de estimativa e a parte de definição de duração de atividades dentro do ágil Ela é bem diferente do Cascata enquanto no Cascata a gente sempre tá falando do famoso eh homens hora ou homens mês versus eh número de horas para uma atividade dentro do á a gente começa a trabalhar com conceito de stó points que a gente começa a trabalhar

com capacidade do time quantos ST points aquele time entrega por Sprint Então muda um pouco a maneira com que a gente faz o planejamento daquelas entregas mais algum ponto pessoal então agora eh os principais motivos que a gente tem ali de dizer por que eu tenho que usar x E por que que eu não uso Y né Por que que eu vou seguir uma metodologia ágil e não uma cascata porque dentro do ágil eu vou seguir uma scrum e não canan então eu procurei trazer aqui os principais fatores que ajudam a gente a a decidir

e definir cada uma delas e não não é uma fórmula para eh chegar em alguma delas específico mas sim como instigar a discussão que vai fazer com que a gente chegue no resultado qual que é complexidade do projeto eu trouxe até uma colinha aqui porque evitei deixar o texto todo no no slide mas a complexidade do Projeto vai influenciar diretamente aquilo que você vai utilizar para poder gerenciar ele por qu projetos com requisitos bem definidos e com baixa incerteza como a gente falou lá no início cara vamos pelo formato Cascata por quê Porque eu já

sei quando vai começar quando vai terminar qual que a equipe que vai ser alocada quem que é o desenvolvedor quantas horas ele vai ter por dia trabalhando naquilo e Fechou tá entreque Ah não é um projeto muito complexo e eu não tenho certeza de tudo que vai surgir no meio dele que eu vou ter que desenvolver Então vamos para um formato mais ajai Ah agora dentro do ajai o que que eu vou utilizar eu vou utilizar scrum porque ele tem início meio e fim e porque eu tenho uma equipe de um tamanho adequado e porque

eu sei que essa equipe se encaixa bem no scrum OK agora não pode ser um cban pode ser um lim então a complexidade do projeto acho que é o o primeiro e um dos principais fatores já para começar a filtrar o projeto é complexo e é incerteza vai pro ajo depois dentro do ajo vê qual se encaixa melhor indo na sequência qual que são eh Quais são as necessidades do cliente Ah o cliente precisa ter esse projeto entregue rápido o cliente precisa ter esse projeto eh sem muita interação da equipe dele com o escopo pré

infido Legal vamos para um Cascata Ah não ele precisa ter entregas frequentes ele precisa ver isso incrementalmente tomando corpo ele precisa fazer um lançamento agora nem que seja de um produto mínimo viável e daqui um pouco você pode adicionando novos requerimentos Ok então vamos para formato AJ e vamos para um scrum outro ponto que a gente falou antes cultura organizacional o que que isso quer dizer se o cliente não usa a jaio não adianta a gente querer forçar colocar um projeto a jao lá dentro se a a a empresa se quem tá implementando o projeto

não tem e uma cultura jao não espera trabalhar de acordo com com as entregas de um de uma metodologia ágil a gente forçar a barra nisso vai gerar problemas então a cultura organizacional às vezes por mais que você olhe e fale poxa esse projeto aqui tinha tudo para poder rodar bem num scram mas a cultura organizacional de onde você tá implementando aquele projeto não segue scran eh não vai funcionar vai ser um grande problema e você não vai conseguir entregar tamanho e complexidade do time se eu tô trabalhando também com um time muito grande vamos

falar aqui de um time de implementação de um RP quem já fez sabe que você precisa ter n papéis diferentes Você trabalha com gerentes Você trabalha com líderes Você trabalha com eh usuários do cliente com smes com Key users então é um muito grande e muito complexo o scran não é o mais recomendável para poder fazer esse tipo de gerenciamento por quê Porque isso e inviabiliza uma Daily numa planning se você coloca um requerimento para poder ser estimado num grupo maior do que seis vai 8 10 pessoas no máximo você já vai ter tanta opinião

diferente que dificilmente vai conseguir chegar num consenso essa equipe ela não consegue ser autogerenciável essa equipe vai depender de um gerente de projetos para poder tá puxando e guiando todo mundo pro caminho certo então Eh um time muito grande é um time muito complexo Muito provavelmente vai colocar você no caminho de fazer uma decisão pelo formato da metodologia cascada e por último e não menos importante restrição de prazo e orçamento porque como eu falei no ágil tem projetos que tendem a rodar por um grande tempo se o cliente tem Budget se o cliente principalmente tá

conseguindo ver e recuperar valor da execução desse projeto é normal esse projeto se esticar por bastante tempo por quê Porque o cliente monetiza isso porque o cliente vê valor porque o cliente reduz esforço de uma área consegue às vezes reduzir um Hat count então ok o orçamento ali fica um pouco melhor de gerenciar agora se eu tenho um prazo que eu preciso fazer esse projeto dentro de um ano e o orçamento é aquilo ali e acabou então vale mais a pena no início desse projeto eu já fazer todo o levantamento de requerimento reduzir as incertezas

mitigar os riscos e colocar isso num formato não AJ colocar no formato Cascata comentários dúvidas desse pontoo Então pessoal n nesses minutos finais eu queria abrir para vocês eh comentarem principalmente para vocês eh contribuir com aquilo que vocês gostariam de ver nas próximas sessões eu trouxe aquela sugestão de pauta Inicial Mas como isso aqui é no formato mais ou menos ágil também vocês têm oportunidade agora de eh sugerir temas que vocês gostariam que talvez não esteja listado ali ou mesmo quais pontos vocês eh esperam cobrir nessas próximas sessões que a gente vai ter então a

palavra é de vocês agora pode falar Carl é na verdade é uma dúvida Bardelli é até para quem tá de fora da cardio né que pelo que eu Até onde eu sei o pessoal lá utiliza o tal do cascá né Eh enfim que na verdade não existe né que que o Fabrício até brincou Eh aí a pergunta não sei nem se vocês vão você vai saber responder por que que eles não utilizam a metodologia ágil 100% e utilizam essa metodologia híbrida que na verdade não existe né Qual que é o motivo o que o que

que eles enxergam ali de benefício ou o que que a gente enxerga né É o que eu vejo ali cara é exatamente o ponto que eu eu vejo que é o ponto fraco do ág aqui que é exatamente a questão do orçamento né eles tentam fazer com que o o ágil fique previsível quanto eu vou gastar o objetivo principal é esse assim Ah então a gente tá trabalhando ágil Ah beleza mas ó tem três caras seis meses beleza vamos ágil né aí esse eu vejo que é um ponto principal acho que tem um ponto cultural

também o pessoal tá acostumado a trabalhar com Cascata e o áo é legal exato Tem muita gente que faz isso carão que puts ágil é entre aspas novo não é mais tão novo assim mas é modinha então eu quero tá na modinha então eu vou falar que o meu projeto é ágil mas no fundo no fundo teu projeto como n Chaka falou tem escopo pré-definido tem prazo pré-definido tem orçamento pré-definido cara não é ágil Por mais que você faça uma uma Daily que você faça uma plan que você faça sprints você tem os papéis que

você chame teu PM de scom Master não é á então muito da Cargil eu acho que vem justamente disso que que o nichioka falou eh É herança é cultura eh é vontade às vezes desejo de querer fazer uma coisa nova sem ter eh essa esse alinhamento ou esse gerenciamento de mudança interna de começar ir por esse caminho por por outro lado a gente tem alguns projetos lá dentro rodando já num formato ág mais ágil puro mas que vai lá vamos pegar o exemplo do inclusive o nome do aplicativo é ágil que é um aplicativo que

que é desenvolvido para Cargil que é utilizado para fazer a a venda de insumos pro pessoal do nutrição animal vende alimentação para gabo tudo e é um projeto ágil E sem trocadilho com o nome do aplicativo mas que constantemente tem problemas por conta de Budget Então existe uma liberação inicial de um Budget e uma ideia de funcionalidades que vão ser desenvolvidas a partir desse momento ele começa a rodar no formato ágil o que que acontece depois de um X número de de entregas é identificado que eh o Budget acabou seja por alguma falha no planejamento

da da unidade de negócios ou mesmo por uma realocação de recursos eh a acontece de acabar o Budget desse projeto o projeto para Então até onde foi entregue é utilizado pelo negócio que não foi entregue dali pra frente fica dentro de um backlog do produto e que pode ou não voltar a ter continuidade então existem alguns projetos lá dentro que eles estão conseguindo mudar um pouco essa cultura e colocar já num formato mais ágil puro eh fora do Brasil isso é bem comum o projeto lá do no aplicativo chamado cardio eg nos Estados Unidos rodava

assim nesse formato 100% ágil mas daí era o que a gente chamava de brincadeira né que era um bolso sem fundo Ali era um Budget paraa área para tocar aquele projeto com aquela Squad pelo tempo que fosse necessário porque sempre surgiam requerimentos novos sempre evoluíam a complexidade dos requerimentos então é entre aspas o cenário ideal do do ágio que pro Brasil é mais difícil de gerenciar né tem que chamar esses gmos aí n fazer esse negócio a gente ensina Para eles um cascar fazer o nosso grupo agora nossa comunidade a gente tá até Carlão falando

muito disso aqui internamente porque tem os projetos internos que a gente executa né e e a ideia é justamente evitar esses eh essas armadilhas assim de de adotar pela metade ou de pegar só o que a gente acha legal que se encaixa na nossa realidade na prática cara é bem bem desafiador estrap entendi isso eh então só complementando né Bardelli eh aqui acho que a complexidade mesmo é o nível de maturidade em relação a lidar conforme conforme aliás L dá as dificuldades que o PM tem eh em avaliar novos requerimentos ou a entrada de novos

requerimentos né E isso obviamente que vai ofendendo né o o o orçamento daquele projeto eh e acordar isso né com o cliente para que você não extrapole né os prazos já pelo menos assim não que eu digo definidos porque a gente tá falando de uma metodologia ágil né mas pelo menos esperados ali pra conclusão a entrega né final daquela plataforma ou do Objetivo ali do projeto né no meu entendimento o ágil deveria estar focando na entrega final ali por exemplo numa plataforma eh e os requerimentos deveriam eh ir se ajustando eh conforme vai tendo uma

maturidade sobre o que queria ser entregue sobre o que o cliente tá esperando daquilo eh mas o ofensor aqui é que a gente tem a entrada de novos requisitos que esses são sim de fato os ofensores né eh e aí a pergunta é justamente essa né como que a gente pode como que a gente pode blindar digamos assim a a estrutura né do do projeto frente a esses requerimentos novos né excelente André eu acho que isso vai muito eh de encontro com o que eu tava falando de de Poxa eu vou pegar um pinar um

item do ágil aqui que eu acho legal esse outro eu acho legal esse aqui eu não quero eu não vou seguir eh a metodologia como um todo bibliograficamente falando dá as ferramentas e dá os métodos de você conseguir blindar um scrm uma equipe um backlog um po justamente desses tipos de ofensores da pessoa chegar no meio da Sprint e falar cara eh não faça isso Faça aquilo ou outro isso no áo assim é uma das piores ofensas que você pode ter por outro lado como a gente vai falar pro cliente e segura aí que eu

não vou fazer isso agora eu vou fazer isso na próxima Sprint eu não posso parar o que tá sendo feito dentro dessa Sprint é cultural nosso é e E quando você aind vem junto com uma metodologia que tem a chancela de ser uma metodologia flexível é natural o cara pô mas você não falou que é flexível você não falou que é uma metodologia que eu posso mudar o escopo no meio do projeto pode mas não quer dizer que você pode também mudar um planejamento de uma Sprint trocar uma ordem de um requerimento grande que tá

sendo desenvolvido por outr sem ter repercussões de prazo ou de entregas então assim é flexível é tem as ferramentas tem mas isso tudo tem que ser alinhado com uma equipe de gerenciamento de mudança junto com o cliente junto com a área de negócio para que esses limites sejam respeitados e sejam colocados dentro também daquilo que é esperado da entrega caso o contrário e a tendência disso não funcionar e da gente ter que começar a usar a nossa criatividade e começar a utilizar uma mesta com outras metodologias ou até mesmo criar um cascajo é quase certeza

que vai acontecer uma uma experiência que eu tenho é e sobre essa coisa de de que o Carl ali comentou né dos problemas que tem não V não consigo falar da Cargil mas imagino que possa acontecer parecido na Cargil é pessoal pega a parte da flexibilidade da da metodologia Isso quer dizer que você pode flexibilizar também a própria metodologia de um ponto de vista de a metodologia ela funciona se você respeitar uma parte importante do que é definido no no smb né então porlo você não pode fazer um projeto ágil se você não tem uma

figura você pode chamar ela como você quiser você não seja uma figura equivalente a um pi né porque o cara é o dono do produto ele é o cara que define se isso pode ser alterado se isso aqui pode ser postergado se isso aqui e pode ser não feito se você não tem essa figura com essa autoridade e invariavelmente o projeto não tem no invariavelmente a gente percebe que no projeto não tem a pessoa com essa autonomia ou seja ela tem que buscar lá fora já começa a ficar com cara de cascata isso né exatamente

uma mudança que tem Ah é eu tô fazendo construções pequenas Então eu vou deixar para testar isso no final cara de cascata você pode fazer isso aí você vai e cria uma Sprint para testar é uma saída metodológica para fazer isso aí deixa tudo pro final aí chega no final quando você vai testar o que que você descobre Não era isso que eu queria Então eu acho que o que acontece é que a flexibilidade acaba saindo do que é flexibilidade do do ajo né Deixa de ser a flexibilidade começa ser criatividade demais e fica jogando

por formato do Cascata Ah se eu colocar a equipe com todos os papéis que que tem definido nas cerimônias vai ter muita gente dedicada você cai no mesmo problema que o cascato cai né se você não tem dedicação se você não tem time nenhum projeto termina então acho que eu acho que no final as armadilhas são muito parecidas E aí o pessoal Às vezes tem a falsa expectativa que o ajayo por ser flexível ele vai resolver todos esses problemas com criatividade e Tem coisa que que não dá para para mudar né a ausência de Pio

é uma que eu vejo muito em projeto assim dessa natureza que tem uma figura lá que eles pegam umba ou um cara que era gerente de projeto ou líder de projeto do cliente e coloca com pior mas ele não tem autonomia nenhuma para definir nada do produto aí você fala tá bom E qual é o papel desse cara aqui se ele não tem autonomia sobre o produto se ele sempre tem que ir buscar fora essa essa informação para ver se eu postergo a entrega se eu se eu mudo de de um Sprint para outra se

eu posso mudar a carinha da solução se eu posso fazer uma entrega parcial porque isso é é um MVP acho que quando a gente começa a falar mais das terminologias vai ficar mais claro as situações que a gente que a gente passa num projeto de de viaj mas acho que no final do dia o ofensor é sempre muito mais eh a falta de time a falta de entendimento e a falta de autonomia para definir eh o o do time né da equipe que é uma equipe autogerenciável para fazer as entregas exato muito bom Fabrício mais

alguém pessoal comentar mais alguma coisa eh do contrário então encerramos por hoje eh Agradeço o tempo a disponibilidade de todos vocês e nos vemos na no próximo encontro terça-feira que vem obrigado e até mais pessoal Valeu obrigado obrig obrigada T Tchau queo bom