O que é uma boa cultura de engenharia de software?

Fala, galera. Novamente, um conteúdo no Medium e resolvi compartilhar com vocês aqui também. Pra quem quiser conferir o artigo na forma original, só seguir este link: https://igorstefano.medium.com/o-que-%C3%A9-uma-boa-cultura-de-engenharia-de-software-fd4bdc57fe59. O corpo do texto está na íntegra abaixo. Valeu!

Cotidianamente, gosto de discutir com colegas de trabalho, líderes e pares em outras empresas sobre a cultura de engenharia de software. Acho interessante observar como a equipe de desenvolvedores de cada empresa busca resolver os problemas que enfrenta. Nas linhas a seguir, coloco o que, no meu ponto de vista, é uma visão geral do que nós, enquanto equipes de tecnologia, devemos buscar para termos uma boa cultura de trabalho.
Para mim, a equipe de engenharia de software deve se guiar em três princípios: espírito de equipe, foco na qualidade e entrega de valor.

Espírito de Equipe

O espírito de equipe simboliza a responsabilidade compartilhada que uma boa equipe de engenharia se compromete a ter; no cotidiano, se vê isso em uma equipe que não tem medo nem dificuldade em se comunicar entre si para conquistar um objetivo. No ponto de vista do código, isso se mostra em "deixar o acampamento mais limpo do que quando o encontrou", como diria a Regra do Escoteiro citada por Robert C. Martin, ou seja, não ignorar oportunidades de melhoria quando encontradas, seja em meio ao desenvolvimento ou em um code review.

Também é vantajoso para o crescimento técnico da equipe e para a empresa que não seja alimentada uma cultura individualista com silos de conhecimento, isto é, com indivíduos que detém o conhecimento único do funcionamento de partes do sistema. Construir desta forma pode ser, para profissionais sênior, mais veloz, mas não é uma maneira segura ou confiável de se manter a médio e longo prazo.

Ademais, no ponto de vista organizacional, espírito de equipe significa criar uma cultura livre de culpa nos processos (blameless culture), em que, em eventuais incidentes, os processos envolvidos são examinados e melhorados em vez de punir um membro em específico. Isso cria um ambiente onde todos podem aprender com todos, e contribuir da melhor maneira correspondente ao seu papel na equipe.

Um exemplo de prática que ajuda a gerar essa cultura é o post-mortem, que consiste em criar um documento em relação a um incidente específico após a sua resolução. Posso dizer que tive contato com esta prática; ao longo do tempo, precisei realizar a confecção de post-mortems de incidentes que ocorreram com partes do sistema pelo qual eu estava responsável.

No documento, incluí informações como a causa, como foi realizada a correção e passos que podem ser tomados para evitar que um problema da mesma natureza ocorra novamente. Esses passos foram transformados em tarefas para a equipe, enquanto o documento está disponível para consulta da equipe no caso de que incidentes similares ocorram novamente.

Foco na Qualidade

A equipe de desenvolvimento deve ter como parte intrínseca de seu dever entregar o melhor código possível, tendo como medidas a sua manutenibilidade (quão fácil de manter ele será caso seja necessário entender, modificar, consertar ou estender) e estabilidade (quão difícil seria que problemas ou outros comportamentos inesperados surgissem ao alterar esse código ou outras partes que dependem dele).

Para otimizar essas duas métricas, uma dada equipe pode aplicar diversas técnicas e processos, a depender da maturidade média dos integrantes. Em geral, um código de qualidade vai aplicar design patterns onde sejam necessários (quando o forem), uma boa documentação para facilitar a entrada de novos contribuintes e testes automatizados para garantir que o comportamento ao longo do tempo se mantém estável.

Para prover um exemplo de como um desenvolvedor pode manter a qualidade do código onde trabalha, uma das ferramentas mais essenciais para isso são as pipelines, que nada mais são do que etapas pelas quais o código pode passar antes de ser enviado para produção. Podemos configurar pipelines para que os nossos testes automatizados rodem (impedindo que o código suba com um teste quebrado), um linter seja acionado para garantir a padronização no estilo adotado pela equipe, além de organizar os releases da equipe, entre outros usos.

Em última instância, foco na qualidade também significa que todos na equipe precisam se comprometer a estar abertos a possíveis melhorias. A realidade do nosso cenário é de constante mudança, e por vezes formas de trabalho que em um recorte histórico poderiam ser consideradas ótimas podem não ser as melhores no próximo. Melhoria constante é mudança constante.

