Métodos ágeis - Princípios, frameworks e ferramentas [Scrum e XP]

e aí pessoal beleza esse vídeo de hoje a gente vai conversar sobre métodos e metodologias ágeis vou falar sobre os valores do movimento os princípios vou entrar no em fremax vou mostrar os cromos os principais atores os principais rituais do freio york vou falar um pouquinho dia que você vim programe e vou mostrar para vocês algumas ferramentas e ações que nós realizamos dentro da brene que nós julgamos que nos auxiliam a ser ágeis caso vocês queiram ir direto para algum ponto específico na descrição vocês conseguem fazer isso já que vocês vão para descrição aproveita e

se inscrevam é acompanha bora lá vem comigo é a beleza gente um papo um pouquinho diferente vai conversar um pouquinho sobre metodologias ages e aqui eu vou falar tanto dos rituais dos nas metodologias principalmente do scream e um pouco de extreme programming mas vou trazer um tanto a visão do que de fato eu aplico hoje lá na brain e não tô falando que seja há verdades absolutas mas é a forma como eu entendo que isso funcione para a o meu negócio a gente tem existem basicamente duas visões em cima disso e nós falamos de pessoas

que defendem que as metodologias precisam ser seguidas à risca para que elas funcionem senão vai ser a justificativa dela não funcionar não ter seguido à risca já eu eu entendo que e eu preciso entender estudar as metodologias ágeis os métodos vagens e eu preciso ver como eu consigo aplicar isso no meu cenário então eu estudo escrow estudo aqui tem problema me é o estudo a metodologia do spotify e aí eu vou a partir delas ver o que que se aplica no meu cenário a gente vê aí as vezes a galera seguindo algo muito à risca

a exemplo o que andou acontecendo com a proposta lá da mitologia do spotify oi e o caso é que nem spotify na música aquela metodologia risca né você planejou uma coisa mas na hora de executar aquilo sofreu mutações para que se adequasse perfeitamente ao ambiente a que se tinha e é o que eu entendo que a gente tem que fazer nas nossas organizações é analisar estudar e ver como se aplica no nosso cenário tão é em cima disso que vai transformar o nosso bate-papo eu vou a contextualizar eles um pouquinho e depois eu vou trazendo

práticas de aplicadas neste contexto tá então eu eu trago com o título de o que eu ensino e que eu pratico porque é o ensino metodologia sagens e eu vou mostrar também como eu pratico essas coisas tá beleza espero que o papo a greve aí ó os nossos pensamentos de vocês relacionados ao tema primeira gente desenvolvimento de software tradicional ou cascata é o que que nós tínhamos nós temos um fluxo que era muito bem definido que diz assim ó beleza nós já temos tudo do cliente vamos desenhar as telas ou fazer a prototipação de telas

desenhar os layouts depois de desenhar os layouts vai lidar com cliente eu vou planejar eu vou montar os diagramas que representam essa estrutura que eu já validei com o cliente depois bom já defini aqui então vez que isso vá levar seja um projeto de 6 meses 7 meses e depois eu vou para fase de execução e vou pegar tudo isso que eu já falei com o cliente e vou executar isso durante cinco seis meses eu vou liberar para fazer teste essa fase de teste bom efetuar correções e depois vai implantar no cliente isso talvez oito

meses depois de ter validado com ele e provavelmente o que vai acontecer neste cenário é algo tipo isso porque eu vou mostrar para ela tá aqui olha só que foi que tu pediu cara é e é uma utopia imaginar que o cliente vai conseguir expressar exatamente o que ele quer e nós também temos o desafio de interpretar o que ele o que ele tá nos passando e transformar isso em um software não é um desafio que é muito difícil de há de se ter êxito e ainda mais lançamento do logia né a tendência é que

a gente entregue e tenha dedicado sei lá oito meses de projeto e entregar um negócio desse e o cliente secada e não é isso que eu queria e aí eu vou ter que dizer cara mas foi isso que tu disse que tu queria até aqui ó assinou contrato aqui tá aqui e aí a gente vai ter um desconforto junto ao cliente e aí é o cliente vai ter que desembolsar para que se tenha um desenvolvimento da forma que ele queria então correções e mais correções e mais ajustes isso vai custar muito caro cliente eo cliente

vai ficar obviamente insatisfeito e nós vamos investir muito mais tempo que deveríamos no projeto no fim vai ser ruim para todo mundo que a gente satisfeita ele ele vai evitar me contratar novamente ele não vai me indicar a para outros serviços então todo mundo tem a perder com isso né se eu conseguisse identificar isso no primeiro mês que tá andando errado eu vou aos poucos fazendo correções na trajetória do projeto para que daqui a pouco beleza não vou terminar em noite vou terminar em nove porque eu não tinha o entendimento o ideal da expectativa do

cliente mas eu fui ajustando e acabou aumentando um pouco prazo encarecer um pouco projeto mas o cliente está participando ativamente disso e dessa forma ele vai entender o porquê que tá mudando aí essa a expectativa ea proposta da metodologia ágil todos os métodos vagens aqui mais uma figurinha só pra gente visualizar fala de novo que eu gosto bastante que diz assim ah como o cliente explicou é um cliente explicou de uma forma o líder entendeu de uma forma diferente e o analista projetou ainda diferente o programador ainda mudou isso mais um tanto e o consultor

