Como é trabalhar em uma grande equipe de programação?

Eu sempre tive sorte de trabalhar em uma pequena equipe de programação. Eu acho que o máximo com o qual trabalhei são 11 programadores. Como é trabalhar em um projeto com centenas de desenvolvedores? Milhares? O que escala e o que não escala?

EDIT: Obrigado por todas as respostas! Parece haver muito poucos aspectos positivos:

• possível trabalhar em mega-grandes bases de código
• melhor desenvolvimento de carreira interna
• proteção dos funcionários contra a administração abusiva (isso é mais - em pequena do que em + em geral)

Existe algum outro benefício para grandes equipes?

Acho escalas de burocracia muito bem.

Fora isso, não muito. Projetos grandes têm equipes grandes porque não há outra maneira, não porque é mais eficiente (por desenvolvedor). Você paga um custo assim que adiciona uma segunda pessoa à mistura em termos de ineficiência (por exemplo, transferência de conhecimento e comunicação).

O maior projeto em que trabalhei teve cerca de 70 desenvolvimentos em 5 locais diferentes. Mesmo uma alteração de uma linha levou um dia no mínimo, embora isso tenha ocorrido em parte devido ao fato de a compilação levar mais de 45 minutos em um link de rede de Zurique a Londres e o início do aplicativo demorar mais 45 minutos. Os check-ins levaram cerca de 5 minutos por arquivo. Eu não estou brincando. Os desenvolvedores de Londres poderiam fazer isso em uma fração do tempo.

De qualquer forma, o que você costuma encontrar é que, em grandes projetos, você terá vários membros da equipe com os quais não interage muito. É mais como uma coleção vagamente afiliada de mini projetos. Li uma vez que o desenvolvimento da Microsoft tendia a dividir projetos em equipes de 5 a 7 desenvolvedores, mesmo para grandes projetos como o Microsoft Office.

Parte da diferença também é a diferença entre pequenas e grandes empresas: as maiores tendem a ter mais processo, mais regras, menos flexibilidade e assim por diante. Mas isso não é garantido.

Pode ser bom para o desenvolvimento de carreira. Em uma empresa pequena, alguém precisa sair ou morrer antes que você possa obter uma promoção (ou a empresa precisa crescer para que a equipe se expanda e você suba), enquanto em departamentos de desenvolvimento maiores, você pode se mover entre equipes e assim por diante.

Além disso, às vezes você pode encontrar pessoas realmente inteligentes para se apegar e aprender. Em pequenas empresas, ser tão isolado e autossuficiente pode ser propício para os programadores ficarem um pouco "estranhos", mais ou menos como um eremita.

A comunicação é o que eu considero a maior coisa que começa a se degradar à medida que o tamanho da equipe cresce. Torna-se mais difícil divulgar a comunicação e mais difícil garantir que todos continuem na mesma página. Eu trabalho indiretamente em uma equipe de cerca de 75 desenvolvedores, usamos uma base de código comum, mas muitos dos 75 se dividem em grupos menores para "atividades" individuais. Para nós, a comunicação é apenas um pesadelo total.

O gerenciamento de grupos maiores também é mais difícil, pois na maioria dos ambientes, após 8 a 12 pessoas, membros adicionais do gerenciamento se envolvem, infelizmente isso apenas exagera o problema de comunicação, pois normalmente cria um ambiente do tipo "silo" em que os subconjuntos individuais começam a interromper o processo. grupo grande e tente manter o conhecimento dentro do grupo.

Quando eu fiz software para sistemas de armas, tínhamos GRANDES equipes de desenvolvedores de software. Como ninguém pode entender os requisitos (alguns dos quais foram classificados), tratava-se de equipes e de como as equipes interagiam umas com as outras.

1. Gerenciamento de configuração - o processo noturno de construção - foi um grande negócio. Naqueles dias, era preciso um grande cluster de computação distribuída para recompilar o mundo todas as noites.

2. As autorizações de trabalho - e cobrar seu tempo pelo item de linha correto no cronograma geral do projeto - foi uma grande dor no pescoço. Até as 0,1 horas. incrementos.

Mas o maior negócio foi a notificação de alterações. Particularmente alterações na interface.

Isso foi tão importante que eles inventaram esse processo louco de duas camadas. A maior parte do esforço foi feita para garantir que a Solicitação de Aviso de Alteração de Interface (não a notificação em si, mas a solicitação de notificação) tivesse elaborado software de suporte com um banco de dados e relatórios e o que não.

Uma vez que o pedido foi aprovado, o aviso real mais ou menos foi sem dizer. Significando que era realmente um processo de uma camada e a solicitação efetivamente era o aviso. Mas, quando você está desenvolvendo o desenvolvimento em cascata, tudo precisa ser pensado muito antes de qualquer desenvolvedor aparecer.

