Como lidar com diferentes estilos de desenvolvimento (de cima para baixo versus de baixo para cima) em uma equipe?

37

Digamos que você acabou de começar a trabalhar em uma equipe muito pequena em um projeto {atualmente relativamente pequeno, embora seja maior depois]. Observe 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 liberado para outras pessoas, portanto, nenhuma decisão foi tomada ainda.

As Metodologias

Um de vocês gosta de começar a codificar e ajustar as peças à medida que avança antes de ter necessariamente uma idéia clara de como exatamente todos os componentes irão interagir (design de baixo para cima). Outro de vocês gosta de fazer o design inteiro primeiro e definir os detalhes de todos os componentes e comunicação antes de codificar uma solução.

Suponha que você esteja trabalhando em um novo sistema em vez de imitar os existentes e, portanto, nem sempre é óbvio como deve ser o design final correto. Portanto, 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, e muito menos como proceder para projetá-lo.

Quando o desenvolvedor de baixo para cima grava algum código, o desenvolvedor de cima para baixo o rejeita devido a possíveis problemas futuros previstos no design, apesar de o código poder resolver o problema em questão, acreditando que é mais importante corrigir o design. antes de tentar codificar a solução para o problema.

Quando o desenvolvedor de cima para baixo tenta resolver 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 ocorrerão na prática e acha que o design talvez precise ser alterado no futuro quando os requisitos e restrições ficarem mais claros.

O problema

O problema em que isso resultou é que o desenvolvedor de baixo para cima acaba perdendo tempo porque o desenvolvedor de cima para baixo decide com freqüência a solução que o desenvolvedor de baixo para cima escreveu que deve ser descartada devido a uma falha de design, resultando na necessidade de -escreva o código.

O desenvolvedor de cima para baixo acaba perdendo tempo porque, em vez de paralelizar o trabalho, o desenvolvedor de cima para baixo agora se senta frequentemente para elaborar o design correto com o desenvolvedor de baixo para cima, serializando os dois até o ponto em que pode ser ainda mais rápido para 1 pessoa fazer o trabalho que 2.

Ambos os desenvolvedores querem continuar trabalhando juntos, mas não parece que a combinação esteja ajudando os dois 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 software útil.

A questão

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

A única solução eficiente em que consigo pensar que não perde tempo é permitir que cada desenvolvedor siga seu próprio estilo para o design. Mas isso é mais difícil do que parece quando você faz uma revisão de código e realmente precisa aprovar as mudanças uns dos outros, e quando você está tentando criar uma estrutura coerente para os outros usarem.

Existe uma maneira melhor?

Mehrdad
fonte
12
Para mim, parece que o cara "de cima para baixo" quer fazer o Big Design Up Front. Enquanto o "bottom top", o cara só quer começar a invadir e chegar à solução gradualmente.
Euphoric
24
Ambos estão corretos. Você precisa encontrar um compromisso com o qual ambos concordem. Um lado precisa aprender que alguns projetos iniciais podem economizar tempo a longo prazo. O outro lado precisa aprender que, a certa altura, é benéfico parar de pensar e começar a trabalhar.
Euphoric
8
@Euphoric: Eu amo isso. Uma pessoa diz que ambos estão errados, uma pessoa diz que ambos estão certos, um diz que eles precisam se comprometer, um diz que eles devem dividir as tarefas em partes e apenas trabalhar em coisas diferentes. A mensagem que estou recebendo é que ninguém realmente sabe qual é a abordagem correta!
Mehrdad 29/06
4
A palavra "comunicação" vem à mente.
Bryan Oakley
4
Quem é o gerente? Quem toma as decisões?
corsiKa

Respostas:

54

Obviamente, ambos estão errados.

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

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

No entanto, um meio termo é ideal - se você conhece os objetivos para os quais está trabalhando (que obtém de um amplo trabalho de design) e continua a codificá-lo (sem nenhum planejamento detalhado), então colhe as recompensas de um sistema organizados e desenvolvidos com eficiência.

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 que o software em funcionamento), mas o verdadeiro ágil que continua trabalhando em direção a um objetivo final geralmente descrito e compreendido.

Para corrigir o problema aqui, tente uma abordagem Agile (Kanban é provavelmente a melhor) que forçará o sujeito de cima para baixo a fazer algum trabalho e forçará o sujeito de baixo para cima a planejar o que está tentando alcançar.

