Você é uma pessoa perita em acumular dívida técnica e eu vou te provar hoje!

Contexto

Você provavelmente tem um smartphone e deve utilizá-lo para tirar fotos, fazer vídeos e acessar alguma rede social. Além disso, você deve utilizar algum app estilo Whatsapp e Telegram para “falar” com seus contatos/amigos. Até o momento, acertei?

Agora vamos aumentar o contexto: provavelmente no seu smartphone tem uma camera com uma boa resolução para fotos e nele tem um espaço razoável de armazenamento (mais de 32 GB). Além disso seu smartphone está com a opção de armazenar fotos na nuvem para você nunca perder os momentos mais legais!

No ínicio de uso do smartphone tudo está tão bem! Tudo abre rápido! Passam meses e você continua tirando fotos, fazendo vídeos, recebendo e enviando arquivos no “zap” e assim vai! Até que chega um momento que a nuvem hospedeira (tipo o da Google) te manda esse alerta!

E agora o que fazer???

São quatros alternativas:

1. Comprar mais espaço na nuvem!!! ☁
2. Comprar um celular novo! $$
3. Deixa do jeito que tá! Não vai parar nada! 🤡
4. Entender quais arquivos estão ocupando espaço desnecessário na nuvem, parar um tempo e remover os arquivos desnecessários. E repetir isso pelo menos 1x todo mês. Além disso, também arrumar as configurações para não encher a nuvem de novos itens desnecessários.👀👀

Pois bem, a resposta da maioria das pessoas não é a opção 4, sendo que é a opção mais barata ao longo do tempo!

Esse pequeno exemplo é uma boa metáfora para você entender o que é dívida técnica. De tanto não termos a disciplina de apagar coisas inúteis, a gente vai acumulando arquivos até que chega um momento em que acaba ficando caro para continuar a usar o celular pois ele não atende mais a expectativa do dono, pois o celular está lento, sem espaço, não grava mais vídeos, etc.

Quando trazemos isso para o mundo de software, chamamos isso de dívida técnica, que são tipo “sujeiras” ou más práticas. Inicialmente, elas não atrapalham o funcionamento do software, mas com o passar do tempo, elas vão se acumulando e começam a deteriorar o sistema. É semelhante a juros mensais que se acumulam em uma dívida bancária. Se você não pagar os juros, você conseguirá mais investir em nada.

Um dos motivos para ser tão díficil melhorar um software, é por que ele está cheio de dívida técnica, ou seja, o código não é simples, sem testes automatizados, sem padrão e cheio de outras más práticas. No gráfico abaixo, Jim Highsmith apresenta o custo da mudança. Toda mudança em software custa ($$) mas se você não cuida da sua dívida técnica, vai custar mais do que o valor ideal.

E no smartphone??

No exemplo do celular, nos pagamos a dívida técnica, removendo as fotos inuteis, por exemplo.

Sabe aquelas fotos desfocadas e repetidas? Remova elas!

Sabe os vídeos do zap e as fotos que chegam em todos os grupos?? Remova elas!

Sabe aqueles prints de tela que você usou uma vez e nunca mais usou? Remova eles!

REMOVA tudo aquilo que não gera valor nenhum e ocupa espaço de memória

Mas para fazer isso, leva tempo (as vezes horas, dias, meses). Mas se você não começar a pagar sua dívida técnica, nunca vai melhorar!!!!!

Os brasileiros estão levando mais tempo para trocar de celular e gerenciar sua dívida técnica nele vai te ajudar a não precisará gastar com um smartphone novo antes do tempo. Para saber mais sobre o comportamento de brasileiros e celulares, veja essa notícia:

Brasileiros ficam mais de dois anos com o mesmo celular, indica pesquisa

Espero que tenha gostado e se você se identificou com algo, deixe um comentário!

Mas Fusca, não é débito técnico??? Se você chegou até aqui com o conceito de débito técnico, você deve ler esse post !

Como acabar com seu débito técnico!

Pair programming — materiais confiáveis para lhe ajudar nesse tema

Parear ou não parear? Aqui você encontrará embasamento para tomar essa decisão!

Breve explicação. Se você já conhece a prática, pode pular essa parte!

Trabalhar em par é uma prática descrita em XP (eXtreme Programming) e ela é uma alavanca poderosa para promover a propriedade coletiva de código fonte.

No pareamento, duas pessoas estarão trabalhando na mesma tarefa e no mesmo computador durante uma fração de tempo (pode ser horas ou dias ou semanas). Após essa fração de tempo, sugere-se trocar a dupla, ou seja, realizar o move people around, que é outra prática de XP.

No pair programming, uma pessoa começa no teclado (na função driver, ou seja, digitará o código) e a outra pessoa irá fazer o papel de navegador (navigator), dando as instruções de como resolver o problema. De tempos em tempos (25 min, por exemplo), os papéis se invertem. Durante a codificação, utiliza-se testes unitários para garantir a qualidade do trabalho.

“Duas pessoas na mesma tarefa??? Isso é desperdício!!!”

Esse questionamento é feito com frequência por lideranças quando surge a ideia de utilizar essa prática para determinadas tarefas. Pensando nisso, preparei um conjunto de conteúdos relevantes e com profundidade para te dar mais segurança na hora de adotar essa prática.

[TL;DR]:

• O que é programação em par e quais são seus benefícios?
• Razões para você não caminhar numa jornada solitária na programação
• Parear consome 15% a mais de tempo total de trabalho mas reduz, pelo menos, 15% a quantidade de códigos com defeito
• Pareamento acaba com o comportamento isolado e de ego do programador e ativa áreas cerebrais que não são ativadas enquanto se programa solitariamente
• Conselhos e lições aprendidas ao realizar pareamento
• Parear numa visão de neurociência
• Case de sucesso e pontos de atenção do pareamento — Objective
• Case de redução de bugs e aumento de vazão de tarefas com pareamento — LuizaLabs
• Case de sucesso de TDD e Pair programming, afetando a cultura organizacional — Ateliê de Software
• Ao invés de parear, por que não todos do time trabalhando ao mesmo tempo na mesma tarefa (mob programming)?

Parear consome 15% a mais de tempo total de trabalho mas reduz, pelo menos, 15% a quantidade de códigos com defeito

Em fevereiro de 2000, surgiu o primeiro estudo sobre os benefícios da programação pareada. Alistair Cockburn e Laurie Williams realizaram um estudo analisando a quantidade de tempo que o pareamento consome. Foi descoberto que a diferença de tempo é de 15% a mais frente ao trabalho solitário e não o dobro do tempo, como costuma-se afirmar.

Além disso, foi percebido aumento na qualidade de código (ou seja, menos bugs), menos linhas de código (mais simplicidade) e maior satisfação do time ao trabalhar com pareamento.

Pareamento acaba com o comportamento isolado e de ego do programador e ativa áreas cerebrais que não são ativadas enquanto se programa solitariamente

Em 2016, Jon Jagger apresentou no NorDevCon uma palestra sobre pair programming e nela ele apresenta o conceito Egoless e como a programação pareada pode ajudar para que esse conceito seja aplicado a sua cultura organizacional.

Ele também apresenta como a troca de informações no pareamento ativa partes do cérebro que ficam “dormentes” quando você programa sozinho.

Além disso, ele referencia o estudo de produtividade e qualidade citado no tópico acima.

Pair Programming

Conselhos e lições aprendidas ao realizar pareamento

No link abaixo você encontrará diversas informações sobre programação pareada, padrões e antipadrões dessa prática.

GitHub - BillSchofield/pair-programming-advice

Parear numa visão de neurociência

Gisele Morilha Gonçalves realizou um estudo aplicando neurociência com a prática ágil de programação pareada. Os resultados podem ser assistidos no vídeo a seguir:

Razões para você não caminhar numa jornada solitária na programação

Ron Jeffries escreveu 12 tweets refletindo sobre o trabalho solitário de programação. Na imagem abaixo você encontrará a primeira parte, para conferir os outros 11 tweets, acesse o link https://twitter.com/RonJeffries/status/1114808214648967168?s=20

Ron Jeffries on Twitter: "There are a couple of threads going on just now about pairing, mobbing, working together, etc. Some well-reasoned, and some, well, "reasoned" comments address that some people feel more productive working "solo", and, who knows, for values of "productive", they might be.1/12 / Twitter"

