Mas aí, veio a merdificação.

Métricas, sempre elas

O Substack é uma plataforma onde alguns autores liberam seus textos sem cobrar nada por isso, enquanto outros cobram um certo valor para textos mais importantes. Daí, o que passa a ser relevante para quem escreve?

• Número de views
• Número de menções
• Número de assinantes
• Número de assinantes pagos

E até aí tudo bem, tudo normal. Tem muito conteúdo bom por lá que vale o dinheiro cobrado, e muitas pessoas competentes o bastante para conseguirem viver desse modelo.

O problema não são todos os autores, mas sim o que a plataforma faz para tentar tornar essas métricas atraentes o suficiente para manter os autores ali e atrair novos escritores. Com o tempo, o substack adicionou:

• Uma espécie de Twitter
• Popups pedindo para o leitor assinar a newsletter o tempo todo
• Opção padrão de assinar TODOS os substacks que um autor recomenda ao assinar a sua newsletter

Ler um post no substack se tornou um exercício de paciência e eu comecei a ficar chateado de fazer quem dedica um pouco do seu tempo para ler o que eu escrevi passar por isso. Aí minha vontade de escrever ali foi diminuindo.

Onde eu tracei a linha

Como se nada disso bastasse, as métricas fizeram com que newsletter completamente desprezíveis se tornassem interessantes para o negócio porque geram renda para a empresa.

E isso inclui newsletters nazistas.

Aí sair do substack deixou de ser uma opção e passou a ser uma necessidade para mim.

Pra onde eu fui e pra onde você pode ir?

Se enviar newsletters é super importante para você, o Ghost é a melhor opção. É open-source, fácil de configurar e é bem leve. Muitas pessoas têm feito esta transição, e em termos de funcionalidades é quem mais se assemelha ao substack.

Se você quer só escrever e imagens não são muito importantes para você, dá pra usar o WriteFreely. Como foi feito em Go, é bastante leve (no teste que fiz no meu servidor ele consumia apenas cerca de 50Mb de memoria RAM!). A experiência de escrever é agradável e direto ao ponto. Curiosamente, o WriteFreely foi desenvolvido como alternativa ao Medium porque seu fundador se cansou da merdificação do Medium.

Se você quiser algo gratuito, com alto nível de personalização e tendo total propriedade sobre os eu conteúdo, o melhor a se fazer é usar um gerador de blogs estáticos como o Jekyll, o Hugo ou o Astro. Esse blog foi feito com o Jekyll, que é feito em Ruby e foi criado a mais tempo, e acabei seguindo por esse caminho porque eu já tinha adquirido um tema que se encaixava com o que eu tinha imaginado para meu site. O Hugo é uma opção mais moderna, e provavelmente a melhor escolha aqui, principalmente se você pretende escrever em mais de um idioma.

Outra vantagem dos geradores de sites estáticos é que você pode hospedá-los gratuitamente no Github pages, por exemplo. Nem precisa pagar um servidor.

Se você quer algo para ler, sugiro fortemente usar um RSS Reader, que nada mais é do que um aplicativo onde você adiciona os blogs que gosta de ler e ele te avisa sobre novos posts sem poluir a sua caixa de email. O RSS é ainda uma forma de leitura mais consciente: você precisa escolher aquilo que quer ler e acompanhar, e nenhum algoritmo tenta te empurrar nenhuma outra coisa.

Atualmente, os softwares/serviços que uso são:

• Scaleway, para hospedar meu site.
• Typora, para escrever os posts.
• Plausible, self-hosted. Para coletar métricas respeitando a sua privacidade (nada de Google Analytics aqui).
• Procreate, para criar as imagens que uso no blog
• Vivaldi, navegador que também tem um RSS reader

Mas… e a newsletter?

Bom, por enquanto ela não existe, mas pode ser que no futuro eu crie uma. Agradeço de coração a todo mundo que assinou a newsletter no substack, e espero que vocês sigam acompanhando o que eu escrever por aqui.

Não queria escrever nada superficial sobre isso, então tentei ler cuidadosamente, com baixas expectativas, e fiz algumas anotações ao longo do caminho.

Não é perfeito…

Scrum é um framework e portanto é incompleto por natureza. Ele nos dá a tarefa de completá-lo com práticas, técnicas e ferramentas, e essa é a melhor parte do Framework Scrum na minha opinião.

Quando ouvi pela primeira vez sobre o pacote de expansão, temi que ele preencheria as lacunas e tornaria a coisa toda mais prescritiva, e acho que a maioria das pessoas compartilhou o mesmo sentimento. Os autores conseguiram evitar esse problema muito bem, porém, havia outros problemas que encontrei.

Não é um pacote de expansão

Ao invés de apenas adicionar novas informações, os autores também mudaram alguns conceitos originais (ex: revertendo para o uso da palavra roles ao invés de accountabilities).

Também diz que o Product Backlog Refinement pode ser um evento, o que realmente não aprecio já que na minha experiência esse tipo de linguagem fomenta um comportamento mecânico.

Não é um único documento. Como os autores afirmam logo no início:

“Este documento é uma coleção de trabalhos independentes. Cada seção mantém sua licença original ou status de copyright, conforme indicado.”

Então a leitura é uma estrada cheia de lombadas, e às vezes repetitiva.

Fora isso, eu diria que é praticamente inofensivo.

Na verdade pode ajudar quem está tendo dificuldades com Scrum

Venho ensinando desenvolvimento de software e Scrum desde 2013, e ouso dizer que uma boa parte das perguntas que as pessoas me fazem durante sessões de treinamento podem ser respondidas pelo pacote de expansão.

E na maioria das vezes o SGEP conseguiu fazer isso expandindo o PORQUÊ das coisas, com um enorme foco em empirismo.

Mais palavras facilitam o entendimento

Deixe-me dar um exemplo concreto: a Sprint Review. O Scrum Guide original é um tanto quanto críptico quando diz:

O propósito da Sprint Review é inspecionar o resultado da Sprint e determinar futuras adaptações

Scrum Guide, 2020

Também diz que O Product Backlog também pode ser ajustado para atender novas oportunidades.

Nas minhas aulas frequentemente levo algum tempo para discutir isso: precisamos determinar futuras adaptações, o que significa mudar o Product Backlog de alguma forma. Portanto, uma Sprint Review que não muda o Product Backlog é algo que deveria causar alguma reflexão. Além disso, se a Sprint Review é um evento obrigatório, significa que o Scrum Team não está passivamente aberto a mudar o Product Backlog: eles estão ativamente buscando essas mudanças.

O SGEP usa mais palavras para descrever isso:

“O Product Backlog (o quê) É adaptado” - Não “também pode ser ajustado”, mas um forte “É.”

Esse é o tipo de diferença que importa para mim. Reforçando que Scrum é sobre aprender através de experimentação para que possamos usar informação fresca para desenvolver coisas.

Foco em Empirismo

O principal problema que a maioria das pessoas tem com Scrum, às vezes sem nem perceber, é que usam o framework acreditando que vai aumentar a velocidade de desenvolvimento. Isso frequentemente coloca Product Owner e Developers em confronto ao invés de colaboração. Esse problema é tão comum que a última atualização do Scrum Guide mudou o termo “Development Team” para “Developers”, e a explicação de por que fizeram isso foi:

O objetivo era eliminar o conceito de um time separado dentro de um time que levou ao comportamento de “proxy” ou “nós e eles” entre o PO e Dev Team.

Agora existe apenas um Scrum Team focado no mesmo objetivo, com três diferentes conjuntos de responsabilidades: PO, SM e Developers.

- Scrum Guide 2020 Revisions

Não me entenda mal: eu gosto dessa mudança. Mas para iniciantes ou mesmo pessoas que têm usado o Framework Scrum de forma disfuncional por muito tempo, isso não vai resolver nenhum problema. Quer dizer, nem o SGEP resolve, mas pelo menos acho que fez um trabalho melhor tentando alcançar isso.

Por exemplo, o SGEP:

• Afirma claramente que ser uma feature-factory ou uma discovery factory não é desejável

• Estabelece que o Product Owner precisa comunicar efetivamente os resultados

• O Produto se torna um artefato com métricas baseadas em resultados

O SGEP também cria a Definition of Outcome Done, e tenho sentimentos mistos sobre isso. Por um lado adiciona mais uma peça ao quebra-cabeça e torna o framework Scrum mais prescritivo, mas por outro lado pode ser especialmente importante para aqueles começando ou tendo dificuldades com Scrum.

Falando nisso, o SGEP também fornece alguns insights valiosos para aqueles começando ou tendo dificuldades com seu trabalho como Scrum Masters.

Fornece melhores direções para Scrum Masters

O Scrum Guide original descreve o Scrum Master em meia página. E se você tem uma boa dose de experiência com o framework, isso é mais que suficiente.

O SGEP, porém, entra mais nos detalhes específicos, mas sem limitar muito do seu trabalho. Afirma, por exemplo, que o Sprint Backlog deve ter trabalho suficiente para começar, ex: comece com um ou dois Product Backlog Items em direção ao Sprint Goal. E você pode ler essa frase como: “não existe Definition of Ready”.

Outro exemplo é o Product Backlog: enquanto o guia original afirma que o Scrum Master deve encontrar técnicas para definição efetiva do Product Goal e gerenciamento do Product Backlog, o SGEP adiciona algumas informações valiosas em cima disso, como: Um Product Backlog menor frequentemente fornece mais Transparência ou até a sugestão de usar um Outcome Criteria para Product Backlog Items.

Mais uma vez, sei que essas são notícias velhas para alguns. No entanto, torna óbvio algumas das coisas que as pessoas frequentemente têm dificuldade em aprender.

Então, é valioso?

Pode ser. Mas não para todo mundo. Mas ler é um bom exercício de qualquer forma, então vá em frente. O foco em empirismo é o que me fez gostar, e é um pacote de expansão, o que significa… é opcional de qualquer forma. Você também pode pegar algumas das ideias e aplicá-las se não quiser adicionar tudo.

Então, se você está indo bem com Scrum, não precisa. Afinal, você provavelmente já está fazendo a maioria das coisas descritas lá.

Se você sente que o Scrum Guide é críptico e te deixa com a sensação de que deveria elaborar um pouco mais em alguns aspectos porque você está travado, então o Scrum Guide Expansion Pack pode ser uma boa coisa para você.

Agora, vamos voltar às nossas armadilhas e também falar sobre uma “guerra” que está acontecendo pelos últimos 40 anos: a Guerra dos Editores. Pode parecer uma guerra boba, ou uma simples questão de preferências, mas confie em mim: não é apenas tribalismo geek, é sobre filosofias fundamentalmente diferentes de interação humano-computador.

Eu sou um usuário de NeoVim. Isso significa que sou um daqueles geeks que prefere digitar código no terminal ao invés de usar algo mais moderno como VSCode. Enquanto uso NeoVim eu nunca uso meu mouse ou touchpad: apenas digito coisas e uso um monte de combinações de teclas para navegar pelo código. Mas não estou sozinho! O primeiro editor Vi foi criado em 1976 e desde então sua popularidade só cresceu entre os mais geeks dos desenvolvedores de software.

Por quê? Bem, vamos explicar isso enquanto falamos sobre uma das armadilhas que mencionei em Munique:

Armadilha 4: A Visão de Túnel na Codificação

Vi e seus irmãos (Vim, Neovim) se tornaram populares porque permitiam que desenvolvedores navegassem pelo código mais rápido. Ao invés de mover sua mão para o mouse, rolar para baixo, selecionar uma parte do código que você quer mudar e então digitar a mudança, esses editores propuseram uma ideia diferente: eles teriam modos. Enquanto no modo INSERT, tudo que você digita no teclado apareceria na tela, assim como acontece em qualquer outro editor. Mas no modo NORMAL, cada tecla no seu teclado pode ser usada para navegar pelo código.

Por exemplo: se você pressionar 3wce você instantaneamente mudaria o conteúdo da terceira palavra naquela linha. (Algo como: Vá para a 3ª Word Change até seu End).

Basicamente cria um dialeto para que você possa dizer ao seu editor onde você quer ir e o que quer fazer com seu código sem precisar usar mouse, menus, etc. E acelerar como navegamos pelo código é importante porque desenvolvedores de software gastam mais tempo navegando e entendendo o código do que escrevendo.

Um gráfico representando os resultados de uma pesquisa sobre como desenvolvedores gastam seu tempo

Então, por que estamos focando em usar LLMs para gerar código quando também podemos usá-los para nos ajudar a entender o código? Quer dizer, eles são ótimos programadores, não estou negando isso. Mas na minha experiência eles podem fornecer muito mais valor explicando o código ao invés de apenas criá-lo.

Aqui está um exemplo prático de como fiz isso: estou atualmente escrevendo um software para melhorar as atividades práticas que realizo nas minhas aulas. E em algum momento decidi pedir ao Claude para explicar minha própria arquitetura para mim. Como o Claude se destaca em output de texto, achei que seria legal usar uma ferramenta como Mermaid, uma ferramenta que transforma inputs de texto em diagramas elegantes. Pedi ao Claude para explicar a estrutura usando MarkDown e Mermaid, e colei o resultado em um editor de texto compatível com ambas as tecnologias chamado Typora. Aqui está o resultado:

Essa é uma ótima documentação que pode ser usada para explicar tanto aos desenvolvedores do meu time quanto ao próprio LLM como a arquitetura funciona! Especialmente porque o diagrama pode ser lido pelo LLM como um simples input de texto, minimizando a quantidade de tokens consumidos em cada interação.

