No mundo do software ser rápido é fundamental. Não apenas para ser o primeiro no mercado, mas também responder aos clientes adicionando novos recursos e eliminando bugs rapidamente, a fim de manter a sua satisfação. Mas nós temos um problema com a “velocidade”. Assumimos que ir mais rápido está relacionado com dar prazos aos objetivos, o que pode determinar o fechamento de um negócio ou o sucesso de um produto.

Somos erroneamente levados a pensar que vamos ser mais rápidos trabalhando mais ou com mais pessoas. No entanto, como Frederick P. Brooks observou em  “O Mítico Homem-mês” que “Adicionar mais programadores a um projeto atrasado só o tornará mais atrasado.” A pressa não nos torna nem mais rápidos nem mais produtivos. A pressa aumenta o estresse, dificulta o foco e destrói a produtividade.

Desenvolver software é difícil e complexo. A necessidade de velocidade cria um ambiente instável e insustentável, nos deixa estressados, menos focados e menos produtivos. Conceitos como capacidade de equipe, horário fixo de trabalho, prazos em horas ou dias e velocidade são imaginários e existem mais para posicionar gestores. As entregas dependem diretamente das habilidades das pessoas, da eficiência dos processos e da qualidade da produção.

No final do dia obtemos software legado. A pressão dos prazos combinada com a incompetência leva ao software legado e de baixa qualidade, o beco sem saída de um software funcional. Funciona em produção e gera lucro, mas precisa do sangue, da vida e da energia dos desenvolvedores de software para continuar trabalhando de alguma forma. Os desenvolvedores têm muito medo de tocá-lo, então se funcionar ninguém quer alterá-lo.

Robert C. Martin tem um ditado perfeito sobre sintomas de software legado: “Se o seu software está ficando cada vez mais difícil de desenvolver, você está fazendo algo errado.” Enquanto corremos, estamos destruindo tanto a qualidade que cada passo que damos para a frente torna todo o progresso e fluxo mais lento do que antes. Por isso acredito que a única maneira de desenvolver mais rápido é desacelerando.

Contrate desenvolvedores preocupados com a qualidade e que sigam bons processos.

Processos e ferramentas não constroem produtos, mas pessoas sim. Para uma empresa de software talvez a habilidade mais importante que ela deva possuir é saber contratar e reter talentos. Tem impacto direto no futuro da empresa e do próprio produto. Se a empresa não desenvolve software mas procura um parceiro da área, ela precisa se informar sobre a qualificação dos desenvolvedores e quais processos eles seguem.

Equipes produtivas adotam a cultura de auto-organização e da melhoria contínua. Praticando juntos novos conceitos e tecnologias e coletando e fornecendo feedback constantemente. Bons programadores gostam de aprender e estão dispostos a investir tempo e dinheiro em busca de novos conhecimentos e habilidades.

Prazos e estimativas são importantes para os negócios, mas somente bons programadores que presam por qualidade e que não apressam entregas são capazes de entregar software com qualidade e de forma sustentável durante um longo período de tempo.

Na Aelian nós fomentamos essa cultura realizando revisões de código, incentivando nossa equipe a manter uma rotina de estudos, compartilhando conhecimento através de artigos e vídeos técnicos, realizando sessões de programação em pares e periodicamente trocamos feedback visando manter um ambiente de melhoria contínua.

Como a desaceleração pode melhorar a qualidade do software.

Sem ter uma base de código de qualidade não há como você ser ágil. Se o software está ficando cada vez mais difícil de desenvolver, isso é um sinal ruim. A primeira coisa que você precisa fazer é desacelerar parando de criar novos recursos por um tempo, e pedir para os desenvolvedores focarem em eliminar o débito técnico e bugs.

Corrigir bugs e implantar diretamente em produção não é um procedimento adequado. Precisamos de uma maneira melhor e mais disciplinada para fazer isso. Quando um desenvolvedor deseja corrigir um bug, primeiro ele deve escrever um teste e reproduzir o problema programaticamente. Em seguida, ele corrige o bug e verifica se os testes estão passando. Assim a implantação em produção torna-se segura.

Chamamos essa técnica de TDD (Test Driven Development). É uma dentre várias práticas e processos do XP (Extreme Programming) como Refatoração, Integração Contínua, Revisão de Código, Programação em Pares que são adotadas pelos desenvolvedores. Mas para adotar com eficiência esses métodos é preciso disciplina, prática e principalmente tempo.

Nosso objetivo final deve ser alcançar a entrega contínua e liberar com frequência. Para isso utilizamos de estratégias e métodos de implantação, de mecanismos de feedback a práticas de teste automatizadas, isso requer uma mentalidade diferente, onde não tem espaço para a pressa. Eu conto um pouco de como implementamos isso nesse artigo.

Desacelerar para ir mais rápido como uma filosofia.

Como bom desenvolvedores, nós não queremos escrever código que simplesmente funcione: queremos escrever código que seja limpo, de fácil manutenção, fácil de entender e bem testado. Para isso, precisamos desacelerar e nos concentrar nas pessoas e nos processos envolvidos na construção do software. E assim obtermos um software funcional, de qualidade, sustentável, de forma segura e mais rápida.