There are a couple of threads going on just now about pairing, mobbing, working together, etc. Some well-reasoned, and some, well, "reasoned" comments address that some people feel more productive working "solo", and, who knows, for values of "productive", they might be.1/12

Case de redução de bugs e aumento de vazão de tarefas com pareamento — LuizaLabs

Victor Castanheiro e Rafael Raza de Campos compartilharam o case deles na LuizaLabs. Nesse case, eles aplicaram programação em par e tiveram redução de bugs (código com defeito) em 75% e com menos bugs, foi possível entregar mais tarefas de valor a cada semana.

Os aprendizados foram tantos que até o formato da mesa foi alterado para ter maior efetividade na programação em par.

Case de sucesso de TDD e Pair programming, afetando a cultura organizacional — Ateliê de Software

Aline Garcia e Matheus Haddad do Ateliê de Software, apresentaram um case sobre o impacto da adoção do pair programming e TDD no dia a dia da empresa. Ao adotar ambas as práticas, a cultura de aprendizado é desenvolvida, junto com a autonomia.

Case de sucesso e pontos de atenção do pareamento — Objective

A empresa Objective tem um case detalhado de como foi escalado o ágil dentro de suas equipes de software através da adoção de diversas práticas ágeis, dentre ela o pareamento de software e testes unitários. No vídeo abaixo você vai ouvir a trajetória de erros e sucessos com pair programming.

O que é programação em par e quais são seus benefícios?

Nesse material, andrefaria descreve de o que é a programação em par, quais áreas do cérebro são ativadas com essa prática e como ela ajuda você a chegar no Flow State.

Ao invés de parear, por que não todos do time trabalhando ao mesmo tempo na mesma tarefa (mob programming)?

Woody Zuill é o criador do Mob Programming. Ele esteve no Agile Brazil de 2019 compartilhando sobre essa prática. A palestra está disponível no link abaixo e você entenderá como Mob pode reduzir o leadtime das tarefas e aumentar a qualidade do trabalho.

Com Mob Programming, todas as pessoas de um time estarão numa mesma sala e no mesmo computador, resolvendo um único problema. Com isso, o tempo de interrupções será próximo a zero, não existindo desperdício.

Tim Ottinger, escreveu uma série de dicas para realizar mob programming de forma efetiva.

A Few Tips for Mob Programming

Caso você tenha outros links de conteúdos sobre programação pareada, adicione nos comentários!!! Até a próxima!

Frustrações de uma pessoa desenvolvedora — tema: estimativa

“Eu não acho estranho uma pessoa errar uma estimativa. Acho estranho acertá-la com frequência” Rodrigo Yoshima

Esse é o segundo post de uma série de postagens que relatam situações que acontecem no desenvolvimento de software, mas com a visão de quem coloca a mão em código fonte. O primeiro post pode ser conferido nesse link e fala sobre qualidade.

O tema de hoje será contado por mim e pelos meus amigos Daniel Wildt (linkedin), Guilherme Motta, Lucca Bonifácio Roder(linkedin) e Vinicius Campos Silva(linkedin) e um relato anônimo. Cada uma dessas pessoas tem uma história incrível e que merece a sua atenção e leitura concentrada.

Meu relato:

É segunda feira, 9h da manhã. Já estou com meu café e vou para a sala de reunião para aquela “alegre” reunião chamada planning. Já sei que vou ouvir o PO por 1h, mas minha mente vai entender só os primeiros 15 min que ele falar. E na sequência vamos ter que jogar o nosso baralho mágico, chamado planning poker.

Passada uma hora de explicação, o SM pergunta: “Alguma dúvida?” e ninguém fala nada. Então o SM fala: “vamos lá, escolham suas cartas”.

Eu olho pro lado, em busca de ver o que o meu amigo vai selecionar, afinal de contas, não quero passar vergonha e ser o único que vai jogar uma carta alta (tipo pontuação 20) e também não quero colocar uma carta de interrogação, pois o pessoal vai achar que eu sou burro. Mas uma coisa é certa, eu não entendi nada.

Chegou a hora de revelar os votos. Todos colocam 20 pontos!!! O PO se assusta e fala: “gente… não é tudo isso não, será que não é 8 ou 13??? Vai lá gente, vocês são feras demais, 20 é muito para um time tão bom quanto o de vocês.”

A gente finge que acredita no elogio. Eu respiro fundo e falo: “tá bom… é sempre assim… vai 13 então”. O PO e o SM comemoram. Eu só penso em acabar logo essa reunião chata.

Daniel Wildt

Já disse que uma feature levaria 248 horas e meia. E MEIA. E essa era a estimativa pessimista. :P

Teve um outro caso de uma feature que terminei em 1/3 do tempo previsto e me pediram pra não sinalizar que estava pronto, para não gerar questionamento sobre a estimativa errada. :)

Anônimo

A história frustrante que vivi com estimativa é sobre o uso de ponto de função para estimativa de software. A gestão desejava que as contagens fossem feitas, entretanto, ninguém acreditava nessa estimativa, nem o time de desenvolvimento e nem a área de negócios.

A gestão desejava que as contagens fossem feitas, entretanto, ninguém acreditava nessa estimativa, nem o time de desenvolvimento e nem a área de negócios.

Mesmo tentando trazer o contexto de métricas estatísticas para os times como o leadtime, throughput e wip, não conseguimos força para evoluir por que existia esse apego da alta gestão para usar o ponto funcional como estimativa.

O time calculava o ponto funcional para agradar a gestão, mas não usava a informação para nada. Era passada outras estimativas para o negócio que também não era pautada em dados históricos. Continuamos com problemas de confiança entre negócio e TI, negócio falando que TI nunca entrega no prazo e TI sempre falando que negócio muda o tempo todo.

Guilherme Motta

Alguns anos atrás, nossa equipe no Brasil trabalhava remotamente com uma grande empresa americana. Iniciamos um projeto com um time distribuído entre Brasil e EUA.

Nesta equipe, que já havia trabalhado junta em outros projetos, já trabalhávamos conceitos relacionados a métodos ágeis (e boas práticas de engenharia de software) e na época esse cliente estava tendo boas experiências trabalhando com Scrum.

Eventualmente, a pessoa responsável pela gestão desse projeto apresentou um plano, distribuindo o escopo conhecido em 9 meses, 18 sprints de duas semanas.

O backlog havia sido todo estimado pelo time utilizando Planning Poker e as estimativas foram feitas baseadas em esforço, resultando em números da sequência Fibonacci que pareciam fazer sentido.

Ao final do primeiro Sprint, algumas conversas estranhas aconteceram:

• Incluímos na nossa velocity trabalho parcialmente completo
• Quebramos histórias de usuário para “captalizar” na entrega da Sprint trabalho que não havia sido concluído
• Adicionamos novas tarefas, com estimativas atribuídas depois do trabalho feito
• entre outras bizarrices..

Ao final do primeiro Sprint, o time havia entregue exatamente X pontos, e para minha surpresa, era exatamente o número de pontos que havia sido proposto no planejamento do projeto para a entrega da primeira Sprint.

Ao final do segundo Sprint, mesma coisa. Criação de novas User Stories, remoção de tasks, movimentação de escopo entre Sprints, qualquer coisa para chegar no tal número planejado para a velocity da segunda Sprint.

E assim foi o projeto, 9 meses e 18 sprints onde foi entregue exatamente o número de pontos planejado 9 meses antes.

A pessoa responsável pelo projeto recebeu um prêmio/reconhecimento ao final do trabalho por excelência em planejamento, gestão e estimativa.

Na realidade, o que de fato ocorreu, é que nossas métricas e reportes tinham como objetivo se alinhar com o plano inicial. O time percebeu mas optou por ignorar e fazer o melhor possível para entregar valor para o nosso no cliente.

Este projeto, foi uma das experiências que me estimulou a aprender mais sobre gestão e um grande aprendizado sobre o que não fazer.

Lucca Rodder

O que falar sobre estimativa???? Olha confesso que é algo que me causa ansiedade mas, gosto de compartilhar minhas experiências e meu ponto de vista sobre o assunto rs.. Vamos lá…

