Come dovrebbe essere distribuita l'abilità attraverso i team?

Dopo aver letto questo, Ho visto che sembra esserci un grande disaccordo su come i team agili dovrebbero essere strutturati all'interno di un gruppo di sviluppatori con capacità variabili (ovvero quasi tutti i team). Tutti i migliori sviluppatori dovrebbero essere inseriti nei propri team e ricevere la massima priorità di lavoro? Ciò garantirà praticamente che le attività più importanti vengano eseguite. Allo stesso tempo, rimani con i team "meno che perfetti" altrove che accumulano debito tecnico, anche se si tratta solo di compiti a bassa priorità. D'altra parte, i team distribuiti uniformemente potrebbero avere il vantaggio di rendere un po 'meglio i tuoi sviluppatori in ritardo, ma hanno il potenziale per demotivare i tuoi battitori più pesanti. Inoltre, se mescoli un mucchio di buoni motivi di design con un mucchio di terribili anti-motivi, puoi davvero finire con qualcosa che potrebbe anche essere un mucchio di anti-motivi.

Ci sono alcuni rischi noti con A-Teams, ma se le dinamiche sono giuste allora penso di sì, metterei le mie persone più forti sui progetti più importanti insieme agli sviluppatori junior con il maggior potenziale. Per i tuoi progetti con priorità più bassa hai bisogno di un buon team leader, se possibile, per impedire loro di andare lontano dai binari. Il debito tecnico sta per succedere, qualunque cosa accada. Non tutti i debiti tecnici sono uguali; il costo / responsabilità del debito tecnico è in primo luogo proporzionale al valore commerciale del progetto, quindi mentre i progetti con priorità più bassa possono avere più verruche, il costo di questi è probabilmente ancora molto meno di quanto non significhino problemi significativi sui progetti con priorità alta essere.

Ricordo che quando ero all'università uno dei nostri professori ci raccontava un aneddoto sulle strutture del team (ho dato un'occhiata al documento di cui parlava proprio ora ma non riesco a trovarlo).

Fondamentalmente, la storia è stata la seguente:

Un gruppo di programmatori è stato diviso in gruppi in base all'abilità, con i peggiori programmatori x raggruppati insieme, i successivi x raggruppati insieme, ecc. E i migliori raggruppati insieme.

A tutti è stato assegnato lo stesso compito e gli è stato assegnato un periodo di tempo entro il quale completarlo.

Alla fine del periodo di tempo, gli organizzatori hanno esaminato le soluzioni ai compiti e, con loro sorpresa, hanno scoperto che la soluzione più efficace proveniva dal team composto da gente media. Al contrario, il team composto dai programmatori A * ha realizzato una delle peggiori soluzioni perché ha trascorso tutto il tempo a discutere su quale fosse la soluzione migliore .

Se hai bisogno di una squadra che realizzerà cose, prendi un gruppo di ragazzi medi e un ragazzo dominante che può guidare, è stata la conclusione dello studio (se ricordo bene), altrimenti i membri più dominanti passeranno più tempo a combattere che a ottenere roba fatta!

La stragrande maggioranza degli sviluppatori inesperti potrebbe non essere in grado di elaborare disegni robusti ed eleganti per conto proprio, ma possono riconoscerlo e capirlo quando ne vedono uno. Se non ci riescono, di solito mancano di attitudine o preparazione per essere assunti in primo luogo.

Ci sono anche alcuni sviluppatori più esperti che sono in grado di comprendere progetti software molto complessi, ma non hanno la discrezione di sapere quando qualcosa di più semplice sarebbe meglio.

Nella mia esperienza di solito hai problemi permanenti con squadre miste solo se contengono membri non preparati, membri inutilmente complessi o entrambi. Altrimenti, se il tuo team ha problemi, di solito possono essere risolti con una migliore comunicazione o assegnando ruoli appropriati.

Raggruppare le persone migliori in un singolo team può sembrare un'ottima soluzione a breve termine, ma si tratta di un fallimento a lungo termine e ha costi aggiuntivi. Ad esempio la mia azienda preferisce quando le persone imparano dai loro colleghi più abili invece di pagare per la formazione. Se separi le persone migliori, queste non saranno in grado di trasferire le conoscenze a persone meno qualificate. A breve termine, le tue migliori squadre possono ottenere buoni risultati, ma a causa della mancanza di trasferimenti di conoscenze il numero di persone qualificate non aumenterà. È molto meglio avere un team meno performato all'inizio e aumentare le prestazioni su tutti i team man mano che le persone diventano più abili.

Inoltre cosa succede se persone qualificate decidono di andarsene? Chi prenderà i loro progetti?

Un altro punto è che la squadra dovrebbe essere composta da persone con diversi set di abilità. Avrai sempre compiti facili (e noiosi) che sono troppo costosi per essere eseguiti dagli sviluppatori più esperti.

Quelli che non possono insegnare, fanno ...

Penso che ci siano più fattori da considerare.

Otterrai il massimo valore distribuendo quelli che possono insegnare come team leader. Possono insegnare agli altri membri del team e contribuire a migliorare la qualità del loro lavoro.

Non tutti i programmatori senior faranno buoni contatti. Quella capacità di comunicare informazioni è un'abilità in sé e per sé. Questa abilità non è qualcosa che si sviluppa attraverso l'esperienza di programmazione. Si sviluppa attraverso l'insegnamento e la spiegazione.

L'assegnazione di una squadra "A" presenta due problemi significativi. Il primo è la compatibilità. Avere squadre che vanno d'accordo e lavorano bene insieme è molto più importante della loro "abilità". Ora possono trattarsi di due programmatori di abilità "alta", due programmatori di abilità "bassa" o un mix. Il fatto che possano lavorare bene insieme significa che saranno più produttivi.

Il secondo numero riguarda la crescita. Due programmatori "a bassa abilità" non impareranno molto l'uno dall'altro, oltre alle cattive abitudini. Allo stesso modo due programmatori qualificati "altamente" non impareranno molto l'uno dall'altro. Tuttavia, mescolare i livelli di abilità "bassa" e alta "aiuterà a migliorare le abilità dell'abilità" bassa ". Miglioreranno anche le capacità dell'abilità" alta ". In che modo cercare di insegnare una materia troverà rapidamente i tuoi punti deboli in questo soggetto. Non ho considerato un'abilità "padroneggiata" fino a quando non puoi insegnarla a qualcun altro.

Dall'altro lato della medaglia, penso che abbia senso mantenere squadre che possono "tenersi al passo" l'una con l'altra. I programmatori del tuo tipo A-Team non vogliono aspettare i tipi B-Team per fare i loro bit. I tuoi tipi B-Team potrebbero essere intimati dal flusso di lavoro in stile A-Team.