Disclaimer: todas as evidências são anedotais ou experiências próprias. Nenhum trabalho ou livro foi usado como referência. O texto é, pura e simplesmente, minha opinião pessoal.
No mundo agile, é normal repetirmos que toda a stack é de propriedade comum, que todos devem cuidar e se sentir responsáveis pela qualidade de código e pelo projeto como um todo. Atingir e utilizar esse tipo de arranjo é muito bonito na teoria, porém, muito difícil de ser aplicado na prática.
É necessário uma equipe muito madura e comprometida para manter essa dinâmica funcionando. No geral, quando tudo é de todo mundo, nada é de ninguém. Muitas coisas acabam sendo negligenciadas ou mal feitas, e todo mundo vai ter uma desculpa para não fazê-las.
A proposta aqui é transformar cada integrante da equipe em “dono” de um pedacinho do projeto.
Alguns exemplos de responsabilidades que podem ser distribuídas são:
- Arquitetura;
- Documentação: de usuário, ADRs, post-mortems;
- Versionamento: branchs, tags, formatação dos commits;
- Testes: cobertura, tipos de testes;
- Atualizações: controle das dependências;
- Débito técnico;
- Padronização: padrões de código, linters;
- Builds e deploys;
Impacto
A separação de responsabilidades permite que cada integrante consiga contribuir de maneira mais impactante e profunda, já que não é necessário uma preocupação tão grande com todas as áreas ao mesmo tempo.
Essa maior participação pode causar, também, uma melhora na percepção de pertencimento e realização, favorecendo decisões com benefício a longo prazo, ao invés de decisões que podem ter uma melhora no curto prazo mas serem prejudiciais depois.
Pressão
Participar de um projeto moderno traz consigo a necessidade de uma gama cada vez maior de conhecimentos. A pressão por bastante conhecimento em cada uma das partes acaba por atrapalhar o desenvolvimento do pessoal e consequentemente, a qualidade do projeto. Diminuir esse leque pode trazer maior tranquilidade e uma melhor experiência de trabalho.
Accountability
Um time onde cada um é responsável por uma parte, permite um maior controle das partes, já que cada um sabe com o que se preocupar e qual é sua área. Isso não significa que só essa pessoa fará esse trabalho, mas que ela é responsável pelo resultado final.
Hierarquia
Algum nível de hierarquia é necessária para que o time como um todo funcione. Todos devem contribuir, ser ouvidos, mas é importante que alguém tenha o poder de decisão, o que evita alguns problemas como over engineering e principalmente, um projeto muito heterogêneo. O ganho no longo prazo de se ter uma “única voz” é muito grande, já que o todo se torna mais conciso.
Conclusão
A distribuição das responsabilidades permite um maior controle e um aumento de qualidade nas partes individuais do projeto. No geral, a qualidade técnica tende a subir significativamente, porém, vem também com uma maior necessidade de gestão e controle, já que, em essência, esse modelo favorece um time de especialistas e não generalistas.