Olha para ser sincero as experiências não foram tão boas, primeiro que a maioria dos projetos já tinham prazos definidos e segundo as pessoas desenvolvedoras mais experientes analisavam o projeto antes da própria equipe e davam uma estimativa "aproximada" baseados em experiências próprias, isso é muito crítico pois, nem sempre essas pessoas que deram essa estimativa "aproximada" participavam de fato da equipe que participava do desenvolvimento, ou seja, quando projeto ia para equipe que iria desenvolver geralmente já chegava com prazo "mais ou menos" definido e a estimativa das funcionalidades parecia para mim algo apenas para cumprir um protocolo e uma tentativa de achar um meio termo para o prazo final da entrega.

Um ponto muito difícil nisso tudo são os imprevistos e as mudanças no meio do desenvolvimento, não pelas mudanças que essas são comuns mas, por entrar mais coisas no backlog para a sprint atual e não despriorizar outras tarefas fazendo com que tivéssemos vários atrasos nas entregas. Um problema para mim é o desgaste emocional que isso causava, toda retrospectiva parece ser uma lavação de roupa suja e nós sempre escutarmos a frase dos nossos líderes "Mas vocês estimaram", isso me deixava com a sensação de que a estimativa no projeto era exclusivamente para achar culpados pelas falhas e que os líderes não caminhavam lado a lado com as pessoas desenvolvedoras.

A lição aprendida por mim é que uma maneira assertiva de se fazer uma estimativa é usarmos como base outros projetos já trabalhados que possuem tech stack semelhantes, a senioridade do time semelhante e os desenvolvedores do projeto estimarem. Não podemos estimar apenas como base na nossa própria experiência mas, olhar o cenário em volta e responder algumas perguntas tais como:

• Quantas pessoas possuem uma experiência alta nessa tech stack?
• Quantas pessoas já desenvolveram funcionalidades parecidas com essa?
• Como podemos durante o projeto ajudar as pessoas a se desenvolverem?
• Caso as pessoas mais experientes do projeto tiver um imprevisto, os outros membros do time conseguiriam fazer essa tarefa nesse mesmo tempo?
• As histórias estão prontas para desenvolvimento, ou está faltando informações muito importantes?
• Como está a saúde emocional da equipe?

O segredo é questionar muito, pensamento coletivo e liderança apoiando. Quando uma pessoa percebe que possui um suporte o trabalho flui muito melhor.

Os desenvolvedores do projeto sabem muito bem quantas histórias cabem em sprint e quanto tempo leva para desenvolver as funcionalidades.

Tem uma frase que gostaria de deixar aqui.

Se você não é uma das pessoas que coloca a mão no código no projeto, você não está apto a opinar sobre quanto tempo leva para transformar uma tarefa em código para esse projeto.

Vinicius Campos

Compartilhando um pouco sobre as estimativas na época em que eu trabalhava em consultoria. Costumava ser frustrante e acredito que muito próxima a realidade de outras pessoas. Em uma das minhas experiências profissionais, tínhamos que estimar a escrita das documentações técnicas e funcionais, analisar todas as linhas de classe/métodos que seriam alteradas, a prática de testes sempre era considerada metade do tempo de desenvolvimento, além de considerarmos suporte ao cliente no pós-entrega e ao final da “estimativa” a nossa planilha de estimativa adicionava 20% de tempo para garantir uma “segurança” para o prazo. Lembro de discussões nossas para aumentar horas em um lugar e colocar em outro para “facilitar” a aprovação, não considerando a nossa real capacidade de absorver o projeto. Ou seja, passava uma falsa sensação de que tudo estaria sob controle.

Essa estimativa passava pela aprovação do cliente, que algumas vezes pedia para reduzir a estimativa dos testes/suporte ou até mesmo removê-la para ficar mais barato. Eu pensava o quão custoso e sustentável seria este tipo de comportamento a longo prazo.

Além disto, tínhamos que registrar diariamente as horas empregadas no projeto, que apenas serviam para reforçar que o planejamento daria errado. Nossas estimativas tinham a premissa que:

• Consideravam que uma pessoa é produtiva 100% do tempo;
• Não tínhamos dependências de outras áreas/pessoas;
• Espera de aprovação de pull requests que apenas o cliente fazia (e algumas vezes levava dias);
• Dúvidas que poderiam surgir ao longo do projeto e mudanças na solução;
• Problemas com ambientes de desenvolvimento;

Entre outras que faziam parte do nosso desafio no dia a dia.

O problema ao final era que o trabalho feito sempre era maior que o planejado e vendido ao cliente. E jamais essa estimativa era revista durante o projeto vigente causando situações desconfortáveis quanto ao nosso progresso e nos projetos seguintes para estarmos mais próximos à realidade, sendo que qualquer nova estimativa, principalmente para mais em projetos futuros, era questionada e ajustávamos a um valor “adequado”.

Conclusão

Pare de acreditar em estimativas. Pare de oprimir as pessoas com essa prática e pare de gerar uma insegurança emocional nas pessoas desenvolvedoras que erram estimativas. As pessoas erram estimativas porque estimativa não funciona, não é porque as pessoas não são competentes!!!

Mas se tiver que usar estimativas, não use números. Use proporções de grandeza (P, M, G e se for maior que G, precisa ser quebrada). Eu tenho gostado do formato que o paulocaroli usa no Lean Inception, na etapa de funcionalidades:

Se tiver que usar números e prazos, técnicas de previsibilidade vão te ajudar a ser mais assertivo. Materiais como do Raphael Albino e Caco poderão te ajudar:

• https://medium.com/rd-shipit/m%C3%A9tricas-em-times-%C3%A1geis-as-3-m%C3%A9tricas-fundamentais-que-voc%C3%AA-precisa-saber-e-dominar-816ffb6a53c5
• Livro métricas: https://www.casadocodigo.com.br/products/livro-metricas-ageis

Aqui eu relato um pouco de uma experiência que começou a dar certo, com T-shirt size (estimativa por tamanho de camisa)

Mas se ainda assim você quer continuar usando pontos e números, saiba que o Jira permite estimar com precisão em decimais!!!! Vai lá! agora você vai acertar #sqn

A jornada frustrada de uma pessoa desenvolvedora — tema: gerenciamento da qualidade

Admita, ainda não fazemos qualidade em software!

O relato

Em 2004, durante a graduação, comecei a ouvir sobre gerenciamento de projetos e de um tal de PMBOK. Parecia ser bem interessante, pois ele era bem completo e apresentava detalhes do gerenciamento de comunicação, custo, escopo, prazo e qualidade. Parecia que tinha resposta para tudo e eu fiquei com a sensação de que os problemas estariam resolvidos no dia a dia de desenvolvimento de software.

Doce ilusão de um aluno de graduação que acreditou em tudo o que o professor falou

Eu pensava que aplicando PMBOK com o que eu havia aprendido de programação e banco de dados iria ser um ótimo profissional. Por um tempo até quedeu certo .

Lembro que nesta disciplina ouvi sobre um tal triângulo das restrições e que poderia ser chamado de triângulo de ferro.

Num modelo acadêmico até que dava certo, mas trabalhando com projetos de software, dentro de algumas organizações, vi que não era bem assim. Era muito difícil ter um software bom, barato e rápido. As três opções eram impossíveis, sempre tínhamos que escolher duas delas. Na verdade quem escolhia era o líder (ou chefe) e com muita frequência (pra não falar sempre) era sempre priorizado o barato e rápido.

A qualidade sempre era comprometida.

Passou um tempo e me apresentaram a evolução do triângulo de ferro. Agora a qualidade era inegociável e por isto ficava no centro do triângulo. Agora as arestas eram escopo, custo e prazo.

Mesmo com esta mudança, o teste do bom, barato e rápido, ainda vencia o rápido e barato. Ou seja, vamos trabalhar com escopo e custos enxutos e com tempo curto de entrega. Este foi o cenário perfeito pra esquecer de vez a qualidade do produto, e isto era potencializado pelo tempo curto que havia sido acordado com o cliente, sem consultar o time ou analisar os históricos de entrega e a capacidade do time.

Resumindo, nunca havia tempo para melhorar.

Se não bastasse tudo isto, evoluíram o triângulo de ferro para o quadrado de ferro. Agora qualidade voltou a ser uma restrição. Mesmo com esta alteração, a qualidade continuou sendo a ponta mais fraca das restrições.

Qualidade continuou sendo a ponta mais fraca das restrições

E o tempo passou e cada nova tentativa de aplicar um modelo de projeto de software não surtia efeito no quesito qualidade do software. Eles só acentuavam a deterioração do software e geravam a insatisfação de cada pessoa desenvolvedora que tinha que alterar o código fonte. Foi aí que eu descobri algo:

