Quale metodologia è più vicina all'équipe chirurgica in The Mythical Man-Month?

Question

Il Mythical Man-Month è ora classico, ma la metodologia del "Team chirurgico" è ancora interessante. Quale metodologia le assomiglia di più o ha la stessa essenza?

Per riassumere l'analogia del team chirurgico: Un chirurgo comprende il problema/il dominio aziendale ed è l'esperto. Sono l'autorità quando ci sono domande o conflitti con la squadra. I chirurghi lavorano tra di loro quando ci sono problemi, diciamo con il design, funzionando come una squadra ristretta di esperti. Quindi, in sostanza, hanno la conoscenza del dominio, sono incaricati di fare ciò che pensano sia giusto e fanno la vera codifica? Il resto del team si concentra sul supporto, test, documentazione e piani di progetto sono compiti delegati. Di conseguenza, il chirurgo è anche la risorsa più qualificata/addestrata.

La risposta potrebbe essere il progetto, la programmazione, le metodologie di progettazione in quanto sembra avere implicazioni nei principali domini della metodologia. Agile, MDA, Extreme, nello sviluppo di sourcing? Questa domanda ha anche più senso per il software di grandi dimensioni in un dominio aziendale complesso, si pensi al controllo del traffico aereo, non a uno sviluppatore COTS oa un'utilità comune.

Answer 1

Uno dei modelli menzionati in Organizational Patterns of Agile Software Development è intitolato "Tre a sette helper per ruolo"; differisce da Surgical Team in quanto presta attenzione a ogni ruolo, ad esempio non è solo il ruolo del chirurgo che ha aiutanti o relazioni: tutti i ruoli hanno un certo numero di relazioni.

Un altro modello della stessa fonte denominato "Architect Also Implements", che può essere analogo a "Surgical Team" in quanto l'Architect in particolare è (presumibilmente) altamente qualificato.

Answer 2

io non sono sicuro che qualsiasi metodologia si rivolge davvero così, perché è davvero una questione di priorità degli sviluppatori e piegando tutto ai loro bisogni, piuttosto che essere nulla di come gli sviluppatori in realtà sviluppare il loro software.

Se stavate cercando qualche metodo che lo contenga, suppongo che questa possa essere una brutta notizia. Preferisco considerarlo buone notizie, nel senso che è possibile utilizzare questo approccio con quasi tutte le metodologie di sviluppo del software.

Ho lavorato esattamente allo un progetto che è stato eseguito in questo modo. È stato così piacevole, mi sento quasi male chiamarlo "lavoro". Quattro di noi sviluppatori (con personale aggiuntivo di supporto, inclusa la scimmia occasionale di codice junior extra) hanno ottenuto una quantità di codice veramente prodigiosa scritta e funzionante correttamente in soli 9 mesi. Altri posti che non avrei potuto fare con un team di 20.

Answer 3

Nel caso di un chirurgo, l'attore chiave è sia l'esperto di dominio che l'implementatore.

I.e. è sia il gestore del programma software (architetto) che lo sviluppatore.

Questo tipo di metodologia potrebbe adattarsi a determinate situazioni di cortocircuito: ad esempio, un'operazione complessa come una migrazione del server live o un aggiornamento del software.

Per lo sviluppo in generale, tuttavia, ci sono alcuni problemi con tali metodologie "eroe":

• sviluppatori chiave pochi a capire il dominio del problema in misura sufficiente, e devono affidarsi a esperti di dominio.Questa è semplicemente una funzione di specializzazione: è difficile trovare programmatori di kick-butt che siano anche avvocati, dottori, contabili o comunque esperti nel settore che il software sta modellando.

• La scalabilità è limitata dal numero di "chirurghi" disponibili.

• C'è un sacco di tempo per il resto del personale mentre aspettano le istruzioni, dal momento che il "doer" altamente focalizzato sta anche gestendo il team. Va bene in sala operatoria, dal momento che hai a che fare con un mandato "zero bug" e "live software". Ma in questa economia, un carico di lavoro più distribuito è più efficiente, anche se si verifica un problema di sincronizzazione occasionale tra i membri del team.

Answer 4

Dal testo vedo il seguente:

Agile come:

• piccole squadre concentrati sulla soluzione di problemi specifici
• La collaborazione tra le surgeions

non Agile Come:

• I chirurghi sono l'autorità, guidano il piano, determinano il progetto, assegnano compiti di supporto (li osservano come sottomessi alla codifica) e fanno la codifica. Tutti questi sono molto di comando e di controllo nell'approccio e contrari ai team di auto-regia (vs un team diretto)
• Sembra non esserci collaborazione con il business partner (per non parlare di frequenti collaborazioni con il partner busines)
• Appare non esserci backlog prodotto priorità, in tal modo il chirurgo raccoglie ciò che è importante non è il partner commerciale
• non sembra esserci alcuna consegna incrmental (feedback loop stretto)

per un progetto cascata, si suggerisce di utilizzare un team di esperti (chirurghi) per pianificare, progettare, codificare ecc. e assegnare compiti al "suppor" t "personale. Su una squadra agile, i test non vengono considerati come supporto ma come parte integrante della consegna.

Non si può dire con certezza la metodologia proposta. Tuttavia, sembra che usi il linguaggio (piani di progetto, attività) e presupponga che l'approccio a cascata venga seguito (fasi come la progettazione, la codifica, i test guidati da un piano). Qualunque sia la metodologia utilizzata, quella per cui i pochi determinano il lavoro per i molti.