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

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?

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.

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.

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

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.

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.

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.

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.

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.

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.