M1: Bom dia, boa tarde, boa noite. Vamos começar mais um episódio dos Agilistas. Hoje eu estou aqui com o Vinição. E aí, Vinição, beleza?Vinição: E aí, pessoal, tudo bem? Bora lá.M1: Então, gente, hoje nós estamos fazendo aí, se não me engano, 20 anos do Manifesto Ágil. Isso me deixa meio horrorizado porque mostra como é que eu estou velho também; já tem 20 anos do Manifesto Ágil, e aí nesse marco do Manifesto Ágil a gente achou interessante conversar um pouquinho sobre o que significa o Manifesto Ágil mesmo, e uma coisa que a gente gosta muito de fazer aqui no podcast é trazer na prática exemplos que ilustrem os princípios do que a gente fala. Então a gente fala sobre descentralização, mas tenta mostrar na prática como é que a gente faz isso. A gente fala sobre times auto-organizados e fica tentando mostrar na prática como é que a gente faz isso. Então é interessante porque quando você lê os princípios, eles são simples, mas quando você tenta colocá-los em prática é super complicado. É tão engraçado isso, como é a vida das organizações, a forma como elas são estabelecidas; é difícil colocar certas coisas em prática. Engraçado, porque hoje a gente fala do agilismo em um âmbito maior, mas o Manifesto Ágil obviamente surgiu no contexto de desenvolvimento de softwares, os princípios são mais voltados para desenvolvimento de software, e aí, só para relembrar o ouvinte, os caras se juntaram lá em um resort, eu acho que era Snowboard o nome do resort.Vinição: Snowboard em Iutá.M1: Em Iutá, e os caras se juntaram lá, e eu acho interessante porque eu sempre gosto de falar do Manifesto Ágil como um movimento para quebrar um círculo vicioso que estava instaurado na época, que era o círculo vicioso de sempre atribuir aos problemas que você tinha para entregar software, atribuir o erro a uma falta de planejamento e de detalhamento. E, imagina, se você acredita que o que você tem que fazer para entregar bem um software, vamos voltar aí nos anos 2000, 99, vamos pegar no momento do Manifesto Ágil, hoje a gente vai falar mais de software mesmo, de repente pode estender para organização, mas se você entende que o fracasso estava sendo causado por falta de planejamento e detalhamento – e aí um parênteses, tinha relatórios da época que mostravam até 70% de fracasso na época, nessa década de 90, eu lembro do caos de 95 a 97 mostrando 70% de fracasso, e o fracasso é não cumprir prazo e orçamento e, pior ainda, às vezes, mesmo gastando mais, não cumprir a expectativa dos usuários. Aí você imagina, em um contexto desse, se você vive no paradigma tradicional e as coisas deram errado, você pensa assim: “Poxa, então no próximo eu vou planejar mais e vou detalhar mais”, e você entra no famoso círculo vicioso. E a gente brincava, eu já participei com projetos de especificações de 600 páginas, assinadas página a página, assinadas com sangue, como se o jeito de você evitar o problema era quase que na marra fazer todo mundo assinar que o que tinha que ser feito era aquilo que estava escrito. E aí, gente, o que que acontece? Um grupo de caras, com escolas um pouco diferentes, alguns criavam metodologias um pouquinho diferentes, mas com alguns princípios em comum, se reuniram aí nesses resorts e deram origem a esse movimento que é tão mainstream, cara. E na minha visão o que eles fizeram foi falar assim: “Vamos quebrar esse círculo vicioso e vamos pensar em um jeito de desenvolver software diferente”, que fundamentalmente é um jeito que ao invés de ter compilado o gerenciamento, o planejamento detalhado, tinha que compilar a evolução e a execução. E aí você pega o manifesto, a gente vai ler ele aqui junto e discutir com o Vinição, o manifesto fala isso. Imagina, naquela época os caras, inclusive é engraçado porque é feio pra caramba o site, não é, Vinição? Não sei se você lembra do site, era as carinhas, era tipo uma fotinha.Vinição: Eu acho que eles mantêm até meio que de propósito, eu acho. Tipo assim para mostrar as raízes, sabe? Ele lembra muito software de pessoas de universidade. Eu lembro que um professor meu, o Constatino, que escreveu um livro com você, feio para caramba o site do Constantino, mas importante.M1: É curioso, porque você olha assim, é uma página muito simples. E é engraçado, só um parênteses aqui também, um dos livros mais importantes do agilismo, para mim, foi o C Programming, e eu lembro que quando eu indicava ele para alguém, eu brincava: “É um livro pequeno e simples”, porque você não pode ter um livro sobre linguagem complicado, seria meio… ter um tratado de mil páginas sobre metodologia ágil. Mas essa página fala: “Estamos descobrindo maneiras melhores de desenvolver software fazendo nós mesmos e ajudando outros a fazer o mesmo. Através desse trabalho, passamos a valorizar”. Então olha só que interessante: os caras falam: “Gente, tem uma forma melhor de fazer isso aí que está dando tão errado, e a gente está explorando isso, fazendo isso, e agora estamos tentando passar isso para a comunidade”. E aí vem alguns princípios que eles valorizam, e esses princípios são quais? Primeiro princípio: indivíduos e interações mais do que processos e ferramentas, softwares e funcionamento mais do que documentação, colaboração com o cliente mais do que negociação de contratos e responder a mudanças mais do que seguir um plano. E aí, depois, os caras falam uma coisa que é muito importante que é: “Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda”. Ou seja, no caso de indivíduos e interações, mais do que processo e ferramenta; não quer dizer que os processos e ferramentas não tenham valor, mas o que que eles valorizam mais.Vinição: Até sobre esse ponto aí, eu acho que é o ponto menos compreendido do manifesto. O pessoal que é como se fossem os itens da esquerda acima de tudo, então esqueçam os itens à direita, e na verdade é simplesmente uma priorização. Às vezes eu falo que um dos livros mais famosos de Uml, por exemplo, é um livro do Martin Fowler que assinou o manifesto, entendeu? Então você só tem necessidade de saber como usar bem, quando usar bem não é uma prioridade, mas eu lembro de vários projetos e produtos que eu participei com entidades muito fortes que quiseram ser excelência, mandar por exemplo (para um órgão)? [00:06:25] do Estado. Um expert da ferramenta eletrônico que a entidade fatura era assim: toda vez que chegava um dev novo no time, a gente tinha que explicar tudo. Imagina se não tivesse um documento que explicasse isso, não é? Teria que ficar se desgastando toda hora, tudo de novo, sem nenhuma base. O diagrama de componentes, por exemplo, que é um diagrama que mostra a interligação de sistemas é muito útil para você explicar uma arquitetura. Então não significa que só porque o software rodando é mais importante do que orientação para gente, não significa que na verdade em vários momentos é necessário ter uma documentação boa sobre determinadas coisas.M1: Muito legal, Vinição. Diria que você fez uma explicação sobre um método e princípio dos princípios. Isso é muito importante.Vinição: O princípio de como usar menos princípios.M1: É, exatamente. Porque os caras salientam isso, está escrito aqui: “Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda”, e aí muitas vezes o ágil foi confundido com sair fazendo de qualquer jeito, rir de quem fez qualquer documentação, que ojeriza qualquer diagrama, igual você disse. O cara tem um diagrama lá coibido. E você falou, esse livro, é o Uml Distilled que você deve estar falando do Martin Fowler?Vinição: Eu não lembro exatamente o nome, não, mas eu sei que é um livro bem famoso de Uml, que inclusive já li.M1: Eu acho que deve ser Uml Distilled. Esse livro é antigo, eu li ele também.Vinição: Tem um, que é um outro que tive com você, você não vai lembrar, não, mas eu tive com você, e com o nosso muito amigo Marquinhos, que é quase o famoso Marquinhos, que quase fez parte da DTN no início, ele entrou e saiu, fez parte da nossa história, mas de qualquer forma já fez muito parte da nossa história. Ele me ensinou muito que determinadas decisões arquiteturais, independente se é com o cliente ou não, às vezes são algumas guinadas que você dá, por exemplo, em termos de arquitetura, é importante você ter alguma matriz de documentação, nem que seja em uma planilha eletrônica, em um Excel simples, mostrando quais opções que a gente tinha na época, porque quando você tem uma decisão importante, depois, no futuro, a gente mesmo se questiona: “Por que que a gente não seguiu aquele caminho?”. E isso não tem a ver só com contrato entre clientes, tanto é que, por exemplo, há três anos atrás (Tortu Works)? [00:08:50] solta um radar que é bastante seguido e ele faz os ordenamentos de mais de… nesse radar, ele tinha registro de decisões dev e decisões arquiteturais. É uma empresa que, como a gente, segue os pilares do agilismo. Então você vê que, na verdade, isso aí que você e o Marquinhos me ensinaram há muito tempo atrás tem muito a ver com essa questão de documentar o que é realmente importante, o que você vai usar para alguma coisa.M1: É curioso, Vinição, porque outro dia a gente postou nos Agilistas um enzina antigo, falando sobre um enzina antigo sobre o desassossego do agilismo, e para mim isso que você está falando reflete muito isso. A gente quer procurar regras simples e aplicáveis em qualquer contexto, então é muito mais fácil para um cara ler isso e falar: “Então beleza, não tem mais documentação”, e aí acabou. E não o cara ter que usar o julgamento, a experiência, conversar com outras pessoas, analisar a situação e pensar: “Poxa, aqui é algo extremamente complexo, difícil de enxergar. Um diagrama vai ajudar. Aqui é uma inteiração muito complexa e que está muito instável. Vamos documentar isso para facilitar o entendimento?”. Esse tipo de julgamento, e de não ter uma regra sempre tão fixa, é o que eu comento nesse enzima antigo. Coincidência, porque foi postado recente, mas que para mim causa um pouco de desassossego, porque é muito mais fácil alguém saber que ou faz documentação ou não. E, na verdade, o que eu acho que aconteceu muito com o Waterfall é o outro lado da moeda mesmo. Aqui, no começo do Ágil, às vezes tinham pessoas que adotavam esse extremo de falar assim: “Cara, se você está documentando você está errado. Se você está fazendo, você está errado porque nós somos ágil”, e aí no Waterfall acontecia o contrário também. Eu lembro que eu mesmo, eu acho que eu já contei isso aqui, eu fui fazer uma vez um projeto lá seguindo Gup à risca, mas à risca mesmo, então estava com a interpretação dessa aí; eu não conseguia desenvolver nada, ficava só fazendo diagrama, porque toda hora que mudava alguma coisa eu queria mudar os diagramas, eu voltava lá, aqueles diagramas mais bestas, sabe? Diagrama besta, assim, era algo pouco relevante para o sistema, mas eu ia lá, mudava o diagrama porque eu queria ter a experiência de fazer tudo, então é como se fosse uma odisseia.Vinição: No fundo, se pegar esse princípio do software funcionando sobre documentação para a gente, na verdade, se você dar um passo atrás no fundo que, assim, no fundo quando a gente faz software a gente está traduzindo, encaminhando um modelo para representar, para resolver algum problema na realidade, e esse modelo é representado por uma linguagem de programação e alguém precisa entender essa linguagem de programação para poder fazer com que seja alterável. E, no fundo, as linguagens que a gente escreve documentos mesmo em português, vamos falar assim, ou inglês, na verdade também são linguagens, só que em determinados lugares são boas para algumas coisas e muitos para outras, então a maior parte de linguagem de diagramas não compilam. A linguagem de programação é boa para representar uma parte que está executando e que é bastante volátil. Agora, a linguagem de diagrama é boa para ilustrar coisas que são bastante complexas e que você quer ter uma luz condutora. Então, no fundo, você está traduzindo um problema para um modelo que tem hora que você usa algumas linguagens que são diagramas, documentos, e tem horas que você usa linguagem de programação. No fundo, é tudo isso. Então você eximir um ou outro de forma meio cega, aí, na verdade, você está usando a ferramenta errada para descrever a coisa de um jeito que a outra representaria melhor.M1: Sim, ótimo insight. Já que nós estamos em software e funcionamento, eu acho interessante falar sobre ele, por quê? Eu acho um princípio poderoso, duradouro. Porque, na verdade, o que o cara está falando aqui, na minha interpretação, é assim: não perca o contato com a realidade, não perca de vista aquilo que você está fazendo; é um software que funciona e que gera valor. Porque esse negócio é engraçado, como eu acabei de falar. Eu fiquei tão vidrado quando eu tentei fazer um waterfall, claro, uma interpretação bem exagerada – defensores do waterfall vão falar: “Você exagerou ali”; eu fiquei tão vidrado ali que, na verdade, era muito mais importante fazer todas as fases e transições e tudo e o software saía ali, sabe? O software era quase que um subproduto do meu processo, e não o negócio que você está fazendo. E hoje, Vinícius, eu acho que a gente pode falar sobre isso, esse software em funcionamento é mais do que um software em funcionamento; é progresso completo, é geração de valor, é OKRs a serem mandados. Fala um pouquinho sobre isso.Vinição: É, exatamente. Até complementar com isso, porque na DTI a gente tem muito isso, talvez seja o princípio que a gente mais siga de todos. Tinha até uma frase, tem no escritório, fala que tem por que a gente não está lá mais, mas fala que o que importa é um processo concreto, porque, até você já me falou muitas vezes isso, eu conversei com você lá na (APAN)? [00:13:59] em especial, aprendi muita coisa lá com as lições, então uma coisa que eu vi você falando muito, por exemplo, que hoje em dia eu concordo plenamente, é que a questão do software estar rodando é um fator de convergência. Então por mais que você tenha ali muita coisa para poder domar durante um projeto de software, para o software ter que estar funcionando ele gera um valor brutal de convergência, e além disso, como você diz, mesmo o software funcionando, ainda não é um fator de sucesso total. O fator de sucesso total é realmente você estar mexendo em algum OKR, estar alguém usando, estar alguém provando, não importa esse negócio de valor que tinha por trás daquilo ali. Então isso hoje em dia virou realmente uma obsessão para a gente lá na DTI e a gente vê que toda vez que a gente começa, a gente até brinca, usa esse termo, toda vez que a gente começa a estocar software, coisas ruins começam a acontecer.M1: Exatamente. Eu fico brincando, não precisa de data sites para poder saber que existe essa correlação gigante entre estoque e problema. Eu acho engraçado, se tem uma coisa que eu aprendi na minha vida, comecei a desenvolver software em 95, é que piscou o olho, está divergido, é uma coisa impressionado. Essa força de convergência é muito importante, é muito, muito importante mesmo. Esse princípio é duradouro, e eu acho legal isso. Idealmente, você tem um time com competências tais que ele consegue medir o sucesso por valor gerado mesmo. Idealmente. Mas se você não consegue isso, já é um caminho muito bom você pelo menos estar colocando um software que funcione em produção, com uma transição para essa geração de valor, porque pelo menos aquilo que você tem que fazer, aquilo que você consegue fazer naquele momento você está fazendo, você não está se iludindo.Vinição: Tem um autor, o Kaigan, ele fala em um dos livros dele que tem um aspecto, que a gente fala muito, quase que da natureza humana. Por mais que você seja o cara mais responsável do mundo, se uma coisa que você entregar daqui um ano, você não consegue ter o mesmo senso de urgência se você imaginar que aquele negócio vai ser entregue daqui uma semana, vai ter uma série de pessoas usando, aquele negócio pode gerar problemas, então isso é um fator de convergência muito forte. Isso aí eu defendo. Se você (inint) [00:16:17] qualquer desenvolver maduro, designer, o time maduro, basta você fazer isso. Eu lembro uma vez que eu fui em uma palestra e tinha uma pessoa do Nubank, estava discutindo lá sobre a questão (texter)? [00:16:28], se tem, precisa ter ou não ter, eu ficava assim: “Se você coloca um time entregando o tempo todo, o time fica quase que organicamente responsável, não tem como não ficar responsável se você sabe que o que você está entregando ali o tempo está gerando um impacto positivo ou negativo para várias pessoas”. É uma fábrica de maturidade, vamos falar assim.M1: Bem isso. É interessante, eu falo sempre que nas conversas aqui eu acho ótimo, porque a gente tem um insights. Eu pensei em um negócio aqui que eu achei legal que é assim: a gente sabe que existe sistema de recompensa que libera dopamina. A gente, eu e o Vinícius, nós adoramos trazer os exemplos biológicos. A gente faz uma coisa, o nosso organismo nos compele a repetir uma coisa que deu certo porque libera a dopamina e a dopamina é uma sensação boa. E o perfil de um cara que tenha dopamina entregando coisas em curto prazo é dopamina entregando documento. Os caras têm que tentar criar um sistema de recompensa no sentido certo. Além dessa pressão, é muito mais gratificante, você ter um hush de dopamina quando você bota um negócio no ar e você vê que está dando certo, do que um hush de dopamina quando você terminou dez diagramas. Como a gente falou, o diagrama é importante para ajudar o time a entender mais fácil, etc, mas o diagrama não é o fim.Vinição: Devem ter uns perfis que gostam disso, de repente uns advogados aí.M1: É, os advogados. Conheço gente próxima que ia gostar disso. Outro princípio aqui, que eu acho que todos aqui, quando eu leio de novo, são muito duradouros. Até voltando aqui para o primeiro, eles não têm uma ordem aqui de importância, mas os indivíduos e interações mais do que processos e ferramentas. Isso aí eu acho que muitas vezes eu falo que para mim isso é a essência do agilismo e é a essência de uma filosofia de gestão, de essencialmente acreditas nas pessoas, e muito mais usar as demais coisas, que seriam aí os processos e ferramentas, que estariam talvez representando o ambiente, como habilitadores. Mas habilitadores, acima de tudo as pessoas. É como se o manifesto falasse para você não tirar o olho do que que é importante. Você está fazendo aquilo tudo para habilitar indivíduos a interagirem e fazerem grandes coisas. O que que você diz sobre isso, Vinição?Vinição: No fundo, se você for analisar isso aí, até refletindo aqui, já tinha refletido sobre isso antes, no fundo ele está representando além das pessoas a própria coisa das interações; isso é muito pouco compreendido quando você fala de complexidade. Às vezes a análise muitas vezes reducionista que a gente fala muito despreza um pouco essas interações, então quando a gente fala um pouco de ambiente, vai até além do que processos e ferramentas. Tem uma série de coisas que estão embutidas nisso aí, incentivos. Se você coloca OKRs, isso se reflete de outra forma, então eu acredito que quando o pessoal, toda vez que eu leio sobre agilismo, acho que no fundo alguém se inspirou sem saber em como se fosse a teoria da complexidade. Eu acho que o pessoal não compreendia muito bem ainda o que é algo relativamente novo. Além dessa valorização das pessoas, que você fala muito, vou usar essa expressão que hoje em dia é bem popular, do people positive, ainda você pensa nas pessoas, é um entendimento maior sobre como que um ambiente na verdade provoca uma série de interações entre as pessoas, e as interações são coisas que são muito difíceis de explicar. Tanto é que quando você tem um número grande de elementos no sistema, no caso pessoas, o número de conexões normalmente começa a ficar fatorial, exponencial. Não é tão fácil entender normalmente quando você tem tendência, você faz uma técnica reducionista; você não consegue entender muito bem aquele negócio ali. E aí todo aquele raciocínio que a gente fez é claro que vale aqui também para processos e ferramentas. A gente sabe que é muito importante na DTi, só que um importante muito mais nessa questão que a gente falou do Uml do Martin Fawler, de saber usar bem, de você ter ali o arsenal, como a gente fala na DTI, saber quando usar bem o arsenal ao invés de ficar prescrevendo qualquer tipo de utilização daquele arsenal. E, além disso, tem aquele raciocínio que um cara que explica, eu acho um sujeito legal, é David Snowden, quando ele fala naquele esquema de enabling constraints. Então normalmente a maior parte dos processos funcionam melhor quando você tem um ambiente complexo quando eles são muito mais uma restrição habilitadora do que uma prescrição de tudo o que tem, de um volume muito grande de regras. Então você ter um método de, por exemplo, tipo (inint) [00:21:09], que tem pouquíssimas regras, ou (incanban)? [00:21:11], isso muitas vezes já é suficiente; é um conjunto pequeno de regras, alguns falam também de light weight frameworks, que eu acho que é um conceito bem aplicado aí desse esquema de enabling constraints, na verdade faz com que você deixe os indivíduos e essas interações dos indivíduos, os times, terem um nível de autonomia bacana, mas algumas restrições que habilitam o trabalho, entendem?M1: Muito bom tudo isso que você colocou, isso aqui dá uma aula de complexidade. Esse sentimento que você tem, eu acho que quem estuda complexidade, que a gente adora o tema, você fica com uma sensação se é uma ciência que se desenvolve mais próxima do mundo real, mais próxima de onde as coisas acontecem, e que ver que é difícil explicar tudo simplesmente com leis gerais. Muitos livros de complexidade inclusive fazem uma introdução dessa, fazendo o contraste entre, sei lá, uma física clássica, que tenta criar  leis universais, e uma física mais estocástica, lei de Bowler, sabe? Aquelas coisas que acontecem mais ali e que geram comportamento emergente. Eu acho perfeitas as suas colocações. Alguém olha para um grande time e alguém quer ter a pretensão de explicar porque ele tem um processo e uma ferramenta que ele segue. Então, beleza, basta você ter vários times repetindo aquele processo, aquela ferramenta, e na verdade o grande time, que é um comportamento emergente daquele time, daquele grande time, é fruto dessas interações que existem dessa rede que é criada ali.Vinição: E essa é a grande crítica que tem emergido na comunidade em relação, que começa a ter, que é o jeito mais fácil de replicar, receitas de bolo de frames, de processos, e aí começa, tem os posts de zoar, e tem as piadinhas aí. Só fazendo um fechamento aqui, o que a gente falou nesse link por exemplo do agilismo com a teoria da complexidade, alguns autores que escreveram um pouco depois, tipo aquele, não sei se está certo assim, o Jurgen Appelo, que escreveu aquele livro, Management 3.0, é legal que ele já está mais claro acho que na cabeça de muita gente, então ele já fez toda uma introdução quase que de teoria da complexidade. É interessante que fica um pouco até divergente do jeito que o David Snowden explica, mas tem muita sobreposição também, mas ele já deu uma clareza completa de como que uma coisa meio que tem origem na outra, sabe?M1: Dá para explorar tanto essas coisas, não é, Vinícius? Você me falando isso, a gente tem até que avançar para o próximo, mas você falando isso. É engraçado, sabe por quê? Parte do fenômeno de talvez dar muito mais importância para o lado direito, os processos e ferramentas, e não entender que o lado esquerdo é mais importante, é a forma como o líder tradicional se enxerga, sabe? É uma coisa que a gente comenta muito, porque o cara tem que ter um poder de gestão de controle ali que é muito mais fácil ele pensar que para ter esse poder do outro lado lá do que pensar que de forma meio…Vinição: Mais tangível.M1: É, e pensar que quer dizer então que de forma meio invisível e que não influenciam acontecem milhares de interações e isso faz os caras, aquele time ser foda? Aí você fala: cara, a resposta é isso mesmo, é exatamente. Não você ali com o seu processo, com a sua ferramenta, não. São os caras interagindo. Isso é muito interessante, porque isso é mais um exemplo de que o líder tem que mudar a perspectiva dele, se enxergar muito mais como um habilitador dessas interações desse ambiente. Outro princípio aqui, que é interessante, isso foi 20 anos atrás, a gente até perde um pouco o sentido, porque já ficou tão óbvio, que é a colaboração ao invés de negociação de contratos. Hoje a TI já se estende tanto, já fica tanto evasivo que isso, dentro da empresa, tinha ainda a relação contratual entre a TI e os setores, e isso tudo hoje está mudando; você tem estruturas organizacionais mais horizontais e voltadas para o fluxo de valor, e todo mundo junto no mesmo barco. É tipo a máxima expressão desse princípio, concorda?Vinição: Eu concordo plenamente, e eu acho que isso tem muito link com o que a gente acabou falou. Não vou ficar me repetindo demais, mas eu enxergo muito isso na questão do contrato, dessa negociação ou contrato com o cliente, podendo ser um cliente interno ou externo, sendo muito mais ali um conjunto básico de regras que você vai usar em casos extremos só para criar restrições do que que seria o acordo. Se você tiver um contrato que tenha um trilhão de regras, na verdade é uma restrição não habilitadora ao invés de ser uma restrição habilitadora. O contrato deveria reger determinadas medidas que você deveria seguir, mas no dia a dia não tem como colocar contratualmente falando ali. A gente até brinca às vezes: será que no futuro vai ter um blockchain que você consegue escrever o contrato todo complicado? Eu duvido, porque aquilo ali, você está refletindo, a não ser que fosse só interação de máquina. Enquanto você tiver ser humano, um ambiente completo, é impossível refletir tudo. Então isso, na verdade, reflete exatamente isso que eu estou falando. No fundo é assim, boa parte dos programas você vai ter que resolver com confiança entre as pessoas, desenvolver relacionamento, negociar coisas, saber lidar com ambiguidade, ter lido e sabe lidar com ambiguidade, e aquilo ali tudo sendo pautado por um conjunto básico de regras que aí pode até ser um contrato, entende?M1: E o último aqui é a própria essência do agilismo, que é o responder a mudanças mais do que seguir um plano. Sabe o que eu acho interessante? Eu costumo falar isso para algumas pessoas que não conhecem exatamente a história. Eu fico brincando que é como se o mundo (voca)? [00:26:46] ou o mundo (bane)? [00:26:47] sempre tivessem existido para quem tentou fazer software, sabe? O cara mesmo lá há 20, 30 anos atrás, e, para mim, o que esses caras perceberam há 20, 30 anos atrás, os caras viram que eles não conseguiam descobrir o que que tinha que ser feito, se mesmo não conseguiam descobrir pelos métodos tradicionais, porque o processo era um processo era um processo de aprendizado, ninguém sabia na verdade, a questão era essa. E o pessoal percebeu: “Poxa, se eu não consegui descobrir o que tem que ser feito, eu tenho que me adaptar muito mais do que seguir um plano”. É curioso, porque o mundo foi, na medida em que as forças digitais foram fazendo o mundo ficar muito instável e os próprios negócios e organizações começaram a ficar com essa mesma percepção de não saber o que fazer, esse princípio de responder a mudanças começou a ficar dominante em um âmbito maior. Só que isso que eu acho curioso, Vinição, para a gente poder ir fechando aqui, mas comentar esse princípio também. Apesar de ser claríssimo, me parece ainda um desafio gigante, porque ainda todo mundo fala, fala, fala, mas precisa de um plano; todo mundo fala, fala, fala, mas acha que está errando se não conseguir saber exatamente o que vai fazer, sabe? Fala do (inint) [00:27:54] etc, mas, você concorda? Me deu um negócio: o mundo está obrigado as empresas a entenderem que tem que responder mais à mudança do que seguir um plano, mas está tão encrustado na nossa cabeça de alguma forma que não ter um plano que é errado, não ter um plano é pecado, parece que é um negócio difícil de mudar ainda. Você acha que tem sentido o que eu estou falando, ou não, o pessoal já está mais avançado nisso?Vinição: Acho que tem total sentido. Só dando um passo atrás, eu vou correr o risco de errar aqui a citação, mas eu acho que é no início do livro do Jeff Sutherland, daquele do Fazendo o Dobro na Metade do Tempo, se não me engano, tem aquela citação famosa lá, eu acho que é de um general americano, que os planos caem por terra no primeiro tiro quando você está em uma guerra, em uma batalha, em alguma coisa do tipo.M1: No primeiro contato com o inimigo.Vinição: É o entendimento do ambiente em que você está. Na guerra é bem óbvio que isso é uma mera ilusão. Talvez isso aí que você falou, isso a gente até conversou outras vezes, talvez seja uma grande influência da revolução industrial, dessa obsessão por otimização ou por criar um ambiente totalmente ordenado e otimizado e que não vai mudar tanto, então isso talvez tenha ficado aí quase que um século, ou até mais de um século, incrustrado nas mentes, nos livros, nas literaturas todas, então realmente é um ato de humildade reconhecer que toda essa volatilidade existe em vários ambientes. Eu acredito que a influência vem muito disso.M1: Muito bom. Infelizmente estamos chegando ao final aqui. Para mim, fica uma coisa que é o que você falou antes, que é a crítica que existe às vezes na comunidade que está usando só ferramenta. A verdade é que o que tem que ser bem compreendido são os princípios. Você pode ir lá atrás do ferramental, dos frameworks e tudo, é importante para te acelerar, para te ajudar a criar os enabled constraints, etc, mas a compreensão mais importante é a desses princípios, porque eles é que vão te permitir realmente achar o tom correto para a sua organização, para a sua história e seguir o caminho que você quer trilhar. E veja que são princípios poderosos e duradouros mesmo. Achei muito legal esse episódio, a gente relembrar do manifesto. Espero que tenha sido bom aí para vocês ouvintes, que tenha trazido alguns insights. Abração, Vinição.Vinição: Até mais, abraço, pessoal.