C'è stata una recente ricerca sul modello di Fred Brooks del "Team di software chirurgico"? [chiuso]

Question

C'è stata una recente ricerca sul modello di Fred Brooks del "Team di software chirurgico"? [chiuso]

#1 da (4 voti)

3

Sto leggendo per la prima volta The Mythical Man Month . In esso, Fred Brooks * propone un modello di sviluppo del software basato sul funzionamento di una squadra chirurgica. C'è un "chirurgo" (uno sviluppatore senior) che fa quasi tutto il lavoro di progettazione e implementazione, un "copilota" che discute queste idee con il chirurgo e occasionalmente fa una piccola codifica, un "toolsmith" (dev ops), una lingua esperto e altri operatori amministrativi.

Non posso non aiutare a essere colpito dal fatto che, nonostante la grande fama di The Mythical Man Month , non ho mai visto né sentito parlare di un ufficio che opera effettivamente su quel modello. Questo nonostante la rapida ascesa dell'industria tecnologica e il culto del "programmatore rockstar" che è alla moda tra le startup di oggi.

E quindi mi chiedevo se questo fosse dovuto al fatto che il modello chirurgico è diventato obsoleto in qualche modo. Dopotutto, ora abbiamo miglioramenti come il controllo della versione (rendendo obsoleto uno dei suoi ruoli amministrativi), ottimizzando i compilatori (forse rendendo l'esperto linguistico obsoleto) e lo sviluppo agile (che potrebbe non rendere nulla di obsoleto, ma sembra sostanzialmente diverso dal metodo a cascata che le persone usavano in quei giorni).

La domanda, quindi: c'è stata qualche ricerca sull'efficacia del modello del "team chirurgico" di Brooks nell'era del moderno sviluppo del software, con processi agili e strumenti moderni? Che cosa dice la ricerca di oggi è la struttura del team più efficace?

* Credito in cui il credito è dovuto: tecnicamente, Brooks riassume le precedenti ricerche di Harlan Mills e F.T. Panettiere. Sto usando il nome di Brooks solo perché il suo nome è più riconoscibile.

teamwork project-management development-process

posta HardlyKnowEm 23.06.2015 - 16:31

fonte

1 risposta

Leggi altre domande sui tag teamwork project-management development-process

Ho bisogno di un servizio web per questo caso? Sincronizzazione dei dati su più client Quali sono le mie opzioni per esporre le impostazioni di personalizzazione all'utente amministratore?

score 4 · Answer 1

Il motivo per cui non vedi questi team di software chirurgici è spiegato dal modo in cui gli sviluppatori vengono assunti e assegnati ai team.

Due condizioni preliminari per tale squadra sono:

Che ci dovrebbe essere, all'interno di un'azienda, sviluppatori che hanno livelli diversi con un divario importante tra i più esperti e quelli meno esperti,
E sono pronti a lavorare insieme.

Parliamo della prima condizione. Quando guardi le diverse aziende, gli sviluppatori che assumono hanno un livello di abilità, livello di esperienza e cultura simili. Troveresti uno sviluppatore talentuoso ed esperto in una piccola azienda che crea siti Web PHP per negozi locali? Probabilmente no. Preferirai incontrare programmatori che non sono particolarmente bravi nel college e che non sono particolarmente interessati al loro lavoro. Se trovi un ragazzo di talento junior, puoi essere certo che lascerà questa compagnia non appena troverà un posto migliore, e troverà un posto migliore, perché molte aziende sono alla ricerca di sviluppatori di talento.

Ora, potresti trovare molti sviluppatori demotivati e inesperti che lavorano solo per soldi in Fog Creek o Valve Software? Io non la penso così, non solo perché non saranno assunti, ma perché non cercheranno nemmeno di avere un'intervista lì.

Ciò significa che all'interno della stessa azienda, ci saranno sviluppatori e sviluppatori junior con dozzine di anni di esperienza professionale, ma tutti condivideranno la stessa cultura e cercheranno di lavorare il meglio che possono in alcune aziende, o semplicemente lavorare per soldi in altri.

All'interno dell'azienda, noterai ancora una volta che i più talentuosi vogliono e sono incoraggiati a collaborare . Se c'è un progetto stimolante che è cruciale per l'azienda, puoi star certo che troverai i migliori sviluppatori lì. Un progetto noioso che non ha nulla di cruciale sarà invece dato agli sviluppatori che hanno un talento leggermente inferiore. Questo è un modo naturale di fare le cose, e questo è ciò che accadrà se le persone stesse decidono su quale progetto lavoreranno successivamente, senza essere formalmente assegnato dalla direzione.

Mentre esiste la possibilità per il management di forzare un team di software chirurgico mescolando sviluppatori di talento con quelli meno talentuosi, si dovrebbe notare che le persone potrebbero non andare d'accordo l'una con l'altra . Il rischio è che, poiché sanno che sono stati messi insieme intenzionalmente dalla direzione, la persona più esperta può iniziare a comportarsi come un coglione con le sue coppie; a loro volta, gli sviluppatori meno esperti possono cercare di evitare di confrontarsi con quello più esperto. Confrontalo con un gruppo di persone che ha deciso di lavorare insieme e che si rispettano a vicenda, e puoi capire perché i team di software chirurgici non sono una pratica comune ...

Secondo me, i team di software chirurgici potrebbero funzionare. In alcuni rari casi, e con persone che sanno cosa stanno facendo e che sono pronti a lavorare con colleghi più o meno talentuosi. Detto questo, nell'ultimo decennio la tendenza era piuttosto verso gruppi agili di persone auto-organizzanti che hanno una cultura simile e un'esperienza simile, ma si specializzano in diversi ambiti per essere complementari .