Com tantas pessoas trabalhando em paralelo, havia uma placa de controle de configuração. Todos os vários gerentes de equipe, além de um grupo de pessoas cujo trabalho era simplesmente coordenar as mudanças.

Meu primeiro trabalho de programação "real" foi trabalhar com outros exércitos para desenvolver sistemas internacionais de controle de tráfego aéreo. Foi um empreendimento de muito sucesso e fomos considerados um ambiente de nível 5 do modelo de maturidade de capacidade. Desde então, estou em lojas de médio e pequeno porte. Então, qual é o melhor lugar para se estar? Pessoalmente, eu compraria uma loja menor do que a enorme qualquer dia. Embora alguns possam considerar o Nível 5 como o Santo Graal, para mim foi sufocante. Tudo tem que ser documentado, aprovado, assinado, etc. Não me interpretem mal, eu definitivamente vejo o valor, especialmente para sistemas tão críticos quanto o controle de tráfego aéreo, mas a questão é: como você deseja gastar seu dinheiro? dia? Você quer a liberdade de poder sonhar com as coisas e depois implementá-las, ou você deseja escrever nos requisitos? Talvez se eu tivesse ficado mais tempo com o sistema ATC, eu poderia ter chegado ao nível de poder projetar e desenvolver, mas mesmo isso exigia um número X de anos, número Y de aprovações e número Z de promoções - tudo bem prescrito sem chance de desvio. Foi sufocante.

Uma última coisa, em geral, acho a qualidade dos desenvolvedores muito mais alta nas empresas menores, simplesmente porque elas não podem se esconder. Não é difícil ser medíocre em uma empresa muito grande, mas torna-se dolorosamente óbvio em uma empresa pequena e elas geralmente não duram muito.

Eu trabalhei (brevemente) em uma organização com pelo menos centenas de desenvolvedores. Mas é claro (?), A organização é particionada internamente para que você, como um único funcionário, não tenha contato direto com todos os outros, seria muito difícil acompanhar isso.

Nesse local específico, o software foi dividido em componentes, com equipes formadas em torno de componentes. Algumas equipes trabalhariam com apenas um único componente (grande), enquanto muitas equipes eram responsáveis ​​por vários componentes (menores).

Obviamente, isso implica tudo o que o trabalho com uma base de código muito grande faz; coisas como gerenciamento de configuração, construção, integração etc. tornam-se importantes, grandes, coisas que são feitas por departamentos dedicados especializados. E você os admira, por ser capaz de coletar a saída de todos os departamentos de desenvolvedores e integrar regularmente (uma vez por semana, onde eu trabalhei) a integrar tudo isso em um todo coeso que realmente funcionou.

Eu nunca trabalhei para uma grande equipe de programadores , mas o resultado de uma organização aumentando de tamanho geralmente é mais regras. Isso nem sempre é uma coisa ruim! Além das regras que dificultam a vida de todos, também existem mais regras para proteger os funcionários e garantir um bom processo.

Vi gerentes de pequenas organizações se safarem de coisas que os levariam imediatamente ao departamento de RH da empresa.

A única diferença que notei em grandes projetos é a política do escritório. Quanto maiores os projetos, mais dominantes são as políticas.

Meu primeiro projeto fora da escola foi algumas centenas de desenvolvedores. Como um desenvolvedor arrogante e ingênuo recém-chegado da escola, eu realmente não estava pronto para isso. A única coisa que salvou minha hiney (e é a única coisa que vai nunca realmente protegê-lo) foi a quantidade de amigos que eu fiz.

Essa é a maior lição que aprendi disso. Tente fazer amizade com todos . Até os idiotas. Em particular, se você tiver a chance de parar de trabalhar por um minuto e conversar com alguém com quem nunca conversou antes, faça-o.

Certa vez, passei um ano trabalhando em uma equipe com mais de 500 pessoas, cerca de 200 delas eram desenvolvedores. Estávamos entregando um EOA, integrando várias soluções SOA diferentes.

Na prática, havia entre 30 e 50 equipes, cada uma com um número variável de programadores (3 em nossa equipe), cada uma com responsabilidade por um aspecto diferente da entrega geral.

A maior equipe em que trabalhei foi de cerca de 15 pessoas (isso foi apenas por 3 ou 4 meses, em uma empresa diferente). Eu era o líder técnico da equipe, e comecei a trabalhar às 7 da manhã. Recebia 2 horas antes que todo mundo entrasse, era a única maneira de realizar qualquer uma de minhas próprias tarefas.

Eu não gostaria de trabalhar em uma equipe com mais de 8 ou 10 desenvolvedores, 15 eram demais para uma única equipe (a equipe poderia facilmente ser dividida em duas, infelizmente não é minha decisão), 3 ou 4 desenvolvedores são um bom tamanho confortável IMHO