Para finalizar nossa sequência de artigos sobre qualidade de código, gerência e times, vamos parar um pouco de falar sobre repositórios – como falamos no último artigo – e vamos começar a falar um pouco mais sobre processos e ideias que podem ajudar a melhorar cada vez mais a qualidade de um código entregue pelo time, mas que não necessariamente tem a ver com o código em si.

Trabalho eficiente

O maior motivo pelo qual um código é entregue em atraso ou com má qualidade é a eficiência com que este trabalho é realizado. Hoje, existem centenas de milhares ou milhões de maneiras de se tornar uma pessoa, um time ou até mesmo uma gama de times mais eficiente.

Organização pessoal

É extremamente importante que nós, como indivíduos, sejamos organizados para executar nosso trabalho de maneira rápida e eficiente, liberando tempo para comprimirmos grande parte de nossas tarefas no mesmo dia.

Você pode pensar: “Mas o que isso tem a ver com a qualidade de um time?”, e a resposta é: tudo. Times são feitos de pessoas. Se todas as pessoas do time são desorganizadas, então uma não vai poder ajudar a outra a completar seu trabalho de forma rápida e eficiente, porque ela mesma não estará com tempo por conta do seu próprio trabalho.

Em contrapartida, pessoas organizadas conseguem administrar melhor seu tempo e tarefas, disponibilizando um pouco dele para ajudar colegas que estão com problemas, inclusive, ajudando-os(as) a serem mais organizados por si só.

Todos nascemos com um espírito de organização nativo. O grau que cultivamos este sentimento pode ser maior ou menor – algumas pessoas podem ser mais organizadas com itens materiais, e outras preferem ser mais organizadas em relação às tarefas do dia. Independente do tipo, existem metodologias como o GTD, que ajudam muito na hora de se organizar pessoalmente.

Organização do time

Uma vez que você se organizou pessoalmente, é possível levar essa organização a outro nível com metodologias de desenvolvimento ágeis, como o Scrum. Gerenciar projetos pode ser bastante complicado e desafiador quando não se tem uma metodologia muito boa ou então quando não se tem uma boa sistematização de como e quando as tarefas devem ser feitas, e é nesse ponto que o Scrum se torna essencial para que o time entregue o trabalho com qualidade.

O Scrum, especificamente, possui uma série de cerimônias (que não vou descrever aqui), que ajudam a manter não só a organização do time, mas também a comunicação do mesmo – que abordaremos um pouco mais adiante – fazendo com que os membros se tornem, de fato, uma única força de trabalho conjunta, não realizando tarefas repetidas e sabendo exatamente tudo o que precisa ser feito.

Além disso, tão importante quanto saber o que precisa ser feito, é fazer o que precisa ser feito. Na maioria dos modelos de gestão que surgem “organicamente” em um time, o maior problema está nas interrupções que são causadas por fatores externos a quem está, de fato, desenvolvendo a tarefa. No Scrum, este tipo de interrupção não existe.

Mantendo tudo igual

O Scrum – assim como todas as metodologias ágeis – visam a organização e gestão do projeto, mas não ditam formas de se manter este projeto, o que fica totalmente a critério de quem o está desenvolvendo. Isto causa muitos problemas de qualidade.

Primeiramente porque, em um ciclo de vida comum de um software, a complexidade tende apenas a crescer, e nunca diminuir, e isso acarreta o nosso segundo motivo: a organização acaba se perdendo.

Style Guides

É comum ver códigos que são construídos com maestria no início da vida, ficarem extremamente complicados e difíceis de se entender – o famoso “código macarrônico”. Isso acontece porque, com o crescimento da complexidade, as amarrações de um sistema tendem a ficar mais difíceis e o trabalho para se fazer alguma coisa dentro dele se torna exponencialmente maior, de forma que a maioria dos desenvolvedores acabam focando muito no negócio e se esquecem dos seus parceiros, e a primeira coisa que se perde são os padrões de desenvolvimento.

Todo time tem um padrão de desenvolvimento, seja ele um guia de estilos como o Standard ou então uma arquitetura como MVC. O fato é que não é possível se desenvolver software em conjunto com outras pessoas se não houver uma padronização de: nomes, campos, símbolos, arquiteturas e etc.

Para resolver este problema, uma prática interessante é a escrita de um StyleGuide do time ou da empresa. Este documento deve ter todas as regras de desenvolvimento, padrões de nomenclatura, padrões de pastas e toda a lógica básica por trás dos padrões que o time vai seguir.

Porém, todos sabemos que documentação acaba se perdendo ao longo do tempo se não for mantida. Para ajudar a evitar este problema, o uso de ferramentas como o Prettier, Editor Config e o ESLint é essencial não para criar, mas para manter a organização do repositório de trabalho, pois elas forçam os usuários a se adequarem a este padrão definido.

Repositórios de governança

O problema, quando tratamos de regras e guias, é que nunca sabemos onde devemos colocar estas informações, porque elas não fazem parte de um projeto específico e também é difícil categorizar essas ideias. A melhor solução para este problema é também a solução mais simples possível: Crie um repositório.

O conjunto de regras que regem um time, uma equipe ou uma empresa é chamada de governança, por isso, esses repositórios são chamados de: repositórios de governança.

Você pode dar qualquer nome para eles, desde que seja lá que todos os documentos sobre o time sejam colocados. Aqui são algumas ideias de documentos que você pode armazenar:

• Guias de estilo
• Padrões de desenvolvimento
• Padrões de nomenclatura
• Regras de versionamento
• Datas de cerimônias do Scrum
• Modelos de arquivos de configurações (.gitignore, .package.json, .editorconfig, .pretierrc)
• Definição de quais pacotes serão usados por padrão para fazer tarefas específicas

E qualquer outra regra que seu time precise documentar.

Comunicação

Esta é uma noção que está implícita em todo o time mas nunca é levada como uma regra de qualidade. A comunicação é a parte essencial para qualquer time.

Grande parte da comunicação de um time é advento de um processo de criação de cultura – como falamos nos outros artigos – e este processo só vai se dar quando todos do time concordarem sobre ele.

Um time que se comunica bem não pode ter medo de se encontrar cara a cara para reuniões diárias – deve manter seus horários e compromissos independente se um ou dois membros do time não estejam presentes e também deve saber o que os outros integrantes estão fazendo e como (se possível) ajudá-los de forma que todos possam continuar o trabalho de forma mais rápida e juntos.

O medo de dizer que sua tarefa está errada ou então que não saber fazer algo é o principal motivo pelo qual times deixam de se comunicar de forma eficiente e passam a realizar relatórios de status ao invés de ter, de fato, uma comunicação produtiva.

Se você é um gestor de um time, o processo de criação desta cultura deve vir primeiramente de você e, naturalmente, ser passado para os demais, mas nunca imposto!

Da mesma forma, se você não é gestor mas é um integrante com este espírito de comunicação, então é sua responsabilidade passar este espirito para os seus colegas para que todos concordem que: o time que se comunica é o time que pode fazer qualquer tarefa com qualidade, pois um pode suprir as deficiências do outro enquanto mantém seus próprios afazeres em um alto nível qualitativo, pois sabe que os demais intervirão se qualquer tarefa esteja abaixo deste nível.

Conclusão

Finalizamos nossa trilogia sobre gestão de projetos e times com qualidade que vai além do código escrito, mas está no código que criamos para nos comunicar com os demais membros que, juntos, ajudam a desenvolver o que almejamos.

Espero que esta sequência tenha sido esclarecedora tanto para gestores quanto para integrantes de times!

Até mais!