gbjbaanb
fonte
10
+1 para a versão BS do ágil. Hoje em dia, existem tantas pessoas que estão errando de maneira ágil ...
T. Sar - Restabelece Monica
17
Não sei se a sua resposta está apenas sendo votada por causa da sensacional "ambas estão erradas" no começo, mas o resto parece depender de suposições erradas. Observe na pergunta que eu disse que as duas pessoas podem até ser mais produtivas individualmente do que trabalhando juntas. Portanto, certamente não é o caso que o desenvolvedor de cima para baixo não esteja realizando nenhum trabalho real. Da mesma forma, também não é como se o desenvolvedor de baixo para cima não estivesse produzindo algo que fizesse o que deveria. Em vez disso, os dois estilos estão apenas em conflito quando trabalham juntos por causa de como o problema é abordado.
Mehrdad 29/06
18
@ Mehrdad bem, a maioria das pessoas é mais rápida ao trabalhar individualmente, mas você obtém um software melhor ao trabalhar em conjunto - como uma citação dizia: "se você quiser ir mais rápido, viaje sozinho. Se você quiser ir longe, viaje juntos" . Então você perguntou como fazer esses caras trabalharem bem juntos - e eu lhe dei uma resposta que acho que funcionaria, os constrange à colaboração sem forçá-los a trabalhar como um - uma metodologia comum de desenvolvimento que ambos ficariam felizes em seguir. Você disse que seus conflitos estão afetando sua produtividade.
Gbjbaanb
11
@Mehrdad A resposta que você precisa, mas não merecem agora;)
Insane
2
@ThalesPereira O que é a "versão BS do ágil"?
Sjoerd222888
23

Os dois desenvolvedores precisam manter um respeito mútuo .

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

A pessoa de baixo para cima também deve respeitar a "estrutura" da pessoa de cima para baixo e perceber que isso pode ser bom para evitar esforço desperdiçado, resolver o problema errado, sair do tópico etc. O codificador de baixo para cima deve ter pelo menos em mente o que a pessoa de cima para baixo está tentando fazer e tenta abordar pelo menos as preocupações do descendente, conforme expresso na estrutura. Isso seria verdade mesmo se a parte inferior inferior discordasse de partes da própria estrutura.

Tom Au
fonte
7

Você pode minimizar a perda de tempo gasto por cada desenvolvedor se dividir grandes tarefas em várias menores e mais focadas. Faça com que eles trabalhem juntos para que nenhum deles fique muito à frente do outro. Sprints curtos e entregas pequenas percorrem um longo caminho. É mais fácil corrigir um pequeno erro do que um grande.

Pode parecer contra-intuitivo o seu objetivo, mas a programação em pares funciona. Há coisas que você simplesmente não consegue entender imediatamente, às vezes por horas ou até dias. Se trabalhar diretamente em tarefas em conjunto estiver fora de questão, tente revisar / standups de código com mais frequência durante a semana.

Mantenha todos informados!

Se você estiver vendo os desenvolvedores lançarem código porque eles estavam em seu próprio mundo, você precisará capturar e reconciliar os conflitos o mais rápido e eficientemente possível. Seu chefe apreciará e a equipe apreciará não ter que jogar fora o trabalho de uma semana 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 corrigindo seus erros à medida que avançam é 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.

Penso que esta citação é apropriada, dado o seu cenário.

"Se duas pessoas concordam com tudo, uma delas é desnecessária." ~ Algum Cara Velho

Dat Boi
fonte
7

Isso realmente soa como um cenário ideal para mim. Então, novamente, eu sou os dois desenvolvedores ao mesmo tempo. Eu gosto de esboçar o "panorama geral" na forma de notas que acabam encontrando seu caminho para 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 eu entendo melhor como as peças se encaixam, e as peças evoluem conforme os requisitos mudam e eu recebo novas idéias.

Talvez seja um bom modelo para múltiplos cérebros.

Kevin Krumwiede
fonte
5
Acho que os problemas do GitHub são uma vantagem para todos, deixando de lado idéias aleatórias para recursos futuros, problemas em potencial, anotações pessoais, etc. Isso os tira da minha cabeça, mas de uma maneira que eu possa ter certeza de que estarei capaz de encontrá-los mais tarde.
Hby2Py
6

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

Isso pode ser feito através da supervisão, como outros indicaram, mas ainda melhor com o acordo mútuo sobre um cronograma de iteração de quando projetar e quando codificar, e evitar, em geral, codificar o que está atualmente sob design.

Ponto de bônus, assim que um projeto é dividido em módulos menores, o programador de cima para baixo pode projetar coisas nas quais o programador de baixo para cima não está trabalhando atualmente, tornando-a uma fase em que ambos fazem o que querem. No entanto, isso implica na capacidade de ambos fazerem os ajustes necessários quando chegar a hora de juntar tudo.

