Como lidar com diferentes estilos de desenvolvimento (top-down vs. bottom-up) em uma equipe?

Obviamente, ambos estão errados.

O cara de baixo para cima está hackeando código e nunca produzirá algo que faça o que é suposto fazer - será uma rotatividade contínua conforme os requisitos desconhecidos forem determinados.

O cara de cima para baixo pode gastar tanto tempo em visão arquitetônica e não fazer nada produtivo também.

No entanto, um meio termo é ideal - se você conhece as metas para as quais trabalha (que você obtém de um amplo trabalho de design) e continua codificando (sem qualquer planejamento detalhado), colherá as recompensas de um sistema que é organizado e desenvolvido de forma eficiente.

A propósito, chama-se Agile (não a versão BS do ágil que algumas pessoas praticam onde os procedimentos são mais importantes do que o software em funcionamento), mas sim a agilidade que é trabalhar para um objetivo final comumente descrito e compreendido.

Para consertar o problema aqui, tente uma abordagem ágil (o Kanban é provavelmente o melhor), o que forçará o cara top-down a fazer algum trabalho, e forçará o cara de baixo para cima a planejar o que ele está tentando fazer. alcançar.

Os dois desenvolvedores precisam manter um respeito mútuo entre si.

A pessoa de cima para baixo precisa respeitar o fato de que a pessoa de baixo para cima pode ter inventado algo que realmente funciona. Como um dos meus professores "quant" me disse: "Um modelo de trabalho vale mais que 1000 palpites". Se for esse o caso, a pessoa de cima para baixo deve pensar em refazer seu "design" para acomodar o trabalho da pessoa de baixo para cima.

A pessoa de baixo para cima também deve respeitar o "quadro" de cima para baixo, e perceber que isso pode ser bom para evitar esforço desperdiçado, resolver o problema errado, desviar do assunto etc. O codificador bottom up deve pelo menos manter em mente, o que a pessoa de cima para baixo está tentando fazer, e tentar abordar pelo menos as preocupações de cima para baixo, conforme expresso na estrutura. Isso seria verdade mesmo se o bottom-upper discordasse de partes do framework em si.

Você pode minimizar a perda de tempo gasto por cada desenvolvedor se você dividir tarefas grandes em várias tarefas menores e mais focadas. Peça-lhes que trabalhem em conjunto para que nenhum deles fique muito à frente do outro. Sprints curtos e entregas pequenas vão longe. É mais fácil consertar um pequeno erro do que um grande erro.

Pode parecer contra-intuitivo para o seu objetivo, mas a programação em par funciona. Há coisas que você simplesmente não pega imediatamente, às vezes por horas ou até dias. Se trabalhar diretamente nas tarefas em conjunto estiver fora de questão, experimente rever / colocar em stand-up de código com mais frequência ao longo da semana.

Mantenha todos informados!

Se você está vendo os devs descartar código porque eles estavam fora em seu próprio mundo, você precisa pegar e reconciliar os conflitos o mais rápido e eficiente possível. Seu chefe irá apreciá-lo, e a equipe apreciará não ter que jogar fora uma semana de trabalho porque ele não sabia o que o outro cara estava fazendo.

Você também deve vê-los trabalhando juntos como uma bênção. O fato de estarem trabalhando juntos e consertando seus erros é um bom sinal. Eu fiz isso no meio do seu post pensando "cara esses dois provavelmente se odeiam ..." e para minha surpresa você disse que eles querem continuar trabalhando juntos.

Acho que essa citação é apropriada, considerando seu cenário.

"If two people agree on everything, one of them is unnecessary." ~ Some Old Guy

Isso realmente soa como um cenário ideal para mim. Então, novamente, eu sou ambos desenvolvedores ao mesmo tempo. Eu gosto de esboçar o "quadro geral" na forma de notas que acabam sendo incluídas em um rastreador de problemas. Então começo a pensar nos detalhes da implementação de baixo para cima. O quadro geral evolui à medida que ganho uma melhor compreensão de como as peças se encaixam e as peças evoluem à medida que os requisitos mudam e eu recebo novas ideias.