de negócios descreveu de uma forma muito mais perfumada a documentação do projeto enfim ir lá no final o tio cliente realmente queria ele queria uma coisa bem mais simples do que ele explicou bem mais simples do que o consultor de negócios explicou - macabra do que o líder entendeu enfim então uma série de ruídos foi sendo inserida no projeto até se chegar em algo que não era o que o cliente queria bom então essas fases elas precisam cedo em cortadas reduzidas ou pelo menos tendo feedbacks mais continuamos para ajuste os mais rápidos eu entrando rapidinho

sem um túnel do tempo lá em 1999 alguns acontecimentos históricos a foi onde surgiu o euro foi onde nós tivemos o nosso bang do millenium nós tivemos o fluminense conseguindo executar uma mágica mudança de série c para série a bill gates foi pela primeira vez o homem mais rico do mundo o metallica veio pela primeira vez que o brasil o fhc era o nosso presidente o juventude conseguiu seu feito mais inédito e foi campeão da copa do brasil e esses foram alguns acontecimentos ao nosso redor ainda nesta época muita coisa acontecia relacionada a conferências e

conferências de orientação a objetos e design pata nesse melhorias de código e estratégias de refatoração a cirurgia o livro de clean code do robert martin shellback muito envolvido já na área de engenharia de software e esses caras todos participavam em alguns momentos de conferências juntos eles começaram a né tem que dar para dois né que eles estavam falando um partes de coisas muito similares né estavam propondo coisas que se encaixavam em alguns momentos e chega o momento que eles disseram o cara para aí vamos nos reunir aqui e vamos escrever um manifesto que vai especificar

o que que é ser ágil é o manifesto ágil eles pegaram tudo que tava rolando na época que você me programem kanban scrum clear crystal clear te de kanban e em comum essas coisas aqui vamos fazer então o manifesto ágil escrevendo lá manifesto ágil com quatro valores e 12 princípios que eu vou passar rapidinho agora com vocês aqui até para não ficar muito chato para gente ir na nas questões mais práticas da sequência é o que propõe de valores na indivíduos e interações mais do que processos e ferramentas software em funcionamento mais do que documentação

abrangente colaboração com o cliente mais do que negociação de contratos responder a mudanças mais do que seguir um plano os corpo disso daqui é basicamente vamos ver o que quem está propondo né porque está propondo essas coisas que o quê que isso resolve lá no modelo tradicional e a partir disso eles definiram esses valores né que é vamos tentar enxergar mais o cliente ou tentar ser mais ágeis e envolver o cliente dentro dos processos para que nós temos feedbacks mais rápidos antes defenderam esses valores aqui e depois esses valores eles definiram 12 princípios oi e

aí passando rapidamente sobre os princípios que eu coloquei aqui como mandamentos a gente ele tem assim é nossa maior prioridade é satisfazer o cliente aceitar mudanças de requisitos entregar software funcionando com frequência se vocês olharem essas coisas elas estão diretamente relacionadas com os valores né ou então empregado sofre com frequência tô quebrando aquele ciclo lá de entregar o software só no final do processo se entregar isso de forma mais continua aí vocês vão ver na sequência aqui os chrome o ex trin programme eles propõe práticas para atender a esses mandamentos aqui a esses princípios e

valores vocês vão conseguir associar rapidamente o que a gente tá vendo lá nas práticas sugeridas com o que a gente tem aqui especificado então a prioridade é satisfazer o cliente com entrega adianta bom então aqui que a identificando os atrasos se têm tradicionalmente nas entregas de só cara que precisa ter organização de entrega contínua adiantada e centro entregar valor que o cara vai poder já converter essa entrega em diferenciais competitivos para ele depois pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e aquele tá trazendo a proposta ele não faz sentido nenhum trazer o

cara aqui uma vez no início do projeto e depois nunca mais falar com ele só no fim a gente precisa ter pessoas do negócio constantemente participando do desenvolvimento para que os ajustes sejam identificados em tempo sem tanta perda de tempo quanto tínhamos anteriormente não precisa se der pessoas indivíduos motivados e o que sejam de confiança para realizar esse trabalho e aí vocês vão ver que os métodos aqui eu vou mostrar da sequência eles contam muito com essa aí com esse princípio aqui método mais eficiente e eficaz de transmitir informações para e por dentro de um

time de desenvolvimento é através de uma conversa cara a cara e vocês vão ver que tem lá a proposta da daily as reuniões cara cara reuniões com cliente então tudo isso são evidências que são criadas aqui continuar atenção a excelência técnica e bom design simplicidade times auto-organizáveis a necessidade de reflexão constante ou periódica de como ficar mais efetivo tudo isso eles colocaram lá ficar vocês vão ver que os rituais que nós temos nas metodologias eles eles vão atendendo a esses pontos aqui é bom e aí vocês vão podem ter em vez de dizer assim o

cara eu uso o escravo é usa que você programe não eu posso a partir disso pensa assim como é que eu atendo a esse mandamento haja o dentro da minha organização dentro do meu time desenvolvimento deixa eu ver vamos fazer uma reflexão aqui como que a gente atingir a busca por excelência técnica que a gente fala fazer isso esses então a gente cumprir com esse mandamento aqui e esse esse é um bom momento acho que já fica claro que na metodologia nas metodologias ágeis o nosso foco passa a ser no cliente então o centro das

atenções é o cliente oi e aí eu vou iniciar falando dois com ela e aí eu vou iniciar falando do escravo que é o framework mais popular do mundo de ameaça dosagens e é preciso passar rapidamente um dicionário é porque a gente vai acabar falando sobre isso em alguns momentos e dependendo de como o conteúdo foi recebido por trazer mais conteúdo a respeito do tema tá mas hoje nesse bate-papo a gente só entendeu rapidinho que quer 10 histórias ou estórias de usuário quem é uma sprint o que que é um sprint backlog o escravo a

