Temos um novo projeto em andamento e, no momento, os desenvolvedores foram divididos em duas equipes, a equipe A e a equipe B. Esse projeto tem duas partes, que requerem desenvolvimento em toda a pilha de desenvolvimento. Amostra muito simplificada de nossa pilha mostrada abaixo:
Cada parte do projeto requer desenvolvimento em toda a pilha; portanto, eu normalmente esperaria uma abordagem de desenvolvedor de pilha cheia, que é como dividimos nosso trabalho na equipe B, projetando e trabalhando as interações entre diferentes partes.
Recentemente, eu aprendi, no entanto, que a equipe A quer estar encarregada de certas partes da pilha e está propondo uma divisão entre as duas equipes, onde a Camada de Abstração de Dados (e a colocação de conteúdo na camada de Dados) é gerenciada por sem desenvolvimento da equipe B. A divisão seria algo parecido com isso:
Para mim, isso parece muito natural. Cada equipe possui diferentes objetivos e escalas de tempo para alcançá-los, mas o Time B dependerá do Time A para implementar os recursos. A solução proposta é que as interfaces comuns sejam definidas antecipadamente (provavelmente há um prazo de 2 anos no projeto para que possam ser numerosas). A equipe A desenvolverá os bits necessários para essas interfaces desde o início, apesar de ter seu próprio conjunto de metas, enquanto a equipe B desconsiderará todas as chamadas para o curto prazo imediato, para que possam progredir.
Tenho preocupações com esta abordagem em relação a:
- As interfaces podem mudar e a Equipe A pode não ter largura de banda ou tempo para acomodar requisitos variáveis.
- Os erros no código do Time A podem impedir o andamento do Time B e, novamente, eles podem não ser a prioridade para corrigi-los devido ao fato de o Time A ter uma fila de priorização diferente.
- Falta de conhecimento espalhado pelas equipes - a equipe B pode não entender completamente o que acontece e pode tomar más decisões de design por causa disso.
Foi sugerido que muitas empresas do setor têm sub-equipes e devem ser capazes de lidar com isso. Pelo meu entendimento, geralmente as equipes dividem o que eu esperava inicialmente (Full Stack) ou dividindo a pilha de tecnologia como abaixo:
Então, estou interessado em saber o que o resto da indústria está fazendo. A maioria das divisões é vertical / horizontal? Uma divisão diagonal faz sentido? Se ocorrer uma divisão diagonal, minhas preocupações parecem válidas e há mais alguma coisa com a qual a equipe B deva se preocupar? Para observar, provavelmente serei responsável pelo sucesso ou fracasso da equipe B.
Respostas:
Suas preocupações são extremamente válidas. Especialmente os dois primeiros pontos sobre o time A não ter tempo para adicionar recursos ou corrigir bugs que afetam o time B. Já vi isso acontecer em meu próprio trabalho algumas vezes.
Pode ser uma boa ideia se:
Sabe-se que o Time A estará trabalhando nos projetos que exigem novos recursos no banco de dados, enquanto o objetivo do Time B é essencialmente executar recursos "somente de front-end". Por exemplo, se a Equipe B estiver escrevendo o novo aplicativo para iPhone da sua empresa, é provável que eles não adicionem novos campos de banco de dados por um tempo, pois precisam portar / reimplementar todos os recursos da versão para desktop.
A "pilha completa" tornou-se suficientemente complexa para que nenhum desenvolvedor (ou equipe de desenvolvimento) possa efetivamente "possuir" a coisa toda. Por "próprio", quero dizer não apenas adicionar recursos e corrigir bugs, mas entender e se preocupar com todo o sistema, a ponto de evitar evitar adicionar mais dívidas técnicas ao longo do tempo. Nesse caso, a divisão "diagonal" é a jogada mais sensata se a equipe A possuir uma API da interface do usuário / Web que seja extremamente simples ou inevitavelmente fortemente acoplada à implementação do DAL / banco de dados (talvez algumas ferramentas internas de diagnóstico?), Enquanto a equipe B todas as coisas complicadas de front-end voltadas para o usuário.
A gerência entende o risco de a Equipe A se tornar um gargalo e estaria dis-diagonalizada, se ou quando esse risco se transformar em um problema real.
Não posso falar com o que é mais ou menos comum no setor, mas pelo menos onde trabalho, há uma clara necessidade de todos os desenvolvedores de aplicativos serem "full stack". O que temos são equipes de "infraestrutura" que desenvolvem / mantêm nosso banco de dados interno, nossa estrutura de serviços da Web e nossa estrutura de interface do usuário (mencionei que minha empresa é grande?), Para que todas as nossas centenas de aplicativos possam ter pilha completa desenvolvedores, enquanto a empresa como um todo ainda pode fornecer desempenho consistente e interface do usuário para todos os nossos serviços.
Recentemente, nossa empresa criou uma nova estrutura de interface do usuário, então houve um período em que alguns de nossos novos aplicativos foram bastante bloqueados por bugs e recursos ausentes na nova estrutura. Esse não é mais o caso, principalmente porque alguns de nós receberam permissão para enviar solicitações pull à equipe que possui a estrutura (não é exatamente "des-diagonalização", mas você entendeu).
fonte