Sto avviando una società di software finanziario e nel processo ho studiato i principi e i metodi Agile e l'unico aspetto dello sviluppo che non ho ancora visto indirizzato è dove adattare il continuo bisogno degli sviluppatori di apprendere nuove competenze e tecnologie nello sviluppo processi.

Prima di lavorare su software finanziario negli ultimi due anni, ho trascorso gran parte della mia carriera come programmatore di grafica 3d lavorando su videogiochi e software GIS e biometrici e ho sempre dovuto tuffarmi da una scogliera nelle cose e capire come volare. Anche se ci sono sempre riuscito, sono sicuro che non vivrò più a lungo come avrei fatto se non mi fossi suicidato a lavorare così tante 100 ore settimane e mesi alla volta.

Ora che sto avviando una società di software che non ha abbastanza le intense esigenze innovative della grafica 3d, voglio stabilire un approccio più olistico allo sviluppo.

Forse l'agile semplicemente non si occupa di questo, ma se lo fa, non ho trovato dove e apprezzerei qualsiasi conoscenza, competenza o esperienza che qualcuno ha con questo.

Questo non ha molto a che fare con Agile, o anche con l'ingegneria del software. È semplicemente vero per qualsiasi azienda in qualsiasi attività commerciale: è necessario dedicare tempo alla formazione. Periodo.

Agile ha questa idea di "ritmo sostenibile", il che significa che, in nessun momento, il team dovrebbe lavorare di più di quello che potrebbe sostenere per un periodo di tempo indefinito. Cioè nessun "tempo di crisi". Questo deve essere onorato anche dalla formazione. Quindi, un ritmo sostenibile per la tua squadra è "non più di 5 ore di fila senza interruzione, non più di 9 ore al giorno, non più di 40 ore a settimana" e vuoi fornire il 10% di tempo per l'allenamento, quindi devi pianificare i tuoi progetti per 36 ore settimanali.

Ma ancora una volta, questo non ha nulla a che fare con Agile, questo è solo buon senso e matematica della scuola primaria.

Personalmente, penso che qualcosa come consentire mezz'ora al giorno, una mezza giornata alla settimana e un'intera settimana al trimestre consentirebbe al team di acquisire blocchi di conoscenza di dimensioni diverse in modo rapido e costante.

Esistono anche alcune pratiche Agili che aiutano nel trasferimento delle conoscenze, ad esempio per appianare le differenze nel livello di conoscenza tra i team:

• retrospettive quotidiane
• retrospettive per sprint
• retrospettive per progetto
• programmazione in coppia
• accoppiamento ping-pong (scambio di conducente e navigatore dopo ogni passaggio del ciclo del refattore rosso-verde)
• accoppiamento promiscuo (nessuna coppia fissa, le coppie vengono assegnate in modo casuale e cambiate ogni mattina e pranzo)
• numero dispari di membri del team (se si accoppia la programmazione, lascia un membro del team libero di imparare)
• Programmazione mob
• team promiscui (gli sviluppatori vengono assegnati casualmente ai team ogni giorno / ogni sprint)

La programmazione di coppia e la programmazione mob non solo forniscono una revisione continua del codice, ma anche una condivisione continua delle conoscenze. L'accoppiamento ping-pong impedisce a una persona di "tenere d'occhio la tastiera". L'associazione promiscua diffonde la conoscenza in tutto il team, i team promiscui diffondono la conoscenza in tutta l'azienda e assicurano che ogni sviluppatore conosca ogni progetto e ogni base di codice; porterà anche a un alto grado di standardizzazione nella base (i) di codice. Mentre l'obiettivo principale delle retrospettive è fornire feedback sul processo di sviluppo e adattarsi di conseguenza, può anche essere utilizzato per comunicare un problema non comune e come risolverlo.

Va da sé che il datore di lavoro dovrebbe fornire una vasta biblioteca, abbonamenti a pagamento ad ACM, Springer, IEEE, ecc., Nonché stanze silenziose in cui studiare e stanze più grandi in cui insegnare. Molte lavagne e lavagne a fogli mobili, nonché i proiettori ovunque sono ovviamente sensati in generale, non solo per la formazione.

Sono d'accordo con la maggior parte di ciò che ha detto Jörg W Mittag , ma non con l'affermazione che "questo non ha molto a che fare con Agile". Numerose tecniche agili supportano l'apprendimento e lo sviluppo di individui e gruppi.

I metodi Agile tendono ad essere basati su incrementi o flusso continuo. In entrambi i casi, il lavoro viene ordinato in base a fattori come priorità, valore e dipendenze. Poiché l'attenzione è focalizzata sul lavoro a breve termine, il team può identificare le conoscenze necessarie per fornire e, se la mancanza di conoscenza è un problema, pianificare per acquisire tale conoscenza just-in-time. La visibilità e la trasparenza tendono inoltre ad essere gli aspetti chiave di vari metodi Agile, in modo che le parti interessate possano vedere su cosa sta lavorando il team e come stanno lavorando per migliorare le loro capacità di fornire valore. Quando è necessario un apprendimento approfondito, può essere pianificato nel prossimo futuro o nell'iterazione corrente.

Una volta che le persone in una squadra hanno acquisito conoscenza, ci sono tecniche su accoppiamento e mobbing. La programmazione in coppia è una pratica chiave nella programmazione estrema che è stata applicata anche ad altri metodi ed è progettata per facilitare, tra le altre cose, l'apprendimento. Mobbing sta applicando questo a più di due sole persone. La stretta collaborazione e interfunzionalità dei team significa che non ci sono silos e queste informazioni vengono divulgate.

Anche con la capacità di pianificare ed eseguire l'apprendimento di ciò che è necessario per il lavoro immediato, avere membri del team competenti è molto importante. Avere persone con un certo livello di conoscenza esistente degli strumenti, della tecnologia e del dominio consentirà loro di essere più informati quando si assumono compiti di apprendimento ed essere più efficaci quando si diffondono conoscenze ad altri membri del team.

Pianifica un'attività di prova del concetto per lo sprint in cui desideri pianificare il tempo per apprendere un'abilità. Concentrati su qualcosa di molto specifico, come imparare a creare una tabella HTML accessibile. Continua a programmare le prove di compiti concettuali fino a quando non avrai appreso le competenze necessarie per la storia. Assegna ad ogni attività POC alcuni punti trama e una data di scadenza in modo da poterlo impostare correttamente nel tempo e mostrare i progressi alla fine dello sprint.

E se una storia dovesse essere solo 5 punti per uno sviluppatore esperto? Forse ci vogliono 3-4 compiti a 8 punti ciascuno. Dopo quelle attività POC la storia potrebbe ancora essere solo 5 punti, ma almeno dedichi il tempo per apprendere le nuove abilità in modo che la storia a 5 punti non sia 40 punti, anche se le attività storia e POC aggiungono fino a 40 punti.

Scrum ha l'idea di un "picco". Se il team sta assumendo una nuova tecnologia o capacità, un picco è una storia per incapsulare quel lavoro. Quindi, mentre una storia in agile è un po 'di funzionalità focalizzata sull'utente, l'output di un picco è la documentazione di ciò che è stato appreso e una suddivisione del lavoro per metterlo in pratica nella vera applicazione.

In pratica, ho scoperto che è un buon modo per gestire almeno la formazione su piccola scala - abbastanza per far sì che gli sviluppatori siano aggiornati con un nuovo sistema o framework, dando comunque responsabilità al programma.

Non ho visto questo nelle altre risposte, quindi volevo aggiungere che molte organizzazioni avviano gilde, capitoli o centri di eccellenza nelle aree di competenza. Questi possono essere argomenti ampi come la tecnologia o specifici come lo sviluppo nativo di React. Tutto dipende se l'interesse a partecipare esiste nella tua azienda.