gente já tá falando ajayô que eu não gosto movimento cara só quer um funcionário gigante né que nós temos para envolvido com este tema mas basicamente você já viram requisitos e talvez algum momento e daí ela de requisitos funcionais para usar aqui a proposta é que a gente trabalha com vendas de requisitos trabalhe com histórias de usuário e aí nós temos uma estratégia de a como determinado tipo de usuário eu quero fazer determinada coisa e é eu vou sempre responder a essas três perguntas essa essa terceira aqui ela é considerada a normalmente com opcional mas

pelo menos como determinado tipo de usuário eu quero o que que eu quero fazer isso aqui é um modelinho tradicional de uma história de usuário e e a sprint ela basicamente é a minha proposta de entrega pequena entrega né eu tenho um sprint backlog é e eu tenho um prova outback lógico que vocês estão vendo aqui embaixo um prato de backlog é tudo que eu tenho para fazer nesse projeto que já foi definido ou pelo menos rapidamente rabiscado tá dentro do meu próprio técnico quando eu pego e seleciono coisas para realizar eu deixei tá bom

a sprint do meu time é de duas semanas tá duas semanas é um marco em que eu quero entregar o valor para o meu cliente e aí eu vou fechar e isso com ele e vou dizer bom daqui a duas semanas fecha essa entrega nós vamos te apresentar tu vai validar e assim lab lavar bom então junto com o cliente com pessoas envolvidas gente seleciona e monta o sprint backlog só que vai entrar para essa entrega certo e aí então a sprint é esse tempo que eu tenho aí de duas semanas para desenvolver algo de

valor para o meu cliente a ideia é que toda sprint entregue valor pro nosso cliente e já que a gente vai conversando sobre esse mais alguns pontos esse aqui agora na na sequência quando a gente fala de métodos ágeis aí eu vou passar um pouquinho em cima dos atores quem são as pessoas né e aí também entra dentro desse dicionário nós temos o piu que é o próximo tchau né e a responsabilidade dele é representar no projeto o cliente quem sabe o que que é de maior valor para o cliente é o pro bate a

onda esse cara aqui ele é responsável por alimentar o backlog do produto só omx logger do produto e ele vai definir e vai manter-se backlog do produto priorizado para que o seu time saiba o que que é urgência para o nosso cliente certo esse cara aqui ele é o responsável por garantir o eric é o retorno do investimento né então se o cliente vai investir x ele é o responsável por transformar esse x na maior entrega de valor possível que diz que esse cara é sempre a voz no cliente dentro do projeto e aí você

já vem aqui ó que a gente falava lá de pessoas do negócio e time de desenvolvimento por ser um trabalhar junto a gente já vê no papel dessa pessoa aqui isso acontecendo na esse cara está envolvido com um projeto constantemente e ele representa a voz do cliente e esse é o dono do produto ou o product owner e daí nós temos o scrum master o scrummaster ele é o cara que basicamente mancha da metodologia scrum master é o cara aqui conhece o scream de ponta a ponta dentro desse desse contexto e vai ser o responsável

por ajudar o time a cumprido com todos os rituais com todos a e provendo a executando o papel de facilitador dos cromos o pessoal tiver alguma dúvida esse é esse cara que vai que vai se reportar o scrummaster e o p ou eles têm papéis muito importante neoop ou como que apresentando o cliente o scrummaster ele acaba representando em certos momentos o time ele eles às vezes se confunde um tanto com o papel do gerente de projeto mas o gerente de projetos ele não é o melhor o scrum master não exerce a a sofia sobre

nenhum membro do time ele não delega ele ele é mais um apoio dentro da equipe tá diferente do gerente de projetos que têm responsabilidades representa o time diante do cliente o scrummaster ele não manda em ninguém ele não define o que o que quem vai fazer tá certo e aí nós temos o nosso time que são lance os desenvolvedores a galera que vai meter a mão na massa que vai trabalhar que vai transformar a visão do cliente em um produto e aí a gente fala aqui na expectativa de um time auto-organizado que a gente também

falar cita isso dentro de um dos princípios que eu citei para vocês anteriormente oi e aí gente e o que que tem que ser alto organizado porque não tem chefe não tem gerente de projetos mandando então a gente precisa sim de time os responsáveis que consigam definir enxergar prioridades precisam se alto gerenciar para saber para onde é que tem que ir o que que tem que fazer qual é a melhor estratégia para que a gente consiga cumprir com as entregas como é que um pode ajudar o outro o time representa o todo nós vamos falamos

nunca deu x ou y ou scrummaster não ou sucesso é do time como um todo ou fracasso é do time como um todo é isso é o que é defendido aqui dentro do escroto é a visão edu todo é o time scrum não é o fulano em ciclano a situação foram os pegar o fluxo do do escravo ele é basicamente este daqui olha só nós temos o product backlog que eu citei para vocês agora há pouco que era gerenciado pelo dono do produto o caldo tchau né responsabilidade dele manter esse cara priorizado e sempre com

um volume suficiente de histórias para que o time eu possa desenvolver então esse backlog é alimentado com os pares de usuário tá certo daí aqui eu tenho um emaranhado de histórias de usuários onde numa reunião de planejamento que é o sprint planning aqui é o rei o ano todo mundo para do tião não era escura mastertime desenvolvimento talvez você tem que holder eu não todo mundo aqui nessa reunião o hino nós vamos definir fazer uma seleção do que que nós conseguimos executar em uma sprint e a gente vai ter definido aqui qual é a duração

da sprint ó que a gente tem a recomendação lá de duas a quatro semanas cara eu pessoalmente eu faço os prints sempre de duas semanas dentro do meu time lá então nós chegamos nesse na conclusão de que duas semanas é o tamanho ideal e é o número que é mais praticado dentro do mercado tá e aí eu vou definir aqui o time vai definir e aqui também muito importante e fala o time definir não é o gerente de projeto se vai dizer isso aqui a gente o meu time consegue entregar em duas semanas e aqui

todo mundo vai participar desse planejamento e com isso todo mundo também vai ter a responsabilidade de fazer com que ele dê certo né porque ele não vou poder tirar o corpo fora de ar também cara se você acha que dava para fazendo em duas semanas mas o óbvio que não dá esse aqui é o serviço para dois meses aqui todo mundo participou do planejamento e disse que isso dava para ser feito em duas semanas daí tem uma série de rituais que nós podemos utilizar aqui para fazer esse planejamento um deles é um player em pouca

e ele poderia ser um tema de um outro papo mas aí a ideia do plano em pó querer que todo mundo faça as suas estimativas individuais e depois se faça uma compilação eu tenho outro slide para falar um pouquinho sobre isso tá mas é uma das formas de fazermos o sprint backlog aqui é desse sprint backlog depois que todo mundo definir o que que dá para botar dentro da sprint e entra o ciclo de execução e aí esse ciclo de execução aqui de duas semanas e dentro dessas duas semanas todos os dias nós temos a

dani do escravo ou o stand up me tem que também é chamado que aí a proposta é esse segundo nome ele já nos remete a a proposta dela stand up missing a ideia é uma reunião diária em pé a proposta que ela seja em pé para que ela seja rápida nela cristiano pessoal 60 já começa a desvirtuar o objetivo então a proposta é uma reunião diária um pé e que ela não passa de 15 minutos e aí todo mundo responde 3 questões dentro dessa reunião diária o tio fiz ontem o que eu vou fazer hoje

e qual é se eu tenho algum impedimento para realizar a tarefa que eu topo o meu dia então tem um planejamento no reflexão diária band val o que que eu consigo fazer hoje e achamos ela tem algum impedimento e aí no início da manhã a gente faz essa reunião assim a proposta porque se tem impedimento alguém já pode me ajudar alinhar a remoção deste impedimento é papel do scrum master apoiar a nessa remoção bom identifiquei aqui pulando tem um empreendimento eu vou apoiar ele como resolver este impedimento no desenvolvimento do do dia dele para que

ele no próximo dia na bn dele no que eu fiz ontem ele vai dizer que ele conseguiu cumprir com o que ele prometeu no dia anterior essa é a ideia aqui nossa vender acontece todos os dias tá nesse tamanho é 15 minutinhos é a nossa dele eu não falei sobre tempo aqui do sprint backlog na e pode ser até mas aqui a gente fica normalmente duas horas duas horas aproximadamente duas horas por por semana da nossa da nossa sprint aqui então se a minha sprint tem quatro semanas um dia de de sprint backlog de sprint

planning já é mais do que suficiente a beleza dani nós temos quando encerra-se esse ciclo nós temos o nosso sprint review e no sprint review aí eu tenho normalmente uma hora aqui para casa da semana a gente normalmente não passa de um turno ou duas horas nessas nossas experiências pequenininha o que é a hora em que nós trazemos o cliente para dentro do e para dentro da empresa ou vamos o cliente e fazemos uma apresentação a validação a investir validar depois de oito meses eu tô validando o trabalho de duas semanas e ele é de

cara isso aqui beleza tá validado então beleza vamos selecionar agora o que que a gente vai fazer na sequência a gente volta a fazer um creme da próxima sprint e nesse meio aqui onde tem assim ó eu faço o review e aí eu tenho todo mundo ativo participando piou apresentação do clientes né steakholders você quiser e eu tenho um sprint retrospective aqui é o momento em que o meu time para e ele vai fazer algumas análises e eu gosto bastante de trabalhar com um quadro que é o start-stop e continue e aí a gente faz

uma análise em cima da sprint e ver assim bom start o que que nós não fizemos até aqui que a gente precisa iniciar a fazer com urgência para melhorar o desempenho do nosso time e aí a quem a gente fala daqueles princípios de excelência de melhoria contínua e identificamos o que que tem que melhorar vai precisar fazer isso tem precisa se comunicar melhor para isso para lá vai lá o que que nós fizemos que foi muito bom deu muito certo e a gente precisa destacar para quem não seja esquecido eu vou botar na minha coluna

de continua então tem start eu tenho continuar e eu tenho agora o stop claro que a gente fez que nós não podemos fazer mais foi muito errado se deu muito deu muito problema e não pode cair no esquecimento que não podemos mais fazer coluna de stop e aí você coloca isso lá no quadro para ficar à mostra e compilar e isso depois até para si se realizar planos de ação em cima disso certo isso é papel da reunião de retrospectiva é a hora de refletir como ser mais efetivo como time como é que nós possamos

melhorar o nosso tipo e aqui eu deixei documentado né pra galera olhar e vamos repassar aqui brevemente a nossa reunião de planejamento já conversamos duração de duas horas por semana perfeito aqui acontece o plano em poker cara eu vou explicar rapidinho eu não vou perder muito tempo com isso mas acho que vale a pena qual é a moral do playing poker para vocês entender dando um pouco era a proposta é fazer um jogo de carta de planejamento de tempo de estimativa oi e aí o scrummaster ou algum membro do time lê a história de usuário

e os detalhamentos critérios de aceitação não tenho documento bem rico com relação a isso todo time um seu baralho e aí é um baralho que normalmente segue uma sequência de números normalmente nos números de fibonacci e tudo isso existe uma lógica né bom e com esse baralho e após ouvir a história cada um vai botar sua carta sobre a mesa ali e aí tem aplicativos que a gente pode usar para jogar no celular e aí não precisa ter um baralho é uma boa alternativa para não se ter o baralho discreta baixa aí screamtime acho que

é o nome de um dos apps se consegue fazer o jogo através de aplicativo é mas a ideia é escolhe uma carta com o custo o custo para se resolver essa história e aí a gente não fala normalmente em tempo oi e a isso é um sou um pouco estranho a gente fala disso scream points né e a ideia dos escuro points é a seguinte é a ideia aqui é não trabalharmos com tempo porque historicamente a gente não sabe estimar tanto a gente a muito a última tempo e então a ideia que aqui a gente

trabalha com as expansões e a ideia é bom vamos pegar uma história de modelo e aí vamos dizer que bom avaliando rapidamente vamos dar um número para ela é cinco beleza uma história lá de cadastro e gerenciamento de usuário quem sabe e aí nós definimos o peso dela como sendo 5 que que vai acontecer na próxima eu vou virar história e aí vai ser uma história lá sei lá gerenciamento de cliente e eu vou fazer sempre uma comparação pensando assim bom gerenciamento dia de usuário se definiu como cinco por quê porque sim é mas agora

as outras elas serão todas vistas em comparativo com essa gerenciamento de cliente bom se é mais fácil ou mais difícil cara é mais fácil do que gerenciamento de usuário porque eu não vou ter que manipular autenticação social não vou ter que fazer isso não tem que fazer aquilo então é mais fácil o como mais fácil é é bem mais fácil qual é o número abaixo dos cinco que eu tenho na sequência de fibonacci três e dois será que é três você naquele dois pô eu vou vou jogar no texto então assim a gente vai definir

um jogo e todo mundo vai pensar e todos vão jogar eu disse que as suas internet porque simonetti no sugere números do tipo 1 1 1 2 3 5 8 13 21 ou seja números com espaçamento caso aveu e se eu fosse jogar com cartas com números 1 2 3 4 5 6 7 8 9 o que que aconteceu na minha cabeça vamos pegar o modelo ali do cinco que eu disse tá eu tenho uma atividade que custa 5 e aí eu vou pensar numa próxima vou ficar com dúvida será que é sete será que

eu jogo 8 será que jogou nove porque são números muito próximo e agora se eu pensar entre entre 8 e 13 e na 8.321 a minha cabeça vai encaixar muito melhor só com essas três opções do que tendo dez números em sequência porque a ideia é que todo mundo joga as cartas e aí a proposta é que ninguém saiba o que o outro pensou exatamente para evitar a influência porque é natural se eu tenho um cara que a referência dentro do meu time ele vai influenciar todo mundo com relação a tempo e se eu não

souber o que que aquele cara pensou eu vou fazer a minha estimativa e essa é a proposta porque nem sempre foi esse cara que vai executar e nem sempre a visão dele e acerta então preciso de todas as visões e por isso que o jogo ele trabalha com essas questões mais ocultas e que conseguem pegar a estimativa de cada um e com esses números com espaçamento legal a ideia é que a gente conseguiu chegar e num consenso de valor só que todo mundo faz opção número 8 mas sim acontecer de alguém colocar oito e outro

colocar 21 ou três colocar em 8 e um colocar 21 e esse cara que colocou 21 ele vai receber o espaço para falar e ele vai argumentar o porquê que ele julgou esse 21 e se alguém colocou um abaixo então vamos 13 diversos 8 e 1 23 um 21 quem colocou três vai justificar o porquê e quem colocou o 21 vai justificar o porquê os extremos sempre vão receber espaço para falar e tentar justificar os seus porquês porque assim talvez o cara que ele disse três ele já resolveu um problema desse tipo que está sendo

lido na história e ele sabe uma manha umas e ti que vai resolver os possíveis impedimentos isso e vai trazer facilitadores e aí ele vai convencer os outros de que realmente isso é 13 ou o cara que botou 21 ele já viu algo parecido e ele entende que cara tem várias tretas envolvidas com bom e que você é mais complexo do que parece que ele pode convencer os outros depois de ouviu se as partes todo mundo joga de novo é qual é as cartas e pensam o segundinho sally e joga de novo a ideia é

que com duas no máximo três rodadas se cheguem a um consenso se não o scrummaster vai definir a que o número da maioria vai ficar ou talvez uma média aí cada time conduz como acha que que é mais apropriado para resolver esses problemas mas a ideia é que se chegue em um consenso de valor tá de custo esse esses números esses clan points eles definem uma velocidade do time e aí eu vou chegar sim é bom meu time consegue realizar três histórias né a gente selecionou três histórias para sprint e essas três histórias tomando esses

números a gente chega num número qualquer será 23 esse 23 ele define a velocidade do meu tio ia fazer o meu time desse projeto ele tem velocidade 23 e depois de duas interações duas experiências eu posso julgar que após as reflexões nós já somos mais eficientes a gente consegue trabalhar com mais pontos e aí vou selecionado o backlog bom selecionei duas tarefas é só que deu 16 mais uma deu 20 23 e a gente é mais efetivo agora então podemos aumentar a velocidade do time a gente pega mais uma tarefa de cinco pontos ela vão