Talvez seja um bom modelo para vários cérebros.

Na minha opinião, eles são perfis complementares e podem acabar indo muito bem. Tanto a codificação como o design são fases necessárias na programação e você não quer acabar em uma equipe onde ninguém quer fazer X, tudo que você precisa é de um pouco de organização (veja eu posso ter um ousado palavra também!)

Isso pode ser feito por meio da supervisão, como outros apontaram, mas ainda melhor por acordo mútuo em um cronograma de iteração de quando projetar e quando codificar, e evitar, em geral, codificar o que está atualmente em projeto.

Ponto de bônus, assim que um projeto é splat em módulos menores, o programador top-down pode projetar coisas que o programador bottom-up não está trabalhando atualmente, tornando-se uma fase em que ambos fazem o que quiserem. Isso, no entanto, implica na capacidade de ambos fazerem os ajustes necessários quando chegar a hora de juntar tudo.

Uma nota: você disse

Assume that you are working on a new system rather than mimicking existing ones, and thus it is not always obvious what the right end-design should look like.

Isso faz parte do problema: a menos que você esteja trabalhando em um projeto minúsculo para um problema já resolvido, não é realmente um projeto final correto . Existem muitos designs possíveis. Tenha em mente que, a menos que você esteja fazendo isso para aumentar o ego devido à beleza de seu código, o objetivo final é um aplicativo funcional. É isso aí. Como você chega lá é irrelevante, e a melhor maneira de deixar os dois irem rápido é fazê-los trabalhar juntos, de forma complementar.

Como outros disseram, ambas as visões podem estar corretas de certas maneiras. Está longe de ser incomum que dois desenvolvedores discordem sobre práticas, especialmente para algo tão subjetivo quanto os processos de design e desenvolvimento. Você tem duas pessoas aqui que são apaixonadas pelo que fazem e conhecem bem como fazê-lo: abraçar isso!

Há um grande potencial aqui para você permitir que ambas as pessoas trabalhem em seu próprio caminho e ainda combinar as peças para obter um aplicativo em funcionamento.

1. Eu teria os dois sentados e discutindo, encorajando-os a ver do ponto de vista do outro.

2. Depois dessa discussão, você pode começar a falar sobre planejamento: isso deve ser feito em equipe, com o entendimento de que nenhum dos dois tem que "conceder" ao outro, mas é preciso fazer concessões. Há várias maneiras de planejar a arquitetura de uma base de código que permita que ela seja estendida com facilidade mais tarde, sem introduzir uma tonelada de código extra.

3. Uma vez que você possa levá-los a algum tipo de trégua, deixe-os correr soltos! Deixe que o 'top down guy' planeje a arquitetura de alto nível, interfaces, hierarquias, etc. Deixe o 'bottom up guy' entrar e começar a escrever o código assim que houver um par de módulos planejados. Faça com que eles concordem formalmente em aceitar os métodos do outro como sendo bons para o projeto como um todo: Planejar para permitir mudanças futuras fáceis é bom, mas não precisa ser codificado dessa maneira imediatamente. Crie interfaces e elimine métodos para obter a estrutura do código e aceite que um bom bocado do código para o futuro não será realmente escrito até ser necessário.

4. Peça que eles revisem o design e o código com frequência, juntos. Repita os ciclos em que você mergulha em alguns segmentos da arquitetura, planeja com mais detalhes e escreve essas partes.

5. Este é provavelmente o ponto mais importante: Facilite pontos no ciclo em que eles falam apenas sobre o processo, em vez do trabalho que está sendo feito. Reflita sobre a dinâmica sendo construída: há quatro perguntas que você deveria estar fazendo. O que correu bem que devemos continuar fazendo? O que foi mal que devemos parar de fazer? O que estamos perdendo? O que podemos fazer sobre o que estamos perdendo?