Descobri que se a qualidade (ou a excelência) não for um valor organizacional, ela não haverá atenção a qualidade, mesmo que esteja como declarado num modelo de trabalho.

E esta descoberta serve para os modelos de processos e maturidade de software como o CMMI e MPS.br. Estes modelos descrevem coisas muito legais e úteis mas cá entre nós, as empresas aplicam estes modelos para ter um selo e não para se transformarem e entregarem valor. Eles são bons para as empresas e não para as pessoas que trabalham nas empresas. Não desejo CMMI e MPS.br para ninguém em sua jornada de software. É traumatizante.

CMMi e MPS.br são bons para as empresas e não para as pessoas que trabalham nas empresas

Os traumas

Como seria bom se esta seção não existisse, mas participar de certificações e projetos de software, geraram alguns efeitos colaterais. O primeiro deles é você ser obrigado a participar destes modelos, ao melhor estilo ser cobaia de um experimento sem poder opinar.

As semanas (ou meses) que antecedem a visita dos certificadores geram uma tensão desnecessária, afinal, alguém vem avaliar você de algo que você não é bem aquilo.

Outro trauma que posso relatar, mas agora na visão de triângulo/quadrado de ferro é como pessoa desenvolvedora você começa a carregar a culpa dos erros de estimativas sendo que uma estimativa não deveria ser considerado uma promessa de entrega. Ou seja, dá problema na aresta de prazo ou custo e a culpa é toda sua. (este será tema do próximo post: a frustração da estimativas)

Sempre é mais fácil apontar para alguém do que analisar a capacidade do sistema de trabalho e os impactos de interrupção e complexidade.

E como mudar isto?

Nesta jornada com software, descobri dois pontos que impedem que haja qualidade em software:

• ausência da cultura de qualidade
• trabalhar com projeto de software ao invés serviço de software

Um projeto tem início, meio e fim, ou seja, o que é importante é o tempo fechado. Já em serviços, entendemos que eles vão ser contínuos ou até mesmo infinitos. O software que você faz hoje (ou presta manutenção) continuará com ou sem você. Continuará com ou sem sua empresa. Alguém vai ter que continuar a mantê-lo funcional. Cabe a você hoje cuidar da qualidade e não outro.

A cada vez que você não cuida da qualidade, você estará encurtando a vida útil do software.

Visto isso, hoje eu entendo que software é infinito. E qualidade tem que ser feita a todo tempo. Cada vez que algo está sendo alterado no código fonte, uma oportunidade de melhorá-lo surge. Um código não pode retornar piorado para o repositório. Ele sempre tem que retornar melhor (lembre da regra do escoteiro).

Por favor, liberte-se desses modelos de triângulo/quadrado de ferro. Estes modelos matam a qualidade.

Aprenda a lidar com prazos de entrega, mas sem abrir mão da qualidade. É melhor entregar com um ou dois dias de atraso inicial, mas com a qualidade atendida.

Qualidade não é um ato, é um hábito — Aristóteles.

A medida que você luta por qualidade, isso começa a se tornar cultural. E se o local que você trabalha já têm isto como valor organizacional, você tem a oportunidade de fazer isto acontecer.

Conclusão

Hoje eu acredito que qualidade deve ser a todo tempo de forma contínua e extrema. Sempre é hora de melhorar e todos podem melhorar o código fonte. Acredito que todos devem lutar pela qualidade, independente da hierarquia.

A pensar assim sinto-me mais feliz, sem muitos traumas ou culpas desnecessárias. A qualidade me tornou mais rápido no que eu faço, me tornou mais profissional. Um software com qualidade todos querem trabalhar nele.

Se você se identificou com algum item deste artigo, compartilha nos comentários suas percepções, traumas e conclusões.

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Será mesmo?

Agilidade e temas técnicos, ainda combinam? Um resumo do que vi entre 2017 e 2019

Caso você não consiga ler todo o artigo, saiba que a agilidade técnica não morreu conforme gráfico que inicia este artigo. Agilidade técnica não morreu, graças às pessoas que de fato entenderam que ainda estamos aprendendo a fazer software melhor e ensinando outros a fazerem o mesmo e que a contínua atenção e a excelência técnica aumenta a agilidade.

A seguir, conto um pouco de como este assunto mexe comigo, fique a vontade em seguir ou não com a leitura.

Agilidade e temas técnicas, ainda combinam?

2017 foi um ano marcante em minha carreira profissional pois adotei a postura de não mais aceitar um ágil “mais ou menos” e misturado com o modelo tradicional de software. Adotei como propósito de vida os valores e princípios ágeis e encarei uma carreira focada em agilidade, com um viés mais na parte técnica. Poderia dizer que neste ano, parei se fazer ágil e passei a ser ágil. E pra ser ágil você precisa voltar a essência de tudo.

Por isto, fiquei algumas semanas ruminando o manifesto ágil. E três pontos me chamaram a atenção :

• Estamos aprendendo a fazer software
• Estamos ensinando outros a fazer
• A contínua atenção à excelência técnica e bom design aumenta a agilidade

Ao ler estes pontos percebo o quanto me identifico com eles, afinal desde 2005 venho trabalhando com software (sujando as mãos com código) e conseguindo pagar meus boletos com isto.

E o que eu fiz a partir desta análise no manifesto?

Para aprimorar o ponto de contínua atenção à excelência técnica, mergulhei em alguns estudos, como design pattern, TDD, devops e as práticas de XP (eXtreme Programming). A medida que eu avançava nas práticas de XP eu conheci seus valores, que norteiam muito do que eu faço nos dias atuais.

Para os pontos de estar aprendendo a fazer software e ensinando outros a fazerem software melhor, eu descobri a importância de ser mais humilde e não tão escravo de uma linguagem de programação. Descobri que o importante é saber fazer um código limpo, que seja para outros seres humanos e com testes unitários. Aprendi isto participando de eventos como TDC (The Developers Conference), Caipira Ágil e Agile Brazil. Nestes eventos conheci muitas pessoas que me ajudaram a olhar software por uma outra ótica. Mas ao participar destes eventos, algo me incomodava. Eu não encontrava muito do que o manifesto pregava, sobre ser um manifesto ágil para o desenvolvimento de software. Onde será que nos perdemos?

Uma bandeira

Olhando este cenário, entendi que precisávamos (ou ainda precisamos) voltas as essências. Então, este assuntos passou a ser a minha bandeira de 2017 até agora (início de 2020). De lá pra cá ouvi muita coisa. Comentários do tipo:

• “agilidade não tem nada a ver com software”
• “agilidade e devops são coisas separadas”
• “evento de agilidade tem que falar das tendências futuras"
• “importante na agilidade é gestão e processos”
• “Agilidade é scrum e Kanban”
• “Agora é agilidade para RH”
• “A culpa é dos desenvolvedores que não vem para os eventos de agilidade”
• entre outras que não lembro…

Mas também conheci pessoas que pensavam como eu e queriam evidenciar a importância de retornarmos a essência ágil. De 2017 para os dias atuais muita coisa rolou e agora temos vários fatos concretizados:

• Voltamos a falar de assuntos técnicos em conferências ágeis, conforme consta no gráfico que inicia este artigo. Destaque para o Agile Brazil, Scrum Gathering Rio e Agile Trends (este último, ainda um pouco mais tímido).
• Temos uma trilha de eXtreme Programming nos The Developers Conference (TDC) de Florianópolis, Porto Alegre e São Paulo.
• Tivemos uma edição presencial e outra remota da XP Conf BR em 2018
• Tivemos vários palestrantes brasileiros no principal evento de eXtreme Programming no mundo, a XP Conf, em 2017, 2018 e 2019 (atualização: em conversa com meu amigo Juliano Ribeiro, ele me passou uma realidade que na XP Conf dos anos anteriores também tivemos brasileiros.)
• Temos um curso de excelência técnica, ministrado pelo Klaus Wuestefeld num dos principais centros de treinamento de agilidade do Brasil (Software Zen: Alisson Vale)
• Temos uma trilha dedicada a Design de Código nos The Developers Conference (TDC) de Florianópolis, Porto Alegre e São Paulo.

Fico feliz em ver que uma pequena faísca que foi levantada a partir dos dados de submissões do Agile Brazil (gráfico inicial deste artigo, medições dos anos 2016 e 2017), geraram mudanças na forma como se fala de agilidade.

