Adam Smith vs. sviluppatori fullstack - e produttività in DevOps?

Di Adam Smith, la divisione del lavoro può renderti 240 volte più efficace (ad esempio in una fabbrica di spilli che produce spilli in 18 fasi).

Perché allora i ruoli multi-qualificati sono così richiesti se ciò in realtà riduce la produttività - o Smith aveva semplicemente torto, perché allora?

Le ricerche di "sviluppatore fullstack" sono ancora in tendenza su Google, sebbene apparentemente più lente di due anni fa:

=====

Per riassumere, uno sviluppatore full stack sarebbe in grado di fare praticamente tutta la catena del valore (correggimi se sbaglio):

• Discutere con i clienti e perfezionare i requisiti agili praticabili per la sua parte del lavoro
• Decidi quale architettura, strumenti e componenti raccogliere - basta dargli un taccuino
• Scrivi codice per frontend, backend, ingration, che è compatibile tra dispositivi e non richiede molti test o lo include
• Dati di profilo e scape, utilizzare le API Cloud AI / ML per funzionalità avanzate
• Annotare il codice IaC richiesto e l'implementazione
• Essere in guardia in caso di errore o processi di vendita
• Essere consapevoli del design rilevante per la sicurezza, patching generale, migrazione e modernizzazione
• Tabella oraria dell'account in modo scroutinizzato per facilitare la fatturazione del datore di lavoro
• ... ho dimenticato qualcosa?

UPD - " Abbiamo bisogno della produttività della specializzazione ma non vogliamo la visione insulare del mondo di" divisione estrema del lavoro ". (DevOps Guys, " DevOps, Adam Smith e la leggenda del generalista " , 2013-2016)

Esistono due tipi di lavoro:

1. Sfruttamento : lavoro ben definito che può essere facilmente suddiviso in fasi ben definite, in cui ogni fase può essere appresa e padroneggiata da sola e il passaggio da una fase all'altra non richiede comunicazione.

2. Esplorazione - Lavoro indefinito, che richiede l'apprendimento e la sperimentazione per realizzare ogni fase e la consegna tra le fasi richiede enormi quantità di comunicazione di tutto l'apprendimento e lo stato del progetto.

Adam Smith si preoccupa totalmente dello sfruttamento e non dell'esplorazione. Il lavoro svolto nei dipartimenti di ricerca e sviluppo del settore è per definizione principalmente esplorazione e quindi non è coperto in alcun modo da Adam Smith.

Ma abbiamo visto che nelle fasi successive di miglioramento continuo, che sono in parte attività di sfruttamento, l'applicazione di CI / CD può portare simili guadagni di produttività, che potrebbero in qualche modo essere rintracciati in Adam Smith da qualcuno molto fantasioso.

Adam Smith non ha dovuto prendere in considerazione il passaggio di informazioni da uno stadio all'altro. Questa è una parte fondamentale di qualsiasi progetto IT significativo. Quindi uno sviluppatore fullstack ha i vantaggi significativi che:

• non devono parlare con nessuno in un altro dipartimento per fare le cose
• non devono aspettare che le altre persone ci si avvicinino
• c'è molto meno possibilità che qualcosa si perda nella traduzione tra uno strato e l'altro

Per ulteriori informazioni sull'importanza delle informazioni che passano nei progetti IT, vedere il Mese dell'uomo mitico di Fred Brook .

IMHO la risposta ha molto a che fare con la disponibilità di risorse e dimensioni.

Credo che la teoria di Adam Smith possa essere applicata solo su larga scala - intere nazioni / economie nel contesto originale, o, nel contesto di sviluppo del SW - grandi gruppi di sviluppo.

In una grande squadra è, infatti, più efficiente assumere risorse umane più specializzate:

• non sono rockstar - spesso considerati un segnale di pericolo in organizzazioni così grandi
• sono in genere più facili da trovare, più economici di quelli con uno spettro di competenze più ampio
• in genere non aumentano i rischi di attrito, ad esempio non saranno infelici perché usano solo un sottoinsieme delle loro abilità.
• in un confronto (forse strano) della devopsia il principio "bestiame vs animali domestici" può essere applicato in organizzazioni così grandi e per ragioni abbastanza simili. Queste risorse specializzate sono, dal punto di vista aziendale, letteralmente solo capite nei pool di risorse umane, dimensioni che possono essere rapidamente adattate in base alle esigenze, in genere assumendo / licenziando.

Oh, e tali team possono essere funzionali solo se sono integrati da risorse di architetti di alta qualità che sarebbero necessarie per dividere il prodotto in compiti più piccoli e specializzati che possono essere affrontati con risorse specializzate.

In team di dimensioni più ridotte o anche one-man (in genere startup o persino team più piccoli isolati in organizzazioni più grandi) è inefficace o addirittura impossibile utilizzare tali risorse e svolgere comunque il lavoro:

• semplicemente non hanno il budget / le risorse per assumere le diverse risorse specializzate necessarie per coprire l'intero sviluppo del prodotto
• in realtà cercano / apprezzano rockstar che possono indossare più cappelli e cambiare immediatamente ruolo con grande flessibilità, senza incorrere in ritardi e costi aggiuntivi delle risorse umane

Mi considero uno sviluppatore fullstack sulla base della seguente combinazione di responsabilità:

Programmazione front-end e back-end

Posso apportare modifiche all'interfaccia utente fino a un certo punto: scrivere html, css (come sviluppatore web) e in qualche modo in qualche modo fornire dati all'interfaccia utente dal database, fornirli in un servizio ecc.

Lascio i test, l'architettura e quelli a parte, incontrare i clienti può essere aggiunto alla descrizione di lavoro.

Di fronte

Il contrario per il mio punto di vista sarebbero i ruoli severi dei ragazzi dell'interfaccia utente e dei ragazzi del back-end.

conclusioni

Non vedo lo stack completo davvero così pieno come hai detto, più come un'espressione elegante come l'agile o il cloud che in determinate condizioni devono solo essere menzionati per attirare l'attenzione della gente e la vera implementazione può variare notevolmente. Almeno su mischia e agilità ho visto così tante variazioni che i termini hanno esaurito il significato.

In breve, non credo che Adam Smith avesse torto, ma penso che ci siano alcune serie differenze tra il suo modello di divisione del lavoro nella produzione e silos nello sviluppo del software.

Innanzitutto, l'esempio di fabbrica dei pin (per quanto ne so) era puramente ipotetico; sebbene la maggior parte delle fabbriche manifatturiere moderne possano tracciare le proprie radici in questa divisione del lavoro, non sono a conoscenza di studi che abbiano effettivamente verificato scientificamente questa ipotesi.

In secondo luogo, Smith era principalmente interessato alla produzione di beni materiali; ci sono alcuni output tangibili associati alla produzione di materiale che non hanno analoghi analoghi nello sviluppo del software. Ad esempio, nella realizzazione dei pin, le dimensioni fisiche sono importanti come requisito funzionale; non esiste un confronto ovvio con quello nel software. Questo è importante perché gli oggetti tangibili possono essere replicati attraverso la ripetizione esatta; lo sviluppo del software non è mai lo stesso problema due volte. Gli sviluppatori sviluppano metodi comuni per produrre risultati prevedibili, ma non si codifica mai lo stesso problema due volte. Qualsiasi componente sviluppato nello stack presenta complessità a differenza dei componenti fisici e tali complessità hanno interazioni oltre la misurazione tangibile (altezza, peso, lunghezza, ecc.). Un puntatore a pin non si preoccupa di come funziona il tronchese, purché il filo venga tagliato secondo le specifiche. Nello sviluppo di software,i confini non sono mai così chiari .

Gli sviluppatori di stack completi non sono tenuti a fare tutto il lavoro da soli (non sono destinati a essere un singolo creatore di pin), ma dovrebbero essere in grado di comprendere tutti gli elementi dello stack e il modo in cui tali elementi interagiscono. Una squadra full stack dovrebbe essere composta da individui a forma di T specializzati in una o più aree, ma che comprendano lo spettro (e potrebbero essere in grado di intervenire ad un certo livello).

Dove penso che il lavoro di Smith sia vero nello sviluppo del software è nell'area del cambio di contesto (o multitasking ); se un singolo sviluppatore è responsabile di tutte le aree di sviluppo, ci vuole tempo per passare da una responsabilità all'altra. Su vasta scala, la collaborazione tra membri del team con esperienze diverse nello stesso team di prodotti può bilanciare il cambio di contesto e le interazioni complesse.

Un punto importante da capire è che la divisione del lavoro non significa sempre una persona diversa per passo.

Vorrei portare la mia storia in una fabbrica di automobili, ero su una catena di assemblaggio dei sedili, per ottenere un posto completo con airbag, pelle, poggiatesta ecc. La catena era divisa in 9 fasi. Stavamo lavorando alla catena. Ogni persona faceva solo una fase alla volta, ma ogni ora ci spostavamo sulla fase successiva per evitare troppe ripetizioni. La giornata lavorativa è durata 8 ore, quindi non siamo saliti su tutti i palchi ogni giorno.

Questa è esattamente una divisione del lavoro in cui si esegue solo una fase dell'assemblaggio in un determinato momento, ciò non impedisce di essere in grado di eseguire l'intero assemblaggio.

Come già affermato in altre risposte, questo è un po 'diverso dallo sviluppo del software, ma penso che questo metta in luce il motivo per cui uno sviluppatore Full Stack non si escluda a vicenda con la divisione del lavoro, qualcuno con le capacità di gestire l'intero ciclo di vita di un'applicazione non lo è richiesto per farlo tutto il tempo.

In generale, quando sento lo sviluppatore di FullStack, penso più a qualcuno in grado di programmare back-end efficienti e un'interfaccia utente gradevole allo stesso tempo, in opposizione a Front and Back Dev.