Coding é mais sobre times do que você imagina. Entenda o porquê.
Você prefere “codar” sozinho ou discutir suas soluções em grupo?
"Ideias não nascem prontas. Os debates são essenciais para aprimorá-las, estimulando criatividade e inovação."
Assim como uma ideia, um código dificilmente nasce em sua melhor versão. Um desenvolvedor sozinho tende a se contentar com a primeira solução ou a adicionar complexidade desnecessária.
Sozinho você será capaz de escrever um código que funcione, mas poderá “ignorar” boas práticas de desenvolvimento, aumentando custos com manutenção e chances de erros, principalmente em sistemas de maior complexidade. Sozinho, faltam referências e estímulos para otimizar o que foi escrito.
Coding é um processo interativo. Código bom precisa estar em constante processo de melhoria, sua otimização ocorre de forma incremental. O processo de otimização terá melhores resultados se feito em grupo, sendo estimulado a partir de discussões, com testes, experimentações e refactoring.
Construir software sozinho é subestimar nossa capacidade de criar algo realmente grande e aumentar o risco de falharmos. Por trás de milhares de linhas de código ou do design de uma arquitetura altamente escalável, temos a ânsia de criar algo realmente de impacto. Então, por que não aumentar a chance de sucesso compartilhando este processo?
As vantagens do Collective Code Ownership
Desenvolver e manter software sozinho são tarefas que envolvem uma série de riscos.
O Collective code ownership é um conceito apresentado pelo Extreme Programming, um dos processos de desenvolvimento ágil mais conhecidos e antigos do mercado. Consiste no fato de que todos do time se sentem responsáveis pelo código e sua qualidade. Qualquer membro pode alterar, evoluir, corrigir falhas e realizar refactoring. Ninguém é dono exclusivo de uma parte ou de todo o código.
Entre as grandes vantagens deste modelo, está o aumento do “Bus factor e a redução das chances de projetos naufragarem.
"Bus Factor é o número de pessoas que precisariam ser atropeladas por um ônibus (ou qualquer veículo, ou sair de férias, ou mudar de empresa, etc) para que o projeto falhe. Para garantir o sucesso de um projeto, é importante manter este número sempre acima de 1. "
Além do Bus factor, outras vantagens que podemos citar são:
- Comunicação fluída, todos sabem o que está acontecendo;
- Conhecimento compartilhado, estimulado pela rotatividade dos desenvolvedores;
- Menor tempo de resposta aos erros, qualquer um pode fazer um bugfix e corrigir o problema;
- Menos bloqueios e maior produtividade, não é preciso autorização para modificar parte do código;
- Tomada de decisões mais rápidas, todos conhecem toda ou grande parte da base de código, o que gera discussões produtivas;
Lembre-se que desenvolvendo sozinho corremos o risco de percorrer longos caminhos no sentido errado e mesmo que estejamos certo, vai levar muito mais tempo para alcançar os resultados.
Disciplina e boas práticas
A disciplina do time, o uso de boas práticas e ferramentas na rotina de desenvolvimento são essenciais para o sucesso deste modelo. Entre algumas destas práticas podemos citar:
Code Review: fazer a revisão de todo o código incluído ou modificado é uma excelente forma de compartilhar o conhecimento, seja negocial ou de boas práticas de programação, como clean code. Pode promover a redução de riscos de "quebra" de serviços e promover o feedback rápido para os mais novatos a respeito da qualidade das suas implementações.
Talks/Meetups: possibilitam reforçar os aprendizados dos desenvolvedores e desafios pelos quais passaram. Estimular que elaborem pequenas palestras, pode reduzir o risco de que outros tentem “reinventar a roda” ou cometer os mesmos erros.
Pair Programming: colocar lado a lado desenvolvedores com perfis, visões e experiências diferentes, pode parecer perda de tempo, mas sem dúvidas, que participa tende a sair melhor e com novos aprendizados. A diversidade de opiniões e pontos de vista, irão criar inúmeras possibilidades de resolução de problemas, além de maiores chances de acerto e ganhos de qualidade.
Daily Meetings: checks diários permitem a resolução rápida de bloqueios do time através do estímulo à colaboração entre os membros. Melhor do que todos com atividades "em andamento", é termos atividades "concluídas". Ponto importante é que a daily deve trabalhar para o time e não como um status report. Deve servir para que todos saibam o que está sendo feito e como podem colaborar para um resultado melhor.
Responsabilidade de todos != responsabilidade de ninguém
"Cão com muitos donos morre de fome"
A linha é tênue entre todos são responsáveis e ninguém é responsável. O que diferencia é o resultado do time diante de suas responsabilidades, e consequentemente, a confiança e autonomia conquistadas.
Da mesma forma, ownership coletivo não implica na ausência de liderança. Todo time deve ter um líder, quem remova nossos bloqueios e nos mostre a direção correta. Ter um líder não significa que as decisões devam que ser tomadas de forma unilateral, sendo impostas, mas que podem sim ser tomadas a partir de discussões.
Algumas ações e boas práticas que podem contribuir para a construção da confiança:
- Prevenção de falhas através de um bom nível de cobertura de testes e automação de rotinas de build e deploy;
- Monitoramento do desempenho e disponibilidade das aplicações e serviços;
- Indicadores de desempenho do time;
- Resposta rápida a bugs;
Conclusão
Não limite sua capacidade de desenvolver soluções de impacto. Não aumente o seu risco de falhar. Exponha e discuta seu código.
Através do coding coletivo e boas práticas de desenvolvimento, podemos gerar um ambiente onde times têm maior confiança e produtividade, soluções são discutidas, modificadas e otimizadas constantemente.
Esqueça aquela história de herói, hacker ou gênio. Grandes produtos e empresas não atingiram sucesso com uma pessoa apenas, mas sim com poderosos times. Afie suas habilidades de comunicação e estimule o comportamento colaborativo no seu time.
Comentários