Il modo migliore per coinvolgere gli sviluppatori junior nella progettazione di un'applicazione da zero? [chiuso]

Siamo un team di 3 sviluppatori (2 sviluppatori esperti e uno junior).

Abbiamo appena iniziato un nuovo progetto. Abbiamo progettato l'applicazione, concentrato gli sforzi per scegliere l'architettura giusta e ora stiamo ponendo le prime linee di codice. Ne stiamo scrivendo il nucleo, quale sarà il fondamento dell'intera applicazione.

Non è nemmeno un'applicazione facile. Requisiti prestazionali elevati, modello di entità complessa ampiamente distribuito, ecc.

Siamo tutti fuori dalla nostra zona di comfort, in particolare i junior. Non ha l'esperienza per creare un buon design in anticipo. Questo non è un problema, però, perché io e gli altri sviluppatori siamo lì per aiutare e crediamo entrambi nel mentoring e nella costruzione di team, ma ... non sappiamo esattamente quale sarebbe il modo migliore per farlo, in modo che ottenga un'esperienza piacevole e apprende il massimo delle competenze.

Entrambi ci siamo resi conto che non avevamo un junior su nuovi progetti, solo su quelli esistenti dove era più facile per il junior perché aveva un'intera base di codice da cui imparare e ispirare. Ma per questa app non abbiamo quasi nessun codice. Abbiamo appena iniziato

Stavamo pensando ad alcuni approcci:

• fagli provare da solo per un paio di giorni, poi interveni e rifatti il ​​codice insieme a lui, guidalo nella giusta direzione e poi ripeti => Potrebbe non essere un'esperienza divertente per lui dal momento che faremo notare i suoi errori su ogni refattore ;
• fagli accoppiare la programmazione con uno di noi => potrebbe diventare solo uno "spettatore" e essere d'accordo con tutto ciò che facciamo, senza realmente imparare molto o digerire gran parte delle informazioni;
• farci costruire lo scheletro di ogni modulo, con un design solido e poi dargli il modulo per aggiungere i pezzi mancanti => potrebbe non essere divertente da raccogliere dopo di noi e c'è il rischio che presta attenzione solo a colmare le lacune e non per l'intero design.

Come possiamo coinvolgerlo nel design in modo che non si senta in qualche modo lasciato fuori da esso e che impari molto dall'esperienza e acquisisca abbastanza fiducia per provarlo da solo?

Raccomando le seguenti linee guida:

• Coinvolgi lo sviluppatore junior nelle riunioni di progettazione e sollecita il suo contributo. Questo lo farà pensare al quadro generale, anche se non è pronto a realizzare personalmente il progetto di alto livello.
• Cerca di isolare e definire chiaramente un modulo dell'applicazione da assegnare allo sviluppatore junior. Descrivere per iscritto quali sono gli ingressi / uscite e altri requisiti del modulo. Evita di assegnargli un modulo che non può essere facilmente testato o che può essere testato solo se integrato con altri moduli ancora da scrivere.
• Forse lo sviluppatore junior potrebbe aiutare in modi diversi dalla codifica dell'applicazione principale. Ad esempio, potrebbe scrivere il codice di prova. Lungi dall'essere un lavoro umile, scrivere buoni script di test fornisce un prezioso contributo al progetto e offre allo sviluppatore junior una solida conoscenza del progetto.

Penso che dipenda dall'area in cui vuoi migliorare lo sviluppatore junior. Quando ero (molto) junior mi davano le API che dovevo costruire una cosa limitata, come:

• questa funzione fornisce N numero di canali personali dalla tabella del personale
• questa funzione fornisce statistiche sul personale dato l'ID del personale

->

Attività: costruire una pagina con un elenco di canali personali che mostrano le sue statistiche quando si fa clic su un record personale. Ecco una semplice pagina di esempio creata in precedenza nel progetto.

L'aspetto più importante di un determinato compito è essere risolvibile solo da quelle risorse fornite e non richiede alcuna modifica in esse.

Tutti e 3 i modi mi stanno bene. In realtà provare 10 diversi modi agili allo stesso tempo dovrebbe darti presto buoni risultati, almeno saprai in che modo funziona e quale no (quale funzionerà meglio dipende molto dalle personalità dei giocatori).

Il problema di programmazione della coppia non si verificherà se ti attieni al processo con i cappelli di battitura / pensiero che cambiano ogni 10 minuti (circa), senza eccezioni, seguendo il processo originariamente descritto da Kent Beck (non ricordo dove)

Per quanto riguarda il coinvolgimento di altre persone nella progettazione, ciò che abbiamo scoperto è utile se durante la fase di progettazione vengono creati alcuni documenti di progettazione (con alcuni modelli UML). Le altre persone (i tuoi ragazzi) possono quindi rileggerle, esaminarle, interpretare l'avvocato del diavolo. Questo ruolo di una terza parte incontaminata indipendente può effettivamente essere molto utile, ad esempio per i test esplorativi - http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries