Gilson: Bom dia, boa tarde, boa noite vamos começar mais um episódios Os Agilistas e hoje nós vamos falar sobre um tema que eu diria muito importante, mas era muita dúvida e a gente quer discutir esse tema, nas suas mais diversas facetas que é o tema de estimativas. A gente fala que é importante, porque existe uma tradição, a primeira coisa que eu acho que quando alguém no pensamento até mais convencional, a gente vai falar sobre isso daqui a pouco. A primeira coisa quando alguém precisa de uma solução pergunta, é uma estimativa para poder saber prazo e preço. Já no Agilismo a gente vive comentando que você pode chegar a partir de um ponto onde isso nem vai ser necessário. Então a questão é, preciso saber estimar ou não preciso saber estimar? Se eu preciso saber quando é que eu estimo? Tem mais de um jeito de estimar? A estimativa tem propósito diferente dependendo da fase que ela está, se é no começo de um orçamento, se é mais para frente. Enfim, tem muitas perguntas aqui e hoje a gente trouxe uma equipe grande aqui para ajudar a responder isso, que é um tema que gera muita polemica, então vou colocar o pessoal aí no circuito. Nós estamos aqui com Magão, beleza Magão?Magão: Bom dia pessoal, bom dia, boa tarde, boa noite.Gilson: Aqui a gente chama pelos apelidos mesmo.Magão: Se falar o nome certo ninguém sabe.Gilson: Na verdade, eu chamo ele de Magão porque eu não sei o nome dele. Estamos aqui com o Felipão.Felipe: E aí pessoal, beleza?Gilson: Vocês veem como que estimativa é um assunto difícil, Felipão não conseguiu estimar o tempo para chegar aqui nessa reunião e atrasou um pouquinho.Felipe: Realmente, atrasei dois minutos então achei que você já começou aí (mostrando) [00:01:37] muito bem como é que o cliente tem expectativa em relação a estimativa.Gilson: Exatamente, 1 minuto é dinheiro. Estamos aqui com o Vinição também.Vinição: Tudo bem pessoal?Gilson: E estamos com o Andrezão, tudo ão aqui, cara, estamos com o Andrezão.André: Tudo bem galera?Gilson: Então, vou começar a fazendo a primeira pergunta que eu acho que é a pergunta (obvia) [00:01:58], que é o seguinte: o que é uma estimativa no final das contas, o ouvinte vai ver que é importante definir uma estimativa porque como o Felipão já deu uma dica ali, a estimativa ela ganha um ar de precisão, que se fosse tão preciso não deveria chamar estimativa. Então, quem se habilita a responder o que é uma estimativa?Felipe: Eu queria que eles fizessem as primeiras respostas, mas eu vou pedir a palavra aqui até pela piada inicial eu vou dizer o que não é uma estimativa. Uma estimativa não é uma definição precisa do tempo que vai se gastar para fazer alguma coisa, André.André: Vou começar aqui, minha primeira participação aqui no podcast vou começar a responder a primeira pergunta, assim, uma estimativa para mim seria uma projeção assim de tempo esperado para cumprir uma tarefa, para alguma coisa acontecer, pode ser uma projeção de tempo, projeção de tamanho.Gilson: De tempo ou de esforço?André: De esforço, acho que seria ou de tempo, ou de esforço ou de tamanho, depende do que é que é estimativa.Gilson: Na verdade assim, você decide o que é que você quer estimar, para projetar um tempo você precisa de projetar os esforços, saber qual que é a equipe ou saber quanto a projeção de tempo vai dar, uma coisa vai se (inint) [00:03:14] na outra.André: Isso, se for uma estimativa para cumprir uma tarefa seria mais de esforço, se for uma estimativa que precisa chegar de um ponto A ao ponto B seria de tempo. Então acho que tem casos para cada um desses tipos.Gilson: E também a coisa que eu acho importante ressaltar aqui, a gente falou brincando mais é muito sério é que a estimativa ela imediatamente após ser feita ela ganha um ar de certeza.André: Ela já vira uma pedra ali.Gilson: Ela vira na pedra. Então um negócio que eu acho incrível, cara, que é assim quando você faz uma estimativa, por exemplo, imagina que você tem um backlog, nós vamos discutir daqui a pouco como (estimar) [00:03:50], mas imagine que de algum jeito você fez uma estimativa. Quando alguém compra de um jeito muito adicional que no fundo a pessoa está esperando comprar um escopo fechado ali ou está esperando ter a solução. O que é que acontece nesse momento dessa estimativa? Todo mundo fica forçando aquela estimativa para baixo, fica todo mundo forçando, ninguém força para cima eu falo assim, o cliente nunca força ela para cima. E por que é que isso é ruim? Porque se é uma estimativa, para a estimativa em geral estar certa você tinha que errar para cima algumas, errar para baixo outras.André: Ser uma representação estatística no geral e não tentar forças a estatística para baixo.Gilson: É como se você botasse, cortasse todo o outro lado de uma curva de distribuição que pudesse dar as estimativas para cima, deixasse só as estimativas mais otimistas no final das contas. E depois reclamasse que as estimativas não foram cumpridas.Vinição: Eu complementaria até o que você falou que o cliente tende, quando eu falo cliente não é só o cliente numa relação de cliente fornecedor não, pode ser uma área também que demanda serviço para uma área de TI dentro de uma empresa, tendem, tipo assim, a minimizar o esforço, “só fazer um ajuste ali”. E junta isso com todo mundo da área de desenvolvimento sabe que o pessoal tende a ser extremamente otimista, tem estudos que mostram, tipo assim, que o pessoal do software é extremamente otimista. Aí junta essas duas coisas então gera um negócio que tende a falhar em relação a expectativa que é gerado em relação as estimativas.Felipe: Essa expressão “é só”, eu já brinquei em vários fóruns que toda vez que alguém fala assim, “isso é só fazer aquilo”, eu falo, “mais um ponto”, “não mas é só por, “mais um ponto”, cada “é só” vira mais um ponto.Magão: E é complicado também, tipo, pegando o gancho aí no que o Gilson falou e o Vinição, que muitas vezes o pessoal atrela a estimativa a um prazo, são coisas diferentes, o pessoal, geralmente, quer uma estimativa de um tempo para dar um prazo. E a estimativa ela não é assertiva e o prazo, dificilmente, o cliente ou quem quer que seja a área, aceita que não seja tão assertivo. Então o pessoal as vezes pede uma estimativa e dá um prazo exatamente em cima daquela estimativa e qualquer desvio que der ali, acaba gerando um transtorno muito grande. Então acho que esse é um dos problemas de acoplar uma coisa na outra e acho que gera muito problema.Gilson: Então, ou seja, acho que a primeira conclusão importante aqui é que a estimativa pela sua natureza de incerteza, ela nunca poderia ser usada para dar uma certeza, tipo assim, já que ela tem uma notória de incerteza. Ela permite que você mais ou menos se organize, coloque metas, coloque os recursos. Mas se o seu plano for completamente baseado que aquela estimativa tem que dar certo, seu plano já era, não é isso?Felipe: Exatamente. Essa questão de dar uma certeza eu estimei, daí, “então a data é tal, eu posso me comprometer com todos os envolvidos”. Eu sempre comento que quando esse tipo de coisa está acontecendo a gente tem sempre aquele tripé, o tempo, o escopo e a qualidade vou deixar até o dinheiro de fora, mas tempo, escopo e a qualidade, a qualidade ela é inegociável. A qualidade não tem que entrar na variável. Então, se o tempo vai ser utilizado para fixar qualquer tipo de comprometimento, não tem como ser ao contrário. Agora, se o escopo tiver que ser fixo dada a natureza de incerteza da estimativa, temos que aceitar que o tempo pode variar.André: Você vê que estimativa é um negócio tão difícil que mesmo dentro de um sprint, nas épocas em que eu era develop líder, por exemplo, era bastante comum ter um desenvolvedor, por exemplo,  que ele pegava, ele já tinha noção do que é que ele ia fazer, na verdade, ele já tinha executado num pouco. Mas várias vezes caia naquela situação dos 90%, tipo assim, no primeiro dia “quanto que você já conseguiu terminar?” “90%”, aí chega no outro dia 91, aí para chegar, para cumprir os 10% aí demorava uns 10 dias.Felipe: A estimativa é assíntota, ela é uma assíntota.Gilson: Só uma coisa que eu lembrei, que eu acho assim cursoríssima com software, pense bem. A gente falou de estimar esforço e de estimar tempo, mas na verdade antes de tudo você deveria estimar o tamanho das coisas. Então assim, por que é que eu acho que software é uma peculiaridade impressionante? Se você pede para alguém para ir pintar a sua casa, por exemplo, o cara vai estimar o tamanho da área, ele talvez vai medir até a área certinha, mas é a partir da área que ele vira e fala, “cara, pelo meu histórico você tem que pintar X metros quadrados”. Então assim, idealmente, se você soubesse assim, “vou fazer 10 quilos de software”, para fazer 10 quilos de software.Felipe: Tem um livro esqueci exatamente o nome, esqueci exatamente o nome do Sam do (inint) [00:08:50], eu já citei.André: Sam Newman.Felipe: Sam Newman? Ele fala que é como se você fosse construir uma ponte, ele fica fazendo esse paralelo com a engenharia, é como se essa distância toda hora que você medir lá de novo ela ficasse mudando, se for fazendo uma comparação com a engenharia tradicional. Então é tipo esse exemplo que você está falando, como é que você vai lá e mede essa área?Gilson: Eu fico, eu sempre falo isso cara, software tem um negócio que é isso é assim, você não tem uma unidade de tamanho que seja universal, mesmo que você tivesse essa unidade de tamanho, como você não sabe antes o que você quer, porque lá a parede já está lá, você sabe que aquela parede mede tanto. Você não sabe, e o que eu acho mais curioso em software mesmo para quem que dita em ponte função, por exemplo, mesmo contar depois o tamanho não vai, pode ser polemico de uma coisa que já está pronta, entendeu? Então assim, acho isso interessante para quem está ouvindo para poder entender o tamanho do problema e aí assim, volta uma coisa que acho que a gente já falou dos episódios que é o que? Aquilo que eu comecei falando da abordagem tradicional? Porque na abordagem tradicional o pensamento é assim, eu tenho um problema, aí eu sei a solução, aí assim, se eu sei a solução então basta eu saber o preço daquilo ali, o prazo, que vai para alguém botar. Isso que eu acho curioso, a gente nem acredita nisso, a gente acredita no outro caminho, eu tenho um problema eu não sei a solução, eu preciso de uma equipe que vai me dar, vai desbravar o caminho. Eu acho curioso que mesmo o método tradicional para quem trabalhou, e eu já trabalhei muitos anos com o método tradicional, mesmo nessa de eu sei a solução ela é voltada num nível tal que, na verdade, a estimativa é um negócio completamente impreciso, entendem?Felipe: Coisas acontecem, ainda que você saiba a solução.Gilson: Não, e por causa disso, porque você sabe a solução, mas você não traduz isso em alguma coisa que você depois converte para esse esforço tão facilmente, sabe? Você tem lá uma lista de requisitos, vamos supor, que você jura que você precisa daquilo mesmo, mas na hora de fazer aquilo mesmo você pode descobrir coisas que são mais trabalhosas, entendeu? O que eu queria dar um sentimento para quem está ouvindo dessa independentemente primeiro se nós estamos do agilismo ou do método tradicional, como é uma atividade, para tentar criar empatia com quem está, quem pede o software. Porque eu acho, eu entendo quem pede cara, muitas vezes pode se colocar numa posição assim, “esses caras mexem há vinte anos com isso cara, aí eu peço uma coisa lá os caras não conseguem”. É igual o Vinicius falou, dentro do sprint.Magão: E é complicado também, a pessoa te pede uma solução, alguma coisa em software, “não, vou resolver para você”. Aí o cara quer saber, logico, quando pelo menos que vai terminar, vai chegar próximo, “não sei, vou fazer aí uma hora eu te entrego”. O cara vai falar, “você está de sacanagem”. É muito difícil o pessoal ter essa confiança assim, que o pessoal vai estar fazendo o melhor mesmo para entregar.Vinição: Software eu acho assim, uma palavra que define bem software é um negócio extremamente emaranhado. Assim o próprio software, o time, uma série de coisas. Tanto é que muitas vezes o jeito de se aumentar a velocidade de um time as vezes é diminuindo o time, entendeu? Então é um negócio bem paradoxal. Por isso que é muito difícil esse tema de estimativas.Felipe: Aí eu vou até dar um passo atrás aqui cara, porque nós estamos falando isso de incerteza e tal e o podcast chama Os Agilistas, nós estamos falando sobre agilidade, e muitas vezes que eu estou dando uma palestra, eu sempre pondero igual o Schuster fez com métodos tradicionais. Agilidade, o agilismo ele se emprega na sua maior potência é quando a gente tem realmente uma situação de incerteza, uma situação em que a gente não sabe, nem necessariamente o que é que é preciso ser construído. Aí eu sempre uso uma analogia eu falo assim, “cara quando a gente pega um método tradicional ou processos tradicionais em que os mestres tradicionais podem ser melhores aplicados”, dou o exemplo da construção civil que igual o Schuster deu aí de uma parede. Você vai pintar uma parede, começa uma parede ela termina uma parede, você começa a construir um prédio ele começa um prédio ele termina um prédio. Agora um software por mais que o cliente ou solicitante acredite que quer alguma coisa, que saber o que é que quer, um software pode começar uma parede e terminar um caminhão, não é incomum. Agora, na construção civil um prédio sempre vai começar um prédio e terminar um prédio. Então como ele pode começar um prédio e terminar um caminhão, toda a incerteza envolvida nesse meio do caminho pode fazer com que estimativa se estiquem ou reduzam. E eu queria só comentar mais alguma coisa, Schuster você falou que estimativa a gente deve prezar por estimar por tamanho, que eu concordo plenamente, já tive discussões homéricas com colegas, outros fornecedores e com clientes sobre isso, a gente realmente acredita que a estimativa por tamanho favorece amortecer essa curva de erro. Mas na verdade eu deixei de ser um pouco xiita, eu até acredito que você quer estimar por pontos de função, você quer estimar por hora, que até me dá um arrepio aqui, quer estimar por hora, quer estimar com outros métodos, existem métodos proprietários, inclusive, as empresas concebem seus próprios métodos. Não me importa muito, mas eu queria ponderar aqui o porquê é que eu acho muito importante fazendo o paralelo entre estimativa de tamanho e estimativa em horas, ou estimativas mais granulares, vamos dizer assim. Eu sempre dou um exemplo, faço uma analogia as vezes quando eu estou dando alguma palestra eu digo assim, eu pego uma caneta, essas canetas, pinceis atômicos e falo assim, “e se eu te pedir de longe aqui”, aí as vezes as pessoas estão indiferentes a áreas da sala, o que é importante. “Se eu te pedir para me dizer separado a tampa da caneta com o corpo da caneta”, para me dizer, “olha, a tampa é um, quanto você diria que esse resto da caneta é maior do que essa tampa?” Aí as pessoas, geralmente, falam, “duas vezes maior, três vezes maior”, o que é plausível dependendo da sua perspectiva se você tiver do meu lado aqui você vai ter uma ideia melhor. Aí depois eu pergunto, “agora eu vou pedir para vocês me derem precisão em centímetros de cada uma delas”. Aí a galera fala assim, “já é mais difícil, eu não estou com o objeto na minha mão”. E o software é a mesma coisa, se a gente tentar ser granular e dizer assim, “isso é tantas horas e cravar”.Gilson: De forma absoluta, porque assim tem toda uma teoria que mostra que o ser humano em geral é muito melhor com comparações do que com, sei lá, se alguém te der um peso e pedir assim, “quantos quilos tem esse peso?” Você vai fala, isso é o peso mais leve, “agora compara com esse”, “esse aqui parece duas vezes mais pesado, esse parece três vezes mais pesado”. Então assim, o método de estimativa que alguns ouvintes podem ver as vezes a gente falar em planning poker, etc. No fundo é assim, independentemente, de quanto tempo eu vou gastar para fazer uma coisa, se aquela coisa é a coisa mais simples eu vou comparar ela com outras coisas. Aí eu vou ter uma arvore balanceada de pesos, eu vou, pelo menos, aí assim, por que é que eu acho isso interessante? Porque você pode até errar depois, a equipe pode ainda ter que ajustar produtividade dela, ela pode (tentar) [00:15:58], por exemplo, errando na produtividade e estar demorando mais para fazer a coisa simples do que ela imaginava. Mas na hora que ela corrigir isso, existe uma chance que é aquela arvore (inint) [00:16:07].Felipe: Então, aí você pegou no ponto chave da coisa, porque quando você falou produtividade você traduziria como velocidade. Quando a gente fala de horas e pontos é muito mais fácil haver uma convergência, e uma concordância de que algo é duas, três vezes maior ou menor que algo. Mas o tempo que se gasta é muito pessoal, porque as vezes uma pessoa é hiper produtiva num determinado assunto, ela gasta muito menos horas, a outra é menos produtiva, vai sempre tender a dizer, “mas eu gasto mais”. A estimativa de esforço ela é mais democrática, é mais fácil de você convergir, igual você disse eu posso estar menos produtivo nesse momento por alguma razão, mas nós ainda concordamos que os tamanhos das coisas estão corretos.Vinição: Eu vou dar uma de Schuster aqui, estou brincando Schuster, vou tentar fazer um resumo aqui para a gente prosseguir. A gente falou muito aí dá problemática da coisa, o quão difícil é o tempo de estimativas e tal. Mas aí então, qual que é o caminho dado esse contexto, dado que a gente está mexendo com software, no software é assim, emaranhado, é difícil de ter previsibilidade. O que é que vocês entendem que seria um bom caminho, uma boa forma de conduzir, dado todo esse cenário? E ainda colocando uma pitada até para os ouvintes que seguem a gente aí e trabalham com cenários, lidando ainda com empresas, times, clientes, que demandam um certo nível de previsibilidade, ainda lembrando de colocar aí isso, não podemos tirar isso (inint) [00:17:41].Gilson: Só adicionar uma coisa Vinição, acho que para falar de qual o caminho a ser seguido, a gente tem que pensar o seguinte. Qual é o papel final da estimativa, entendeu? Porque assim, se a gente começou aqui concordando que software pela sua natureza é difícil de estimar, tem muita incerteza, etc. Qual fica sendo o papel da estimativa então? Para o que é que serve? Alguém pode, “então para de estimar”.Vinição: Inclusive, eu acho que é uma opção.Gilson: Mas assim, a gente sabe que no mínimo nós vamos falar sobre isso, talvez, para parar de estimar tem que ser após algum momento, não dá para chegar de repente e falar, mas assim, para não ficar antecipando as coisas, qual é o papel da estimativa então afinal, dado que ela tem essas características inerentes a ela, e mais ainda em software pela natureza dele que a gente tentou explicar aqui?Felipe: Eu diria que o papel mais importante da estimativa ir gradativamente aumentando a maturidade do time em relação ao que ele pode se comprometer, para mim seria o mais importante. Segundo, é dar previsibilidade para quem é ansioso de saber e aí para quem é ansioso, eu coloco toda esses stakeholders seja cliente, seja uma área, enfim.André: Eu acho que para os stakeholders seria mais assim dar uma noção de que uma meta deles, ou algum alvo que eles estão buscando ele é realista e que eles podem alcançar ele com mais ou menos, aquele hand ali de esforço.Felipe: Exato, então acho que isso dar uma previsibilidade. Mas como eu disse que ela tem um objetivo inicial de aumentando a maturidade do time em relação ao o que é que eles conseguem se comprometer, e aumentando a maturidade em relação a relação dos envolvidos, dos stakeholders do time de desenvolvimento. Vocês brincaram assim, “então por que é que eu faço? Melhor parar de fazer”. É o futuro quase que inegável de um time que atinge um nível de maturidade alto na minha visão, quando a gente vai realmente entrando em fluxo, e virando quase um relogiozinho, as entregas começam a realmente estarem mais sempre do mesmo tamanho, o time está conseguindo acertar bem. A tendência é que o time conheça tão bem o próprio escopo, o tipo de coisa que está trabalhando que vá para um método menos prescritivo, tipo um (lean kanban) [00:19:56] aonde a gente pode se lançar mão do no estimate.Gilson: Mas do que isso.Felipe: Não estima mais.Gilson: Na minha visão, pelo menos, na hora em que um time, aí é o futuro, futuro mesmo, quando um time vira um time que é gerador de valor o jeito de orçar ele muda completamente. Assim, ninguém orça, há vários times que existem nas empresas hoje eles não são orçados a partir de um escopo, entendeu? A empresa não percebe isso, cara, eu falo assim, na medida em que uma organização vai ficando toda digital ela vai ter N times cuidando de N ativos digitais. Igual já tem hoje N times, ela não pega todo ano e fica orçando o escopo de que as pessoas vão entregar, entendeu? Assim, o que parece tão pouco natural é porque hoje, na minha visão, o pessoal ainda pensa o seguinte, eu tenho que construir uma solução, aí eu tenho que pegar um dinheiro para construir aquela solução. O cara não pensa assim, “eu sou uma empresa que tem trocentos ativos digitais que me geram valor e que sustentam o meu negócio, então eu tenho que ficar ali gerando valor, e o meu esforço é para gerar valor e não para ficar definindo o escopo”. Mas antes de começar eu só queria fazer uma pergunta, pode ser para você Magão, que você está querendo falar. Que é o seguinte, a gente aqui é extremamente pragmático então beleza, pode ser que as organizações vão chegar num ponto desse avançado, mas elas obviamente não começam assim, na verdade é até o contrário. As organizações, apesar de estarmos em 2020 a maior parte das empresas por motivos históricos ainda é imatura para adotar o ágil, e aí a gente sempre fala do alimentar o (inint) [00:21:31] que o Breno falou no episódio. Cara, o cara vai olhar para a gente e falar assim, “bicho, beleza, discurso é bonito, mas eu tenho uma área aqui que está me pedindo mais ou menos um valor, está me pedindo mais ou menos um prazo, vai ter um (inint) [00:21:43] que vai me acompanhar, mais ou menos da forma tradicional. Então a pergunta é, como é que a gente começa? Que tipo de estimativa que a gente pode fazer nesse começo para o cara ter o que falar para os tigres aí? Eles dão um alimentozinho ali para os tigres?Magão: É até isso aí que eu queria puxar mesmo, a estimativa num primeiro momento ela serve mais para quem está, não digo de fora, mas não dentro do time assim stakeholders ou quem quer que está bancando aquele projeto, para ele ter uma noção também de quanto tempo vai demorar, quanto tempo vai gastar. Só que até pela estimativa ser muito complicada, no primeiro momento você também não tem como estimar precisamente, porque você não conhece o escopo, você ainda não debruçou daquilo ali para entender os desafios técnicos o que quer que seja.André: Tem a ver com o cone da incerteza aí, quanto mais antes no tempo, menos certeza você vai ter para poder assumir um valor.Magão: Exatamente. E aí a gente tem, a gente pode citar vários tipos de estimativas que a gente faz durante o ciclo de vida, vamos dizer assim de um produto alguma coisa. No começo, como é muita incerteza ainda a gente costuma fazer algumas estimativas mais macro, talvez, que a gente chama de tamanho de camisa, que gera muita discussão, mas é só para dar uma.Gilson: Explica um pouquinho mais, a gente está pressupondo o que é que é uma estimativa de tamanho de camisa?Magão: É simples como uma numeração de camisa assim P, M e G, super pequeno, tamanhos M ou tamanho médio, e grandes são aquelas requisitos ou necessidades do cliente que são grandes demais e ainda nem tem noção do que é que é aquilo. Isso gera certa discussão porque você vai naquela discussão, o que é que P, o que é que é M, o que é que é G? Para cada pessoa pode ser uma coisa.Gilson: Mas é meio por comparação, a equipe vai concordando. É um planning poker em alto nível, digamos assim.Magão: Exatamente, você usa comparação, sei lá, pega todos aqueles requisitos escolhe um que você acha que é um tamanho P, ou 1 lá que o Felipão citou no exemplo da caneta.Gilson: Só que (com uma granularidade) [00:23:40] bem diferente, vão ser mais, talvez (inint) [00:23:43] ou épicos?Magão: Talvez em épicos ali, que você nem entrou para o nível de histórias ainda. E aí é aquela, beleza, você tem um P, mas qual que é o tamanho do seu P? Aí vem um outro problema, pode ser o P você pode falar que é sei lá, uma semana ou você pode falar que são três meses, então é bem complicado. Mas pelo menos você já consegue dar uma clareada e uma acalmada, vamos dizer assim, no cliente.Gilson: Pode ser com comparação com outros sistemas similares, com outras histórias.Magão: Exatamente, estimativa por analogia pode ser bastante útil nesses cenários, você pega algum modulo, alguma coisa similar que foi feito no passado e faz uma comparação com o que você está olhando.Felipe: Mas olha que interessante isso que o Magão falou, por que é que no início, quando tem essa vontade de saber, diz, “muito bem meu chapa, legal o discurso, mas o que é que eu vou falar aqui?” Aí a gente vai, uma das formas é a gente pegar um escopo maior e ir para esse tamanho de camisa, por que tamanho de camisa? Porque é menor granular e é mais fácil de convergir quando a gente fala, vamos pegar aí, tamanho de camisa, tanto em P, M e G, quando a gente vai para planning poker usando Fibonacci lá, depois a gente pode falar mais disso, a gente tem lá, 1, 2, 3, 5, 8 e por aí. Então quando a gente fala P, M e G exclusivamente na minha visão para ficar mais fácil de você fazer a comparação porque você tem menos granularidade e o ponto maior de granularidade seria você tentar estimar em horas.Magão: Mas assim, eu diria que tem um aspecto psicológico de gestão de expectativas muito forte aí com o cliente.Felipe: Porque já aceitam variabilidade maior.Magão: Fica (bem parecendo) [00:25:17] incerto.Felipe: Ou seja, ela mostra claramente para que ali já tem uma variabilidade (intrínseca) [00:25:22].Vinição: Você usa bem o que seria estimativa.Gilson: Torna mais concreto que aquilo é uma estimativa.Magão: A linguagem está sendo usada.André: O espectro é tão pequeno que você evidencia ali que já é uma estimativa.Gilson: Quase falar assim, “isso aqui parece fácil, isso aqui parece difícil, isso aqui eu não sei”.Magão: Esse G aqui eu não sei, mas vamos chamar aqui de G. Aí quando o cliente fala assim, não, mas eu quero um número aí você faz uma tabelinha de pares e joga ali no Excel. Mas isso já gera um ganho absurdo para o cliente, porque, por exemplo, se ele tem um conjunto de requisitos muito grande e ele não sabe por onde começar, talvez só essa ideia inicial, mesmo sendo bem precisa você já ajuda ele a priorizar, que seja o backlog alguma coisa, que ele pode começar, “isso aqui como é menor eu vou começar por isso, (que é) [00:26:10] valor mais alto”. Você já vai atacando um pouco aquela visão ali de tipo assim, que é um cheque em branco, tipo assim, que você não sabe.Felipe: Começa a atacar essa visão.Gilson: Não e convenhamos gente, a gente as vezes tem uma visão eu sempre falo, nós somos muito técnicos aqui na empresa e a gente, as vezes, tem uma visão muito técnica, mas assim pensa bem é muito, não tem jeito de você realmente falar para um cara o seguinte, “cara é impossível falar, dar qualquer número, é impossível”, o cara vai dizer, “você está de brincadeira comigo, é impossível. Eu quero algum número, você pode me falar?” A questão para mim é um número que carrega consigo esse grau de incerteza todo mundo entenda isso, e que seja um racional transparente e compartilhado de forma que tenha uma medida em que as coisas aconteçam todo mundo saiba, entende? Assim, eu sempre comento isso com os nossos clientes assim, eu acho que o importante é ter um racional transparente e compartilhado de forma que as premissas adotadas sejam as mesmas. Então assim, está todo mundo concordando que aquilo é pequeno, ao botar um P ali é porque está todo mundo entendendo que aquilo parece ser simples mesmo. Aí se durante uma discussão aparece uma coisa que muda a natureza daquilo, aí pelo menos então não pode concordar os (inint) [00:27:22], mais simples não, é diferente de você, (é que) [00:27:25] nem começar com nada.Felipe: E é isso mesmo aí que você falou, porque no início o que a gente pode começar é começar a trabalhar essa sensação de (check-in) [00:27:36] em branco, mas o maior poder dessa estimativa de tamanho, de camisa, por exemplo, dentro de um backlog ainda muito incerto. Ele vai vindo depois, porque depois que você começa a construir você vai dando essa concordância de que, “então os meus sprints costumam caber, mais ou menos, uns dois P, um M ali”, você começa a ter uma forma de medir melhor, obvio, que ainda com incerteza o que é que você consegue pôr para frente aí num roadmap.Gilson: Então gente, assim, só para tentar ficar mais claro para quem está ouvindo, porque eu fico pensando o seguinte, a gente fala, eu acho esse assunto ele complicada, sabe? Pelo seguinte, imagina a gente fala muito que os suas tem que entregar resultado, não é isso? Então eles têm que ser orientados, por exemplo, pelo (OKRs) [00:28:26]? Aí alguém pode estar confuso, “mas se eles têm que ser orientados pela (OKR), por que é que a estimativa interessa então, o que é que a estimativa está importando, entendeu? Então assim, a impressão que me dá é que esse é um caminho de conversão mesmo, sabe? Ninguém no começo está preparado e durante muito tempo não fica preparado para trabalhar com (OKR) [00:28:48] e no começo e, talvez, durante muito tempo alguém ainda fique pegando dinheiro para fazer uma solução. É o jeito que ele consegue o dinheiro, porque nesse mundo ideal que a gente fala o cara ia defender que ele precisa de um time para entregar tão OKR e confia nesse time e vai sabatinando.Vinição: Só que não começa assim, é como você disse é um mundo ideal, não só a gente a DTI mais os nossos ouvintes também vão enfrentar situações que são também, tem a ver com um mundo mais tradicional onde essa parte de estimativas ainda vai ser muito cobrada, por isso que eu acho que o assunto é bastante relevante, viu?Gilson: Só para mudar um pouco o assunto é o seguinte, acho que já ficou claro então para quem está escutando qual que seria o papel da estimativa e esse papel inicial de tentar, pelo menos, criar um número que você possa ficar perseguindo, que você possa conseguir um orçamento, que você possa explicar para os outros um racional de por que é que você acha que vai gastar aquilo etc. Mas que o idealmente, com o tempo você iria convertendo aquilo de uma forma que você gerasse valor continuamente que seria muito mais importante do que isso. Mas existe uma discussão também muito grande, uma preocupação, eu não digo clientes, que (são) [00:30:04] as pessoas não técnicas, que estão consumindo o serviço de uma equipe que é o seguinte, beleza, independentemente, se eu peguei esse dinheiro de como eu peguei o dinheiro, se eu não tiver estimativa essa equipe vai ser produtiva? Ela vai correr atrás? Ou ela vai ficar ali viajando? Essa é uma questão, vocês concordam? Fala aí Andrezão.André: Eu concordo, isso aí assim, eu acho que vai muito da maturidade aí do relacionamento do time com o cliente dele. Assim, no início o cliente vai estar sempre um pouco desconfiado e querer estabelecer uma relação aí de comando e controle e estar investigando exatamente com o que é que o time está gastando o tempo e tudo? E à medida que o tempo vai passando e o time começar a conseguir entregar e dá uma cadência nessa geração de valor, o próprio cliente já vai conseguindo adquirir uma maturidade ali para entender que essa estimativa ali, ninguém está de sacanagem. Então no final das contas é uma estimativa e tem incerteza e, às vezes, vai errar para cima ou para baixo, e isso é uma natureza da própria estimativa.Gilson: Então, mas a minha pergunta é assim, independentemente, da percepção extrema não é importante para as próprias pessoas terem algum tipo de referência, para inclusive saber se estão acertando, se estão ou não? Vocês falam não?Vinição: Acho que as estimativas elas deveriam funcionar num formato bem parecido com os OKRs que onde você estabelece o resultado como um desafio e não vinculado, tipo assim, a uma meta financeira no caso dos OKRs. É igual a estimativa ela deve funcionar como um desafio, porque se ela virar um negócio que o cara, que a pessoa é obrigada independente de qualquer coisa que acontecer a cumprir aquilo ali, é claro que a pessoa vai colocar uma estimativa mais alta para que ele consiga cumprir. Inclusive, essa é toda a forma de pensar do movimento do no estimates que é exatamente não ter estimativas, porque se você é meio que obrigado a colocar um negócio que você vai ter que cumprir, senão cai uma faca no seu pescoço, você vai colocar um valor mais alto. Então é muito mais, deveria ser encarado como se fosse um desafio que a própria pessoa meio que coloca no início que ela vai buscar de fato a conseguir terminar antes, como se fosse um desafio pessoal, uma questão de maestria ali e tal.Magão: Eu acho que são dois pontos, é esse que o Vinição citou que é para o time buscar aquilo ali e tem um ponto muito importante que eu acho que vem depois no final do ciclo, alguma coisa assim, que é rever como foram as estimativas e o que realmente você gastou dentro daquilo ali, dentro daquele sprint. Por isso dá um feedback muito bom, para o próprio time, para identificar algumas falhas, algumas deficiências que o time ainda tenha, talvez, por exemplo, a gente trabalha com suas que full stack e, as vezes, você tem um sprint em que as tarefas de back end lá foram bem estimadas, mas a de front end o time errou miseravelmente na hora de estimar, isso acontece muito. E aí, eu acho que o importante é que no momento ali de retro, o que quer que seja, debruçar sobre isso aí e analisar, “por que é que será que a gente errou? Será que a gente está sendo otimista demais? Ou a gente não está quebrando bem as histórias para estimar?” Então isso dá um feedback muito bom para o time para ir evoluindo durante o projeto.Gilson: É difícil de negar que no curto prazo o time tem ficando mais assertivo?Magão: Exatamente.Felipe: Sem dúvida.Vinição: Tem mais uma ação.Gilson: (inint) [00:33:30] bastante o negócio, simplificou.Felipe: O contexto é cada vez mais conhecido.Gilson: Conhece a tecnologia, os membros se conhecem, e assim, se o time nem partiu de uma hipótese qualquer, aquela história que tem até lá no lean startup, tem uma frase famosa, eu não lembro exatamente da frase, mas é uma frase sobre ciência que é como se fosse assim, “se eu não tenho nem hipótese eu não tenho nem como aprender, porque eu não sei se eu errei”. Tipo assim, a coisa aconteceu e pronto. Mas então assim, estou entendendo que vocês são contra esse movimento no estimates? Pergunta forte agora?Felipe: Eu Felipão sou super a favor, inclusive, mas acho que tem que ser feito com muito cuidado, porque baseado até no que o André comentou ali na hora em que ele estava respondendo a sua pergunta. Eu acho que controle e autonomia é igual um balanço de parque, desculpa, controle e maturidade, quanto maior maturidade menor é o controle necessário, mas se a maturidade diminui, nós temos que aumentar o controle. E a estimativa ainda que eu concorde muito com o Vinição, ele está completamente certo de que não pode estar escrito na pedra, não pode ser uma coisa faca no pescoço, ela é sim um mecanismo de controle, ela é um horizonte que o time vai perseguindo, vai se instruindo para depois sim conseguir chegar num ponto máximo ali de maturidade aonde ele realmente não precise de estimativa. Então eu sou a favor do no estimate, desde que haja maturidade.Vinição: Eu sou a favor até pelo seguinte, se você vai tendo um time mais maduro e que está, vamos supor, trabalhando com lean kanban, vamos dizer assim, as histórias naturalmente têm a durabilidade de uma semana, para mim isso mata tudo.Gilson: Não, é engraçado isso que eu estava pensando, quando eu falei assim, por exemplo, se não tem uma estimativa você não tem nenhuma hipótese sob a qual você decide se está certo ou errado. A verdade é quando o time vai amadurecendo e não entrega por curtíssimo prazo, seja um lean kanban, igual você disse, no máximo uma semana já existe uma hipótese subjacente o tempo todo que você tem que entregar aquilo em curto período e se você está errando aquilo, você começa a se atentar, “por que é que eu não estou conseguindo entregar (isso) [00:35:41] em curto prazo?”Vinição: E se tiver alguém muito improdutivo no time assim, vai conseguindo não começar não entregar tão frequentemente, uma semana.Gilson: Existe uma (restrição) [00:35:49] habilitatória ali? Que é essa restrição do tipo assim, cara, isso aí seria péssimo no longo prazo.Vinição: É uma estimativa by design, tipo assim, a gente precisa o design de como o time vai entregar já tem uma estimativa subjacente ali que é uma semana.André: Exatamente, assim o próprio ato do time começar a quebrar as histórias e ter um pouco mais de noção de qual o tamanho de uma história que é o tamanho ideal para eles trabalharem já vai dar uma noção de quantas histórias eles conseguem entregar numa semana.Felipe: Agora eu queria só fazer um comentário aqui em relação a uma coisa que o Vinicius falou que ficou na minha cabeça aqui, que é se o cara está com a faca no pescoço ele vai fatalmente estimar para cima, então eu queria só pontuar algumas pegadinhas aqui do processo de estimativa que geralmente a gente vê e que acredito que os nossos ouvintes sejam eles consumidores de um time ou participantes de um time, eles fatalmente veem esse tipo de pegadinha acontecer. Uma é uma frase que eu sempre repito, “só estima quem faz”, não tem condição de você colocar alguém na roda para estimar que não está comprometida e entregar. [00:36:58]Vinição: Já teve alguma situação que o diretor (queria estimar) [00:37:00]?Felipe: Cara, diretor, usuário que nunca ouviu falar de desenvolvimentoMagão: Tem uma outra também que quem não está no time, mas já trabalhou, “não, na minha época eu fazia”.Felipe: Então assim, rola muito, só estima quem faz por quê?Vinição: Quem faz não, quem está fazendo.Felipe: Quem está fazendo, exatamente. Muito mais fácil quem está realmente comprometido em entregar um determinado escopo.Gilson: Vem cá, desculpa, viu eu estou representando aqui, já tem muitos anos que eu não faço, estou aqui representando a ala, eu me senti ofendido.André: Representando a ala do “na minha época”.Gilson: Eu falo assim, não é possível a pessoa ingressar na conversa e usar as referências que foram usadas no passado para dar opinião.Felipe: Para sabatinar acho que aí você falou exatamente, para sabatinar sim.Gilson: Para mim o cara tem todo o direito de assim, falar, “seu Felipão esse aqui era um, esse aqui está parecido com aquilo”.Felipe: Isso eu concordo. Eu vou refazer a minha frase, só estima quem faz, mas qualquer pessoa que possa (aportar) [00:38:09] informação é muito bem-vindo no processo de estimativa e pode questionar sim uma estimativa. Mas ela nunca pode, ela nunca pode ser o voto de minerva ali que vai definir, “não é isso”, ela no máximo pode contrapor e gerar discussão normal dentro de um processo de estimativa.Gilson: Tem que existir um racional, o que eu falo racional é assim, é tipo assim, “Magão eu parei”, eu nem cheguei, eu particularmente não cheguei nem programar (inint) [00:38:33], então seria um bom descaso da minha época. Mas imagine eu chego para você e falo, “cara, beleza, mas isso aqui está muito parecido”, que a estimativa por comparação é isso?Felipe: Sim.Gilson: “Isso aqui está muito parecido com isso e com isso”. Aí o que é que eu imagino numa discussão dessa? Você pode realmente, tem razão, ou até está parecido, mas só parecido, na verdade, existe tal coisa aqui que faz com que fique muito mais complexo.Magão: Exatamente, tem os dois pontos isso que vocês citaram aqui, que  a pessoa pode sim sabatinar e é até bom para a discussão, porque as vezes você está enviesado com algumas coisas você não está vendo algum detalhe ali, que alguém de fora vai te ajudar a ver. Mas tem muito disso também, que tecnologia muda muito rápido, por exemplo, sei lá, cinco anos é uma eternidade então é uma coisa que talvez era simples aí, não estou falando que foi da sua época não, mas aí trazer um (VD) [00:39:25] ali.Felipe: Igual o Vinição falou aqui, que quando eu era (DL) [00:39:27] a gente amarrava cachorro com linguiça.Magão: Por exemplo, fazer uma aplicação no desktop, é um negócio completamente diferente de fazer uma coisa web, escalável, por mais que a gente vai atacar um pedaço de cada vez tem alguns detalhes tecnológicos ali atrás que tem que ser levados em conta, entendeu?Vinição: O problema que eu vejo é que muitas vezes isso vem de forma meio coercitiva assim, de forma explicita ou implícita. Esse que é o problema, não vejo problema nenhum igual o Schuster falou, se estiver trabalhando com informações, assim, claramente pegando uma informação cruzando com outra ali é claro que tem várias pessoas que são extremamente inteligentes, chegam ali cruzam várias coisas ali e colocam uma informação nova na mesa que é claro que deveria ser usado.Felipe: Então só para eu concluir minha listinha aqui, uma outra.Gilson: Sua listinha só teve um item por enquanto.Felipe: Só teve um item, comecei pelo mais polêmico. Esqueci.Gilson: Estimei errado minha listinha.Felipe: Não, um segundo ponto que eu acho também que é uma pegadinha comum dentro de estimativas é exatamente que o Vinição falou a pessoa por não entender muito bem o que tem que ser feito, “não, eu vou estimar para mais para dar um (inint) [00:40:37]”. Isso está errado, se você está tendo que estimar para mais, é muito provavelmente porque o nível de quebra do que você está tentando estimar não está legal. Então se for assim, “não, porque isso aqui eu não sei o que é que tem que fazer aqui”, é obvio que a gente não tem que saber a solução de tudo. A gente não sabe como vai resolver todos os problemas, mas se tem algo tão obscuro que está te fazendo jogar uma estimativa muito para cima, para você ficar seguro, muito provavelmente o que você tem que fazer: parar a estimativa e mergulhar um pouco mais para poder tentar quebrar e tentar ter uma estimativa mais granular. Então essa é uma segunda pegadinha que eu enxergo aí no processo de estimativa. E a terceira para dizer que minha lista não é só de duas, e a terceira é que eu enxergo também é quando a gente ouve a seguinte frase, ainda tem mais um, a seguinte frase, “não, eu acho que isso aqui é um ponto porque eu gasto um dia para fazer”. Eu já coloquei as duas na mesma frase aqui, primeiro, fazer associação de ponto com o tempo já é uma coisa muito perigosa, porque se a gente está estimando em ponto em tamanho, é justamente para se livrar desse viés muito granular. Então essa é uma pegadinha, tentar realmente evitar fazer analogia do tamanho com o tempo gasto.Gilson: Não a questão do granular, porque acho que uma das coisas mais difícil das pessoas entenderem, porque até para o desenvolvedor é difícil isso. Uma coisa é assim, “isso aqui é uma coisa simples”, outra coisa é, “quanto tempo demora para fazer isso?” As vezes tem um cara que faz em 1 minuto e tem um cara que faz em sei lá, vai usar uma média da equipe de esforço. Mas são coisas de natureza diferentes, sabe? Uma coisa é o peso daquilo que tem que ser feito em relação as outras coisas e outra coisa é o esforço. Isso muda, porque na verdade na cabeça da equipe já identifica aquilo como unidade do típico 1 dia, não é? E aí as duas coisas se misturam.Felipe: Isso é um perigo cara. E a quarta coisa, então assim, a terceira é comparar, é tentar fazer uma analogia direta de hora com o ponto. E a quarta é o famoso, “eu gasto”, porque o eu trago muito da experiencia individual da equipe, quando você mesmo falou Schuster a velocidade, a capacidade de estimar deveria ser uma média de produtividade do time e nunca eu. Porque se a pessoa pega uma gripe, e tem que ficar fora do time pronto, tudo o que ela estimou baseado na própria experiencia certamente vai ser impossível de cumprir. Então também a gente tem que evitar fazer estimativas baseadas, avaliar a complexidade de algo baseado na própria experiencia.Gilson: Por isso, eu não sei se todo mundo está familiarizado, eu tenho um planning poker que é um processo participativo que aí você evita o viés de uma pessoa, tem várias. Agora só para a gente começar a caminhar para o fechamento, então olha só, para ver se a gente consegue dar uma ordem aqui no que a gente falou. Estimativa é super difícil de fazer e super incerto, vai ser necessário num primeiro momento em altíssimo nível para tentar justificar quanto que você pega de dinheiro para tentar, realmente, todo mundo concordar com algum raciocínio sobre, “olha, vamos ter algum racional para pedir um dinheiro, para pensar num prazo, porque isso é importante para qualquer negócio. E, uma vez que, a gente faça aquilo vamos tentar fazer os melhores (esforços) [00:43:58] para chegar naquilo. Para poder ver se a gente está convergindo para aquilo, a gente começa então com essa estimativa mais ao curto prazo que é para ir dando segurança na trajetória, não é isso? Ou seja, você começa por esses exercícios contínuos de estimativa também. Talvez, podendo chegar num dia em que a equipe está tão madura, a área de negócios está tão confiante, a empresa já se converteu em que o mero fato de você estar continuamente entregando coisas em curto prazo, faz com que seja desnecessário, e estimativa vira quase um desperdício. O lean poderia falar, “elimine isso aí porque vocês entregam o tempo todo”. O negócio muda de rumo o tempo todo, o negócio já entende que precisa botar dinheiro ali sempre, porque aquilo é um ativo continuo, então a estimativa pode virar um desperdício, num dado momento, vai ficar lá fazendo muito esforço.Felipe: É claramente esse resumo aí que você fez mesmo, nem ficaria complementando muito.Gilson: Então está bom pessoal, alguma coisa adicionar aí?Magão: Não, acho que é isso mesmo.André: Satisfeito com o resumo.Felipe: Acho que foi bem estimado, foi muito bom.Gilson: Tinha estimado que ia dar 46 minutos o episódio, faltam quatro segundos, então falou pessoal.Felipe: Até mais, até mais pessoal.