chegar lá no 30 pontos bom vamos experimentar seu time agora consegue resolver histórias que somam 30 pontos de história e aí esse número é o que vai definir o que nós chamamos de velocidade do time que a somatória de pontos de história que o time consegue executar dentro de uma sprint certo isso vai ajudar até na seleção né tem um barco as quantas tarefas eu pego quais cara vamos tomar ali ó de acordo com os escolher point aqui a gente já tá em 50 pontos não dá para fazer tudo isso isso oi gente já viu

o que é em duas semanas nós conseguimos fechar x pontos aí você já vão identificar que a sprint tá muito pesada certo e nós temos aqui dentro ainda não não vou falar sobre esse conceito agora vou deixar para outro momento o opa ah eu deixei essa imagem aqui vocês talvez estejam se perguntando até agora do porque é só para reforçar aqui a reunião diária ela tem que acontecer com a mesma frequência da tiazinha lá lá nossa avó que nos manda aquela mensagenzinha de bom dia ou de boa noite todos os dias então tem que acontecer

com frequência tem que existir a regra a frequência diária da reunião a resposta das três perguntas que eu já tinha acertado para vocês respeitar o tempo então são os rituais que nós temos dentro dos planos da retrospectiva eu já tinha conversado com você sobre a validação das histórias a duração de uma hora por semana ela que a gente específica o perdão revisão reunião da rede de revisão a de retrospectiva ela segue o mesmo padrão só que ela faz aquela variação start-stop continue que eu já comentei com vocês eu vou trazer alguns pontos do extreme programming

quem é o jogo complementam o que a gente faz com os chrome eu não tô entrando em alguns conceitos dos plantar a ideia é que a gente fazer uma visão rápida e prática sobre questões que a gente consegue aplicar o wi-fi sem programa em ele também é uma metodologia ágil e ela propõe algo mais aplicado no mundo de desenvolvimento de software então não vou entrar nas práticas e valores em todos é só destaquei alguns aqui que com certeza vão fazer sentido nas práticas de vocês então ele tem assim ó programação em par e aí ele

fala a senhora a rua das práticas do que tem programa en el programa que é a programação em dupla e a defesa que é que isso torna o time mais entrega a código de mais qualidade vão pensar vocês codificando com alguém do lado de vocês e vocês vão ter distrações entrar em facebook abrir whatsapp web na máquina de vocês ou parar de cuidar para responder alguém no messenger do facebook provavelmente não se você tem um pouquinho de bom senso vocês não vão fazer isso porque o cara tá ali do lado e ele tá acordando junto

contigo ele tá pensando junto contigo aí daqui é uma máquina e duas pessoas programando tá então isso aí já nos aumenta a produtividade consideravelmente né porque nos vai nos eliminar distrações eu vou pensar duas vezes antes de fazer um código é de má qualidade porque focada junto comigo aqui além do que ele vai me ajudar a pensar em um código de melhor qualidade eu vou ter um pensamento diferente aqui um pouco fora da caixa que com certeza vai me eliminar alguns impedimentos que eu posso ter então são algumas práticas aqui que com certeza agrega um

quando a gente fala de perto programe o que que eu recomendo tá não é que vocês façam perto problema em todos os dias mas é uma boa prática daqui a pouco cara a ou uma vez por semana o time trabalho em pé ou definir tarefas dentro do backlog que sejam mais complexas e que vocês poderiam quando alguém for pegar ela resolver ela infarto é uma prática legal hoje a gente tem considerando vs code cara agente tem um uma extenção do vert cold que a live chegando que você consegue em compartilhar o mesmo código a trabalharem

no mesmo código através de duas três quatro máquinas diferentes então facilita mais ainda uma prática de pedra programa e até em questões em que vocês não estejam no mesmo espaço físico né temos bastante recurso para nos ajudar nesse contexto e é legal que opera programa em você tem compartilhamento de práticas né de métodos que vocês vêm por aí é só aquilo ali que eu fulano fez ou não tava ligado nessa prática aí eu não tô ligando e se apague não fale cação aprender vamo trocar e com certeza um vai aprender com outro isso vai ser

ótimo para vocês certo que mais desenvolvimento orientado a testes ou nosso tdd e aqui a proposta vamos rodar o teste primeiro porque você vai nos dar qualidade nós vamos desenvolver funcionalidades apenas que realmente são necessárias depois de desenvolver o teste não vou entrar em detalhes sobre isso mas com certeza uma prática muito legal que nos traz bastante qualidade de entrega o rectory proposta de bom faça um código que funciona depois o relatório para deixar ele é utilizado e da melhor maneira possível outra prática de dentro desse no programa o código coletivo que na verdade ele

já tá sendo praticado principalmente no pé do programa e ali que é não vamos deixar só uma pessoa saber de tudo né isso é um problema dentro das organizações vamos fazer trocas hoje tu tá no módulo amanhã no a gente vai arrevesar e eu vou trabalhar nesse modo ou tu vai trabalhar no mesmo eu vou trabalhar na frente ela mas não deck isso no início com certeza vai ser custoso mas vamos pensar nas habilidades que esse time vai desenvolver em médio prazo né com certeza se vai ter um time muito mais qualificado e com conhecimento

do todo e aí e depois ali a integração contínua e diária baseada nos testes aí está falando de iniciar decidi que é desenvolver código que funciona passou interessa tem que ser integrado tem que estar lá no ambiente de homologação para teste coisas desse tipo é só algumas práticas que tem aqui dentro que são bem interessante recomendo bastante a leitura aí do que se programe para você assim entender trazendo um pouquinho mais e para a minha prática e ela vou trazer as ferramentas que a gente utiliza hoje na brain in em relação plena em poucas retirado