A questão é que, não importa se você escreveu o código manualmente ou se um LLM escreveu a coisa toda para você, você ainda será responsável pelas consequências. Portanto, entender o que está acontecendo é fundamentalmente importante.

Lembre-se: se algo funciona e você não sabe como, quando parar de funcionar você não saberá o porquê.

Armadilha 5: O Viés de Volume

Algumas pessoas ainda estão reclamando da qualidade do código gerado por LLMs e discordo fortemente dessa opinião. Na minha experiência, o código gerado é na verdade muito bom.

O que me incomoda é a quantidade de código.

Especialmente porque não acredito em “vibe coding” (isto é: confiar no código gerado e nem dar uma olhada nele). Preciso revisar o código e garantir que está fazendo o que deveria fazer porque… sou um adulto responsável? Então, quando o LLM muda 8 arquivos e adiciona 200 linhas de código para cada prompt que faço, meu trabalho se torna extremamente doloroso e bem, sem graça. Tentei múltiplas abordagens e diferentes prompts para reduzir esse problema mas ainda não encontrei uma solução.

Para ser justo, o Claude 4.0 apresentou uma grande melhoria quando se trata dessa armadilha específica, e acho que teremos uma solução definitiva para isso num futuro próximo. Mas ainda não chegamos lá.

Um prompt, MUITAS mudanças

O que sinto é que ao invés de nos ajudar a andar mais rápido, os LLMs estão nos ajudando a dar passos maiores. Ambas as abordagens podem nos ajudar a cobrir uma distância maior na mesma quantidade de tempo, mas a segunda também vem com um alto custo quando você está andando na direção errada. O modelo de negócio também contribui para isso: quando uso o Cursor, por exemplo, tenho tokens/interações limitados, o que me incentiva a tirar o máximo de cada prompt.

Conclusão

Escrever sobre trabalhar com LLMs é uma coisa estranha. Eu sinceramente acredito em tudo que escrevi neste post hoje. Mas as coisas estão mudando rápido, e este post pode envelhecer como leite ou vinho dependendo dos próximos desenvolvimentos. Se você valoriza aprender mais sobre esse tópico, sugiro fortemente que faça duas coisas: use para criar algo ao invés de apenas ler sobre isso no LinkedIn (melhor ainda: se afaste do LinkedIn de uma vez), e tente ler diferentes opiniões sobre o assunto. O livro de Karen Hao “The Empire of AI” pode ser um bom começo.

A coisa engraçada nessa conferência é que fui a duas palestras subsequentes que se conectaram diretamente com o que apresentei: Nigel Baker e Paul Goddard falaram sobre Pair Programming (e ainda estou decepcionado que eles não mencionaram Penn & Teller nos seus exemplos de pareamento) e o keynote final do Henrik Kniberg que falou sobre IA agêntica em software e desenvolvimento ágil de software. Então, também vou conectar insights das apresentações deles para enriquecer nossa conversa. Para fazer isso, vou mudar a ordem em que inicialmente apresentei as armadilhas.

Armadilha 1 - Fixação na Escrita

Minha primeira reclamação sobre como a maioria das pessoas tem usado IA era sobre como continuamos escrevendo e usando texto como a única forma de falar com nossos LLMs. Kniberg usou duas formas diferentes de comunicação durante sua apresentação: voz e um desenho em guardanapo. E é precisamente sobre isso que eu estava falando: a linguagem tem limitações, e essas são notícias velhas. Nietzsche notoriamente disse que Toda palavra é um preconceito e William James desafiou nossa capacidade de compreender o significado por trás das palavras com sua anedota do esquilo dando volta na árvore.

Se você quiser experimentar como isso poderia funcionar, você pode integrar o Aider com ChatGPT para usar sua voz para programar (e talvez esse possa ser meu próximo post também). Mas se você não quiser ir tão longe, desenhe, tire screenshots para usar como exemplos, basicamente: experimente.

Um diagrama mostrando como os módulos da minha aplicação devem interagir entre si

Agora, o diagrama nos leva imediatamente para a próxima armadilha…

Armadilha 2 - Atrofia para Aprender

Se uma IA pode programar, por que eu aprenderia a programar?, bem… essa é uma pergunta interessante. Na minha palestra mencionei que o código gerado pelos LLMs atuais (como Sonnet 3.7) é na verdade muito bom, e muitas vezes melhor do que o que um humano escreveria. E os LLMs estão melhorando mais rápido do que nós estamos agora, então…

Então ainda precisamos aprender. Olhe o diagrama na seção anterior: ele fala sobre estrutura de software e como organizar o código. Se você não sabe programar, você não consegue criar diagramas como esses e suas opções serão limitadas. Essas limitações podem te levar a becos sem saída e problemas que você é incapaz de resolver, e se seu colega IA também é incapaz de resolver então…

O lado sombrio do vibe

Como Nigel Baker e Paul Goddard disseram na palestra deles: parear é uma ótima forma de aprender. Você provavelmente vai aprender que pessoas diferentes usam LLMs de formas diferentes, e você vai ter que descobrir quando usar cada abordagem. Por exemplo: hoje em dia você pode literalmente programar um agente que checaria tudo que sua pessoa amada postou na internet e automaticamente compraria presentes para ela em datas especiais. E provavelmente serão bons presentes!

Mas é uma boa ideia? Bem, eu não acho. Simon Wardley propõe uma pergunta interessante para resolver esse dilema, e em todo caso, se você ainda não assistiu a palestra dele por favor assista:

Quanto você valoriza um humano envolvido nessa decisão?

E às vezes, quando desenvolvemos software, isso importa. Mas novamente: suas capacidades de tomada de decisão serão limitadas pelo seu conhecimento. Então, continue aprendendo (e tente parear com outra pessoa para que você possa aprender mais e mais rápido).

Armadilha 3 - A Abordagem Monolítica

Eu fiz uma piada durante minha apresentação e disse que Vibe Coding deveria ser renomeado para Conversational Reactive Assisted Programming, ou C.R.A.P.. Todo mundo riu, e momentos depois estávamos todos assistindo Henrik Kniberg fazendo uma demonstração impressionante usando Cursor.

Então, acho que vou ter que me explicar. :)

O termo Vibe Coding foi cunhado por Andrej Karpathy, e ele disse que a técnica é “não tão ruim para projetos descartáveis de fim de semana”. Uma parte chave da definição de vibe coding é que o usuário aceita código sem entendimento completo, e o pesquisador de IA Simon Willison até disse que “Se um LLM escreveu cada linha do seu código, mas você revisou, testou e entendeu tudo, isso não é vibe coding no meu entendimento—isso é usar um LLM como um assistente de digitação.”

Então, por essa definição de Vibe Coding, eu mantenho minha piada. Pelo menos por enquanto. O conceito de não se importar com o código gerado por um LLM pode ser uma boa ideia, mas apenas se soubermos quando usá-lo, e por enquanto não deveria ser 100% do tempo a menos que você esteja construindo um protótipo.

A questão é que, se você não sabe programar, Vibe Coding será sua única opção quando usar um LLM para desenvolver software. E não é realmente programação, porque é não-determinístico: o mesmo prompt pode gerar resultados diferentes. Eu prefiro o termo que Simon Wardley usa: Vibe Wrangling.

Um slide da minha palestra: Se você tem mais conhecimento técnico, você terá mais opções

Talvez no futuro ter Vibe Coding como sua única opção não será um problema, mas ainda não chegamos lá. Pode acontecer ano que vem, em 2035, ou pode nunca acontecer. Mas não importa a resposta, aprender a programar ainda é relevante porque vai expandir suas opções. E essa é minha principal (e talvez única) crítica sobre a ótima sessão de keynote do Kniberg: eu não acho que Vibe Coding é uma evolução de copiar e colar código gerado por um LLM, por exemplo. Eu vejo todas essas abordagens sendo usadas em contextos diferentes, e a decisão sempre vai se resumir a uma versão levemente modificada da pergunta proposta por Simon Wardley:

Quão consciente eu preciso estar sobre a forma como isso vai ser implementado?

Para mim a resposta ainda é “com bastante frequência”. LLMs são enviesados, não-determinísticos e replicam todos os problemas que estavam presentes em seus dados de treinamento. Eles vão cometer erros, e alguns desses erros podem prejudicar pessoas, especialmente em grupos que são sub-representados nos dados usados para treinar os modelos (você pode e deve conferir o trabalho da Dra. Timnit Gebru). Quando aceitamos código gerado por IA sem entendimento completo, estamos herdando não apenas a solução, mas também os preconceitos conceituais embutidos nela.

Então, responder essa pergunta é algo que vamos começar a fazer cada vez mais. E voltando à sessão de Nigel Baker e Paul Goddard: você não precisa responder essa pergunta sozinho.

Estou constantemente ensinando e fazendo coaching com pessoas sobre como desenvolver produtos melhores, seja em aulas de CSM/CSD, como consultor ou como mentor. Eu tenho minha cota de histórias para compartilhar durante esses eventos, mas sabe como é… embora essas histórias sejam novas e empolgantes para os estudantes, não posso dizer o mesmo depois de repeti-las uma dúzia de vezes.

E além disso… preciso de uma desculpa para colocar a mão no código. :)

O Produto

Como instrutor, tento criar simulações para que meus estudantes possam aprender pela própria experiência na maior parte do tempo. É por isso que em 2019 criei o jogo de cartas Scrumchkin, por exemplo. Mas desde a pandemia, a maioria das minhas sessões de treinamento tem sido online, o que torna muito difícil replicar o mesmo ambiente dinâmico que eu tinha com as cartas reais do Scrumchkin em um treinamento presencial.

Então, decidi que meu produto tentaria resolver esse problema:

Os estudantes devem ser capazes de aprender assuntos complexos através de experiência dinâmica e simulações.

Era um fit perfeito, afinal: tenho aulas periódicas onde posso levar o produto para um teste de campo e coletar feedback, e tenho acesso a uma comunidade de instrutores que poderiam estar interessados em experimentar o produto e fornecer um tipo diferente de feedback.

Como tudo que eu precisava era uma desculpa para começar a escrever código, fiquei satisfeito com isso.

Decisão: Escolha uma biblioteca de componentes UI desde o início e continue com ela. Você pode mudar tudo depois, se necessário.

Decisões de Ferramentas

Decidi evitar usar um banco de dados no início, até descobrir que tipo de dados quero armazenar e como quero armazená-los.

Elixir (minha linguagem preferida) tem algo que faz o trabalho muito bem: GenServers. Posso usá-los para armazenar dados temporariamente sem precisar recorrer a um banco de dados. A informação estará lá até que uma de três coisas aconteça:

• Eu reinicie o servidor

• Um erro ocorra e o GenServer seja reiniciado

• Eu termine o GenServer

Essa abordagem me permitiu mover mais rápido e esquecer migrações, por exemplo.

Mas, mas… Mario! Não é arriscado?

Risco depende do contexto. Minhas sessões de treinamento são curtas, e no pior cenário eu perderia cerca de 15 minutos de tempo e os estudantes teriam que reiniciar um exercício se um GenServer falhar durante o treinamento.

Então, é um risco que estou conscientemente disposto a assumir.

Falando em falhas…

Não posso dizer que estou fazendo TDD puro, mas estou escrevendo muitos testes. Especialmente porque estou usando Claude para gerar alguns pedaços de código para mim (vou escrever depois sobre quais pedaços de código o Claude está escrevendo para mim).

É muito difícil usar TDD com um LLM. Esses modelos geram pedaços enormes de código de uma vez. Enquanto isso, TDD é todo sobre aquele ritmo incremental: um teste, faz passar, e depois ataca o próximo. O que estou fazendo é escrever testes para meus GenServers, pedir ao Claude para sugerir testes extras que eu possa ter esquecido e então pedir ao Claude para implementar as funções que fariam os testes passar.

Aprendi que testes agora são muito mais importantes do que eram antes da IA. Quando um LLM faz dezenas de mudanças no seu código, é impossível para você garantir que seu código ainda faz o que deveria fazer. E o Claude quebrou meus testes mais vezes do que eu consigo contar, especialmente quando tentou modificar muitos arquivos de uma vez.

Decisão: Usar IA como copiloto aumenta a necessidade de testes automatizados. E a IA também pode te ajudar a escrever seus testes.

Decisões de Design

Adquiri o tailwindui há muito tempo e gosto de usar seus blocos de construção para criar minhas aplicações. Posso usá-lo para deixar meu produto bonito sem gastar muito tempo refinando demais meu design.

Claro, sendo um não-designer eu também tenho dificuldades com o layout geral. Mesmo tendo blocos bonitos para trabalhar, ainda sou bem capaz de bagunçar tudo quando os junto. Então, às vezes uso Lovable para entender melhores formas de visualizar como os componentes poderiam ficar juntos.

Decisão: Tente adiar ter um banco de dados. Pense em diferentes formas de fazer isso para que você possa aprender mais sobre seus dados antes de se comprometer com uma estrutura de modelo.

Mecanismo de Autenticação

Quando estou em uma sessão de treinamento, não quero que meus estudantes criem contas e lembrem senhas para uma experiência que vai durar 2 ou 3 dias. Também não quero gastar tempo mexendo com um mecanismo de autenticação.

Agora, sei que alguns de vocês estão pensando: “Ei Mario, é 2025! Você pode configurar um mecanismo de autenticação em alguns minutos”. Talvez sim, talvez não. Mas tenho certeza de que ter um mecanismo completo de autenticação instantaneamente adicionaria pelo menos um pouco de complexidade a tudo mais que quero desenvolver.

