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

37

Digamos que você tenha começado a trabalhar em um time muito pequeno em um projeto {atualmente relativamente pequeno, embora esperançosamente maior depois}. Note que este é um projeto real destinado a ser usado por outros desenvolvedores no mundo real, não algum projeto acadêmico que deve ser descartado no final de um semestre. No entanto, o código ainda não foi lançado para outras pessoas, portanto, nenhuma decisão ainda está definida.

As metodologias

Um de vocês gosta de começar a codificar e fazer as partes se encaixarem à medida que você passa, antes de você necessariamente ter uma idéia clara de como exatamente todos os componentes irão interagir (projeto de baixo para cima). Outro de vocês gosta de fazer todo o projeto primeiro e detalhar os detalhes de todos os componentes e a comunicação antes de codificar uma solução.

Suponha que você esteja trabalhando em um novo sistema, em vez de imitar os já existentes, e, portanto, nem sempre é óbvio qual deve ser o design final correto. Então, em sua equipe, diferentes membros da equipe às vezes têm idéias diferentes sobre quais requisitos são necessários para o produto final, quanto mais sobre como desenhá-lo.

Quando o desenvolvedor de baixo para cima escreve algum código, o desenvolvedor de cima para baixo o rejeita por causa de possíveis problemas futuros previstos no design, apesar do fato de que o código pode resolver o problema, acreditando que é mais importante obter o design correto antes de tentar codificar a solução para o problema.

Quando o desenvolvedor top-down tenta descobrir o design completo e os problemas previstos antes de começar a escrever o código, o desenvolvedor de baixo para cima o rejeita porque o desenvolvedor de baixo para cima não acha que alguns dos problemas realmente surgem na prática, e pensa que o design pode precisar ser mudado no futuro quando os requisitos e restrições se tornarem mais claros.

O problema

O problema que isso resultou é que o desenvolvedor bottom-up acaba perdendo tempo porque o desenvolvedor top-down frequentemente decide que a solução que o desenvolvedor de baixo para cima escreveu deve ser descartada devido a uma falha de projeto, resultando na precisa reescrever o código.

O desenvolvedor descendente acaba perdendo tempo porque, em vez de fazer o paralelismo do trabalho, o desenvolvedor top-down agora se senta para desenvolver o projeto correto com o desenvolvedor de baixo para cima, serializando os dois até o ponto em que ele pode até ser mais rápido para uma pessoa fazer o trabalho do que 2.

Ambos os desenvolvedores querem continuar trabalhando juntos, mas não parece que a combinação esteja realmente ajudando qualquer um deles na prática.

Os objetivos

Os objetivos comuns são, obviamente, maximizar a eficácia da codificação (ou seja, minimizar o desperdício de tempo) e escrever softwares úteis.

A questão

Simplificando, como você resolve esse problema e enfrenta essa situação?

A única solução eficiente que posso pensar que não desperdice tempo é deixar que cada desenvolvedor siga seu próprio estilo para o design. Mas isso é mais difícil do que parece quando você analisa o código e realmente precisa aprovar as alterações uns dos outros, e quando você está tentando projetar uma estrutura coerente para os outros usarem.

Existe uma maneira melhor?

    
por Mehrdad 29.06.2016 / 04:23
fonte

9 respostas

54

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.

    
por 29.06.2016 / 09:18
fonte
23

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.

    
por 29.06.2016 / 05:25
fonte
7

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

    
por 29.06.2016 / 05:10
fonte
7

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.

    
por 29.06.2016 / 08:10
fonte
6

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.

    
por 29.06.2016 / 09:57
fonte
5

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.

    
por 29.06.2016 / 13:55
fonte
4

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.

    
por 29.06.2016 / 19:46
fonte
3

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
Portanto, a ênfase deve ser colocada em alcançar um sistema de "trabalho" o mais rápido possível, mesmo que isso signifique ignorar casos de esquina, etc ... Este é o conceito da "fatia vertical fina": em vez de construir as fundações da casa, depois as paredes, depois a estrutura do telhado, ... e apenas obtendo algo utilizável no final (ou nunca obtendo, ou não sendo realmente utilizável) ... é melhor construir um totalmente equipado quarto primeiro, como o banheiro. É utilizável imediatamente e pode ser usado para obter feedback.

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

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

A primeira coisa é que ambos precisam entender a necessidade de colaboração e a necessidade de concordar com um caminho a seguir: constantemente ser repreendido, como eles são, é obrigado a dar nos nervos e afetar a motivação de alguém. Eu apresentei acima o que eu encontrei para trabalhar bem na prática em vários projetos, você pode usá-lo como sugestão.

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.

    
por 30.06.2016 / 14:39
fonte
2

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.

    
por 29.06.2016 / 09:26
fonte