Arthur Havlicek
fonte
11
O +1, pois o último é uma solução acionável em alguns casos, mas na verdade não é realmente viável aqui. A questão é que o programador de baixo para cima também quer contribuir com o design, e o programador de cima para baixo também quer contribuir com o código. Dividir as duas tarefas faria sentido em uma empresa na qual você tenha gerentes, gerentes de equipe, desenvolvedores etc., mas em uma equipe pequena como essa, onde todos querem trabalhar em todo o sistema, não ficaria feliz em dividir as tarefas. Curtiu isso.
Mehrdad 29/06
2
Idealmente, ambos funcionariam tanto no design quanto na codificação, por isso é bom ter um cronograma, mesmo que sua equipe seja pequena. Basta planejar algumas "reuniões" quando ambas puderem gerar perguntas e contribuições sobre como projetar / implementar módulos, e alocar tempo para a próxima tarefa e planejar a próxima reunião. Agile-like, exceto que você não tem que chamá-lo como tal;)
Arthur Havlicek
Infelizmente, nesses casos, o sujeito de cima para baixo criará planos e o sujeito de baixo para cima os ignorará. ie ambos continuarão a fazer suas próprias coisas.
Gbjbaanb
5

Uma nota: você disse

Suponha que você esteja trabalhando em um novo sistema em vez de imitar os existentes e, portanto, nem sempre é óbvio como deve ser o design final correto.

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

Como outros já disseram, ambas as visões podem estar corretas de certas maneiras. Está longe de ser incomum dois desenvolvedores discordarem das práticas, especialmente para algo tão subjetivo quanto os processos de design e desenvolvimento. Aqui você tem duas pessoas apaixonadas pelo que fazem e que sabem como fazê-lo: aceite isso!

Existe aqui um grande potencial para permitir que ambas as pessoas trabalhem à sua maneira e ainda assim combinar as peças para obter um aplicativo funcional.

  1. Eu gostaria que os dois sentassem e discutissem, encorajando-os a ver do ponto de vista do outro.

  2. Após essa discussão, você pode começar a falar sobre planejamento: isso deve ser feito em equipe, com o entendimento de que nenhum dos dois deve 'ceder' ao outro, mas serão necessários compromissos. Existem várias maneiras de planejar a arquitetura para uma base de código que permita que ela seja estendida facilmente mais tarde, sem introduzir uma tonelada de código extra.

  3. Depois que você conseguir que eles cheguem a algum tipo de trégua, deixe-os correr soltos! Deixe o 'cara de cima para baixo' planejar a arquitetura de alto nível, interfaces, hierarquias, etc. Faça com que eles concordem formalmente em aceitar os métodos dos outros como bons para o projeto como um todo: planejar uma mudança fácil no futuro é bom, mas não precisa ser codificado dessa maneira imediatamente. Crie interfaces e métodos stub out para obter a estrutura do código e aceite que uma boa parte do código para o futuro não será realmente escrita até que seja necessário.

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

  5. Este é provavelmente o ponto mais importante: facilite os pontos do ciclo em que eles falam apenas sobre processos, e não sobre o trabalho que está sendo realizado. Reflita sobre a dinâmica que está sendo construída: há quatro perguntas que você deve fazer. O que correu bem que deveríamos continuar fazendo? O que correu mal que deveríamos parar de fazer? O que estamos perdendo? O que podemos fazer sobre o que estamos perdendo?

Isso exigirá algum trabalho: você precisa fazê-los concordar em trabalhar juntos da maneira deles. Não é fácil para algumas pessoas admitir que não há uma maneira única e correta de fazer as coisas. O importante não é como você trabalha ou como é o código no final; o importante é que essas duas pessoas qualificadas e com conhecimento aprendam a trabalhar melhor juntas. Não é algo que você possa simplesmente dizer a eles; tudo o que você pode fazer é guiá-los através de um processo de aprender a fazer eles mesmos. Assim como não há um design certo, não há um caminho certo para as pessoas trabalharem.

DrewJordan
fonte
4

Geralmente, na minha experiência ao longo da minha carreira, o design é insuficiente no início. E o design que acontece de frente é de baixa qualidade . Isto é mau. Principalmente porque o resultado é (em maior ou menor grau) jogar lama na parede e ver o que gruda. A dívida técnica é acumulada desde o início.