Então meu mecanismo funciona assim:

Você me diz seu nome, eu salvo na sua sessão e pronto. A não ser que você seja o instrutor, é claro. Então tudo que você tem que fazer é digitar seu nome como SUPER_SECRET_PASSWORD e você terá acesso a funcionalidades avançadas.

É seguro? Não.

É bom o suficiente para usar em uma aula com 20 pessoas? Definitivamente sim.

Decisão: Autenticação vem no último momento responsável. Pense nisso, trabalhe em volta disso e talvez você acabe criando algo inovador.

Deploy

Recentemente li o incrível livro Simplicity do Dave Thomas, e há muitas boas ideias lá. Uma que particularmente gosto é: automatize seu deploy desde o dia zero, para que você possa fazer deploy frequentemente.

Fiz isso usando github workflows e minha dedibox na Scaleway. Agora faço deploy fazendo apenas um simples:

git push origin deploy

E claro, o deploy ocorre apenas se todos os meus testes passarem. Coisas bem básicas, eu sei. Mas fazer isso desde o dia um me permite fazer deploy frequentemente e coletar feedback rapidamente.

Decisão: Crie um hello world, faça deploy e automatize todo o processo de deployment antes de fazer qualquer outra coisa.

Considerações Finais

Um bom projeto pessoal é um projeto pessoal que você pode rapidamente fazer deploy e ter outras pessoas usando. No meu caso, como instrutor, a ideia de criar uma plataforma para simular coisas da vida real durante sessões de treinamento parece ser um fit perfeito.

Vou revisitar algumas dessas decisões? CLARO! Essa é toda a ideia por trás de cada uma dessas decisões. Um dia vou ter um mecanismo de autenticação adequado e um banco de dados, mas quando esse dia chegar vou ter uma razão para implementar essas coisas.

Como Jaqen de Game of Thrones diria:

O que dizemos para nossa necessidade de implementar autenticação em nossos produtos? Hoje não.

Acontece que a linguagem é provavelmente um dos tópicos mais impressionantes que encontrei desde que comecei a estudar filosofia, e é um caminho completamente sem volta: uma vez que você começa a pensar sobre o significado das palavras e símbolos, nunca mais volta atrás. Tanto que quando me deparei com o último post do Kent Beck (link abaixo), comecei automaticamente a refletir sobre a palavra demo.

Software Design: Tidy First - The Threat of Incremental Delivery

Então, vou tentar explorar um pouco o significado de duas palavras que frequentemente usamos no desenvolvimento de software: demo e review.

Prometo não viajar muito!

O que é um “demo”? Resposta 1:

Como alguém que gosta de videogames, lembro-me de jogar muitos demos quando era mais jovem. Os demos eram basicamente uma versão do jogo com recursos limitados, como uma única fase, e havia inúmeras revistas (como a CD Expert!) que vinham com um CD-ROM contendo dezenas de demos para que você pudesse ter uma pequena amostra de um jogo antes de tomar a decisão de gastar seu dinheiro para comprar a versão completa. Os demos ainda existem e estão por aí, só não vêm mais em CD-ROMs.

Um demo funciona como um “aperitivo” para convencer as pessoas a comprar o produto

Então, um demo é sempre uma demonstração de algo que já está feito. Seu propósito é permitir que as pessoas testem algo antes de responder a uma pergunta simples: isso vale meu dinheiro? Do lado dos desenvolvedores, eles estão tentando demonstrar que a resposta deveria ser um sonoro “SIM!”.

E é por isso que não gosto de usar a palavra demo em cenários onde o cliente já está comprometido com o desenvolvimento do produto. Eles já investiram dinheiro ali, então… qual é o propósito de oferecer a eles uma demonstração?

O que mais é um “demo”? Resposta 2:

A palavra demo poderia ter um significado diferente. Especialmente em ambientes de baixa confiança, onde o cliente precisa de alguma prova de progresso. Alguma forma de validar que o que está sendo produzido pela equipe é 100% coerente com a especificação inicial.

Aqui cliente, se você clicar aqui, uma janela popup se abre e uma mensagem de erro é mostrada, Q.E.D.

Q.E.D - quod erat demonstrandum , ou C.Q.D - Como queríamos demonstrar.

Desta vez, estamos usando uma demonstração para provar algo. Para mostrar ao cliente que estamos trabalhando desde nossa última reunião e que o progresso que fizemos corresponde às expectativas iniciais.

Esse significado pode funcionar melhor para algumas equipes de desenvolvimento de software, mas ainda tem um problema: uma demonstração não é sobre coletar feedback.

E quanto a um “review”?

Re-view. Re-ver. Ver novamente. Funciona?

“Vamos olhar para o software que estamos produzindo mais uma vez e verificar se estamos indo para o destino correto.”

Isso parece bom. Mas ao mesmo tempo penso em quando minha bicicleta passa por uma revisão de segurança:

“Temos uma lista de verificação predefinida, e vamos verificar cada item para garantir que tudo esteja de acordo com os padrões.”

Aí não, já não funciona tão bem.

“Review” não é minha palavra preferida para o contexto de desenvolvimento de softwares complexos, mas é muito melhor que demo. Pelo menos existe a possibilidade de transmitirmos a mensagem correta aqui.

Quais outras palavras poderíamos usar?

Não existe uma palavra perfeita para usar. Mas se olharmos para o framework Scrum, por exemplo: o nome Sprint Retrospective faz todo sentido para mim. O nome Sprint Review não. Estamos revisando a Sprint? Que tipo de review estamos fazendo?

Essa conversa me lembra de quando eu estava planejando meu casamento e tivemos que experimentar todos os salgadinhos chiques, os doces e o bolo (Ô tarefa boa!). Nós os experimentávamos e fornecíamos feedback. Não era uma simples degustação, porque os nossos comentários sobre a comida eram usados para adaptar o que seria servido na festa. Essa experiência está muito mais alinhada com o que as equipes de desenvolvimento de software estão realmente tentando (ou deveriam estar) fazer em um Sprint Review.

Então, se eu fosse renomear o Sprint Review, eu chamaria algo como “Experimentação do Incremento” ou “Experimentação do Produto”.

Assim falamos do que foi produzido (incrementos) e não do processo de produção (Sprint). E uma experimentação é sobre empirismo, torna mais explícita a necessidade da participação ativa do cliente.

É perfeito? Bem… não. Mas:

Toda palavra é um preconceito

- Nietzsche

PS: Se você gosta deste tipo de assunto, provavelmente vai gostar de passar meia hora ouvindo este episódio de Philosophize This! - Episode 178: Susan Sontag on Metaphors. Embora esteja em inglês, é possível ver a transcrição neste link e aí fica fácil traduzir com o auxílio de qualquer navegador ou LLM.

Antes de mais nada, um esclarecimento: não, eu não estou sob efeito de entorpecentes. Mas recentemente comecei a estudar filosofia e tomei gosto pela coisa. E enquanto eu estudava minha cabeça não parava de conectar conceitos e questionamentos filosóficos com técnicas e comportamentos que estamos habituados a ver no mundo do desenvolvimento de software. Fiz logo uma lista sobre possíveis posts que gostaria de escrever, então esse aqui definitivamente não será o último post sobre filosofia e desenvolvimento.

Ou seja… esse post viajado não será o último post nessa linha. :)

Descartes era uns 50% ágil

Descartes enfrentando a realidade do desenvolvimento de software moderno: nem sempre nossas ideias “claras e distintas” passam nos testes unitários.

Descartes era um racionalista , o que significa que ele acreditava que a melhor forma de encontrar a verdade era através do pensamento. Algo que poderia nos fazer pensar nele como um gerente de projetos tradicional, sentado em sua mesa pensando em cada detalhe do plano que devemos seguir para desenvolver nosso produto.

Mas pensar nele dessa forma não seria justo, porque afinal em seu método cartesiano podemos encontrar idéias muito similares àquilo que praticamos no desenvolvimento ágil de software:

• Quebrar problemas grandes em problemas menores

• Ordenar os problemas e resolver os mais simples primeiro

Dá até pra imaginar ele escrevendo testes unitários e quebrando itens do Product Backlog, né? Mas tem um problema: Descartes acreditava que poderíamos alcançar idéias “claras, objetivas e imutáveis”, e que poderíamos usá-las como blocos de LEGO para construir outras idéias maiores.

É como se ele fosse a favor de escrever testes unitários em um primeiro momento para dar clareza e objetividade , mas deixasse de enxergar valor em manter esses testes no repositório depois que as funções fossem implementadas porque aquela idéia já foi validada e consolidada.

Ou seja: Descartes buscava uma verdade imutável, mas o processo para chegar até essas verdades era iterativo.

Mas se Descartes estava parcialmente certo sobre método, onde ele se perdeu? É aí que entra David Hume com uma ideia revolucionária: e se a experiência for mais importante que o raciocínio puro?

Hume teria sido um ótimo Scrum Master

Hume planejando seus experimentos em produção

David Hume teve a vantagem de nascer uns 120 anos depois de Descartes e com isso ter mais material para estudar e explorar. Ele argumentava que o conhecimento real só pode ser obtido através da experiência, e que apenas sentar e refletir ou estudar não nos geraria nenhum novo fato, e sim meras especulações.

Mas mesmo sendo um fã inveterado de experimentos ele sabia reconhecer suas limitações:

Embora a experiência seja nosso único guia no raciocínio sobre questões de fato, deve-se reconhecer que este guia não é totalmente infalível e que, em alguns casos, pode conduzir-nos a erros

- David Hume

Através desse pensamento ele levantou alguns problemas (e refletiu sobre outros que já haviam sido previamente levantados por outros filósofos) que são facilmente reconhecíveis no mundo do desenvolvimento de software:

1. O problema da indução: A experiência passada não garante a repetição de resultados futuros. Popularmente conhecido como: se funciona na minha máquina, funciona no servidor.

2. O problema da causalidade: Só porque um evento A ocorreu seguido de um evento B não significa que um causou o outro. Popularmente conhecido como: para replicar o bug que o cliente encontrou basta seguir estes passos aqui.

3. A falibilidade do experimento: um experimento sempre pode falhar ou nos levar a conclusões erradas. Popularmente conhecido como: se cobrirmos 100% do código com testes nunca mais vamos ter bugs.

É como diria Sílvio Santos e seu auditório: Eu só acredito… VENDO!

Essa máxima é o que deveria reger equipes Scrum por todo o mundo, já que o framework tem o Empirismo como parte de seu alicerce. Se David Hume fosse um Scrum Master e visse equipes que fazem Sprint Reviews com apresentações de slides ou Dailies que são basicamente um Status Report ele definitivamente não ficaria parado assistindo.

Se Hume fosse Scrum Master hoje, ele provavelmente:

• Insistiria em demonstrações de software funcionando

• Priorizaria métricas reais sobre estimativas teóricas

• Questionaria qualquer “verdade absoluta” sobre processos

Legal… mas dá pra concluir alguma coisa útil sobre isso tudo?

Bem, primeiramente eu não sou especialista em filosofia e tomei o máximo de cuidado pra não cometer nenhum crime ao mencionar esses filósofos e seus pensamentos. Estou confortável com o meu entendimento sobre o tema, e acredito que este tipo de entendimento mais profundo sobre o porquê das coisas sempre nos leva a questionar comportamentos mecânicos e estar mais conscientes sobre aquilo que praticamos no dia a dia.

Acho que escrever me faz absorver melhor os temas que estudo, e mesmo que ninguém leia acaba tendo valor pra mim.

Por exemplo, podemos concluir que o contexto importa. Descartes provavelmente escreveria testes unitários para validar a lógica de construção do nosso produto, enquanto Hume pensaria em testes de aceitação para avaliar o comportamento do cliente ao usar o produto. Ambas as abordagens têm um valor que pode ser maior ou menor de acordo com o contexto em que são aplicadas.

Se Descartes e Hume decidissem fazer pair programming hoje, provavelmente criariam o DevOps.

Descartes contribuiria com:

• Infraestrutura como código (afinal, precisa ser clara e objetiva)

• Pipeline de CI/CD (ordem e método em ação)

• Testes automatizados (validando verdades fundamentais)

Já Hume insistiria em:

• Monitoramento constante (porque a experiência importa e falhas acontecem)

• Feature flags (para validar hipóteses em produção)

• Cultura de blameless postmortem (aprender com os erros e tratá-los como parte natural do processo)

Além disso, se entendermos cada prática cotidiana como um experimento que pode falhar podemos começar se atingimos resultados satisfatórios em cada um destes experimentos:

• Por que fazemos reuniões diárias?

• Por que fazemos Sprint Reviews?

• Como posso mensurar o valor que uma determinada prática traz para meu time?

E dessa forma começamos a fazer nosso trabalho com mais consciência, levando sempre em consideração a intenção de cada passo.

Se interessou? Bom, aí vão minhas recomendações:

Eu comecei a aprender mais filosofia através do Estoicismo, e o Diário Estoico de Ryan Holiday é um livro que estou relendo pela terceira vez e portanto não canso de recomendá-lo. Se o estoicismo de agradar, toda a obra de Seneca pode ser interessante para você, e eu recomendo começar com “Sobre a tranquilidade da alma ”.

Outros livros que ajudam a tornar as palavras rebuscadas dos filósofos um pouco mais palatáveis e que gostei bastante foram:

• Ser livre com Sartre (meu favorito desta série!)

• Viver apaixonadamente com Kierkegaard

• Afirmar-se com Nietzsche

• Desapegar-se com Schopenhauer

Estes livros não foram escritos pelos filósofos, mas por professores de filosofia que traduzem os pensamentos para os dias atuais através de metáforas e perguntas para você começar a se questionar.

“Como posso começar a aplicar Test-Driven Development?” Essa pergunta ecoa nas minhas sessões de treinamento como uma chamada de função recursiva. Embora minha resposta padrão sempre tenha sido “Comece corrigindo bugs,” descobri uma abordagem ainda mais envolvente: Advent of Code.

Minha abordagem padrão: corrigindo um bug existente

Vamos examinar um exemplo simples. Imagine que você tem uma função de calculadora:

Quando alguém tenta dividir por zero, nossa aplicação quebra sem cerimônia. Isso apresenta uma oportunidade perfeita para TDD – podemos escrever um teste expressando nosso comportamento desejado:

Meu teste vai falhar, é claro, porque meu código falha. Agora posso corrigir meu código e fazer meu teste passar.

A Abordagem Gamificada: Advent of Code

Como um autoproclamado geek com afinidade por puzzles, descobri que o Advent of Code é o terreno de treinamento perfeito para TDD. Cada puzzle fornece:

• Uma amostra de entrada

• Uma saída esperada

Essa estrutura naturalmente te guia para a mentalidade de TDD – você escreve seu teste baseado no exemplo antes de implementar sua solução. É como ter uma especificação embutida!

Quer dizer, não só é uma boa forma de aprender TDD, mas também é divertido. Você está aprimorando suas habilidades de desenvolvimento, resolvendo um puzzle e praticando uma técnica muito valiosa.

Conforme você avança pelos desafios, pode começar a experimentar mais com TDD e talvez reduzir a granularidade de alguns dos seus testes. Por exemplo, você pode precisar fazer o parse de uma entrada de texto complexa em um Map para resolver o problema, e então isso poderia ser um teste por si só.

Ferramentas Que Melhoram a Experiência

Em Elixir (minha linguagem preferida), o operador pipe (|>) é particularmente poderoso para TDD:

Aquele pequeno triângulo basicamente diz: pegue a saída da função acima e passe para a função seguinte. Essa sintaxe elegante permite que você esboce o fluxo de alto nível da sua solução antes de mergulhar nos detalhes de implementação.

Combine isso com ferramentas como mix test.watch, que automaticamente executa os testes quando arquivos mudam, e você tem um ciclo de feedback rápido que faz o TDD parecer natural e intuitivo.

Pronto para Começar?

Escolha sua linguagem de programação preferida e mergulhe! Você pode explorar meu repositório do Advent of Code 2024 para inspiração:

https://github.com/mariomelo/advent_of_code24

Lembre-se: O objetivo não é perfeição, mas prática. Cada puzzle é uma oportunidade de fortalecer seus músculos de TDD enquanto se diverte!

Para insights mais profundos sobre TDD, confira o excelente artigo sobre Software Design: Tidy First?

Software Design: Tidy First? - Canon TDD

Bom código!

Até agora falamos sobre Estratificação e Cronologia, e passamos da “abordagem Mario Bros” onde sempre desenvolvemos a fase 1-1 antes da fase 1-2 para a “abordagem Megaman”, onde temos mais flexibilidade e podemos desenvolver nossos módulos em qualquer ordem.

Você percebeu que eu acabei de usar a palavra “módulos”? Esse é o problema que vamos abordar neste post: se consideramos que uma determinada parte do nosso software está pronta, isso significa que essa parte não é mais flexível. Se Estratificação é sobre camadas e Cronologia é sobre sequência , Modularidade é sobre as caixas onde colocamos nosso código - e às vezes, essas caixas se tornam prisões.

Entendendo o viés da Modularidade

Quando você derrota um chefe no Megaman, você ganha acesso a uma nova arma. Uma arma completa e funcional, mas também uma arma que nunca mudará. No desenvolvimento de software, no entanto, se tentarmos finalizar uma parte do nosso software e declarar que nunca mais tocaremos naquela área do código… Bom, digamos que simplesmente não funciona assim. Foi mal, Megaman.

Então, qual jogo poderíamos usar como analogia para melhorar a abordagem do MegaMan? Planescape: Torment! (Ou qualquer outro RPG clássico, na verdade).

Em Planescape, cada vez que você acumula experiência suficiente pode melhorar seu personagem adicionando pontos à sua Força, Sabedoria, Inteligência, Destreza, Carisma e Constituição. Você melhora gradualmente essas estatísticas, mas nunca completa nenhuma delas: você sempre pode adicionar mais pontos a uma determinada estatística durante seu próximo “ciclo de evolução”.

Pense no Megaman: quando você começa a jogar, pode escolher uma das 8 fases para jogar. Mas cada vez que você vence uma fase, tem menos opções sobre o que jogar em seguida, até chegar a um ponto onde não terá escolha porque já venceu 7 fases e só resta uma. Você começa flexível, mas perde essa flexibilidade ao longo do caminho.

Em Planescape não adquirimos novos “módulos” para nosso personagem; melhoramos suas características de acordo com nossas necessidades, e nossas necessidades mudam conforme avançamos no jogo.

Chega de jogos. Vamos falar de software!

Bem, tecnicamente esses jogos também são software, mas eu entendi o ponto. :)

Vamos voltar ao exemplo que tínhamos no nosso último artigo: um jogo da Forca. Ao quebrar o viés da Cronologia, decidimos adiar o desenvolvimento de um “Módulo de Dicionário” implementando apenas uma função que sempre retorna a mesma palavra: ELEFANTE.

Ao fazer isso, conseguimos focar em coisas mais interessantes como o mecanismo do jogo sem gastar muito tempo com o dicionário. Se pensarmos no nosso próximo passo, alguém poderia dizer que poderíamos finalizar o dicionário real em seguida e dar ao nosso Megaman uma nova arma. Mas ao fazer isso, prejudicaríamos nossa capacidade de adaptar ao feedback do cliente, pois reduzimos a quantidade de possibilidades que poderíamos desenvolver no futuro.

A menos que estejamos dispostos a descartar parte do nosso trabalho e refazê-lo de acordo com o feedback que recebemos, é claro. Na verdade, não é um crime fazer isso, mas esse tipo de desperdício pode ser drasticamente minimizado se, em vez de implementar o Dicionário, nos fizermos a seguinte pergunta:

Como poderíamos adicionar um único ponto de melhoria em nosso Dicionário, como no jogo Planescape?

Talvez pudéssemos criar uma lista de palavras e escolher uma palavra aleatória cada vez que a função get_word é chamada. Isso é simples, poderia ser feito em alguns minutos e melhoraria muito o jogo.

Observe que não implementamos a integração com a API mostrada inicialmente em nosso último post, mas podemos fazer isso no futuro se acharmos que é uma boa ideia.

Ou não.

Benefícios de quebrar o viés da Modularidade

Digamos que você está desenvolvendo aquele jogo da Forca usando a abordagem MegaMan e faz parte de um Time Scrum. Durante a Sprint Review, você mostra ao seu cliente o que construiu e pede feedback:

Então cliente, terminamos a Interface e o Dicionário. O que você acha que devemos fazer em seguida?

Bem, qual é o sentido de pedir feedback aqui? Se o cliente nos pedir para mudar algo relacionado ao Dicionário ou à Interface, desperdiçaremos muito do trabalho que fizemos, e se eles limitarem seu feedback às áreas restantes do software, não estamos nos beneficiando de todo o propósito do Scrum.

Agora, imagine você com a abordagem Planescape. O time melhorou nosso Dicionário e nossa Interface, mas ao invés de finalizá-los, usamos o tempo restante para criar um Sistema de Pontuação simples:

Neste cenário, você poderia fazer ao seu cliente uma pergunta diferente durante a Sprint Review, como:

Então cliente, baseado no que você viu, onde deveríamos alocar nossos próximos 3 pontos de melhoria? E o que estamos tentando alcançar fazendo isso?

Percebe a diferença? O cliente mantém suas opções e mesmo que nos peça para melhorar algo em que já trabalhamos, não jogamos trabalho fora. Pelo menos não tanto.

Além disso, talvez não precisemos implementar aquela integração com a API agora, já que o cliente decide aprimorar o Sistema de Pontuação e implementar um Mecanismo de Dicas. Enquanto isso, não teremos que nos preocupar com quantas chamadas de API estamos fazendo durante o processo de desenvolvimento, criar mocks e stubs para testar nosso jogo ou criar uma opção de configuração para tornar nosso jogo implantável em ambos os servidores de staging e produção.

O desperdício que minimizamos não está relacionado apenas ao feedback do cliente, mas a todo o processo de desenvolvimento.

Talvez nunca usemos aquela API. Na verdade, enquanto desenvolvia este Jogo da Forca para um curso de Certified Scrum Developer que eu estava dando, minha esposa jogou o jogo e teve uma ideia interessante: já que o curso era sobre Scrum, deveríamos usar palavras do Scrum Guide, e ao fazer isso acabamos com um dicionário estático que tinha 802 palavras diferentes. Todas relacionadas ao mesmo assunto: Scrum.

Como podemos evitar esse viés da Modularidade?

Vou ser direto com esta resposta: Use o Método do Hambúrguer. Eu sei que poderia elaborar mais, mas na minha experiência não há melhor maneira de lidar com esse viés como time do que usar esse método. Você pode ler mais sobre esse método aqui:

https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/.

Também é uma ótima maneira de lidar com dependências, que frequentemente nos empurram em direção ao viés da Modularidade.

Ainda há mais uma coisa que precisamos abordar aqui: A abordagem Planescape: Torment nem mesmo é nosso destino final. Isso porque naquele jogo (que é sensacional, diga-se de passagem) sempre teremos as mesmas 6 estatísticas para melhorar nosso personagem. E se você realmente quebrar este viés da Modularidade, será capaz de descobrir novas áreas para explorar conforme avança.

Mário, você fala demais. Este post está muito longo, poderia resumir, por favor?

Sim! Antes de declarar qualquer parte do seu software como ‘completa’, lembre-se: até o personagem de RPG mais poderoso ainda pode evoluir.

Aqui você encontra os dois artigos anteriores sobre vieses:

Entendendo o Viés da Cronologia

Lembro da primeira vez que joguei Mario Bros no console NES que meu pai me deu quando eu tinha 4 anos: o controle retangular absurdamente não ergonômico, a alegria de jogar um jogo com um personagem que tinha o mesmo nome que eu… Foi incrível!

O jogo era muito linear: 8 mundos com 4 fases cada. Você começa na Fase 1-1 e termina o jogo depois de vencer a fase 8-4. Existiam atalhos que eu podia pegar para pular algumas fases, mas eu nunca podia voltar para jogar uma fase já terminada.

O mundo 1-1 do primeiro Mario Bros resumido em uma imagem

Desenvolver software sob um Viés de Cronologia é como jogar aquele jogo do Mario Bros, exceto que não é tão divertido. Você começa desenvolvendo o mundo 1-1 porque é o que o usuário jogará primeiro. Depois desenvolve o mundo 1-2, e assim por diante. Se seguirmos esse caminho, claramente não estamos caindo no Viés da Estratificação, porque estamos criando todas as camadas para cada fase (não estamos terminando o design de todos os níveis antes de implementar o mecanismo do jogo, por exemplo). Com isso poderíamos coletar feedback do cliente após desenvolver cada fase e usar isso para criar melhores fases no futuro. Mas ainda assim… estamos perdendo algumas boas oportunidades.

Sabe o que é engraçado? Essa progressão linear estilo Mario aparece em todo lugar no desenvolvimento de software. Pegue a tela de login, por exemplo - ela praticamente se tornou nossa “Fase 1-1”. É quase como se houvesse uma regra não escrita que diz “Implementarás a autenticação primeiro” só porque é a primeira coisa que os usuários veem. E na maioria das vezes, esta é a primeira coisa que uma equipe de desenvolvimento de software implementa quando começa a desenvolver um novo produto. Você já fez isso? Eu fiz, inúmeras vezes.

Mas qual é o problema dessa abordagem?

Problemas, eu diria. No plural.

O mais óbvio é que não estamos nos beneficiando totalmente de uma abordagem ágil se estamos seguindo um caminho predefinido. Depois de revisar a Fase 1-1, teremos alguma flexibilidade sobre como desenvolver a fase 1-2, mas não sobre o que devemos desenvolver em nossa próxima iteração. Além disso, todas as nossas conversas sobre o produto deixarão aquele gosto amargo de tempo perdido porque o caminho já está definido. Esse sentimento é bastante comum entre desenvolvedores em Times Scrum durante o Planning e a Review quando estão caindo neste viés.

E se a fase 6-2 for a mais valiosa para meu usuário? Eles terão que esperar 26 iterações para finalmente poder jogá-la!

Outro problema será a mitigação de riscos. Se estou construindo um jogo do Mario, talvez eu tenha algumas ideias ousadas que quero validar primeiro, como um mundo aquático, um castelo com quebra-cabeças ou um chefe muito desafiador. Até mesmo o chefe final!

Então a solução parece direta: basta desenvolver recursos em qualquer ordem que forneça mais valor, certo? Poderíamos construir a fase 4-3 antes da fase 1-2, seguindo as prioridades do usuário em vez da ordem sequencial.

