Quale metodologia è più vicina all'équipe chirurgica di The Mythical Man-Month?[Chiuso]

Question

Il Mitico Mese dell'Uomo è ormai un classico, ma la metodologia del "Team Chirurgico" è ancora interessante.Quale metodologia le somiglia di più o ha la stessa essenza?

Per riassumere l’analogia con l’équipe chirurgica:Un chirurgo comprende il problema/ambito aziendale ed è l'esperto.Sono l'autorità quando ci sono domande o conflitti all'interno del team.I chirurghi lavorano tra loro quando ci sono problemi, ad esempio con la progettazione, funzionando come un team ristretto di esperti.Quindi, in sostanza, hanno la conoscenza del dominio, hanno il compito di pensare che sia giusto e di eseguire la codifica vera e propria?Il resto del team si concentra su supporto, test, documentazione e i piani di progetto sono compiti delegati.Di conseguenza il chirurgo è anche la risorsa più qualificata/formata.

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

Answer 1

Uno dei modelli di cui al schemi organizzativi di Sviluppo Software Agile si intitola "tre a sette aiutanti per ruolo"; si differenzia dalla squadra chirurgica in quanto presta attenzione ad ogni ruolo, ad esempio, non è solo che il chirurgo 'ruolo' che ha aiutanti o rapporti:. tutti ruoli hanno un numero di rapporti

Un altro modello dalla stessa fonte in denominato "architetto implementa anche", che può essere analogo a "squadra chirurgica" dal fatto che l'architettura in particolare è (presumibilmente) della rete.

Answer 2

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

Cioè, è sia il responsabile del programma software (architetto) che lo sviluppatore.

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

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

• Pochi sviluppatori chiave comprendono a sufficienza il dominio problematico e devono fare affidamento su esperti del settore.Questa è semplicemente una funzione di specializzazione: è difficile trovare programmatori spavaldi che siano anche avvocati, medici, contabili o comunque esperti nel dominio che il software sta modellando.

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

• C'è molto tempo libero per il resto del personale mentre aspettano istruzioni, poiché l'"agente" altamente concentrato gestisce anche la squadra.Va bene in OR, dal momento che hai a che fare con un mandato "zero-bug" e "software live". Ma in questa economia, un carico di lavoro più distribuito è più efficiente, anche se si traduce nel problema di sincronizzazione occasionale tra i membri del team.

Answer 3

Non sono sicuro di una metodologia affronta 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 un po 'di Metodologie che impements questo, suppongo che questo potrebbe essere una cattiva notizia. Io preferisco considerarlo buona notizia , in quanto significa che è possibile utilizzare questo approccio con praticamente qualsiasi metodologia di sviluppo software.

Ho lavorato su esattamente una progetto che è stato gestito in questo modo. E 'stato così piacevole, ho quasi sento male definendolo "lavoro". Quattro di noi sviluppatori (con addetti di supporto extra, tra cui l'occasionale scimmia codice aggiuntivo Junior) ha ottenuto una quantità veramente prodigioso di codice scritto e funzionare correttamente in soli 9 mesi. Altri posti sono stato, non avrebbe potuto fare tanto con un team di 20.

Answer 4

Dal testo vedo il seguente:

Agile come:

• Piccoli gruppi concentrati sulla soluzione di problemi specifici
• La collaborazione tra le surgeions

Non Agile come:

• I chirurghi sono l'autorità, la guida del piano, che determina il design, distribuire i compiti di supporto (li viewng come subservent di codifica) e facendo la codifica. Tutti questi sono molto di comando e controllo di approccio e contrario al team auto regia (vs un team diretto)
• Sembra che ci sia alcuna collaborazione con il business partner (per non parlare di frequente collaborazione con il partner busines)
• Non sembra esserci alcun backlog prodotto priorità, in tal modo il chirurgo raccoglie ciò che è importante non è il business partner
• Sembra che ci sia alcuna consegna incrmental (feedback loop stretto)

Per un progetto cascata, si suggerisce di utilizzare un team di esperti (chirurghi) per fare la pianificazione, progettazione, codifica, ecc e distribuire i compiti al personale "di supporto". Su un team agile, test non è trattata come supporto, ma parte integrante della fornitura.

Non si può dire con certezza la metodologia essere sostenuto. Tuttavia, non sembra usare la lingua (piani di progetto, task) e supponiamo che l'approccio a cascata è seguito (fasi come il disegno, codifica, test guidato da un piano). Qualunque sia la metodologia viene utilizzato, è quello per il quale i pochi determinano il lavoro per molti.