O que eu aprendi

Nesta jornada aprendi algumas coisas:

• A grande maioria das pessoas que trabalham com agilidade (scrum masters, agile coach, agile masters, agilistas, etc), não se interessam e nem fazem esforço para entender agilidade técnica.
• Até 2021, a grande maioria das empresas que começaram suas transformações ágeis vão precisar de foco na agilidade técnica, senão o ágil nelas irá estagnar.
• Dojo é uma ferramenta pouco utilizada por facilitadores de agilidade. A maioria tem receio de promover.
• Em conferências, ter entre 15% a 20% da grade com agilidade técnica é o ideal. Ignorar demasiadamente é ruim e priorizar demasiadamente também é ruim.
• Pessoas de agilidade que falam a linguagem técnica tem maior receptividade dos times.
• Conferências de Agilidade (na minha visão) não devem falar de linguagem de programação, mas das boas práticas e como aplicar ferramentas para entrega de valor
• Abordagens recentes de agilidade, como Modern Agile e Heart of Agile, falam do delivery. Isto é assunto técnico. Ou seja, você precisa ficar atento a isto.

Se você concorda, deixe seu aplauso e comentário. Se discorda, gostaria muito de ouvir sua opinião e juntos crescermos na agilidade .

“ The whole point of good design and clean code is to make you go faster” Martin Fowler (https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)

Pensamentos e conclusões a partir do dia a dia de quem trabalha com software

Nota: o autor deste texto não conhece muito de psicologia. O autor deste artigo relata experiências realmente vividas. As vivências foram junto em diversos times que trabalharam com desenvolvimento de software (não necessariamente no papel de pessoa desenvolvedora).

Escrevo este texto no dia 22 de setembro de 2019 e durante todo este mês tem sido realizada a campanha Setembro Amarelo, que visa promover a prevenção ao suicídio, por meio da discussão e ações sobre o tema.

Mas o que isto tem a ver com o dia a dia de pessoas que trabalham com a criação de softwares (pessoas desenvolvedoras, pessoas testadoras, analistas de negócios, product owners, gerentes de projetos, etc) ????

Vamos a alguns fatos

• Produzir um software é um trabalho complexo
• Produzir um software nunca é um trabalho solitário. Muitas pessoas estão envolvidas (incluindo o cliente)
• O trabalho mental é bastante exigido quando se fala de construção de software
• Em alguns momentos, os prazos podem ser algo um tanto quanto perturbador e desgastante
• Horas extras podem se tornar algo recorrente, e isto não é saudável.
• Investir tempo em novas funcionalidades que são descartadas de forma recorrente é algo desmotivador
• O time de trabalho pode ser distribuído e o risco de isolamentos e solidão pode ser agravado

Isto tudo é potencializado (para o lado ruim) caso a cultura da empresa não promova um ambiente colaborativo e incentive mais a velocidade de entrega do que a qualidade.

Com tanta tensão no ar, o clima do time tende a não ser saudável e isso acarreta em problemas, como intensificação dos conflitos, inviabilização do engajamento, queda no rendimento das pessoas programadoras, aumento da dívida técnica e problemas emocionais (ansiedade e depressão, por exemplo).

Ou seja, a saúde mental das pessoas não é respeitada, gerando um problema um tanto quanto sério.

A solução para isto é RITMO SUSTENTÁVEL (sustainable pace)

Originalmente descrito por Kent Beck, no livro eXtreme Programming, ritmo sustentável é uma prática que sugere que todo time tem um ritmo e é necessário encontrá-lo e respeitá-lo.

Times são diferentes e seu ritmo sustentável também é diferente. Respeite isto.

Um ritmo sustentável ajuda a planejar seus lançamentos e iterações e evita que você entre em uma marcha da morte. (site extreme programming). E tendo um ritmo sustentável, podemos começar a ter previsibilidade.

Trabalhar horas extras suga o espírito e a motivação de sua equipe.

Quando sua equipe fica cansada e desmoralizada, ela realiza menos trabalho, não mais, não importa quantas horas sejam trabalhadas. Além disto, trabalhar com a mente e corpo cansados irão fazer com que você escreva mais código de baixa qualidade, aumentando assim a dívida técnica.

Exigir que essa equipe aumente a velocidade para corresponder a essa equipe reduzirá sua velocidade a longo prazo

Manifesto do ritmo sustentável

Pesquisando sobre ritmo sustentável encontrei uma proposta de manifesto para este tema. De repente ele pode ser algo que faça sentido para o seu contexto e quem sabe possa ser o primeiro passo para você iniciar um ritmo sustentável.

Valorizamos

• Puxando o trabalho e indo para casa feliz com a quantidade e a qualidade do trabalho de hoje
• Entrega do escopo de trabalho
• Ter um resultado lucrativo para todo o projeto
• Encontrar tempo para ajustar a maneira como trabalhamos

ao invés

• Pressionando para cumprir datas de vencimento arbitrárias e não listadas
• Fornecendo 100% do escopo
• Orçamento de construção se encontrando
• Focar apenas nas atividades do dia a dia

Embora exista valor nos itens à direita, valorizamos mais os itens à esquerda.

Inspirado no Agile Manifesto em um dos clientes da AgileSparks

Não se mate de trabalhar, tentando ficar rico, nem pense demais nisso. Pois o seu dinheiro pode sumir de repente, como se tivesse criado asas e voado para longe como uma águia.
Provérbios 23:4‭-‬5 NTLH

Além de um ritmo sustentável, você precisa aprender a DIZER NÃO

Como uma pessoa que trabalha com software, você precisa aprender a dizer não. Robert C. Martin, em seu livro “O codificador limpo”, dedica um capítulo para este assunto (parte dele pode ser livro no blog dele).

Como profissionais não podemos concordar com um ritmo exagerado de trabalho. Não podemos concordar com um trabalho “meia-boca” e sem qualidade. Não podemos aceitar que isto seja recorrente e a excelência técnica seja uma opção sempre negociável.

Como um profissional devo dizer não para tudo o que é não é sustentável por um longo tempo. E isto fala também da nossa saúde física e mental.

Na minha opinião não tem nada de engraçado quando falam de pessoas desenvolvedoras e fazem uma ligação delas com café e pizza. Como qualquer tipo de pessoa, precisamos ter um equilíbrio e não somos movidos só a café ou pizza. Valorize os sentimentos , a qualidade de vida, alimentação e a saúde de uma pessoa que trabalha com software.

Devemos dizer não a este esteriótipo criado ao longo dos tempos! Somos profissionais e devemos nos portar como tal.

Por muito tempo acreditei nas imagens acima e até ri delas. Hoje, considero elas distantes do meu dia a dia e as considero uma ofensa e desrespeito.

Conclusão

É tempo de refletir como estamos cuidando da nossa saúde mental. E aproveitar e refletir como temos cuidado da nossa saúde física.

Quem está se importando com isto? Você está num lugar com ritmo sustentável? Você se importa em ter uma vida com ritmo sustentável?

Você anda começando mais coisas do que terminando? Se a resposta for SIM, sinto em dizer que você não está respeitando seu ritmo sustentável. E caso você queira conversar sobre isto, pode me chamar em alguma rede social (em especial Linkedin).

Diga não para o que não está sendo coerente com as suas atividades. Limite seu trabalho em progresso.

Analise a cultura de onde você trabalha. Ela é boa para você?

Valorize a sua vida. Ela é única!

Agora escolham a vida, para que vocês e os seus filhos vivam, e para que vocês amem o Senhor, o seu Deus, ouçam a sua voz e se apeguem firmemente a ele. Pois o Senhor é a sua vida, e ele lhes dará muitos anos na terra que jurou dar aos seus antepassados, Abraão, Isaque e Jacó.

Deuteronômio 30:19,20

Links extras

• Sustainable Pace
• Ritmo sustentável: Como obtê-lo e melhorá-lo?
• Why Crunch Modes Doesn't Work: Six Lessons - International Game Developers Association (IGDA)
• Does Sustainable Pace mean a 40 hour week?
• Sustainable Pace - What's it mean and how to achieve it?
• 3 Signs Your Sustainable Pace is Killing Your Developers
• Sustainable Pace

Entendendo como se contrai dívidas técnicas

Algum tempo atrás escrevi um post que falava como acabar com seu débito técnico. Pois bem, ali você aprendeu duas coisas:

• seus projetos não tem débito técnico. O que você tem é dívida técnica
• técnicas para começar a pagar a dívida (spoiler: em breve vou escrever um post para detalhar mais isto).

Revendo este post, percebi que algo ficou faltou: como como se contrai estas dívidas???

As dívidas podem surgir por diversos meios, imagino não conseguir mapear todas elas, mas vou seguir os autores especialistas no tema e pela minha experiência. Costumo enquadrar a aquisição de dívida técnica por causa de três detratores:

• velocidade para entregar algo
• ausência de refatoração no seu ciclo de desenvolvimento
• ter um sistema de trabalho (ou cultura organizacional) intolerante a falhas

Antes de começar a detalhar cada um destes itens é importante você entender que todo projeto de software vai ter um custo de alteração que é visualizado a partir da necessidade de uma nova feature ou correção de bug. Este custo pode ser de tempo e/ou financeiro. O ideal para este indicador é que ele seja o mais baixo quando pensamos no quanto ele de fato vai pesar no bolso e no cronograma. A distância desta curva ideal de custo com o custo atual é o que chamamos de dívida técnica.

A distância desta curva ideal de custo com o custo atual é o que chamamos de dívida técnica

Ou seja, toda vez que precisamos fazer uma adição de funcionalidade ou corrigir um bug, este tempo se torna muito mais inflado do que o esperado e isto é dívida técnica. Por isto é muito importante você gerenciar sua dívida e pagar ela regularmente para evitar que os juros de não dar atenção a isto se tornem um custo abusivo no seu projeto.

Agora vamos detalhar em como se contrai novas dívidas:

Velocidade para entregar algo

Toda vez que você ou seu time escolher a velocidade ao invés da qualidade, você tende a contrair muitas dívidas técnicas. Para identificar se você está preferindo a velocidade do que a qualidade, leia algumas frases abaixo e se você já presenciou elas, é sinal que você contraiu novas dívidas:

• Não precisa fazer testes unitários. Entrega assim mesmo.
• Entrega assim, o cliente nem vai perceber
• A sprint acaba hoje, então comita do jeito que está
• Refatorar é custo
• Rodou? Compilou? Coloca no ar.

A contração de dívida técnica neste item pode ser ou não de forma consciente, afinal tem horas que é necessário escolher entregar agora (mesmo sem testes) pois não entregar será muito mais custoso (por diversos motivos, como uma legislação ou algo estratégico que o cliente precisa para agora).

A sugestão se isto ocorrer é que, conscientemente, você crie um cartão para pagar a dívida em menor tempo possível (ou seja, não deixe acumular juros).

A forma de contração inconsciente é a ausência de um ciclo de desenvolvimento com padrões de qualidades coerentes. Outra forma inconsciente é a pessoa desenvolvedora não ter habilidade junto as boas práticas. Para tratar isto é necessário capacitação e treino.

Existe um vídeo do Klaus Wuestefeld, falando um pouco deste dilema entre prazo e qualidade. O vídeo é de 2011 e até hoje é contemporâneo.

Ausência de refatoração

Este é o segundo motivo pelo qual os projetos de software contraem dívida técnica com frequência. Se você acredita que uma pessoa desenvolvedora consegue produzir o melhor código fonte logo de primeira, você tem sido muito otimista. Desenvolver software é um processo criativo e repetitivo no qual a cada vez que eu leio o código fonte que acabei de fazer posso encontrar melhorias a serem implementadas.

O ideal é que refatoração seja acompanhada de testes unitários que vão de fato atestar que as alterações realizadas vão continuar tendo o mesmo comportamento do código fonte não refatorado, ou seja, continuará funcionando corretamente.

Lembrete: dívida técnica não é bug. E refatorar não é corrigir bug. Depois que eu corrigi o bug e eu criei um teste unitário para aquele bug, aí sim eu refatoro, buscando como melhorar o código fonte.

Ao refatorar com frequência (em par ou não) você irá perceber o quanto de código fonte escrito não precisava ser feito. Este conceito é chamado de YAGNI e você pode ler mais sobre isto neste post.

Ao refatorar, você tira código desnecessário, reduzindo a complexidade, aumentando a legibilidade e a simplicidade. E como um bônus poderá encontrar bugs que acabaram de ser escritos.

Um sistema de trabalho (ou cultura organizacional) intolerante a falhas

Para explicar este item, vou utilizar o material do Alisson Vale no curso Software Zen . Para saber mais deste curso, acesse aqui

Vamos delimitar o nosso sistema de trabalho ao ciclo de desenvolvimento de software, mas o gráfico abaixo pode ser usado para outras áreas.

1 — Logo no centro você identifica uma oportunidade de melhoria. Todo sistema tem isto. O ciclo de desenvolvimento de software está recheado de oportunidades de melhorias.

2 — ao identificar a oportunidade você pode executar e ter dois resultados: acerto ou erro.

• ao acertar você adiciona motivação para novas oportunidades de melhorias
• ao errar você pode ter situação: aprender com o erro e tentar executar novamente (bem parecido com o TDD) ou evidenciar o erro como uma culpa.

3 — Ao tratar o erro como uma culpa, você incentiva a omissão e aos poucos vai inibindo novas oportunidades. E com isto você vai deteriorando seu sistema.

4 — Já se você incentivar que erros são oportunidades de aprendizado, seu sistema irá entrar em modo de otimização.

Obs: quando eu falo “sistema que incentiva a erros”, estou pensando em meios que permitam que eu falhe de forma segura e rápida. Ou seja, um teste unitário escrito ou um pipeline que evidencie gerações de versões com frequência são bons exemplos de falhar de forma segura e rápida.

Talvez esta seja a explicação mais incrível e bem visual que já encontrei sobre o por que devemos incentivar práticas como TDD e refatoração no ciclo de desenvolvimento. Um sistema que incentiva melhoria, irá pagar dívidas técnicas com frequência e logo a distância da linha ideal de custo da alteração acabará. Ao entender este gráfico não há como querer nutrir um sistema de deterioração.

Conclusão

Gosto de pensar que a dívida técnica é um buraco que todos temos em nossos projetos. Ele pode ser mais profundo ou mais raso. E saber saber como se contrai dívida técnica irá mudar seu comportamento e do seu time, ou seja, iremos parar de cavar o buraco.

Em breve pretendo detalhar como sair do buraco, ou seja, pagar a dívida técnica

Para saber mais sobre como acabar com sua dívida técnica, acesse os slides da palestra que realizei em 2019 no TDC SP e no Agile Brazil

Inspirado no estudo de Simon Sinek — The Infinite Game

Em março de 2019 tive a oportunidade de ouvir Simon Sinek no evento The Global Leadership Summit apresentando seu novo estudo intitulado Jogo infinito, como liderar no século 21.

Após uma explosão de aprendizado e de conteúdo, minha cabeça começou a sintonizar tudo o que eu ouvi lá para o mundo de software. Vamos ao conteúdo:

O Jogo Infinito, por Simon Sinek

No mundo existem dois tipos de jogos:

• os finitos, os quais tem regras fixas, o objetivo é acordado e os jogadores são conhecidos
• os infinitos, os quais tem regras mutáveis, os jogadores são desconhecidos e o objetivo é continuar jogando.

Exemplos de jogos finitos são partidas de futebol e vôlei.

Exemplos de jogos infinitos estão espalhados em nossas vidas e nas diversas áreas de negócios.

Tetris pode ser é um bom exemplo de jogo infinito, afinal é difícil saber quais serão as peças futuramente disponibilizadas e o objetivo é sempre continuar jogando com o mínimo de peças empilhadas.

Além disso, é comum termos jogos finitos dentro de jogos infinitos, mas o inverso não existe.

Cada tipo de jogo possui jogadores distintos. O jogador do jogo finito joga para vencer e um jogador do jogo infinito joga pelo prazer de sempre estar jogando.

Num jogo infinito não existe vitória, existe estar na frente ou atrás!

E Simon Sinek definiu 5 chaves para os jogos infinitos:

• Causa justa
• Equipes de confiança
• Rival digno
• Flexibilidade existencial
• Coragem para liderar

Software: um jogo infinito — por Wagner Fusca

Desde que comecei a trabalhar com software, em 2006, algumas coisas se repetem com frequência:

• muitos software são chamados de “projeto de software” já que eles terão início, meio e fim (como qualquer projeto). O que eu percebi nesta jornada é que software nunca tem fim. Lembro de um “projeto de software” que era para durar 6 meses. Fiquei nele por 4 anos e mesmo assim não havia ideia de término.
• software dificilmente tem regras fixas. Na maioria das vezes percebo que elas mudam com frequência e isto ocorre pela falta de entendimento de negócios pela equipe técnica e pela baixa maturidade do cliente em explicar o que ele realmente precisa.
• Por mais que eu sei quem são as pessoas que irão atuar no “projeto de software”, diariamente descubro que outras pessoas precisarão ser acionadas para que uma funcionalidade seja de fato criada. Estas pessoas (jogadores) são invisíveis. O “adversário” até a conclusão de uma demanda nem sempre é possível de prever já no inicio do trabalho.
• Já vi alguns softwares pararam de serem usados, mas toda vez que um software era encerrado, outros três apareciam para substitui-lo. ou seja, o objetivo é continuar jogando, mas agora usando uma nova estratégias (outros softwares).

Erros que ocorrem com frequência ao tratar software como jogo finito:

• Prazo é mais importante que qualidade
• Tomar como verdade que um plano inicial de tempo e custo serão realmente efetivamente cumpridos.
• Empresa se isolam com medo de perder possíveis propriedades intelectuais
• Pessoas que trabalham com software não se atualizam e nem se envolvem com comunidades de aprendizado (como meetups e eventos)
• Acreditar que estimativas serão totalmente verdadeiras e não haverá distorções
• Grande acúmulo de dívida técnica e não há tempo para pagar a dívida
• Sempre existe um cenário onde existe vítimas, vilões e heróis
• Alta rotatividade de pessoas no time
• Clima de competição e não colaboração (até mesmo entre fornecedor e cliente).
• Mais trabalho braçal do que trabalho do conhecimento.
• Acreditar que uma certificação é o auge do seu currículo.

Evidência que software é um jogo infinito

• regras/requisitos de um software podem sofrer mudanças com frequência
• Todo software vai ter dívida técnica e será impossível zera-la . Você só consegue controlar o crescimento, mas nunca zerar (semelhante ao tetris).
• Buscamos sempre ter entregas contínuas de software. Isto é devops e seu simbolo é infinito

• Um software dificilmente deixa de existir. O que acontece é que ele acompanhou ou não as evoluções tecnológicas. E mesmo usando tecnologias antigas, é provável que o software continue sendo usado.
• O manifesto para o desenvolvimento ágil de software fala mais de algo infinito do que finito (não se esqueça de ver os princípios também).
• As boas práticas de programação são ciclos infinitos, como por exemplo TDD, refatoração, pequenas versões e integração contínua

Como jogar o jogo infinito que é o software?

Das 5 chaves elencadas por Simon Sinek, entendo que 4 delas fazem sentido para o software.

1 — Desenvolva um propósito (ou causa) a qual seu software atende ou irá atender.

• Cada software tem um história que precisa ser respeitada. Pessoas tomaram decisões baseadas no que era melhor para aquele momento, dado o conhecimento e os recursos disponíveis (lembrando que pessoas não são recursos). Por isto respeite o que já foi feito, mas não se conforme em continuar deste jeito.
• Reveja qual causa que o seu software atende? Esta causa sobrevive ao tempo? Sobrevive a governos? Sobrevive as mudanças tecnológicas ?
• Não tenha uma causa pequena. O ideal é que seja uma causa que talvez nunca conseguiremos alcançar, mas as pessoas se conectarão nela e morrerão tentando cumprir

Exemplo: seremos o aplicativo que mudou a forma de operar cartões de crédito no mundo

Exemplo: não teremos divida técnica.

Exemplo: ter versões disponíveis do sistema a qualquer momento e sem intervenção humana

2 — Tenha uma equipe de confiança

• o time que irá trabalhar com um determinado software tem que sentir que existe um ambiente seguro para criar novas linhas de código num software. Práticas de testes unitários, retrospectivas, integração contínua e dojos ajudam a termos um ambiente mais seguro e de aprendizado
• misture pessoas novas com as pessoas que conheçam bem o software. Geralmente as pessoas novas se identificam mais com as causas do que as mais velhas numa empresa. Misture ambas e aprimore a confiança uns nos outros
• permita que o erro faça parte da equipe. Falhar é importante. E falhe rapidamente. Permita também que as pessoas peçam ajuda.
• software não é simples, por isto permita que as pessoas compartilhem ideias.
• acabe com perfis que só seguem regras. Estes perfis só acabam com o software. Precisamos de pessoas que pensam, dialoguem sobre negócios e depois dito tudo, codifiquem (ou testem ou façam a analise)

3 — Tenha ferramentas que evidenciem falhas do software ou má qualidade do código. Use elas como rivais do time e não competidores

• Num jogo infinito não podemos ter competidores, pois não haverá vitória. Geralmente pessoas de times de desenvolvimento não tem tanto anseio pela vitória. Eles tem anseio por fazer um trabalho bem feito e que se orgulhem disto. Não permita competição entre os times de desenvolvimento. Valorize a colaboração.
• Use ferramentas que te ajudem com o dia a dia do trabalho de desenvolvimento de software. Estas ferramentas te ajudam a lembrar o por que das coisas. Encare estas ferramentas como rivais que vão te impulsionar para frente.
• Estas ferramentas irão dizer o quanto você está mais a frente ou mais atrás do que ontem. Este é o poder das métricas!

Exemplo: ao implementar um pipeline de devops você estará garantindo que um software estará sempre pronto para ser gerado e disponibilizado numa versão. E quando este pipeline quebra (tem uma falha), e-mails serão enviados notificando do fato, com o objetivo de mantermos o time com o software sempre disponível. O objetivo não é encontrar um culpado. Ao buscar um culpado, estarei jogando um jogo finito. Num jogo infinito não temos vitória, temos prazer em mantê-lo a build sempre disponível como uma causa do nosso time!

Outros exemplos que ajudam a ter rivais sadios são:

• Usar uma ferramenta de analise estática de código, como o SonarQube
• Usar uma ferramenta para vulnerabilidades do sistema

Nunca poderemos vencer estes rivais mais poderemos tornar o nosso software mais preparado para viver mais.

4 — Tenha coragem

Para entender mais deste item, é melhor você ler o post que fiz em 29/03/2019 .

Conclusão

• Promova uma causa que seu software vai atender.
• Saiba que esta causa será atemporal.
• Invista tempo e estratégias visando promover ambientes seguros.
• Valorize a falha e incentive o aprendizado e o compartilhar.
• Use as boas práticas de software como seus rivais que serão aqueles que irão te ajudar a ter uma boa qualidade no final de tudo.

Aplique tudo isto acima descritos e você terá um produto e times que serão infinitos, como todo software é!

Lembrete: A inspiração para este post é baseado no novo trabalho de Simon Sinek. O vídeo já está disponível e o livro será lançado em outubro/2019

Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

Quando comecei a estudar engenharia de software sempre ouvi dizer que devemos cuidar para não adicionar complexidade de forma demasiada ao código fonte.

Sinceramente, eu não entendia nada do que isto significava. E por não entender, eu programava no modo GoHorse, ou seja, nem pensava e inseria linhas e mais linhas de código.

Até que um dia conheci um princípio da programação extrema (XP) e parece que tudo ficou mais claro.

O princípio se chama YAGNI (You Ain’t Gonna Need It). Em resumo, VOCÊ NÃO VAI PRECISAR DISTO. Ler isto foi tipo levar um soco na cara!

Este princípio diz que você só deve criar código que realmente vai ser utilizado e não adicionar código supondo algo no futuro. Afinal, ninguém tem bola de cristal para descobrir o que vai vir no futuro.

A melhor maneira de implementar o código rapidamente é implementá-lo menos. A melhor maneira de ter menos bugs é implementar menos código. Ron Jeffries

Isto também pode ser aplicado a outras atividades de software, como um requisito que quer atender todos os conjuntos de regras possíveis. Na busca por atender todas as regras, o requisito acaba se tornando complexo e de longa leitura. Ou então um MVP que faz muita coisa e no final de tudo não faz nada e não atende o objetivo inicial.

História

YAGNI é foi descrito pela primeira vez por Ron Jeffries no seu blog em 1998 e posteriormente foi referenciado nos livros:

• Extreme Programming Installed
• Extreme Programming examined
• Refactoring: Improving the Design of Existing Code
• Lean Software Development