Bem… acontece que frequentemente esbarramos em um obstáculo familiar: dependências. Mas é aqui que outro clássico dos games nos oferece uma alternativa iluminadora…

Quebrando o Viés da Cronologia (e as dependências)

Voltando à minha infância e meu console NES, havia um jogo que eu amava ainda mais que Mario Bros: MegaMan. Em todo jogo do MegaMan você podia selecionar qual fase queria jogar, e uma vez que você derrotava o chefe da fase, você ganhava acesso à sua arma e podia usá-la pelo resto do jogo.

Só de ver essa tela eu tenho vontade de jogar Megaman novamente!

Então, você podia escolher lutar contra o Fireman primeiro e usar sua arma de fogo contra o Iceman, ou o contrário. Depende de você. Não havia absolutamente nenhuma sequência predefinida. Mas… o que acontece se tentarmos usar a mesma abordagem no desenvolvimento de software? Bem, às vezes vamos ouvir e dizer coisas como:

“Não podemos desenvolver um relatório sem criar um CRUD para inserir os dados primeiro, afinal não existe relatório sem dados!”

Ok, vamos desafiar isso: Como poderíamos desenvolver um relatório sem ter uma interface para inserção de dados? Bem, mockando os dados. Imagine que vamos construir um jogo da Forca. Alguém poderia dizer que a primeira coisa que precisamos fazer é criar um dicionário de palavras que podemos usar durante o jogo, porque ter uma palavra para jogar é um pré-requisito!

Então, se cairmos nessa armadilha, provavelmente vamos gastar algum tempo desenvolvendo algo como:

Não parece muito, mas requereu algum tempo para pesquisar uma maneira de gerar uma palavra aleatória, ler a documentação da API, criar uma conta, obter uma chave de API, escrever o código, testá-lo e refatorá-lo um pouco. Mas o mecanismo do jogo é muito mais importante, e se pudéssemos economizar algum tempo aqui, poderíamos usar esse tempo para desenvolvê-lo melhor. E uma maneira de fazer isso é estabelecendo uma interface simples.

Quando eu chamo a função get_word, recebo uma palavra, e não me importo realmente de onde ela veio. Se fizermos isso, poderíamos criar nosso Dicionário assim:

Sim, a palavra sempre será ELEFANTE.

Mas não estou dizendo que devemos lançar o jogo assim! Tudo que estou dizendo é que agora, em vez de mostrar ao usuário uma tela que gera um monte de palavras aleatórias, vamos mostrar um jogo da Forca totalmente funcional que sempre usa a palavra ELEFANTE. E fazendo isso, nossa revisão do produto se tornará mais interessante porque agora temos uma pergunta muito poderosa para fazer: O que devemos fazer a seguir?

Poderíamos decidir implementar o Dicionário, ou o cliente poderia pedir outra coisa, como um sistema de pontuação para o jogo ou um mecanismo de dicas. Teremos opções. Não estamos jogando Mario Bros, estamos jogando MegaMan.

E como começo a fazer isso?

Antes de qualquer coisa, liste todas as suas suposições de dependência e comece a questioná-las. Eu gosto de usar a construção “Como poderíamos / sem” para fazer isso:

• Como poderíamos autenticar o usuário sem uma tela de login?

• Como poderíamos gerar um relatório sem ter uma maneira de popular o banco de dados?

• Como poderíamos mostrar esta informação sem usar gráficos?

Segundo e mais importante: certifique-se de que sua equipe sabe trabalhar com interfaces. Isso é fundamental para evitar retrabalho e quebrar coisas.

Lembre-se: para nos adaptar às mudanças com sucesso, devemos aprender a fazer isso sem aumentar os custos de desenvolvimento. Assim como no MegaMan, o melhor caminho nem sempre é o mais óbvio - às vezes você precisa lutar contra o Fireman antes do Iceman, e às vezes você precisa construir aquele sistema de pontuação antes de implementar o algoritmo perfeito de seleção de palavras.

O Viés da Cronologia, assim como seu primo o Viés da Estratificação, nos engana a seguir um caminho predeterminado quando deveríamos estar nos perguntando aquela simples mas poderosa questão: “O que devemos fazer a seguir?”. Afinal, desenvolvimento de software não é sobre completar níveis em uma ordem predefinida - é sobre criar valor da maneira mais efetiva possível.

Em breve teremos o post final desta série, onde exploraremos nosso último viés: a Modularidade.

Ah! E se você chegou até aqui, obrigado por ler!

O evento foi incrível, pois os organizadores (Evelyn, Giuseppe, Khurram e Thomas) e os voluntários fizeram um trabalho fantástico na organização. Saí do evento verdadeiramente feliz e com muito alimento para o pensamento. Essa foi minha motivação para transformar minha apresentação em três posts: um para cada viés que descrevi lá.

Então, o que são esses vieses?

Um viés pode ser definido como “Uma preferência ou inclinação, especialmente uma que inibe o julgamento imparcial”. No desenvolvimento de software, isso poderia ser traduzido como modelar um projeto de software usando conceitos que estão profundamente enraizados em nosso cérebro, evitando assim uma abordagem alternativa que poderia nos ajudar a criar algo mais flexível.

Fazemos as coisas desta maneira porque sempre as fizemos assim. E isso é um loop infinito.

Para quebrar esses vieses, primeiro devemos entendê-los, então vamos começar com o primeiro: Estratificação.

Estratificação?

Sim, eu inventei esses três nomes e não estou realmente satisfeito com eles. Mas, como Phil Karlton disse: “Existem apenas duas coisas difíceis em Ciência da Computação: invalidação de cache e dar nomes às coisas”.

O viés de estratificação acontece quando, após dividir um software em camadas (digamos: banco de dados, backend e frontend), começamos imediatamente a desenvolver a camada mais baixa, que geralmente é o modelo de banco de dados. Imagine isto: você começa com a camada de banco de dados, meticulosamente criando cada tabela e relacionamento. Só quando isso está “pronto” você passa para o backend, e que Deus o livre de alguém mencionar o frontend até que a API esteja completa!

Este é provavelmente o mais famoso dos vieses, pois há muito tempo é chamado de BDUF (Big Design Upfront) e foi uma das primeiras barreiras que tivemos que superar para desenvolver software mais flexível. A coisa triste é que ainda acontece. Muito.

Existem dois problemas principais com essa abordagem. Número um: efeitos colaterais. Uma mudança em um único ponto da camada superior pode gerar múltiplas mudanças nas camadas inferiores.

Segundo problema: efeitos colaterais dos efeitos colaterais, ou: bugs. Agora, porque você teve que mudar o banco de dados, alguma parte do backend que mal está relacionada à mudança inicial pode ser afetada e também afetar alguma parte do frontend que é completamente não relacionada à mudança inicial.

Se você prestou atenção, notou que ao corrigir um bug você poderia desencadear exatamente o mesmo processo novamente, o que nos leva a um loop infinito de desespero, frustração e clientes irritados.

Sou vítima desse viés? Como escapo dele?

Existem sintomas. Seu cliente não conseguirá fornecer feedback valioso porque não verá nada utilizável, a quantidade de retrabalho necessária sempre que você precisar mudar algo será insuportável, e você pode sentir a necessidade de descartar algumas boas ideias devido aos custos de desenvolvimento. Mais importante: seus desenvolvedores ficarão mortalmente entediados.

E justamente porque esse era o status quo não muito tempo atrás, os desenvolvedores entediados de então decidiram criar algo para ajudá-los a sair dessa situação. Algo que permitiria que o banco de dados evoluísse com segurança ao longo do tempo sem gerar muita dívida técnica. Eles chamaram isso de “Migrações de Banco de Dados “.

É bonito, não é? Uma solução técnica criada para resolver um problema técnico que estava dificultando a capacidade da equipe de se adaptar às mudanças. Voltarei a isso mais tarde após o exemplo técnico, então se você já está familiarizado com o conceito ou não está familiarizado com código, pode pular a próxima seção.

Colocando a mão na massa (com código)!

Vamos dar uma olhada em uma Migração de Banco de Dados usando Elixir e Ecto. Imagine que você está criando uma tabela para armazenar os usuários do seu sistema. Você (e seu cliente) podem ter muitas ideias interessantes sobre todos os dados que você pode armazenar lá: nome, e-mail, uma pequena biografia, um avatar, data de nascimento, e a lista continua.

Se entendermos que o banco de dados pode evoluir, podemos começar com algo mais simples. Apenas o nome de usuário e o e-mail, por exemplo.

defmodule MyApp.Repo.Migrations.CreateUsers do
  use Ecto.Migration

  def change do
    create table(:users) do
      add :username, :string
      add :email, :string
      
      timestamps()
    end
  end
end

Fazer esta primeira parte nos fornecerá opções para a próxima iteração. Podemos realmente nos perguntar qual é a coisa mais importante a desenvolver: o avatar? a pequena biografia? algo completamente diferente em outra parte do sistema?

Mais tarde, se decidirmos implementar o avatar do usuário e uma biografia curtinha, poderíamos criar outra migração como esta:

defmodule MyApp.Repo.Migrations.AddProfileToUsers do
  use Ecto.Migration

  def change do
    alter table(:users) do
      add :bio, :text
      add :avatar_url, :string
    end
  end
end

Desta forma, podemos garantir que o banco de dados do cliente estará sempre atualizado e que ninguém executará o mesmo script de banco de dados duas vezes e quebrará tudo.

Existem benefícios técnicos, mas também não-técnicos

Além do benefício óbvio de criar algo mais flexível, existem alguns benefícios não-técnicos muito interessantes. Por exemplo: como você construiu um banco de dados mais leve, o que quer que a equipe precise desenvolver a seguir levará menos tempo simplesmente porque haverá menos campos e tabelas para lidar. Isso também se refletirá na quantidade de efeitos colaterais (ou seja, bugs) que seu processo de desenvolvimento pode gerar, porque a complexidade do seu software não crescerá exponencialmente como antes. Podemos resumir isso como: quebrar o viés de estratificação equivale a economizar tempo.

Esse tempo que você economizou pode gerar um efeito borboleta. A equipe agora pode pensar no que fazer com esse tempo. Talvez aprender a escrever alguns testes unitários, ou dedicar um tempo para experimentar uma nova tecnologia. Como a resposta a essa pergunta não é óbvia, eles terão que colaborar para encontrar a melhor opção. Observe que todos terão que colaborar: desenvolvedores, designers, testadores, pessoas de negócios.

Todo esse conceito de migração de banco de dados foi criado porque alguém desafiou a ideia de que “Não podemos alterar o banco de dados como quisermos”. Uma pessoa técnica, com uma solução técnica. Porque às vezes, quando um desenvolvedor enfrenta um desafio como esse e tem o tempo e os recursos adequados para lidar com ele, uma inovação nasce.

Isso também acontece quando quebramos os vieses de Cronologia e Modularidade, mas falaremos sobre eles mais tarde. :)

Ps: Se você quiser ler mais sobre este assunto, pode conferir o post detalhado e incrível do Martin Fowler, aqui: https://martinfowler.com/articles/evodb.html

Se é verdade agora, seria verdade amanhã também? Provavelmente. As chances são de que ela passe alguns meses até terminar o álbum, e a frase ainda será verdadeira durante esse período. No entanto, se você receber uma informação mais específica, o cenário pode mudar:

• Lady Gaga está trabalhando na primeira música do seu novo álbum

Por quanto tempo essa frase será verdadeira? Talvez alguns dias ou semanas.

• Lady Gaga está escrevendo a letra da primeira música do seu novo álbum

Por quanto tempo essa frase será verdadeira? Talvez alguns dias ou horas.

• Lady Gaga está escrevendo o refrão da primeira música do seu novo álbum

Por quanto tempo essa frase será verdadeira? Talvez algumas horas ou até mesmo minutos.

Quando se trata de software, poderíamos dizer o mesmo. E Kent Beck recentemente republicou um artigo legal sobre o assunto chamado “Software is Bananas” (link abaixo).

Software Design: Tidy First? - Software Is Bananas

O problema é que informações diferentes em contextos diferentes terão “datas de validade” diferentes. Digamos que você tenha um problema e queira criar um produto de software para resolver esse problema, então você formula uma hipótese:

Se essa ideia que eu tenho funcionar, o problema X desaparecerá.

Se você não implementar sua ideia em, digamos, 6 meses, ela pode não fazer mais sentido mesmo que o problema original ainda exista. É natural: o problema é menos volátil do que a solução simplesmente porque existe uma relação de dependência entre eles.

Mas digamos que você decida seguir em frente e implementar sua ideia. Você então começa a fazer anotações sobre como fazê-lo:

Para implementar essa ideia, farei a etapa X, a etapa Y e a etapa Z.

A mesma regra se aplica aqui. Se você não seguir as etapas que estabeleceu imediatamente, poderá decidir implementar a mesma ideia de outra maneira. As etapas são mais específicas e, portanto, mais voláteis.

Em resumo, não tem problema ter uma lista de problemas para resolver, desde que você não gaste muito tempo pensando em como resolver muitos deles de uma vez. E não tem problema discutir os detalhes de implementação de um punhado de ideias, desde que você tenha certeza de que vai implementá-las nos próximos dias.

Durante esses anos fui desenvolvedor, dono de empresa, consultor, instrutor, e aprendi (principalmente cometendo erros) muitas coisas sobre o lado técnico e o lado social do desenvolvimento de software.