Isso exigirá algum trabalho: você precisa convencê-los a trabalhar juntos de suas próprias maneiras. Não é fácil para algumas pessoas admitir que não existe uma maneira única e correta de fazer as coisas. O importante não é o modo como você trabalha ou como o código se parece no final; o importante é que essas duas pessoas qualificadas e conhecedoras aprendam a trabalhar melhor em conjunto. Não é algo que você possa dizer a eles; Tudo o que você pode fazer é guiá-los através de um processo de aprendizado de como fazê-lo. Assim como não há um projeto certo, não há um caminho certo para as pessoas trabalharem.

Geralmente, na minha experiência ao longo da minha carreira, há um projeto insuficiente na frente. E o design que acontece na frente é baixa qualidade . Isto é mau. Principalmente porque o resultado é (em maior ou menor grau) jogar lama na parede e ver o que pega. A dívida técnica começa a partir do começo.

De cima para baixo é geralmente superior ao bottom-up. Embora eu não descarte inteiramente de baixo para cima. A razão para isso é que de cima para baixo obriga você a pensar sobre o problema de forma mais ampla e a fazer perguntas melhores . Isso reforça o primeiro ponto acima ... leva a um design de maior qualidade e geralmente influencia muito o trabalho de nível mais baixo. Isso reduz o retrabalho considerável que muitas vezes é necessário se os componentes de nível inferior forem construídos primeiro.

Existe um risco não insignificante de que, se os componentes de baixo para cima forem construídos primeiro, a pressão de desenvolvimento tenta moldar os requisitos de negócios aos componentes que foram projetados. Isso também é ruim. Os requisitos de negócios devem impulsionar o design, o que deve impulsionar a implementação. Qualquer coisa que vá para o outro lado levará a resultados inferiores.

Nenhuma abordagem é suficiente. Parece que cada um deles é inteligente ou experiente o suficiente para perceber as deficiências da outra abordagem (talvez eles tenham sido queimados?), Mas não conseguem enxergar as deficiências de sua própria abordagem selecionada ...

A verdade é que uma abordagem mista é necessária:

• é quase impossível criar o design "certo" antecipadamente; um grau de experimentação é necessário para identificar os pontos de dor, gargalos, ... (dica: eles nunca estão onde você acha que eles estarão)
• é quase impossível ir a qualquer lugar apenas "indo", é mais provável que você termine em algum lugar que não queria, ou simplesmente corra em círculos, do que qualquer coisa

Misturando ambos, no entanto, você pode:

• faça um esboço com orientações e um esqueleto de infraestrutura
• e desenvolvimento de componentes que se encaixam nessa visão

Como não existe nenhum sistema existente que atenda a esse propósito, é importante perceber de antemão que:

• experimentação / prototipagem será necessária
• iteração, portanto, será necessária

Para que o feedback seja valioso, é melhor abordar primeiro uma parte principal.

Então, o que você faz com seus colegas de trabalho?

Então, eles precisam concordar sobre quem faz o quê. Observe que, na abordagem do meio-termo sublinhada acima, os dois devem cumprir tarefas que apreciam.

Note que construir os esqueletos e construir os tijolos é melhor abordado de forma incremental.

1. Os dois devem obter um esboço do esqueleto e decidir juntos qual "fatia fina" focar primeiro
2. O cara de baixo para cima deve começar a trabalhar na parte mais bem compreendida de "fatia fina"
3. O cara de cima para baixo deve começar a desenvolver o esqueleto, idealmente atacando as peças mais bloqueadoras primeiro por completar a fatia

Enxague e repita até obter a fatia funcionando; acumular feedback ao longo do caminho para ajustar conforme necessário.

Cuidado: este é um protótipo, ambos precisam estar prontos para jogá-lo fora e começar do zero em um design completamente diferente.

O que você precisa é de um líder (ou supervisor) que entenda de desenvolvimento de software, e que tome a decisão sobre qual abordagem deve ser usada no projeto. Se necessário, o líder direciona os desenvolvedores a trabalhar de uma maneira particular, independentemente de suas preferências pessoais.

The only efficient solution I can think of that doesn't waste time is to let each developer follow his/her own style for the design.

Na verdade, poderia ser altamente ineficiente ... porque as chances são de que haverá muito conflito e retrabalho. Pior ainda, você pode acabar com uma falha total do projeto.