You're NOT gonna need it!

Como YAGNI pode me ajudar?

• Simplicidade pro seu dia a dia. Com menos código, mais fácil você dar manutenção e inclusão de novas funcionalidades.
• Arquitetura simples: fugindo do overengineering

• Legibilidade de código: por ter código que atende alguma funcionalidade que realmente existe, você pode usar o vocabulário correto e se concentrar em aplicar as práticas de código limpo.
• Não aumentar a dívida técnica: fazendo somente o necessário, você evita acrescentar code smells, código duplicado e vulnerabilidades. E caso adicione, você poderá pagar a dívida rapidamente pois o código está simples e de fácil checagem por ferramentas de analise estática de código
• Tempos de execução de builds e de execução testes otimizados: menos código significa menos complexidade para ser checada numa build
• Seu tempo investido de forma correta: programar não é uma atividade fácil e investir tempo no que realmente gera valor, irá permitir que você durma tranquilo e não precise acordar na madrugada após ter sonhando com soluções de código fonte (quem nunca fez isto né? )

O que devo fazer para aplicar YAGNI?

• Resista a vontade de fazer mais do que precisa ser feito. Temos a tendência de fugir do objetivo inicial e querer fazer um pouco a mais. Mantenha foco no alvo e adicione a quantidade correta de código fonte para atender esta situação.
• Aplique práticas de testes unitários, em especial TDD.

• Não pare no verde após rodar o teste unitário. Refatore!!!! É aí que está o Yagni
• Ao refatorar com frequência, você irá validar constantemente se aquele código era realmente necessário. Crie pontos curtos de paradas durante o desenvolvimento para validar se pode ser melhorado (caso não esteja usando TDD e pareamento)
• Use pareamento. Uma segunda opinião ou desenvolver em dupla garante esta checagem e menos código fonte

Dica Final

Yagni pode gastar um pouco mais de tempo agora, mas economizará tempos futuros.

XP Rule

Manter seu código pronto para mudanças inesperadas é sobre design simples. Adicionar flexibilidade extra além do que você precisa agora sempre torna um design mais complexo.

Feche os olhos para os requisitos futuros e flexibilidade extra. Concentre-se no que está programado para hoje apenas! — XP Rule

You aren't going to need it. (YAGNI)

Exemplos de YAGNI do dia a dia

Coragem, por que esconder isto dentro de você, querida pessoa desenvolvedora?

Saia da conformidade que vivemos no desenvolvimento de software

Após um dia intenso de palestras incríveis do Global Leadership Summit, várias palavras ficaram populando a minha mente. Uma destas palavras eu considero ser uma possível causa raiz para vivermos um ágil tão frágil (#fragile).

CORAGEM (ou a ausência dela)

Coragem, a argamassa que falta pro seu conjunto de ferramentas

Juliet Funt, CEO WhiteSpace at Work, utilizou de uma metáfora incrível para explicar o por que tantas ferramentas de produtividade dão errado. Ela considera todas as ferramentas como tijolos que estão sendo empilhados e usados pelos times, mas entre estes tijolos falta a argamassa, que são os comportamentos.

Para a minha pessoa, a coragem é o principal ingrediente deste comportamento, mas que não pode ser usado de forma isolada. Mas todos os outros comportamentos sem coragem, provavelmente não vão gerar uma argamassa realmente incrível.

Por exemplo: em extreme programming temos os valores comunicação, simplicidade e feedback. Somente estes três não geram sucesso sem a coragem.

Hoje temos tantas ferramentas de comunicação e mesmo assim continuamos a fazer linha de código que não gera valor. Somos com frequência acompanhados em nossas carreiras, recebendo feedback sobre como estamos trabalhando. Recebemos feedback do cliente sobre nossos trabalhos. Recebemos feedback se o deploy está ok ou não, se os unitários estão ok ou não. Somos incentivados a aplicar a simplicidade através da aplicação de DDD, TDD, entre outras práticas. E mesmo assim continuamos fazendo software de forma ruim. Versionando software como 20 anos atrás. Continuamos entregando sprints e movendo tarefas para a coluna de pronto e não melhoramos o dia a dia de software.

Por que será que continuamos a fazer software como no inicio de nossas carreiras?

Estamos tão conformes e acostumados com as dores na produção de software que elas nem doem mais.

Onde está a coragem para ser a diferença?

Cade a coragem para você levantar dores que estão a muito tempo atrapalhando seu serviço ?

Por que continuar sendo mais um na reunião, onde você sabe que o rumo daquilo não está adequado? Seja uma pessoa corajosa e levante a mão e ajude o time a olhar por uma ótica diferenciada.

Mas daí eu vou me expor ?

Sim. Para ter coragem você precisará se expor. Correrá o risco de falhar. Mas você precisa ser você mesmo. Pequenas ações de coragem geram integridade, formam líderes que vão carregar uma bandeira de mudanças e isto incentivará outras pessoas desenvolvedoras a quererem mudança.

Pessoas desenvolvedoras integras é o que mais precisamos em nossos times. No site do http://www.extremeprogramming.org/ encontramos a seguinte descrição sobre coragem:

Courage: We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works alone. We will adapt to changes when ever they happen.

Coragem: Vamos dizer a verdade sobre o progresso e estimativas. Não documentamos desculpas para o fracasso porque pretendemos ter sucesso. Não tememos nada porque ninguém trabalha sozinho. Nós nos adaptaremos às mudanças sempre que acontecerem.

A coragem de uma equipe é revelada em como ela responde ao estresse.

Como seu time responde a uma mudança de requisito ?

Como seu time responde ter que liberar uma versão do software para este dia? E se fosse necessário liberar em 1 hora? E em 30 min? E em segundos?

Como seu time responde as mudanças tecnológicas? Como as pessoas do seu time respondem a necessidade de parear na codificação e uma demanda?

A falta de coragem é o medo

No inicio deste artigo eu coloquei uma animação do filme Coração Valente. A história deste filme conta sobre William Wallace, interpretado por Mel Gibson, que lidera o povo escocês contra os ingleses em busca de liberdade. Sua liderança foi tão incrível e corajosa que o exército escocês, mesmo sendo amador, era muito maior que o exército inglês. Eles não tinham as melhores armas e o melhor preparo, mas eles tinham um desejo e coragem de lutar pela visão de liberdade.

Não estou incitando você fazer uma guerra onde você está trabalhando, mas incentivo você a se munir de práticas para que o medo possa ir dando lugar a uma visão. Crie uma visão de onde vocês podem chegar.

Liberte-se daquele build demorado. Liberte-se de uma liberação de versão que você não tem confiança. Liberte-se do seu ego que acha que você não tem mais nada a aprender quanto a código fonte.

E o que me ajuda a ter coragem na codificação de software?

Extreme programming propõe 12 práticas que estão listadas na imagem abaixo. Ao aplicar as 12 práticas, Ron Jeffries relata que é raro você ter algum medo quanto ao trabalho que você desenvolveu.

It has been my experience that teams that truly follow all 12 practices will have courage. But, I have been in situations when we thought we were doing a good job only to discover that we lacked the required courage to do the job correctly. Usually the lack of courage can be traced to a failure to follow one or more of the 12 practices. That is where we should look to regain our courage, but courage should be our goal and the practices our means for achieving it.

E como eu começo?

1 — não tenha medo de se expor. Sua atitude, poderá economizar muito tempo e desperdício do time. Mesmo que a sua organização seja algo complexo, saiba que você pode mudar todo um sistema que oprime como os desenvolvedores tem que trabalhar. Seja um “voluntário como tributo” (ver filme Jogos Vorazes)

2 — Entenda onde vocês precisam ir. Crie uma visão de como será a produção de software do seu time.

3 — organize/facilite a elaboração de um plano de mudança. Todos do time poderão contribuir com este plano.

4 — comece com o que você tem hoje. Ataque de forma disciplinada e contínua cada problema (lembre da técnica do estrangulamento. Ela foi descrita por Martin Fowler para a codificação mas pode ser usada para outras áreas também, como o devops e devsecops)

5 — o medo pode existir, mas ele não pode ser maior que sua visão. Um time e as pessoas que o compõem são maiores que qualquer problema e elas podem mudar tudo.

Seja corajoso!

Leitura:

• When is it not XP?
• GLS18 Session Notes-Juliet Funt-The Upside of Simplicity - Global Leadership Network
• Extreme Programming Values