O que escrevi aqui é baseado no que vivi neste mercado, o que significa: é baseado em muitos anos de experiência, mas também é enviesado por essas mesmas experiências. Mas como vi coisas mudando e outras não mudando, gostaria de tentar elaborar meu raciocínio sobre quais são as causas e consequências desses resultados.

Então, vamos lá!

O que mudou em 20 anos?

Bem… Obviamente, a tecnologia mudou. E com isso, tudo mudou.

Quando comecei a programar não tínhamos iPhones ou telefones Android, e curiosamente eu estava trabalhando com computação móvel. Pocket PC 2002 era o sistema operacional e eu escrevia código C++ que precisava ser altamente otimizado por causa de todas as restrições de memória que tínhamos naquela época.

Mobile nos anos 2000: Esses dispositivos conseguiam fazer o Nokia 3310 parecer frágil

Mas mais importante: as organizações mudaram. E a maioria das mudanças que vi foram causadas por inovações tecnológicas.

Complicado, depois mais simples, depois complexo

Se você já escreveu uma aplicação web usando J2EE e Enterprise Beans, lembra como era burocrático. O deploy não era direto, precisávamos escrever muito código para fazer a coisa mais simples e mudanças no schema do banco de dados eram um pesadelo. A questão é que estávamos principalmente criando aplicações web privadas porque a web não era o que é hoje (nem mesmo o Orkut tinha sido criado ainda).

No início, esses pontos de dor incentivaram as organizações a buscar equipes maiores, um departamento de gerenciamento de banco de dados especializado e também um departamento de operações.

Por outro lado, os desenvolvedores começaram a criar ferramentas para resolver esses pontos de dor: frameworks ORM como Hibernate começaram a se tornar populares, depois frameworks como Rails começaram a introduzir maneiras mais fáceis de criar bancos de dados evolutivos e também uma abordagem mais direta para criar uma aplicação web.

Essas mudanças empoderaram os desenvolvedores e permitiram que pequenas equipes fossem ainda mais produtivas do que as grandes equipes corporativas eram. Com isso vimos uma mudança no mercado: todo mundo queria equipes menores com os chamados Desenvolvedores Full-stack. Computação em nuvem estava disponível para todos por menos de US$5/mês com Heroku, DigitalOcean e AWS, e muitas startups começaram a aparecer em todo lugar.

Mas então… tudo mudou.

A web evoluiu e o que era um simples REQUEST/RESPONSE com HTML e CSS se tornou um quebra-cabeça complexo usando Ajax, jQuery, e depois Angular, Ember, React, Vue, Svelte. As empresas começaram a exigir desenvolvedores frontend.

No backend, as coisas ficaram ainda mais complexas. Os gigantes da indústria estavam enfrentando os desafios causados pelo seu próprio sucesso: como lidar com uma quantidade tão massiva de usuários simultâneos? Como armazenar eficientemente essa quantidade massiva de dados?

Então novamente, os desenvolvedores vieram ao resgate e criaram soluções como Docker, Kubernetes, Grafana. Os gigantes compartilharam suas histórias de sucesso e as empresas de médio porte decidiram adicionar toda essa complexidade aos seus produtos para alcançar os mesmos resultados. Em parte, esse movimento também foi causado pelos desenvolvedores: queríamos trabalhar com a tecnologia de ponta usada pelos gigantes do mercado, mesmo que claramente não fosse necessário para nossos servidores que estavam lidando com muito menos usuários do que Google ou Facebook.

Desenvolver um software simples parecia… desnecessariamente complexo. A maioria das empresas com as quais trabalhei naquela época não estavam criando produtos para as massas, mas produtos de nicho com pouca ou nenhuma necessidade de tal complexidade. E foi na verdade quando comecei a trabalhar mais com consultoria e treinamento novamente. Eu estava constantemente defendendo modelos mais simples sempre que eram bons o suficiente.

Ainda estou.

O que não mudou em 20 anos?

Muitas coisas:

• Ainda precisamos de desenvolvedores de software

• As pessoas ainda estão tentando descobrir como medir produtividade no campo de desenvolvimento de software

• Estimativas ainda são um problema para a maioria das pessoas

• As pessoas ainda discutem sobre qual é o melhor editor de texto/IDE/framework/linguagem

• E bem… desenvolvimento de software ainda me traz alegria :)

Não sinto que disse tudo o que queria dizer. Ainda preciso refletir mais sobre como mudei durante esses 20 anos.

Talvez eu escreva mais sobre isso no futuro.

Há cerca de um ano atrás criei um jogo de cartas para ensinar Scrum: o Scrumchkin. O jogo tornou o processo de aprendizado mais divertido e foi adotado por Scrum Trainers de diversos países, até que a pandemia inviabilizou qualquer turma presencial.

E foi daí que surgiu meu projeto pessoal: criar uma versão online do Scrumchkin. O que seria uma ótima oportunidade para brincar e aprender mais sobre Phoenix Liveview.

Inicialmente, pensei na seguinte estrutura para o projeto:

Desta forma, seria possível criar jogos em processos separados e ter um registro com identificadores únicos de cada jogo para que cada partida pudesse ser acessada através de uma URL diferente.

Exemplo:

• O usuário acessa a URL http://scrumchkin.com/game/abc123

• A aplicação web pergunta ao Registro de Jogos onde está o jogo abc123

• O Registro de Jogos encontra o PID da partida e retorna para aplicação web

O Registro de Jogos como uma biblioteca

Tendo em mente o princípio da responsabilidade única , o desenho acima deixa bem evidente a existência de 3 projetos diferentes: O Registro de Jogos, o Servidor de Jogos e a Interface Web.

Os próximos parágrafos vão falar sobre alguns aspectos técnicos de Elixir a título de curiosidade. Se você quiser apenas entender a diferença entre uma biblioteca e uma aplicação OTP basta pular esta parte :)

Tecnicamente o Registro de Jogos é extremamente simples: ele vincula um ID único a uma partida. Ele é basicamente um dicionário que tem como chave um UUID e como valor um PID de um GenServer para uma partida.

Inicialmente, criei o Registro de Jogos como uma biblioteca capaz de fazer operações CRUD em uma tabela ets :

defmodule GameRegister do
  def init() do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
  end

  def save(value) do
    key = UUID.uuid1()
    :ets.insert_new(:scrumchkin, {key, value})
    key
  end

  def delete(key) do
    :ets.delete(:scrumchkin, key)
  end

  def get(key) do
    :scrumchkin
    |> :ets.lookup(key)
    |> format_result
  end

  def list_all do
    :ets.tab2list(:scrumchkin)
  end

  defp format_result([]), do: {:error, "Game not found"}

  defp format_result(item_list) do
    item_list
    |> hd
  end
end

TL;DR - A biblioteca armazena o estado atual de partidas e as vincula a um código identificador. Ela é capaz de listar, obter, salvar e deletar partidas do registro.

Um pequeno problema

Para que eu pudesse utilizar a tabela ets, ela precisava existir. Isto significa que em algum momento a função init do código acima precisaria ser chamada pela minha aplicação web.

  def init() do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
  end

Mas isso vai contra o princípio de responsabilidade única que utilizei para dividir este projeto em partes menores, certo?

O Registro como uma aplicação

Mas o que é uma dependência como biblioteca? Ela é uma engrenagem que faz parte de um todo; algo bem parecido com uma peça de Lego. Sabemos onde estão os pinos e buracos e a utilizamos para construir algo maior.

A dependência de uma aplicação OTP é um pouco diferente.

Pense em um carro. Geralmente, carros têm um mecanismo de refrigeração do motor que é iniciado no momento em que você vira a chave e dá a partida. O carro depende deste mecanismo para funcionar, mas ele é um tanto quanto independente: muitas vezes ele é acionado quando desligamos o carro (aquele barulho de ventilador que vem de debaixo do capô, principalmente em dias quentes).

Esse mecanismo de refrigeração tem interfaces com o motor do carro, mas controla seu próprio estado. Existe uma relação clara de dependência , mas não de controle. O motor depende do sistema de refrigeração para não superaquecer, mas não o controla.

E o mesmo precisava acontecer com meu Registro de Jogos, que ficou assim:

defmodule GameRegister do
  use GenServer

  def start_link(state) do
    GenServer.start_link(__MODULE__, state, name: __MODULE__)
  end

  def init(stack) do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
    IO.puts("Tabela scrumchkin criada")
    {:ok, stack}
  end

  def handle_call({:save, game}, _from, state) do
    key = UUID.uuid1()
    :ets.insert_new(:scrumchkin, {key, game})
    {:reply, key, state}
  end

  def handle_call({:delete, game_id}, _from, state) do
    :ets.delete(:scrumchkin, game_id)
    {:reply, :ok, state}
  end

  def handle_call({:get, game_id}, _from, state) do
    result =
      :scrumchkin
      |> :ets.lookup(game_id)
      |> format_result

    {:reply, result, state}
  end

  def handle_call(:list_all, _from, state) do
    {:reply, :ets.tab2list(:scrumchkin), state}
  end

  def save(game) do
    GenServer.call(__MODULE__, {:save, game})
  end

  def delete(game_id) do
    GenServer.call(__MODULE__, {:delete, game_id})
  end

  def get(game_id) do
    GenServer.call(__MODULE__, {:get, game_id})
  end

  def list_all do
    GenServer.call(__MODULE__, :list_all)
  end

  defp format_result([]), do: {:error, "Game not found"}

  defp format_result(item_list) do
    item_list
    |> hd
  end
end

Mas… o que muda?

Minha aplicação web não é responsável por criar a tabela ets. Ela apenas diz que depende do Registro de Jogos e que ele é agora uma aplicação extra.

A alteração no arquivo mix.exs é simples:

  def application do
    [
      mod: {Scrumchkin.Application, []},
      extra_applications: [:logger, :runtime_tools, :game_register, :game_engine]
    ]
  end
  defp deps do
    [
      {:game_engine, path: "../game_engine"},
      {:game_register, path: "../game_register"}
    ]
  end

Agora, toda vez que inicio minha aplicação com um mix phx.server omeu registro de jogos é iniciado automaticamente e assume a responsabilidade de criar a tabela ets onde vai armazenar os PIDs das partidas de Scrumchkin.

A minha aplicação web depende do Registro de Jogos, mas confia que ele consegue resolver seus problemas sozinho.

O mais curioso é que transferências de outros valores funcionavam perfeitamente. Bem, quase todos. As pessoas começaram a descobrir outros casos específicos onde o problema acontecia: R$ 32,23 ou R$ 155,17.

A idéia desse post não é debater a causa do problema, mas sim mostrar uma técnica que pode ajudar equipes a detectar problemas parecidos.

O texto inclui algum código em Elixir, mas também inclui ilustrações para explicar cada conceito. O objetivo é tornar este conteúdo útil tanto para pessoas técnicas quanto para pessoas não-técnicas.

Testes unitários ajudariam? Bem… não exatamente.

Não me leve a mal: eu sou fã de testes unitários e (quase) sempre pratico TDD.

Mas um teste convencional para uma função de transferência de dinheiro provavelmente seria algo parecido com o exemplo abaixo:

Não fica muito específico?

Repare que o teste onde a transferência é possível foca em apenas um caso: uma transferência de R$ 25,00. E nesse caso, os testes são um sucesso:

Mas podemos escrever um teste para o caso dos R$17,99, certo?

Claro! Depois de saber da existência do erro poderíamos incluir um teste adicional para garantir que transferências bancárias de R$ 17,99 também podem ser efetuadas:

Aqui podemos colocar o famoso ciclo do TDD (Test Driven Development, ou desenvolvimento orientado a testes) em ação: Red, Green, Refactor.

Este teste falha (RED), e então podemos corrigir o problema até que o teste passe (GREEN). E agora, tendo o teste como uma rede de segurança podemos deixar alterar o código para torná-lo mais legível sem medo de quebrar nada (REFACTOR).

O teste falha pois o saldo restante foi de R$2,02 e não R$ 2,01

Pronto! Agora quando fizermos este teste passar vamos garantir que as transferências de R$17,99 funcionarão perfeitamente. Mas algumas perguntas ficam no ar:

• A transferência de R$ 32,23 vai funcionar?

• E se existirem outros valores que geram o mesmo erro?

• E se existirem valores que geram outro erro diferente?

• Como podemos evitar que problemas como esse cheguem aos nossos clientes?

E é aí que entra em cena o PBT — Property Based Testing, ou Testes Baseados em Propriedades.

PBT: limpando onde os testes convencionais não alcançam

É bem simples de escrever o teste dos R$17,99 depois que sabemos da existência do erro.

O que acontece é que nós escrevemos os testes com casos que já temos em mente, de maneira bastante linear e específica. Mas o teste é tão específico que testa apenas um caso. E se o problema continuar acontecendo com transferências de outros valores?

Neste caso, o problema apareceu apenas ao tentar transferir R$ 6,05

Mas… como poderíamos identificar valores problemáticos antes mesmo de saber do problema? É aí que entram os testes baseados em propriedade.

Trabalhar com propriedades significa não pensar em casos específicos, e sim nas características de cada variável envolvida no teste. Neste caso, podemos dizer que:

• O saldo inicial de quem vai transferir o dinheiro pode ser qualquer valor maior que zero.

• O valor da transferência é maior que zero e menor ou igual ao saldo disponível.

Para saber se a transferência foi feita com os valores corretos basta a gente “tirar a prova”, como fazíamos no ensino fundamental. :)

Valor transferido + Saldo remanescente = Saldo antes da transferência

