Che cosa è successo al modello di "Team chirurgico" da "The Mythical Man-Month"?

Anni fa, quando ho letto The Mythical Man-Month, ho trovato molte cose che già conoscevo da altre fonti. Tuttavia, c'erano anche cose nuove lì dentro, nonostante il libro fosse del 1975. Uno di questi era:

Il team chirurgico

Mills propone che ogni segmento di un grande lavoro sia affrontato da una squadra, ma che la squadra sia organizzata come una squadra chirurgica piuttosto che una squadra di macellazione del maiale. Cioè, invece che ogni membro tagli il problema, uno fa il taglio e gli altri gli danno tutto il supporto che migliorerà la sua efficacia e produttività.

Questo è un modello molto interessante per l'organizzazione di un team di sviluppo software, ma non l'ho mai trovato descritto in nessun altro libro di ingegneria del software, nemmeno menzionato da nessuna parte.

Perché?

• All'epoca il "team chirurgico" era persino insolito?
• Oppure è stato provato e fallito?
  • In tal caso, come è fallito?
  • In caso contrario, perché non vediamo questo modello implementato nei progetti software di oggi?

"The Mythical Man-Month" è uscito l'anno in cui ho iniziato il college e, per usare l'attuale vernacolo, UUUGE! :-) Quello che devi capire è la differenza nel modo in cui il software è stato sviluppato POI rispetto ad ORA. Back In The Day (tm) praticamente tutta la codifica è stata fatta per prima sulla carta, poi è stata inserita in un copione (indovinato) delle schede perforate, quindi è stata letta, compilata, collegata, eseguita, i risultati sono stati ottenuti e il processo ripetuto. Il tempo della CPU è stato costosoe risorsa limitata e non volevi sprecarla. Idem e allo stesso modo spazio su disco, tempo dell'unità nastro, ecc., Blah. Sprecare un tempo CPU perfettamente buono in una compilazione che ha provocato errori (shock e horror!) È stato ... beh, uno spreco di tempo CPU perfettamente buono. E questo è stato nel 1975. All'epoca in cui Fred Brooks stava sviluppando le sue idee, che era la CPU dalla metà alla fine degli anni '60, era ancora di piùcostoso, memoria / disco / qualunque cosa fosse ANCORA più limitata, ecc. ecc. L'idea alla base del team chirurgico era quella di garantire che lo sviluppatore di One Super Great Rockstar non dovesse perdere il suo tempo in attività banali come il codice di controllo da scrivania, il keypunching, invio di lavori, in attesa (talvolta per ore) di risultati. Rockstar Dude Developer Man doveva essere CODICE SCRITTURA. La sua legione di groupies / impiegati / sviluppatori junior avrebbe dovuto fare le cose banali.

Il problema era che entro 2 anni dalla pubblicazione del libro di Brooks le idee di base dietro The Surgical Team stavano venendo meno:

