Presentazione di nuovi argomenti ai colleghi

Ho cercato di introdurre argomenti come test unitari, iniezione di dipendenza, inversione di controllo, ecc ... ai colleghi. Ho tenuto mini lezioni, dimostrazioni e ho suggerito questi argomenti durante il pranzo e apprende. L'accoglienza è stata generalmente positiva e le persone vedono valore in tali argomenti.

Anche se sembrano attratti da questi argomenti, l'adozione è stata molto bassa. Quando ne parlo con loro, la risposta è generalmente sulla falsariga di:

Ci proverò la prossima volta. Voglio solo portare questo progetto fuori dalla porta.

Ho la sensazione che sia perché la maggior parte di ciò che hanno visto sono solo dimostrazioni sul tipo di lezione e non hanno alcuna esperienza pratica. Cosa posso fare per aiutarli a spostarli? Non voglio "forzarli" a scrivere codice se non vogliono, perché può sembrare un "compito a casa" e può lasciare loro una brutta impressione.

I nostri progetti in genere non lasciano tempo alla sperimentazione, quindi le persone tendono a rifuggire dalle nuove tecnologie. Ciò non lascia spazio agli sviluppatori per cercare di incorporare nuove cose durante la fase di sviluppo.

Ci sono esercizi divertenti o interessanti (da solo o in gruppo) che consentono loro di avere più esperienza pratica con questi argomenti? Spero di trovare qualcosa che susciti abbastanza interesse in modo che siano disposti a programmare un'ora della loro giornata per lavorare su qualcosa di ordinato, o raggiungere l'interesse sufficiente in modo che possano indagare sul proprio tempo.

Per "provare" e quindi davvero impiantare un'idea nella testa di qualcuno, la teoria (parlare) non è mai abbastanza.

Devi usare quelle pratiche nel tuo codice e farle "scoprire" che ha risolto i problemi in modo carino.

Ciò implica che le tue pratiche devono essere efficaci e dovresti renderlo ovvio.

In questo modo, leggere il tuo codice li ispirerà perché "lo vedranno in azione".

Non dare per scontato che sarà sufficiente dire come funziona.

Parlando per esperienza, se non sono disposti ad applicare ciò che stai cercando di insegnare, significa che a loro non importa. Probabilmente stai perdendo il tuo tempo cercando di introdurre gli argomenti a loro, perché se hanno capito i benefici reali di questi argomenti che avrebbero vogliono applicare loro, non dare scuse per spiegare perché non possono.

È come provare a introdurre qualcosa di meglio di quello che viene attualmente utilizzato e ottenere sguardi vuoti o risposte immediate perché non è possibile farlo; è indicativo che l'altra persona non lo consideri davvero un vantaggio (perché se fossero in grado di vedere il beneficio, non darebbero una scusa).

Triste ma vero. Forse la tua situazione è diversa, ma l'ho incontrata un paio di volte in passato e alla fine era dolorosamente ovvio che nessuno tranne me era interessato a quegli argomenti; Alla fine ho preso la decisione di andarmene e di cercare collaboratori che si prendano cura di loro; il tipo di persone che o non hanno bisogno di me per presentare gli argomenti (perché già li conoscono / li usano) o che saltano ad accettarlo, invece di dire come non possono farlo.

Ho visto molte "buone pratiche" perdere il favore e non abituarmi mai più. Esistono molti tipi di progetti e tali tecniche non sono adatte a tutti i progetti. Assicurati che le cose che vendi possano davvero aiutare.

Se inizi a farlo e le persone possono vedere che stai diventando più produttivo o producendo un codice di qualità migliore, avranno un altro aspetto in seguito. Pensa attentamente, tutto il sovraccarico extra aiuterà davvero il tuo progetto? Non tutte le app ne hanno bisogno.

Se riesci a motivare i tuoi colleghi a partecipare, potresti organizzare Coding Dojos . Queste sono sfide di programmazione in cui i partecipanti si concentrano deliberatamente sul miglioramento delle pratiche. Forse prendere parte a un dojo guidato dai test, ad esempio, porterà i tuoi colleghi a vedere i vantaggi di TDD.

In alternativa, a volte queste cose devono essere imposte dalla cultura. Mi sembra che la cultura della tua azienda non abbia bisogno di loro.

Se diventano un requisito per la chiusura del progetto (probabilmente una decisione di gestione), vedrai una presa, ma almeno allora alcune applicazioni di tali strumenti e la cultura inizieranno a cambiare.

La migliore pratica è sul vero codice di produzione. I Katas sono una bella introduzione, ma nella mia esperienza, non tenere lo stesso "Eureka!" Momenti come vederlo fatto per davvero .

Tuttavia, hai sottolineato che le tempistiche "non consentono la sperimentazione". È davvero una soluzione semplice. Stai già facendo queste cose che stai cercando di insegnare, quindi lascia un invito aperto ad accoppiarti con te mentre stai implementando la nuova fantastica funzione X. Lasciali sedere sulla tastiera e digita mentre sei " guida sedile posteriore ". Ciò consentirà loro di costruire un po 'di memoria muscolare e fiducia.

Buona fortuna per il tuo impegno.