Quando definimos as regras desta maneira, as ferramentas de testes automatizados são capazes de validar diversos casos diferentes. E muitas vezes esses “casos diferentes” acabam incluindo situações que sequer imaginamos, e por isso jamais escreveríamos um teste convencional sobre elas.

Agora, ao rodar os testes descobrimos que existem outros valores que também acabam por gerar o erro:

Opa! Se eu tiver R$0,98 e tentar transferir R$0,71 o problema também acontece!

Ah! Repare que a biblioteca de testes diz: Counter example stored.

As bibliotecas de PBT costumam armazenar os valores que geraram erros e usá-los novamente até que o problema seja corrigido. Ou seja, quando o teste passar é porque o problema foi resolvido, e não porque a biblioteca selecionou apenas valores para os quais o problema não acontece.

Tá, mas o que isso tem a ver com agilidade?

Bem, agilidade é a capacidade de mudar e gerar resultados rapidamente.

É como se você estivesse em um carro de corrida em uma pista sinuosa: para fazer curvas rapidamente e sem perder muita velocidade você vai precisar de um veículo sólido e bem construído. Sem isso, você se limita a duas opções:

• Fazer a curva beeeeem devagarzinho para garantir que o veículo não quebre

• Fazer a curva rapidamente e desmantelar seu veículo

Exemplo:

Imagine que o banco decidisse permitir contas em Bitcoins. Teriam agora que trabalhar com uma moeda que tem bem mais do que duas casas decimais.

Agora imagine que o banco pode ter uma aplicação que:

a) Não tem nenhum teste automatizado

b) Tem alguns testes automatizados

c) Tem testes automatizados convencionais e alguns utilizando PBT

Em qual cenário o banco conseguiria ter um produto funcional em produção mais rapidamente?

Resumindo: Não existe agilidade sem excelência técnica.

Código Fonte e considerações finais

Eu escrevi o código para gerar o erro de forma proposital e assim ilustrar como uma determinada técnica poderia ajudar a resolver um problema.

Caso você tenha curiosidade, o código utilizado neste post está disponível em: https://github.com/mariomelo/post_pbt

Scrum is simple to understand, but difficult to master

- Scrum Guide, 2017 version

Ou seja, existe um universo de distância entre entender Scrum e realmente dominá-lo. E é aí que mora o perigo: Esta distância é o habitat perfeito para as vítimas do efeito Dunning Kruger.

Imagem criada pelo www.investificar.com.br

Do Wikipédia: O efeito Dunning-Kruger é o fenômeno pelo qual indivíduos que possuem pouco conhecimento sobre um assunto acreditam saber mais que outros mais bem preparados, fazendo com que tomem decisões erradas e cheguem a resultados indevidos; é a sua incompetência que os restringe da habilidade de reconhecer os próprios erros.

Dito isto, vamos às três fake news!

1 — O problema do Scrum é que ele é muito simples

O Scrum é um framework, mas é comum escutar pessoas se referirem ao Scrum como uma metodologia. Pode parecer implicância minha, mas essa simples troca de palavras diz muito sobre o entendimento do Scrum.

Afinal, o que é um framework? Bem, de acordo com o dicionário de Cambridge:

A supporting structure around which something can be built

- Dicionário de Cambridge

O Scrum é uma estrutura sobre a qual você deve construir sua maneira de trabalhar. É como o Ruby on Rails, o ExpressJS ou o Hibernate: eles não funcionam sozinhos, mas te ajudam a trabalhar de uma forma mais estruturada e produtiva.

Frameworks são incompletos por padrão e de propósito. São criados para que você possa pensar e expandi-los da maneira que fizer mais sentido no seu contexto de trabalho. E é daí que surgem as práticas ágeis como Story Points, User Story Mapping, Priorização por Risco x Valor, User Stories, etc.

Como o Scrum implementa o ciclo PDCA, é possível adotar uma determinada prática ágil, validar seus efeitos e decidir se vale ou não a pena continuar com aquela prática. E claro, é preciso experimentar novas ideias e repetir esta reflexão ao final de cada Sprint.

Resumindo:

O Scrum é simples e incompleto de propósito para fazer você pensar em maneiras de complementá-lo.

Se alguém lhe disser que o problema do Scrum é ser simples demais, esta pessoa ainda não entendeu nada sobre o framework.

2 — Management 3.0 e DevOps vieram para substituir o Scrum

Em Minas Gerais temos uma expressão muito utilizada quando alguém diz algo assim:

MÉQUÉ??? — Do mineirês: como é que é?

Esta afirmação não faz o menor sentido se você já compreendeu o conceito de um framework: Management 3.0 e DevOps chegam para complementar, e não para substituir.

Afinal, o Scrum Guide diz que:

Os Scrum Teams são estruturados e empoderados pela organização para gerenciar seu próprio trabalho.

- Scrum Guide, 2017 version

Sim, o Scrum não fala sobre automatizar deploys, por exemplo. Não fala em feedback wraps, delegation boards ou motivadores intrínsecos.

Porque o Scrum é um… framework!

Acredito que esta representação visual utilizada pelo Alexandre Magno em seus treinamentos ilustra muito bem esta ideia.

Representação do framework Scrum completado por técnicas emergentes, criada por Alexandre Magno

3 — Não temos mais times Scrum. Temos Squads.

Essa é bem interessante, e eu adicionei aqui porque cada vez mais vejo organizações utilizando termos do famoso modelo Spotify. E muitas vezes a justificativa é a de que os times são multidisciplinares e não segmentado por áreas de conhecimento.

Mas, o que o Scrum Guide diz sobre seu Scrum Team?

• Scrum Teams são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.

• Individualmente os integrantes do Scrum Team podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Scrum Team como um todo.

O conceito de Squads nasceu de maneira colaborativa no Spotify e foi parcialmente documentado em 2012 neste pdf Henrik Kniberg e Anders Ivarsson. No documento, disponível neste link, eles dizem que:

A Squad is similar to a Scrum team, and is designed to feel like a mini-startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production. They are a self-organizing team and decide their own way of working.

É sempre válido refletir sobre o modelo adotado pela organização:

• Seu Scrum Team possui as características mencionadas no Scrum Guide?

• Sua organização provê o ambiente necessário para a existência de Squads/Scrum Teams?

• Qual problema está sendo atacado com a adoção de Squads?

• O que diferencia seu Squad de um Scrum Team?

Os Squads fizeram sentido no contexto de escala do Spotify, e talvez até sejam compatíveis na sua organização. Mas é fundamental compreender quais problemas o Scrum e o “Modelo Spotify” tentam resolver antes de fazer um CTRL+C / CTRL+V.

No final das contas, a desinformação sempre existirá e eventualmente as pessoas podem propagá-la mesmo com a melhor das intenções. A única forma que conheço de evitar essas armadilhas é seguir o conselho do sábio filósofo ET Bilu:

O ET Bilu leria o Scrum Guide antes de começar a usar Scrum

E aí, vamos separar um tempinho para reler as 16 páginas do Scrum Guide?

Bom, e esse é o problema. A priorização com base em **opiniões **(que geralmente têm um peso proporcional ao peso do crachá de quem opina). Quando de alguma forma conseguimos tangibilizar o valor de cada item de nosso Product Backlog a discussão se torna muito mais racional.

Uma forma de entender melhor o valor de cada funcionalidade vem através de um simples questionamento: quanto estamos perdendo por ainda não ter entregue este item?

Responder esta pergunta nem sempre é fácil, e muitas vezes implica em um muito trabalho de pesquisa. O importante é lembrar sempre que nem sempre estamos em busca de uma informação super precisa aqui. O propósito de entender o valor de cada item está em nos ajudar a tomar uma decisão racional.

Por exemplo: digamos que um determinado item vai me render entre R$30.000,00 e R$ 200.000,00. Esta faixa é muito ampla e pode parecer ter pouco valor, mas se eu sei que o custo do item não deve exceder R$ 15.000,00 eu já sou capaz de tomar uma decisão e não preciso investir mais tempo refinando minha pesquisa para diminuir este intervalo.

Cada item pode ter um custo de atraso em um formato diferente: alguns tendem a crescer linearmente e outros exponencialmente. Há ainda aqueles com uma data fixa, como a adequação a alguma lei com data para entrar em vigor e outros cujo custo não tem uma relação tão relevante com o tempo de atraso. Entender quais tipos de item você tem em seu Product Backlog é o primeiro passo para racionalizar seu processo de priorização.

O tipo de item mais comum de se encontrar em um Product Backlog são aqueles cujo custo de atraso tende a aumentar com o tempo, seja de forma linear ou exponencial. Imagine um produto com os seguintes items em seu Product Backlog:

Cada item tem um custo estimado por semana de atraso e um tempo estimado de desenvolvimento. Se dividirmos o custo de atraso pela duração de cada item chegamos ao famoso CD3: Cost of Delay Divided by Duration (custo de atraso dividido pela duração).

Mas por que esse tal de CD3 é importante? Para responder essa pergunta, vamos tentar priorizar este backlog de três maneiras diferentes.

Priorização por tamanho

Se optarmos por entregar primeiro os itens menores, nossa curva de entrega ficaria mais ou menos assim:

Na primeira semana teríamos um custo de atraso equivalente a todos os itens somados (2.000 + 5000 + 6000 + 1500), afinal não entregamos nada.

Ao final da semana 1 conseguimos entregar o item Notificações (que foi priorizado por ter a menor duração) e com isso diminuímos nosso custo de atraso total em 2.000. E aí é repetimos este processo para os próximos items do Product Backlog.

No final das contas, temos o seguinte cenário:

• 1 semana com custo de atraso total de 14.500

• 2 semanas com custo de atraso total de 12.500

• 3 semanas com custo de atraso total de 11.000

• 4 semanas com custo de atraso total de 6.000

Neste cenário nosso custo de atraso total foi de:

(1 x 14.500) + (2 x 12.500) + (3 x 11.000) + (4 x 6.000) = 96.500

Priorização por valor

Quando priorizamos por valor a coisa muda um pouco de figura:

• 4 semanas com custo de atraso total de 14.500

• 3 semanas com custo de atraso total de 8.500

• 1 semanas com custo de atraso total de 3.500

• 2 semanas com custo de atraso total de 1.500

Neste cenário começamos a trabalhar com o item APP por ser o que tem o maior custo de atraso por semana. Ao final temos um custo de atraso total de:

(4 x 14.500) + (3 x 8.500) + (1 x 3.500) + (2 x 1.500) = 90.000

Priorização por CD3

A priorização por valor gerou um resultado um pouco melhor, mas ainda temos espaço para melhorias. Veja o que acontece quando priorizamos pelo CD3:

• 1 semana com custo de atraso total de 14.500

• 3 semanas com custo de atraso total de 12.500

• 4 semanas com custo de atraso total de 7.500

• 2 semanas com custo de atraso total de 1.500

(1 x 14.500) + (3 x 12.500) + (4 x 7.500) + (2 x 1.500) = 85.000

Uma boa redução não é mesmo? E um ótimo exemplo de como uma pessoa que atua como Product Owner pode causar um impacto muito positivo no desenvolvimento de um produto!

Conclusão

Saber priorizar bem é importante, e para fazer isso sempre vai ser necessário ter uma boa noção do valor de cada item de seu Product Backlog.

Fórmulas como o cálculo do CD3 podem ajudar bastante uma vez que você tenha dado o primeiro passo: ter esta noção de valor. Mas este primeiro passo é muito dependente da aproximação do Product Owner com o mercado e o bom entendimento dos problemas de seus clientes. E bem, para isso não tem uma fórmula mágica. :)

Um jeito simples de fazer isso é ter critérios chave para que o time possa avaliar qualitativamente a Sprint que se passou. Mas quais critérios chave devemos utilizar?

Daniel Pink define através de experimentos em seu livro Drive que a Autonomia é um dos três pilares que sustentam a motivação das pessoas no trabalho. Podemos nos valer deste conceito para criar um modelo de retrospectiva mais participativa em 4 passos:

1 — Peça para o time pensar em critérios chave

Estabeleça um limite de tempo curto e escreva juntamente com o time quais fatores influenciam a qualidade do trabalho da equipe.

Lembre-se que a participação de todo o time Scrum é fundamental durante todas as etapas.

2 — Limite os critérios chave

Você pode usar dot voting para limitar os critérios chave que serão utilizados caso seja necessário. O ideal é ter entre 5 e 10 critérios ao final desta etapa.

Importante: Você pode optar por fundir 2 ou mais temas caso eles sejam muito parecidos, apenas lembre-se de fazer isso antes da votação.

3 — Peça para que cada membro do time avalie a última Sprint de acordo com os critérios mais votados

Aqui não precisamos fazer uma análise super detalhada. Podemos utilizar 3 níveis de satisfação, como um semáforo.

Exemplo: Uma pessoa pode votar verde para o critério Interrupções se acredita que foi pouco interrompida na Sprint passada.

Apenas atente-se para dois detalhes: certifique-se de que ninguém no time tenha dificuldades para distinguir as cores selecionadas e garanta que todos os membros avaliaram todos os critérios eleitos.

4 — Avalie junto com o time a evolução ao longo das Sprints

Um dos principais benefícios desta técnica é poder debater com o time o que tem influenciado cada a avaliação de cada critério, e ter um pequeno histórico pode ajudar bastante a perceber algumas tendências e possíveis correlações.

Olhar para uma avaliação conjunta de critérios que o próprio time estabeleceu é uma ótima forma de quebrar o gelo inicial de uma retrospectiva.