Indipendentemente da ciò, questi gruppi spesso hanno il compito di aiutare le persone del gruppo a crescere professionalmente. Questo crea uno spazio separato al di fuori del lavoro per rafforzare ed espandere le competenze sia per le persone che usano tali abilità ogni giorno sia per le persone al di fuori di quella disciplina che sono interessate al cross-training. Questa non è l'unica soluzione a questo problema, ma sembra diventare sempre più comune.

Alcuni altri hanno già menzionato aspetti, ma volevo solo condividere il modo in cui si adatta lo sviluppo personale in un ambiente agile.

1. Sviluppo in corso

Questo è il più semplice, riduci la tua capacità in ogni sprint fino a quando non hai abbastanza tempo per fare lo sviluppo continuo. La parte difficile di solito è attenersi al tuo piano e anche fare lo sviluppo se ci sono più altri compiti da raccogliere. Se hai emergenze puoi sacrificare questa volta di tanto in tanto, ma altrimenti no.

Poiché hai ridotto la tua capacità, tutto ciò che fai in questa categoria è al di fuori della preoccupazione diretta degli altri membri del team e probabilmente non hanno molte ragioni per preoccuparsene o aggiornare la pianificazione specificamente in ogni singolo sprint.

2. Grandi sforzi durante uno sprint

Quello che ho scoperto è che se hai pianificato qualcosa con un impatto maggiore (ad es. Allenamento di 2 giorni durante uno sprint), dovresti aggiornare lo sprint per riflettere questo. Non sono sicuro di quale sia la soluzione teorica per questo, ma ho visto spesso che le persone hanno semplicemente messo il compito di addestramento sulla lavagna per assicurarsi che sia visibile che qualcuno è impegnato in questo.

In alternativa, potresti correggere la capacità dello sprint dello sprint specifico, ma a meno che le persone non osservino attentamente le tue prestazioni / efficienza misurate, starei alla larga da questo. Soprattutto in una squadra nuova, la stabilità è probabilmente più preziosa della precisione.

Agile è un insieme di filosofie, dai un'occhiata al manifesto, questo è TUTTO Agile, quindi quando dici come può Agile risolvere i miei problemi, ti consiglio di imparare (molto) di più su Agile. Diamo una concreta implementazione di Agile: SCRUM. In SCRUM abbiamo i concetti di Sprint e picchi. Attraverso questi due manufatti, è possibile realizzare la creazione di un budget per l'apprendimento.

Se guardi uno sprint come un grafico a torta, puoi dividere le priorità in base all'argomento, uno di questi argomenti può essere ... apprendere nuove abilità!

Un picco è un'attività di ricerca su uno sprint che comporta la valutazione della fattibilità di qualcosa di solito attraverso l'apprendimento.

Infine, la cosa che hai fatto è ancora sul tavolo e puoi imparare MENTRE fai qualunque cosa tu stia lavorando, a quel punto puoi provare ad aumentare i punti / la capacità della storia per affrontare la sfida tecnica.

Per citare dal Manifesto Agile stesso:

Individui e interazioni su processi e strumenti
Software funzionante su documentazione completa
Collaborazione con i clienti sulla negoziazione del contratto
Risposta al cambiamento dopo un piano

L'enfasi è mia, mettendo in evidenza le parti che sono probabilmente più applicabili a te.

Fondamentalmente, gli sviluppatori agili ben addestrati possono rispondere agli ambienti mutevoli molto meglio di quelli che lasciano pietrificare le proprie competenze.

Se posso aggiungere la mia definizione di agile, possiamo anche aggiungere "collaborazione al cliente" nel mix. Trovo che la migliore definizione di agile sia quella basata sull'idea di agilità: se il cliente (o l'ambiente) cambia radicalmente, come si fa a gestire? Se stai promuovendo un ambiente di collaborazione con i clienti, avranno un interesse acquisito nel tuo team sapendo cosa stanno facendo.