Um colega me peguntou sobre o desafio que estás tendo em organizar equipes de desenvolvimento. Sua pergunta se refere a como organizar as equipes; por projetos, por camada…
Abaixo segue minha sugestão…
Dá uma olhada em como Amazon usou a Lei de Conway. Veja também a palestra de Randy Shoup na FlowCon 2013.
O ponto mais importante sobre a lei de Conway na Amazon é o seguinte: alinhar a divisão de API com a divisão dos equipes/times. A comunicação entre as equipes é sempre menor do que a comunicação dentro de uma equipe. Semelhantemente, uma API reduz a quantidade de informação que você precisa saber sobre uma parte do sistema, a fim de interagir com ele. Pense nas equipes como APIs, separadas de forma a simplificar a interação entre elas.
É por isso que as equipes por projetos ou as equipes por camada (UI, DB, etc) tendem a causar problemas. Dividindo equipes por projetos não reduz a quantidade de comunicação entre elas e como utilizam e criam as funcionalidades do sistema. Isso torna as equipes mais lentas, e nos leva a adicionar nivéis de gerenciamento para (tentar) ajudar na comunicação. Dividindo por camada também é ruim. A fim de implementar uma funcionalidade, você precisa alinhar várias camadas; e mais uma vez, isso requer altos níveis de comunicação.
Ou seja, dá-lhe Conway! Começe a pensar na reorganização da sua empresa. Organizar equipes como APIs me parece bem interessante.
Organizações que desenvolvem sistemas de software tendem a produzir sistemas que são cópias das estruturas de comunicação dessas organizações. ~ lei de Conway