Esse pode ser o empurrãozinho inicial que o time precisa para começar a propor ações e experimentos com potencial para aprimorar sua forma de trabalho.

Como as coisas funcionavam

Desde 2014 eu tenho ministrado turmas da certificação CSD (Certified Scrum Developer), e a minha primeira versão do treinamento era composta por incríveis 271 slides. Pode parecer um exagero, mas o curso tinha 40 horas de duração divididas em 5 dias. Isso dá aproximadamente um slide para cada 10 minutos de curso.

Na Facta temos vários quadros brancos à disposição no escritório, mas a coisa mais complexa que eu chegava a rabiscar eram fluxogramas com 7 ou 8 etapas.

O incômodo com as apresentações

Eu já não estava feliz com o Powerpoint e vivia buscando novas formas de organizar e apresentar o conteúdo dos meus cursos e palestras.

Tentei utilizar o Prezi e fiquei muito impressionado com os resultados, até me dar conta do tempo que gastava cada vez que precisava criar ou editar uma apresentação.

Aí descobri o HaikuDeck e me apaixonei pela abordagem simples, mas acabei largando ele de lado por causa dos tempos de loading e por conta do visual dos arquivos PDF que ele exportava.

Então tentei utilizar o reveal.js e achei incrível a idéia de montar minhas apresentações escrevendo arquivos Markdown que eu poderia armazenar em repositórios git (se você não entendeu nada desta última frase, não se preocupe), mas percebi também o quão difícil era rodar a apresentação em outros computadores ou ensinar outras pessoas a editar aqueles arquivos.

Bom, aí eu desisti.

Quando tive o “estalo”

Em junho de 2018 eu estava explicando um conceito para os alunos de uma turma de CSD em Lisboa e acabei desenhando algo no flipchart. Quando me preparava para virar a página, um dos alunos me pediu para esperar enquanto ele tirava uma foto do desenho que eu havia feito. Obviamente eu deixei que ele tirasse a foto antes de virar a página, mas a vergonha veio assim que percebi qual lembrança ele levaria do meu treinamento:

Acredite ou não, o desenho mostra uma estátua iluminada por dois postes de luz

Neste momento decidi que eu precisava desenhar um pouco melhor. Pode parecer um tanto quanto óbvio (porque é), mas foi aí que percebi que desenhos poderiam ser uma ótima forma de comunicar ideias e transferir conhecimento para os alunos.

O único problema é que eu não sabia desenhar. Ou pelo menos eu acreditava nisso.

Como comecei a aprender?

Passo 1: Assisti a alguns vídeos no do Graham Shaw no YouTube (este aqui em particular foi o que mais me chamou a atenção)

Passo 2: Comprei um cursona Udemy, chamado Drawing for trainers, leaders and presenters, do Alex Glod

Passo 3: Comprei um iPad Pro e um iPencil

Tudo bem, eu comprei muitas coisas e algumas delas não são exatamente baratas. Mas elas serviram para acelerar meu processo de aprendizado, e depois de um mês tempo eu já era capaz de fazer algo assim:

Sim, o reflexo no espelho está errado, eu sei :)

Eu estava quase confortável o suficiente para testar meus desenhos na sala de aula, e havia decidido que eu faria um experimento na minha próxima turma: não usaria nenhum slide. Aliás, eu nem levaria o computador para o treinamento.

Mas antes disso eu testei minha nova habilidade em um Factalk, uma apresentação de 30 minutos que fazemos na Facta às sexta-feiras. Afinal, eu definitivamente não encontraria um ambiente mais seguro que esse para fazer este experimento.

Quantos “slides” você consegue ver de uma só vez?

E no segundo mês de aprendizado eu adicionei pincel preto, papel, giz de cera e fita adesiva ao meu arsenal.

No final da sessão, 19 “slides” ficaram visíveis ao mesmo tempo na parede ao lado do fliperama, e a interação entre os participantes foi muito mais natural. Se a apresentação fosse em formato digital apenas 1 slide estaria visível por vez, ou seja, aproximadamente 5% do conteúdo. Ou no caso do meu CSD com 217 slides, menos de 0,5%.

O feedback que tive depois desta apresentação me deu a confiança que faltava para testar esta abordagem na minha próxima turma.

A primeira turma sem slides

O notebook saiu da mochila e deu espaço às canetas e conjuntos de giz de cera, e depois de 10 horas de vôo eu estava confiante para testar minhas habilidades pela primeira vez. Bem… mais nervoso do que confiante, mas pronto.

Logo no começo da minha primeira turma sem slides reparei um grande benefício sobre as aulas sem slides: várias dependências foram removidas quando deixei o computador em casa.

• Preciso levar um adaptador HDMI-VGA?
• O projetor usa formato 4:3 ou 16:9?
• Que tipo de tomada eles usam neste país? Será que o WiFi lá funciona bem e sem restrições de acesso?
  
  

Não era incomum precisar pedir socorro durante os treinamentos em função destes detalhes. Certa vez em 2014 um projetor parou de funcionar e acabou atrasando e desmotivando consideravelmente uma turma minha.

Mas com papel, canetas e giz de cera eu tinha uma preocupação a menos. E com eles, eu podia criar meus slides sob demanda.

Comecei a usar margens e conectar elementos, mas as cores…

Eu mantive o time que estava ganhando e não usei nada além de caneta preta e giz de cera, mas comecei a arriscar novos formatos e a juntar formas (como o boneco carregando a caixa 21).

Criar slides sob demanda foi um novo benefício que percebi neste tipo de apresentação. Às vezes os alunos perguntam algo que está respondido em um determinado slide da apresentação, e ao invés de navegar pela apresentação para descobrir se o slide em questão é o 37 ou 129 eu podia apenas caminhar pela sala e apontar para uma folha colada na parede para recapitular os conceitos do mesmo. Ou desenhar uma nova folha caso fosse necessário.

Outras duas situações me chamaram a atenção durante esta turma:

• Um aluno precisou voltar mais tarde do almoço, e quando voltou notou que havia uma folha nova colada na parede. Ele imediatamente me perguntou se eu podia resumir o que havia sido explicado ali.
  
  
• Como o treinamento em questão tinha 2 dias de duração, os alunos utilizavam os primeiros 5 minutos da segunda manhã caminhando pela sala e relembrando os conceitos resumidos em cada flipchart colado nas paredes.

Os desenhos não eram obras de arte, eles apenas comunicavam idéias de uma maneira agradável e eficaz.

Eu fiquei impressionado com o feedback que recebi desta turma. Apesar dos desenhos serem extremamente rudimentares, todos os estudantes citaram o formato do treinamento em um tom muito positivo. Isso me motivou a tentar levar essa nova habilidade para um próximo nível.

O próximo passo

No quarto mês eu já tinha adquirido algum vocabulário visual, mas me faltava tratar melhor as cores e a organização de idéias no flipchart. Foi então que ganhei da minha namorada um livro chamado UZMO, do Martin Haussmann. Comprei também um conjunto de canetas da Neuland e comecei a estudar a técnica Bikablo.

Além de aprender mais sobre cores e organização de idéias, descobri que o cinza é a cor mais importante para se ter na caixa de ferramentas. Ele me ajudou a compor e sobrepor novos símbolos, e transformou cada flipchart meu em uma espécie de infográfico capaz de resumir os conceitos que eu transmitia de uma forma nova e extremamente agradável.

Menos cores, mais informações e muita composição

Em 4 meses eu deixei de ter vergonha dos meus desenhos e passei a ver pessoas guardando os flipcharts ao final das turmas para decorar o escritório onde trabalham.

Levou algum tempo e esforço, mas foi muito mais rápido do que eu imaginava. Na verdade, eu nem imaginava que isto seria possível.

Atualmente eu desenho para tomar notas durante reuniões, durante meus treinamentos, ilustro minhas próprias apostilas e até crio apresentações desta maneira.

Eu precisei de 4 meses para sair da primeira foto deste post e chegar até a última. Eu sei que ainda há muito a ser aprimorado, mas tenho certeza de que compartilhar este progresso pode motivar várias pessoas que acreditam cegamente que “não sabem desenhar ”.

Se você é uma dessas pessoas, eu lhe desafio a fazer um teste.

E espero ver um de seus desenhos daqui há 4 meses!

RESUMINDO

1- Você consegue desenhar, só precisa de prática.

2- Assista aos vídeos do Graham Shaw no YouTube

3- Construa seu Vocabulário Visual (talvez com este curso)

4- Pesquise sobre a técnica Bikablo na internet

5- Seu objetivo é comunicar idéias de maneira rápida e eficaz, não fazer arte. Não tente ser melhor que o Leonardo da Vinci.

6- Pesquise e siga Graham Shaw, Alex Glod and Martin Haussmann.

7- Compre um pincel preto, um caderno sem pautas, um conjunto de giz de cera e pratique cerca de 30 minutos por dia.

PS: Quase um ano se passou desde que escrevi o post original em inglês. De lá pra cá, eu criei e ilustrei um jogo de cartas para ensinar Scrum e gravei cursos ilustrados sobre agilidade em parceria Emergee e Alura que hoje contam com mais de 70 mil alunos inscritos!

Este texto é uma tradução de um post escrito por mim em 2014 aqui no Medium, em inglês. Link original: Medium

Errar ou não errar, eis a questão

Enquanto seres humanos, todos somos propensos ao erro. No entanto, muitos têm dificuldade de aceitar isso.

Quando você dá o seu melhor para alcançar um objetivo e eventualmente as coisas não saem como o planejado, o que acontece?

Você já se prepara para algum tipo de penalidade que vem pelo caminho?

Ambientes sem espaço para erros

Qualquer que seja sua resposta para a pergunta, ela foi pelo menos parcialmente criada pelo ambiente no qual você viveu até agora.

Você foi livre o bastante para falhar enquanto era jovem?

Você trabalha em uma empresa onde as pessoas são punidas quando se enganam?

Você se sente confortável quando encara pessoas que decepcionou?

Um ambiente onde falhas não são toleradas limita experimentos: tudo precisa dar certo, e quando isto não acontece alguma pessoa será penalizada. Esta penalidade pode vir em forma de demissão, palmadas dos pais ou até mesmo o fim de relacionamentos.

Você sabe bem do que estou falando.

Você está errado. Que vergonha!

- Nós mesmos

Se você já passou por este tipo de ambiente (e as chances são bem grandes) você sabe o quanto precisa pensar e calcular antes de dar cada passo para frente. Ou para trás. Você precisa pensar e repensar cada movimento, pois se você falhar a punição estará logo ali lhe esperando.

As consequências das condenações

Bem, se você olhar na face do mal, o mal estará olhando de volta para você. E quando lhe tiram o direito de falhar você pode começar a achar isso natural e replicar o mesmo comportamento.

Digo isso porque isso aconteceu comigo, e na medida em que comecei a tentar reverter o problema percebi algumas consequências diretas deste tipo de cultura.

Estagnação

Nós geralmente evoluímos por tentativa e erros. E aceitamos conceitos aprendidos na prática mais facilmente do que aqueles aprendidos pela teoria.

Por que nós caímos, mestre Bruce? Para podermos aprender a nos levantar novamente.

- Alfred Pennyworth

Na empresa onde trabalho estamos sempre nos incentivando a tentar coisas novas. Independentemente do que venha à cabeça, todos se sentem livre para propor e contestar idéias com qualquer um. Falhas são toleradas desde que possamos aprender alguma coisa com elas, e isto nos tem feito evoluir de maneira rápida e constante.

Se ninguém tivesse esta liberdade para falhar, perderíamos nossa autonomia e auto-confiança para tentar novas idéias e provavelmente ainda estaríamos presos em 2011 (Data de fundação da empresa).

Procrastinação

Eu não posso falhar, então preciso trabalhar nisto até ficar perfeito. E não importa quanto tempo leve.

Eu quero um novo engano, perder é melhor que hesitar

— Queens of the Stone Age

Certa vez trabalhei em um projeto que visava aprimorar um indicador interno de uma empresa de 10% para 90%. Depois de 5 meses de trabalho o projeto já era capaz de aumentar o indicador para algo próximo de 65% caso fosse implantado.

Os responsáveis pelo projeto preferiram não implantar enquanto não fosse possível chegar os 90% desejados. Isto durou 2 anos inteiros.

Durante 2 anos a empresa continuou com seu indicador na casa dos 10% enquanto poderia ter algo próximo de 65% porque ninguém quis dizer “ Ei, ainda não foi possível chegar nos 90%, mas podemos começar com 65% e evoluir aos poucos ”.

E provavelmente teriam alcançado os 90% muito mais rapidamente se tivessem arriscado.

Mas falhar era pesado demais. E demorar pra falhar faz com que demoremos para evoluir.

Mentiras e Apatia

A casa está em chamas mas ninguém tem coragem de chamar os bombeiros. Inclusive, parece que jogaram o isqueiro fora porque ele poderia ligar alguém ao foco do incêndio.

Não fui eu

- Shaggy

É difícil encontrar alguém com mais informações sobre um problema do que a pessoa que o criou inicialmente. Se esta pessoa se sentir confortável o suficiente para assumir o erro, sua ajuda pode ser crucial para a solução do mesmo.

Quando não há espaço para erros eles não desaparecem, eles apenas somem de vista: vão para debaixo do tapete.

É por isso que retrospectivas são essenciais: elas abrem um espaço para falarmos sobre nossos erros e aprender com eles. É onde aprendemos a limpar a poeira que às vezes fica acumulada embaixo do tapete.