Adam Smith vs. desenvolvedores fullstack - e produtividade no DevOps?

Por Adam Smith, a divisão de trabalho pode torná-lo 240 vezes mais eficaz (no exemplo de uma fábrica de pinos que produz pinos em 18 etapas).

Por que, então, os papéis com habilidades múltiplas são tão procurados se isso realmente reduz a produtividade - ou se Smith estava errado, por que?

As pesquisas por "desenvolvedor fullstack" ainda tendem no Google, porém aparentemente mais lentas do que há dois anos:

=====

Para resumir, um desenvolvedor de pilha completa seria capaz de fazer praticamente toda a cadeia de valor (me corrija se eu estiver errado):

• Discuta com os clientes e refine os requisitos ágeis viáveis ​​para sua parte do trabalho
• Decida qual arquitetura, ferramentas e componentes serão utilizados - apenas entregue a ele um notebook
• Escreva um código para front-end, back-end, ingration, que seja compatível com vários dispositivos e não exija muito teste ou o inclua
• Dados de perfil e de escape, use APIs do Cloud AI / ML para recursos avançados
• Escreva o código IaC necessário e implante
• Estar de plantão em caso de erro ou processos de vendas
• Esteja ciente do design relevante para a segurança, patch geral, migração e modernização
• Cronograma da conta de maneira detalhada para facilitar o faturamento do empregador
• ... eu esqueci alguma coisa?

UPD - " precisamos da produtividade da especialização, mas não queremos a visão de mundo insular da" divisão extrema do trabalho ". (DevOps Guys, " DevOps, DevOps, Adam Smith e a lenda do generalista " , 2013-2016)

Existem dois tipos de trabalho:

1. Exploração - Um trabalho bem definido que pode ser facilmente dividido em estágios bem definidos, onde cada estágio pode ser aprendido e dominado por si próprio e a entrega entre estágios não requer comunicação.

2. Exploração - Trabalho indefinido, que requer aprendizado e experimentação para realizar cada estágio e entrega entre estágios, exige uma quantidade enorme de comunicação de todo aprendizado e status do projeto.

Adam Smith se preocupa totalmente com a exploração e nada com a exploração. O trabalho realizado nos departamentos de Pesquisa e Desenvolvimento do setor é, por sua definição, principalmente de exploração e, portanto, não é coberto de maneira alguma por Adam Smith.

Mas vimos que, nos estágios posteriores de melhoria contínua, que são um trabalho parcialmente explorador, a aplicação de CI / CD pode trazer ganhos similares de produtividade, que de alguma forma podem ser atribuídos a Adam Smith por alguém muito imaginativo.

Adam Smith não precisava considerar a passagem de informações de um estágio para outro. Esta é uma parte crítica de qualquer projeto de TI significativo. Portanto, um desenvolvedor fullstack tem as vantagens significativas que:

• eles não precisam conversar com ninguém em outro departamento para fazer as coisas
• eles não precisam esperar que outras pessoas cheguem a ele
• há muito menos chance de que algo se perca na tradução entre uma camada e outra

Para saber mais sobre a importância da passagem de informações em projetos de TI, consulte Mythical Man Month, de Fred Brook .

IMHO a resposta tem muito a ver com escala e disponibilidade de recursos.

Acredito que a teoria de Adam Smith só possa ser aplicada em larga escala - nações / economias inteiras no contexto original ou, no contexto do desenvolvimento do SW - grandes equipes de desenvolvimento.

Em uma equipe grande, é realmente mais eficiente contratar recursos humanos mais especializados:

• eles não são estrelas do rock - muitas vezes considerados um sinal de perigo em organizações tão grandes
• normalmente são mais fáceis de encontrar, mais baratos do que aqueles com um espectro de experiência mais amplo
• eles normalmente não aumentam os riscos de desgaste - por exemplo, não ficarão descontentes porque usam apenas um subconjunto de suas habilidades.
• Numa comparação devopsiana (talvez estranha), o princípio "gado versus animais de estimação" pode ser aplicado em organizações tão grandes, e por razões bastante semelhantes. Esses recursos especializados são, do ponto de vista comercial, literalmente apenas capita em pools de recursos humanos, cujos tamanhos podem ser rapidamente ajustados conforme necessário, geralmente mediante contratação / demissão.

Ah, e essas equipes só podem funcionar se forem complementadas por recursos de arquiteto de alta qualidade que seriam necessários para dividir o produto em tarefas menores e especializadas que podem ser tratadas com os recursos especializados.

Em equipes de menor escala ou mesmo de uma só pessoa (geralmente startups ou equipes menores isoladas em organizações maiores), é ineficaz ou mesmo impossível usar esses recursos e ainda assim fazer o trabalho:

• eles simplesmente não têm o orçamento / recursos para contratar os diversos recursos especializados necessários para cobrir todo o desenvolvimento do produto
• eles realmente procuram / apreciam estrelas do rock que podem usar vários chapéus e trocar imediatamente de papéis com grande flexibilidade, sem incorrer em atrasos e custos adicionais de RH

Considero-me um desenvolvedor fullstack com base na seguinte combinação de responsabilidades:

Programação front end e back end

Posso fazer alterações na interface do usuário até certo ponto: escrever html, css (como desenvolvedor da Web) e, por outro lado, fornecer dados à interface do usuário a partir do banco de dados, fornecê-los em um serviço etc.

Deixo de lado os testes, a arquitetura e os demais. Encontrar clientes pode ser adicionado à descrição de trabalho.

Oposto

O oposto do meu ponto de vista seria o papel estrito dos caras da interface do usuário e do back-end.

Conclusões

Não vejo a pilha cheia realmente tão cheia como você mencionou, mais como uma expressão extravagante como ágil ou nuvem que, em certas condições, só precisa ser mencionada para atrair a atenção das pessoas e a implementação real pode variar bastante. Pelo menos sobre scrum e ágil, já vi tantas variações que os termos ficaram sem significado.

Em suma, não acho que Adam Smith esteja errado, mas acho que há algumas diferenças sérias entre seu modelo de divisão de trabalho na fabricação e silos no desenvolvimento de software.

Primeiro, o exemplo da fábrica de pinos (tanto quanto eu sei) era meramente hipotético; embora a maioria das fábricas modernas possa traçar suas raízes nessa divisão do trabalho, não conheço nenhum estudo que tenha realmente testado cientificamente essa hipótese.

Segundo, Smith estava preocupado principalmente com a fabricação de bens materiais; existem certas saídas tangíveis associadas à produção de material que não possuem análogos semelhantes no desenvolvimento de software. Por exemplo, na fabricação de pinos, as dimensões físicas são importantes como requisito funcional; não há comparação óbvia com a do software. Isso é importante porque objetos tangíveis podem ser replicados através da repetição exata; desenvolvimento de software nunca é o mesmo problema duas vezes. Os desenvolvedores desenvolvem métodos comuns para produzir resultados previsíveis, mas você nunca codifica o mesmo problema duas vezes. Qualquer componente desenvolvido na pilha possui complexidades diferentes dos componentes físicos, e essas complexidades têm interações além da medição tangível (altura, peso, comprimento, etc.). Um ponteiro de pinos não se importa com o funcionamento do alicate, desde que o fio seja cortado de acordo com as especificações. No desenvolvimento de software,os limites nunca são tão claros .

Espera-se que os desenvolvedores de pilha cheia não façam todo o trabalho (eles não devem ser um único criador de pinos), mas espera-se que sejam capazes de entender todos os elementos da pilha e como esses elementos interagem. Uma equipe de pilha cheia deve ser composta por indivíduos em forma de T, especializados em uma ou mais áreas, mas compreendem o espectro (e podem ser capazes de intervir em algum nível).

Onde eu acho que o trabalho de Smith é verdadeiro no desenvolvimento de software é na área de alternância de contexto (ou multitarefa ); se um único desenvolvedor é responsável por todas as áreas de desenvolvimento, leva tempo para mudar de responsabilidade para responsabilidade. Em escala, a colaboração entre os membros da equipe com experiências diferentes na mesma equipe do produto pode equilibrar a alternância de contexto e interações complexas.

Um ponto importante a entender é que a divisão do trabalho nem sempre significa uma pessoa diferente por etapa.

Eu levaria minha própria história em uma fábrica de automóveis, estava em uma cadeia de montagem de assentos, para conseguir um assento completo com airbag, couro, apoio de cabeça etc. a corrente foi dividida em 9 etapas. Estávamos 9 trabalhando na cadeia. Cada pessoa estava fazendo apenas um estágio de cada vez, mas a cada hora estávamos mudando para o estágio seguinte para evitar repetições demais. A jornada de trabalho durou 8 horas, portanto não subíamos a cada estágio todos os dias.

Esta é exatamente uma divisão de trabalho em que você executa apenas uma etapa da montagem em um determinado momento, que não impede que você possa fazer a montagem completa.

Como já foi dito em outras respostas, isso é um pouco diferente do desenvolvimento de software, mas acho que isso esclarece por que um desenvolvedor do Full Stack não é mutuamente exclusivo da divisão de trabalho, alguém com a capacidade de lidar com todo o ciclo de vida de um aplicativo não é necessário para fazê-lo o tempo todo.

De um modo geral, quando ouço o desenvolvedor do FullStack, acho que mais alguém é capaz de codificar back-ends eficientes e uma interface agradável ao mesmo tempo, em oposição ao Front e Back Dev.