De cima para baixo é geralmente superior a de baixo para cima. Embora eu não descartar completamente de baixo para cima. A razão para isso é que de cima para baixo obriga a pensar sobre o problema de maneira mais ampla e a fazer perguntas melhores . Isso reforça o primeiro ponto acima ... leva a um design de qualidade superior e geralmente influencia muito o trabalho de nível inferior. Isso reduz o retrabalho considerável, que normalmente é necessário caso os componentes de nível inferior sejam 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 tentará moldar os requisitos de negócios para os componentes que foram projetados. Isso também é ruim. Os requisitos de negócios devem orientar o design, o que deve orientar a implementação. Qualquer coisa que vá para o outro lado levará a resultados inferiores.

Brad Thomas
fonte
2
"O design é insuficiente no início. E o design que acontece na frente é de baixa qualidade." - A qualidade tipicamente baixa do design inicial é exatamente o motivo pelo qual você não vê tanto quanto gostaria.
user1172763
11
+1 em "Requisitos de negócios devem impulsionar o design". Na ausência de requisitos de negócios, qualquer projeto inicial é apenas masturbação mental; no entanto, sem requisitos de negócios, apenas cortar é quase sempre um desperdício de tempo e potencial desencorajar o desperdício de tempo e esforço quando você descobre que desperdiçou tanto esforço em algo que é inútil.
Maple_shaft
11
@ user1172763 design de boa qualidade> design de baixa qualidade> sem design. Mesmo o trabalho de design mais pobre contém algum valor, pelo menos, dá foco à visão, ou seja, age para guiá-lo na direção certa. Nenhum plano significa que nenhuma direção significa caos eventual.
Gbjbaanb
4

Nenhuma das abordagens é suficiente. Parece que cada um deles é esperto ou experiente o suficiente para perceber as deficiências da outra abordagem (talvez tenham se queimado?), Mas não consegue enxergar as deficiências de sua própria abordagem selecionada ...

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

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

Misturando ambos, no entanto, você pode:

  • tem um esboço dando instruções e um esqueleto de infraestrutura
  • e desenvolver componentes adequados a essa visão

Como não existe um sistema existente que atenda a esse propósito, é importante perceber antecipadamente que:

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

Portanto, deve-se enfatizar o alcance de um sistema "operacional" o mais rápido possível, mesmo que isso signifique ignorar caixas de canto, etc ... Este é o conceito da "fatia vertical fina": em vez de construir as fundações da casa , então as paredes, a estrutura do telhado, ... e apenas obtendo algo utilizável no final (ou nunca obtendo, ou nem sendo realmente utilizável) ... é melhor construir uma sala totalmente equipada primeiro, como o banheiro. É utilizável imediatamente e pode ser usado para obter feedback.

Porém, para que o feedback seja valioso, é melhor abordar uma parte principal primeiro.


Então, o que os seus colegas de trabalho fazem?

A primeira coisa é que os dois precisam entender a necessidade de colaboração e a necessidade de concordar com o caminho a seguir: ser constantemente repreendido, como eles são, certamente irritará a pessoa e afetará sua motivação. Apresentei acima o que achei que funcionou 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 do caminho sublinhada acima, os dois devem definir as tarefas que apreciam.

Observe que a construção dos esqueletos e a construção dos tijolos é melhor abordada de forma incremental.

  1. Os dois devem fazer um esboço do esqueleto e decidir juntos em qual "fatia fina" devem se concentrar primeiro
  2. O cara de baixo para cima deve começar a trabalhar no pedaço mais compreendido de "fatia fina"
  3. O cara de cima para baixo deve começar a desenvolver o esqueleto, atacando idealmente as peças mais bloqueadoras primeiro para completar a fatia

Enxágue 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 com um design completamente diferente.

Matthieu M.
fonte
Remova as quatro palavras principais, elas são desnecessárias (e estão em total contradição com esta resposta equilibrada).
11
@Tibo: Você é dura, se não podemos sequer sacudir as pessoas um pouco ...: D
Matthieu M.
Concordo :) Eu gosto de sacudir aqueles que vivem em uma torre de marfim, esperando que tudo se quebre sob seus pés. -1 -> +1 btw.
Por fim, outra pessoa que vê a sabedoria de obter um protótipo de ponta a ponta com funcionalidade mínima ainda abrangente, o mais cedo possível. Obrigado por esta resposta, gostei de ler.
Análise difusa
3

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

A única solução eficiente em que consigo pensar que não perde tempo é permitir que cada desenvolvedor siga seu próprio estilo para o design.

Na verdade, pode 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.

Stephen C
fonte