Entrega de Valor

Por falar em melhoria constante, também devíamos falar sobre entrega constante; parte importante do que vem a ser a entrega de valor. De nada importa a melhor estrutura de código, a equipe com mais entrosamento se nada produzirem; ou, mais realisticamente, se o que for produzido não for de agrado do cliente ou em desrespeito ao time to market correto. Dessa forma, a entrega de valor é o princípio mais importante, pois é o que garante a continuada existência da equipe de engenharia e da melhoria dos projetos em que a mesma está envolvida.

Isso não significa que a equipe deve ceder para quaisquer demandas, passar por cima das boas práticas de desenvolvimento do software e se desdobrar para cumprir prazos previsivelmente impraticáveis (provavelmente incorrendo em todos os problemas que os princípios anteriores foram pensados em evitar ou resolver).

Devemos enxergar - tanto o cliente quanto a equipe - que a engenharia de software não é como a engenharia civil. Vivemos um mundo de requisitos que são flexíveis. Até mais do que isso; por vezes, é difícil garantir com antecedência o quão importante uma determinada característica no sistema vai ser (por mais que esse tipo de problema seja suavizado a partir do momento que uma empresa se propõe a ser data-driven, ou seja, tomar decisões baseadas em dados e pesquisa, em vez de instinto).

Por requisitos estarem sujeitos à mudança, também o está a equipe responsável pelos mesmos. E é neste contexto que o conceito de entrega contínua ganha relevância. Diferente da engenharia civil, nós temos a capacidade de entregar o projeto aos poucos. Pelo princípio de Pareto, 80% do valor pode ser entregue com 20% do esforço.

A maior parte do valor de um sistema de estoque para uma loja, para dar um exemplo, vem simplesmente dele existir com seus recursos básicos, como cadastrar os itens presentes e suas quantidades; com essas informações devidamente digitalizadas, a equipe de tecnologia já livrou os administradores de um sem-número de papéis, que precisavam ser conferidos a mão, liberando carga cognitiva para que eles possam tornar os seus negócios melhores em outros pontos.

Isso significa que outros recursos, como uma pesquisa externa de itens ou uma criação automática de gráficos de vendas, que poderiam bloquear o software por um bom tempo se precisassem ser inclusos desde a versão inicial, podem ser liberados iterativamente - gerando, assim, valor continuamente.

Sendo assim, para respeitar os outros princípios, a equipe de engenharia deve saber criar ciclos contínuos de entregas nos quais ela irá atuar, aos poucos, para criar um trabalho de alta qualidade. Ela realiza isso ao compreender e priorizar quais são os objetivos e necessidades do cliente, quais são as peças de software que podem ser montadas para contribuir com essas finalidades e em qual ordem.

Em termos de aplicação técnica, as pipelines citadas na seção anterior também são muito úteis para garantir a entrega constante; uma pipeline bem montada permitirá que o código novo seja integrado com segurança ao produto principal tão logo quanto a aprovação do code review for concedida. Já no ponto de vista de produto, as metodologias ágeis são nossa principal ferramenta para realizar a priorização das atividades.

Conclusão

Penso que, pelos pontos levantados acima, espírito de equipe, foco na qualidade e entrega de valor são de fato os princípios que guiam uma equipe de tecnologia de sucesso. O primeiro faz com que a equipe se sinta bem, o segundo faz com que o produto seja bom enquanto o último agrada o cliente, viabilizando o resto dos processos. Entretanto, a maneira como cada um é trabalhado pode - e deve - mudar de maneira radical entre uma equipe e outra. Afinal, nenhuma equipe é igual a outro, nenhum produto é o mesmo que outro e nem toda entrega tem o mesmo valor para o cliente.

Existe uma miríade de boas práticas que poderiam ser citadas aqui. Coisas como o TDD, DDD, Clean Architecture, entre outras ferramentas úteis para garantir qualidade no trabalho do desenvolvedor. Entretanto, quis passar uma visão pessoal e bem geral sobre o que enxergo que seria útil para a esmagadora maioria das equipes de engenharia de software; cabe a cada uma dessas equipes saber quais são as melhores ferramentas para o seu caso.

E a você, que leu este texto, agradeço a leitura e já quero aproveitar para perguntar: o que você enxerga como importante para equipes de tecnologia? Tem alguma ferramenta que seja ou tenha sido muito útil na sua equipe para manter ou melhorar a cultura de engenharia de software?

Valeu!