1. Terminali CRT e file su disco hanno iniziato a sostituire i keypunch e i deck delle carte. Il tempo del computer è diventato meno costoso, sono diventati disponibili più computer e il tempo di consegna dei lavori è diminuito drasticamente. Quando sono arrivato al college (Miami University, Oxford, Ohio, classe '79, grazie per avermelo chiesto) beneil cambio di lavoro è stato di circa un'ora. Durante la settimana delle finali - quattro ore, forse, a volte sei. (Abbiamo gareggiato per il tempo della CPU con un gruppo di società commerciali e università - e gli utenti commerciali hanno avuto la priorità assoluta). Durante il mio ultimo anno, a quel punto Miami era uscita dal loro accordo di "computer condiviso", aveva installato il proprio IBM 370/145 nel campus e aveva un bel mini HP su cui lavoravo che fungeva da stazione RJE che potevamo trasformare mainframe lavori in giro in cinque minuti o meno. Ora valeva la pena inserire il codice sull'HP, inviarlo dall'HP al mainframe, modificare i pollici / fumare una sigaretta e recuperare l'output molto prima che tu potessi finire di controllare il tuo codice da scrivania.

2. Il team chirurgico ha come premessa di base l'idea che tu (o il "management", dio ci aiuti tutti) puoi identificare The Rockstar Surgical Developer Dude. In effetti, dubito che sia possibile. Ci sono sviluppatori di rockstar, lo sanno tutti - gli studi hanno mostrato differenze di produttività tra i migliori e i peggiori sviluppatori fino al 2000% - ma identificando quella persona senza farli scrivere codice per un lungo periodo di tempoè molto probabilmente impossibile. L'unico modo per sapere se qualcuno è uno sviluppatore di Rockstar è far sì che sviluppino effettivamente il codice, ma se NON sono il Dude dello sviluppatore chirurgico di Rockstar, faranno cose eccitanti come il controllo da scrivania del suo codice, il keypunch su carte e schlepping di scatole di schede perforate fino al dipartimento Job Entry, quindi in piedi in attesa di risultati in modo da poterle riportare a Mr. Rockstar Surgical Developer Dude invece di imparare a programmare l'unico modo che funziona davvero: scrivendo codice, debug, ecc. Back In The Day (tm) non c'erano concorsi di programmazione, non c'era Stack Overflow, non avevi un PC su cui poter scrivere codice ogni volta che ne hai voglia, non c'erano libri di Algorithms For Idiots - l'unico modo per imparare a programmare era andare a scuola e specializzarsi in qualcosa in cui si doveva fare un po 'di programmazione. Ma programmazionedi per sé non è stato preso sul serio, e si pensava che fosse qualcosa che la gente non voleva fare . Nel mio primo corso universitario (SAN151 - Introduzione all'analisi dei sistemi, Dr. Tom Schaber - grazie, Tom :-) ci è stato detto dall'istruttore che "... dovevamo solo affrontare il fatto che avremmo dovuto spendere un un paio di anni come programmatori prima che potessimo diventare analisti di sistemi ". "Due anni?", Ho pensato. "DEVO FARE SOLO QUESTO PER DUE ANNI?!?". Sono stato seriamente sconvolto. Per fortuna aveva torto e da allora ho praticamente programmato un codice. :-)

3. Il team chirurgico presume che i programmatori siano una risorsa relativamente rara. In realtà ci sono voluti ancora alcuni anni, ma con l'avvento dei PC nei primi anni '80 la programmazione è diventata qualcosa in cui tutti i geek potevano essere coinvolti. Il prezzo dei computer ha iniziato a scendere, il prezzo degli strumenti di sviluppo ha iniziato a scendere, ed è stato tutto grandine Turbo Pascal - per gli standard di oggi non era molto, ma al momento era un IDE Pascal completo per circa 40 dollari, il che era assolutamente pazzesco! Ora ANYBODY potrebbe entrare nella programmazione - se tu potessi permetterti un computer, e quando IBM ha deciso di mettere il PCjr (sì, il mio primo PC è stato uno dei più grandi errori di IBM :-) in vendita per circa $ 500 per sbarazzarsi di quei tacchini, contanti disadattati dappertutto saltarono i loro pagamenti di affitto per un mese ("Sì, lo so, ma io ... ho rotto la mia uuvula e ho dovuto fare un intervento chirurgico e ... .uh ... sì, la prossima settimana, nessun problema, grazie, amico ...) e li ha risucchiati a prezzi di vendita al fuoco. Quindi abbiamo speso più di quanto abbiamo pagato per il computer in componenti aggiuntivi per renderlo utilizzabile. ("Sì, amico, la prossima settimana, sicuramente, probabilmente ..." :-).

Ciò che mi rende davvero triste è che anche oggi, se chiedi alle persone se hanno mai letto "The Mythical Man-Month" o se comprendono la lezione principale ("L'aggiunta di risorse a un progetto in ritardo lo rende in seguito") ti danno uno spazio fissare - e quindi procedere a fare esattamente gli stessi errori commessi da Tutti quegli anni fa durante lo sviluppo di OS / 360. Tutto nuovo è nuovo di nuovo ...: -}

Ci sono alcuni aspetti di quel concetto che a volte vengono implementati oggi, ci sono altri aspetti che vengono evitati .

Mantenere le squadre piccole è una delle caratteristiche di base dei metodi Agile, ma è anche praticata al di fuori di Agile.

I team interfunzionali sono anche un punto fermo di Agile, ma anche al di fuori di Agile.

Il ruolo dell'impiegato del programma è ampiamente ripreso da sistemi computerizzati come i sistemi di controllo della versione, i sistemi di gestione della configurazione del software, i sistemi di gestione delle modifiche, i sistemi di gestione dei documenti, i wiki, i sistemi di costruzione continua con depositi di manufatti e così via. Voglio dire, puoi davvero immaginare di pagare un dipendente a tempo pieno per stampare il codice sorgente e indicizzarlo e archiviarlo manualmente?

Allo stesso modo, il ruolo di amministratore di sistema (non parte del team chirurgico di Mills, ma parte di un tipico team interfunzionale degli ultimi anni) è stato superato da concetti come DevOps (che assorbe il ruolo di Sysadmin nel ruolo di ingegnere del software) , Platform-as-a-Service, Infrastructure-as-a-Service e Utility Computing (rendendo il ruolo di Sysadmin "il problema di qualcun altro"), o Infrastructure-as-Code (trasformando l'amministrazione del sistema in ingegneria del software).

Uno degli aspetti che cerchiamo di evitare oggi è che al massimo due persone capiscano il sistema. Solo il chirurgo è sicuro di comprendere appieno il sistema, il copilota può o meno. Questo dà un fattore bus compreso tra 1 e 2. Se il chirurgo si ammala, il progetto è morto. Periodo. La risposta agile a questa è la proprietà del codice collettivo, che è esattamente l'opposto di quel modello: nessuno è singolarmente responsabile di qualsiasi parte del sistema. Invece, tutti sono responsabili di tutto come gruppo .

Infine, ci sono alcuni presupposti integrati in quel concetto, che sono obsoleti. Ad esempio, anche se non è dichiarato esplicitamente, il team è organizzato in modo tale che solo una persona (il chirurgo) disponga effettivamente di un computer. Questo, ovviamente, perché al momento in cui l'articolo è stato scritto, anche l'idea che un'intera squadra avrebbe avuto un computer per sé, figuriamoci una persona nella squadra, era un tratto. (Anche nel 1980, quando venne rilasciato Smalltalk, una delle cose che contribuirono al suo fallimento fu il fatto che il sistema era impostato in modo tale che ogni sviluppatore e ogni utente avessero il proprio computer - completamente impensabile in quel momento.)

Quindi, in breve: non penso che il concetto sia stato implementato esattamente come descritto, ma alcuni aspetti di esso sono sicuramente implementati, alcuni aspetti sono considerati indesiderabili ed evitati attivamente, alcuni sono obsoleti e alcuni sono Probabilmente Good Ideas ™, ma nessuno lo fa.

Una volta, un'istruzione universitaria era qualcosa di unico e gli ingegneri erano tra i pochi eletti. I computer erano costosi e i team hanno lavorato a progetti con una ROI aziendale definita. Questi non erano molto comuni.

Quello che è successo sono stati i microcomputer, l'onnipresente istruzione universitaria e i sistemi informatici che non hanno nemmeno bisogno di titoli universitari per progredire. Inoltre, ciò che è accaduto è stato lo spostamento dell'economia e l'aumento del costo del lavoro.

L'economia di un supporto 8: 2: il rapporto degli ingegneri non ha più senso. Gli ingegneri devono essere il loro supporto. Un essere umano moderno con istruzione e competenze sufficienti per essere efficacemente collegato a un team di sviluppo è troppo costoso per non fare il proprio sviluppo in qualche modo.

(Un termine economico correlato è "la malattia dei costi del settore dei servizi").

Questo schema mi sembra molto simile alla programmazione Mob:

L'intero gruppo (QA, sviluppatori e persino Product Owner se necessario) sta lavorando allo stesso tempo nello stesso problema. No stand up, alta comunicazione, direttamente implementato in live.

Da http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

Il concetto di base della programmazione mob è semplice: l'intero team lavora come una squadra insieme su un compito alla volta. Cioè: una squadra - una tastiera (attiva) - uno schermo (proiettore ovviamente). È proprio come fare la programmazione di coppie a squadre complete.

Guardalo in azione qui: https://www.youtube.com/watch?v=dVqUcNKVbYg

Questo modello di squadra è menzionato di nuovo in Rapid Development - Taming Wild Software Schedules di Steve McConnell a pagina 305. Qui viene chiamato Chief-Programmer Team.

Questo modello è nato perché c'era un genio nel team e le risorse informatiche erano limitate. È caduto in disgrazia perché il genio è raro e con computer onnipresenti e controllo della versione distribuita abbiamo spazio per molte mani al tavolo operatorio.

Altre referenze:

Baker, F. Terry. "Capo team di programmatori di programmazione della produzione", IBM Systems Journal, vol. 11, n. 1, 1972, pagg. 56-73.

Baker, F. Terry e Harlan D. Mills. "Squadre capo programmatore". Datamation, Volume 19, Numero 12 (dicembre 1973), pagg. 58-61.

La mia ipotesi è che la maggior parte dei piccoli team auto-organizzanti tenderà comunque a sistemarsi in un modello di team chirurgico di fatto.

Le ultime due squadre in cui ho partecipato sono state tendenzialmente composte da tre o quattro persone, di solito un anziano (chirurgo), un intermedio (copilota) e un paio di junior / specialisti. Alcuni dei ruoli nel team chirurgico menzionati oggi da Brooks sono ricoperti da maestri e amministratori di sistema Scrum o fornitori di servizi cloud. Ricorda che il controllo del codice sorgente esisteva a malapena al momento, figuriamoci qualcosa di potente come Git.

Pensa alla regola delle due pizze di Bezos. Questa è la tua squadra chirurgica auto-organizzante proprio lì.

C'era un documento di HP che suggeriva qualcosa di simile:

• Ogni ingegnere del software richiederebbe più manager e più persone di supporto.
• Dovrebbero esserci uno scrittore tecnico, un tester, un responsabile della costruzione e un produttore di strumenti per ciascun ingegnere.

Il giornale era nei giorni pre-web ed era di tanto in tanto divertente. Ogni anno è stato educato, il commento è passato un po 'di più da "così ridicolo è divertente" a "forse dovremmo farlo".

I test reali sono notoriamente difficili da progettare, quindi probabilmente rimane un'opinione. Potrebbero esistere alcuni sondaggi sui progetti e le loro percentuali di completamento.

Mi chiedo quanto sia diventata ridondante la necessità di un team chirurgico a causa dell'ascesa di Internet, degli ambienti di sviluppo integrati e dei kit di sviluppo software , che possono assumere molte delle funzionalità che Fred Brooks ha attribuito al team chirurgico, tra cui:

• Chirurgo: un programmatore
• Co-pilota: accoppia programmatori , collaboratori, comunità online come StackExchange o IRC
• Amministratore: ruolo generalmente assunto da un project manager del software
• Editor: IDE che integrano generatori di documentazione come Javadoc o Doxygen; documentazione dai kit di sviluppo software
• Segreteria: client di posta elettronica, strumenti di gestione dei progetti come tracker di problemi e richieste pull, chat room aziendali e mailing list
• Impiegato di programma: IDE che memorizza informazioni sulla progettazione del progetto, con la possibilità aggiuntiva di refactoring del codice; documentazione ed esempi dai kit di sviluppo software
• Toolmith: l'intera comunità open source
• Tester: su base immediata, test suite e librerie di test. Ma ovviamente è necessario un processo di QA separato per il codice di produzione.
• Avvocato linguistico: documentazione online, StackExchange

Penso che devi guardare la premessa di The Mythical Man Month. Assumere più programmatori non fa che peggiorare un progetto software problematico / scaduto. Il problema è nella comunicazione e nel rendere i programmatori appena aggiunti aggiornati sul progetto (richiede tempo dallo sviluppo esistente), sulla tecnologia e talvolta sul dominio stesso.

Un programmatore ben supportato elimina molti dei tempi di comunicazione e coordinamento. Supponiamo che tu assuma un consulente per Technology X. Invece di portare questo consulente ad accelerare il progetto abbastanza da consentire a questo individuo di fare tutto il codice in quell'area, egli guida lo sviluppatore esistente fino al punto in cui può ottenere qualcosa da costruire con un po 'di supervisione.

Uno dei motivi per cui non si vede molto di questo è perché la maggior parte dei software viene scritta da una persona comunque. Le squadre dividono il lavoro e tutti vanno e fanno le loro cose. Associare programmazione, recensioni e tutto ciò che profuma di microgestione è disapprovato. Molti non vedono la programmazione come uno sport di squadra. Una persona risolve un determinato problema con una certa considerazione per i vincoli generali.

Direi che più separiamo progettazione, implementazione, test, documentazione, costruzione, implementazione, operazioni, ecc. In ruoli univoci svolti da specialisti, più seguiamo la filosofia del "team chirurgico" (anche se forse non esattamente nel modo descritto ).

Nella mia esperienza, la filosofia devOps secondo cui ogni persona dovrebbe essere in grado di svolgere qualsiasi compito è un ritorno al modello di macellazione del maiale (per non dire che è male, solo diverso).

Come programmatore che ha spesso ricoperto i ruoli di DevOps e Build Master, ho sentito che spesso finivo in quella posizione di essere la squadra chirurgica ... err ... ragazzo nella squadra. Come build build ho avuto una visione d'insieme dell'intero codice ed è stata la prima riga quando non è riuscita. Spesso lo riparavo da solo.
Spesso sono stato io a scrivere questi sistemi di metriche e misurare i punti caldi nel codice, parti che fallivano più spesso, che attiravano il maggior numero di segnalazioni di errori, ecc. Non pubblicavo solo i risultati per il team, li analizzavo, trovavo anche nodo che ha causato problemi e proposto soluzioni e modifiche architettoniche per risolvere questo problema.

Come DevOps avrei automatizzato enormi parti di processo e spese generali. Ricercherei tecnologie e strumenti che semplificherebbero la vita del team, dell'intero team, degli sviluppatori, dei tester di controllo qualità fino alla gestione. Il mio ruolo era comprendere il processo, sì; ma tenendo gli occhi fissi sulla squadra (gli umani reali) usando (soffrendo) quel processo sono stato in grado di distillarlo al punto da renderlo completamente trasparente pur ottenendo una serie di dati utili per ottenere una visione obiettiva di ciò "quadro generale" sempre sfuggente.

È una posizione ingrata da avere e probabilmente il motivo per cui è evitato così tanto. So di aver fatto bene il mio lavoro quando nessuno ha notato quel processo, quando nessuno ha pensato alla pipeline di costruzione. Quindi sì, una macchina ben oliata viene rapidamente data per scontata. Ma sapevo, in effetti ho misurato, l'impatto moltiplicativo che questo lavoro può avere sulla produttività di una squadra e vale la pena investire.

Quindi sì, penso che quel ruolo sia ancora molto vivo oggi, anche se è vero che si è evoluto da quello che era allora.