um spoiler vocês têm aí podem comprar um baralho dá para jogar com baralho tradicional também não é um não é um problema é mas vocês podem baixar um up tem os quatro times super para você o que cara vocês definir uma carta ela fica viradinha ali vocês lá no celular na mesa você se tocam e ela vira a carta então vai vai estimular a mesma a mesma experiência para vocês da métrica eu já citei para vocês né da gente é utilizado como como métrica oxe bonatti e acho que vale compartilhar uma experiência aqui tá nós

lá na brenda e nós sempre trabalhamos assim ou melhor trabalhar vamos assim no início e ir o que aconteceu é que como a gente trabalha bastante com outros assim os nossos clientes eles que são empresas de desenvolvimento de software eles não solicitavam a estimativa de tempo né e aí ficar a gente só trabalha com ponto de história né que não tem prática ainda estimar o tempo a gente não pensa em tempo a gente pensa em valor só que o cliente muitas vezes ele está pensando no tempo de entrega né e aí a gente não era

muito assertivo nas estimativas que que aconteceu de acabou tendo que é olhar para o tempo também continua trabalhando com os chrome points mas também estimamos tempo de tarefas e medimos resultados e assertividade desses tempos para que a gente consiga ter estimativas mais assertivas para esses clientes que trabalham com o orçamento baseado em tempo né atender eles e precisamos ser assertivos para não prejudicá-los e nem nos o carlos já de projeto gente quando eu tenho muita ferramenta bitlab dá para gerenciar o projeto próprio beach rubi o bitbucket também aí tem outras ferramentas como o mandem tenho

gira que a ferramenta aqui na verdade a gente tá praticamente está indo fora mas é a ferramenta que nós utilizamos até ontem praticamente que é bastante poderosa é bastante consolidada no mercado e eu gosto bastante do bitlab mas para eu ter todos os recursos eu precisaria ter ou os repositórios públicos ou contratar o plano chama de premium lá mas não deve ser seu nome só que ele fica muito caro o gira ele tem um valor acessível para times de até 10 integrantes e com esse valor que fica em torno de 60 reais hoje ele cumpre

com as nossas expectativas só ele ele é um e ele não é muito ágil em termos de não tenho uma experiência tão legal para o usuário e nós acabamos conhecendo o clipe que é uma outra ferramenta e se consegue fazer muita coisa na versão gratuita dele então a gente tem esperimentado hoje nos novos projetos a gente tá usando pick-up em vez do gira mas o gira é uma ferramenta bastante completa e com certeza comprei principalmente para time os menores do que 10 se aumentar de ideias cara valor dele e cresce exponencialmente um exemplo gente de

organização de histórias aqui tá tem várias formas de organizar isso eu trouxe uma para mostrar para vocês o o primeiro eu ter uma coluna de tudo isso aqui considerando o meu sprint o meu pexlog da sprint tá então tenho tarefas a fazer isso dentro da meu planejamento lá de duas semanas a cada um vai selecionar cards do tudo pra em andamento dentro do time e vai assinar para se certo oi e aí eu tenho histórias eu tenho bugs tenho coisas desse tipo que estão vinculadas dentro dessas tarefas a gente pode ter subir tarefas né que

eu tenho as histórias vinculado a um épico que eu não expliquei para você o moço basicamente um épico é um uma história gigante que não consegue ser executada dentro de uma sprint de duas semanas aí isso a gente chama de um épico tá aqui são os os identificadores de tipo da história bug será que tem tarefas também mas não tem nenhuma aqui não tem aqui ó uma tarefa esse é uma tarefa certo quando a história concluída vai para a review o cliente é ou até ser válida oi e aí sim o item passa para concluído

se eu abrir uma dessas tarefas aqui a gente tem algo mais ou menos assim na história perdão naquele padrão que eu disse para você usar como colaborador quero fazer tal coisa os critérios de aceitação são esses as telas a serem desenvolvidas são essas já tem isso aqui é um modelinho de como estava organizada essas histórias eu ainda tenho um controle de tempo aqui ó e onde os desenvolvedores vão lançando a todos os dias tempo trabalhado nessa história e aí ele vai sendo contabilizado aqui essa camisa aqui ó você quer gira tá que eu não disse

para vocês que o relatório aqui ó eu quem foi que escreveu a história e a linha 1 e se vocês olharem no tudo da história e eu tenho ainda aqui ó scrollando eu tenho um check list onde nós levantamos lá no sprint planning onde nós detalhamos a história no sprint player nós pegamos essa história que tinha aqui que ela dashboard de pedidos e a gente detalhou e que nós temos para fazer de design vai tem que avisar layout de black and o que que tem que fazer tem que pagina tem que ser outra serviço e

fazer isso quanto tempo se der para cada um no plane a gente vai documentando tudo isso para chegar no tempo estimado de realização dessa história como um todo é assim e aí a partir daqui os deves vão interagindo com é com esse cartão são josé do bonfim fecha aqui documentá-la qual foi o comitê que fechou não tem coisas desse tipo não vou entrar em muitos detalhes e não vai perder muito tempo dentro do gira e dentro de boa parte das ferramentas de gerenciamento de projetos ágeis a gente tem urbandawn chart ele vai pegar o número

de tarefas ou o número de componentes que eu tenho ele vai montar esse gráfico para mim observe aqui ó ele já sei lá tô iniciou o trabalho com 25 itens mais de 25 né 30 itens aqui ó contagem de itens e aí ele monta uma linha aqui ó de projeção para que lá no que eu estimei de término dessa sprint que era em 20 dias aqui e a aonde eu tenho que me manter para terminar um dia e aí ele mostra aqui ó como foi a evolução do time e não foi o bichão lá ó

o time veio executou alguns itens o número de itens do backlog da sprint aumentou que não é legal mudar mas acontece depois realizou concluiu alguns itens entrou na expectativa depois está guinor e andou o tempo inteiro atrás aqui já já estava sendo previsto o que a sprint e atrasar é a ideia é que quando se identifique isso o time tome ações defina ações para que o futuro diz aqui mude que seja lá vamos colocar mais um deve aqui para tentar emparelhar como expectativa vamos nos organizar para ser mais produtivos aqui nesse exemplo provavelmente isso não

aconteceu e aí aconteceu aqui quando o sprint acabou ela não foi concluída e aí só que é muito ruim para o planejamento para expectativa que a gente tem dentro das metodologias ágeis né será que mas é uma uma ferramenta bem interessante para fazermos o acompanhamento é baseado naqueles tempos ali a gente consegue controlar tempo de cada deve aqui é um plugin que a gente usa no vitchlab oi e aí eu consigo definir assim é bom fulano aqui ó trabalhou neste projeto tantas horas tá o dia o outro fulando trabalhou tantas horas tá o dia o

outro tantas horas tá o dia nem eu consigo definir o número de horas do projeto né isso é extremamente importante para saber quanto é que está investindo nisso né daqui a pouco ele tá pagando para trabalhar o que é bastante comum de acontecer em projetos mal estimados né então muito bom muito importante estão ferramentas aqui de dentro do próprio gira lá na barra a gente usa também o sociais e o cedido do próprio 20 leve né no seus tem o recurso integrado e a bastante importante para fazer a integração contínua e a entrega contínua e

aí ele nos dá históricos que fica todo o acompanhamento cara mandou para master ele já eles farão o gatilho para cantar fazer aí a entrega a continuar já no servidor e manter tudo em produção pobre o que é isso passa na suíte de teste antes só vai para a produção se for aprovado em todos os testes você é muito legal nós passamos rapidinho sobre o nosso workflow né nós lá na brene nós tínhamos um workflow próprio quando iniciamos que identificarmos a não necessidade de ter uma branch the release é mas também vemos que o vitor

vai me falou não era suficiente para nós que era muito simples então criamos um próprio tudo que o reino do tempo nós vimos que cara realmente é gripe low as precisamos dessa branch the release para nós termos mais uma segurança para homologação é um release cê vai fazer homologação a nossa de deve ela nem sempre está funcionando né ela pode estar quebrado porque eles e a quando eu tenho já partes entrega as prontas que podem ser testadas e aí o nosso testa pode trabalhar dentro da frente the release para validar beleza e a master é

óbvio que é produção foi para marcela é quem vai para produção para o cliente e vai passando rapidamente sobre ferramentas de comunicação os leque uma ferramenta bem massa curta bastante ela tem um grande problema que é limite de de palavras são só palavras ou se a linha só acho que eles e aí ela não não guardar o histórico então sei lá não lembro quais são os números não sejam 10 mil linhas o que ultrapassar 10 mil linhas começa a descartar as mais antigas e aí tu perde o histórico conheço nós passamos a utilizar dentro da

brain o discord' escolhe hoje nos atende muito bem e andou entrando uma sulfite dos muito massa então a gente consegue fazer a transmissão de vídeo dentro do discord' criar canais de voz tá nos atendendo muito bem gente não tem tantos robôs que nós tiramos lá no slack para adicionar aí nos ajudar alguns controles tá até para realização da daily nós temos dentro dos leques através de um robô o telegram também uma boa opção até aqui e se quebre vale abrir um parêntese sobre o que que a gente faz de dave hoje e a tia não

segue exatamente a proposta lá no instagram nós utilizamos através de canal de voz todo mundo registra antes da dele o as suas ações e a gente entra na escala de voz a gente faz uma discussão lá de 15 minutinhos sobre as propostas de cada um para os dias resolve identifica impedimentos para então prosseguir com relação a excelência técnica compartilhar com vocês algumas práticas a gente tenta executar na brain nós utilizamos bastante code review bom então o que a galera acorda fica para aprovação do time time revisa então sim realiza lá o merde da entrega tentamos

a nos reunir periodicamente para discutir temas e aí a gente faz as seleções de temas e ouvir podcast olhei artigos do milho um ou seleciona materiais no youtube a galera trabalho em cima desse tema e a gente pega um dia da semana ou a cada 15 dias para discutir em grupo e vendo se isso encaixa de alguma forma dentro do nosso contexto de brain is algumas das práticas que a gente realiza em busca da excelência técnica trabalhamos pelo programa em sempre que necessário não utilizamos isso fixo já tentamos a toda sexta-feira é dia de cada

programa e não funcionou e aí que a gente tenta identificar necessidade e aí sim a gente faz o perto certo acho que eu algumas das práticas que a gente tem eu não queria me alongar tanto mas eu imagino que já tenha me alongado espero que não tenha sido demais então a única reflexão que eu deixei aí cara parem análise e o manifesto ágil como vocês fazem dentro das organizações de você ou se você já trabalham senão como reflexão pessoal como é que vocês fariam analisando sempre o manifesto ágil e pensando se será que nós somos

agentes beleza gente acho que é seu pato fica por aqui espero que tenham curtido não esqueça um dia dar uma curtida assim curtiram e se inscreverem aí se não são inscritos beleza valeu e até o próximo