Coinvolgi il team

le persone resistono al cambiamento

le persone resistono al cambiamento che iniziano, anche quando sono benefiche

ma le persone in realtà resistono ai cambiamenti che sono scottanti su di loro

e le persone con veemenza resistono ai cambiamenti che sono scottanti su di loro con l'implicazione che sono sbagliati / allentati / non abbastanza buoni / etc

Se vuoi che il processo delle "migliori pratiche" fallisca - e fallisca duro - continua a dipingere te stesso come il bello eroe, tutti gli altri come stupidi e dolcetti, e chiama ogni suggerimento che fai "meglio" . La gente ama l'implicazione di essere inferiori, li motiva davvero ad ascoltare le tue idee in modo obiettivo. non

D'altra parte, se vuoi che abbia successo, prendi una lezione dal Manifesto Agile e lascia che il team si auto-organizzi e selezioni da sé i processi che sono appropriati, con le strade per un miglioramento incrementale

In altre parole, non puoi scegliere le migliori pratiche per il team, né possiamo , perché le migliori pratiche sono quelle che si adattano al team e che il team accetterà

Non puoi avviare processi se nessun altro ascolterà. Questa è la realtà triste e dura. TU potrebbe sapere che cosa rende un buon codice e un design di qualità che costituisce una base adeguata per il futuro, ma se sei l'unico, allora è condannato, e nessun tentativo di cambiare le cose lo risolverà. Se le persone volessero aggiustarlo, non avresti dovuto chiedere come implementare un processo perché tutti gli altri sarebbero a bordo con te o avrebbero già provato prima hai avuto l'idea di provare a persuaderli .

So di trotterellare questa vecchia sega ogni volta che viene pubblicato un post come questo, ma essendo stato in situazioni come questa per quasi tutta la mia carriera l'unico risultato finale è stato il mio essere terminato a causa del voler migliorare le cose e costantemente cercando di tirarlo su (anche sottilmente), o di essere frustrato dal fatto che nessuno tranne io voglia migliorare le cose o, spesso nella mia esperienza, sa anche come migliorare le cose e smettere dopo un paio di mesi di frustrazione e "Perché nessuno è mai a conoscenza di modi migliori?" momenti.

Ora, offrirò un certo ottimismo. Se, e solo se, altri nella tua squadra (almeno un'altra persona, quindi non è solo te - altrimenti sembra che tu stia solo piagnucolando invece di cercare di dare una mano), allora puoi iniziare lentamente. Scrivi il tuo codice correttamente, ovviamente. Richiama problemi di scarsa qualità durante le riunioni o le revisioni del codice se li fai con altri sviluppatori (ad es. Cose come "Questo metodo è lungo 1000 righe, dovrebbe essere suddiviso" o "Dovremmo suddividere queste quattro pagine / schermate in componenti riutilizzabili quindi non duplichiamo il codice "). devi iniziare lentamente, e tu devi averlo acquistato da altre persone, altrimenti ti brucerai e rimpiangerai di venire in ufficio tutti i giorni.

Tutti i principi e le migliori pratiche del mondo non aiuteranno nessuno se le persone sopra di te non acquistano l'idea o se non le interessano veramente. Con quello che hai detto hai menzionato "i suggerimenti di base vengono ignorati", il che significa che a loro non interessa quello che hai da dire sul processo.

Questo non è necessariamente perché sono persone cattive, forse solo perché sono sovraccarichi di lavoro e incredibilmente stressati da "clienti importanti che urlano contro di loro" che semplicemente non hanno il tempo di fare un processo che è buono abbastanza la maggior parte del tempo per intrattenere la nozione di stabilire un processo eccellente tutto il tempo. Gestire un'impresa è a volte una cosa sporca, quindi il cambiamento deve essere incrementale e le persone che lo spingono devono essere persistenti e pazienti.

Detto questo, le recensioni del codice non devono essere coinvolte nei lead o nei manager, infatti a volte è meglio se non sono coinvolti affatto. Ottenere due coetanei ed uguali insieme per rivedere un nuovo modulo fa SIA gli sviluppatori che pensano in modo critico al codice e che gestiscono le "migliori pratiche" nella loro mente, anche se questo è normalmente considerato uno sviluppatore BAD, questa persona sarà costretta a considerare le pratiche da in realtà a giudicare su di loro. Scoprirai che le persone che resistono a pratiche consolidate inizieranno presto a cambiare il loro comportamento di codifica per evitare critiche nelle revisioni del codice. Inoltre promuove la leadership tra i membri del team, supporta la proprietà di una funzione e migliora la qualità del codice.

Le revisioni del codice migliorano la qualità dello SVILUPPATORE, e la parte migliore è che i tuoi superiori diretti che sono impegnati a spegnere gli incendi hanno bisogno di un coinvolgimento minimo.

Consiglio vivamente di acquistare un paio di copie dell'eccellente libro di Martin Fowler su refactoring . I principi in là possono essere applicati anche al punto di partenza nel tuo codice base è un casino completo (anche se è più semplice se c'è qualche struttura).

Per ottenere qualche chilometraggio dal refactoring, però, probabilmente dovrai anche iniziare a implementare test unitari e test di integrazione automatica, in modo da poter sperimentare con il tuo codice base senza essere pietrificato tutto il tempo che non hai idea di cosa si romperà se cambi questo o quel bit.

Puoi introdurlo da solo e aspettare che gli altri si meravigliino di come tu stia improvvisamente iniziando a raggiungere l'iper-produttività (perché è lì che stai andando), e poi seguirti. O potresti parlare con alcune anime simpatiche e convincerle a unirsi a te. Oppure potresti provare a presentare questo alla squadra nel suo complesso. Ovviamente il meglio sarebbe se il tuo caposquadra / maestro di mischia / chiunque fosse al comando raccolga la tua idea (e che di solito funzioni meglio se (s) pensi sia la sua idea!) E corri con essa.

Ovviamente puoi fare revisioni del codice. Ma ti prometto che, una volta che il tuo codice base sarà coperto da test unitari, non li farai più a lungo, se non per assicurarti che il codice di tutti sia conforme alle stesse regole di stile.

Come coinvolgere le persone? Hmm, difficile. Avrei pensato che anche le persone che lo fanno per i soldi sono almeno interessate a mantenere il loro lavoro. Quindi, se sei in una posizione di potere, forse vuoi metterli a sedere e fargli capire che lavorare in una squadra significa essere coinvolti, e se non possono o non vogliono farlo, c'è una discrepanza tra loro e il lavoro spec.
Per tutti gli altri è probabilmente meglio fare un po 'di lavoro da solo e quindi presentare i risultati. Questo dovrebbe farli interessare. E visto che lo stai già facendo, tutto ciò che devi veramente fare è venderlo a loro. Prepara una piccola demo di come funzionano bene i tuoi test unitari e cosa ti permettono di fare. Dimostrare il refactoring. Illustrare i risparmi di tempo.

Il solito problema è che molto spesso i bravi programmatori sono cattivi venditori (e viceversa. Lo so perché sono stato in entrambi i campi). E ora ti sto chiedendo di diventare un venditore. Considerando che molto probabilmente tutti gli altri membri della tua squadra sono un venditore di vendite peggiore di una vigilia (altrimenti pubblicherebbero qui invece di te), dovresti avere un certo successo anche se non fai un brillante lavoro di vendita.

BTW: il geniale programmatore che è troppo impegnato a spiegarsi è in realtà più responsabile (si pensi allo scenario "hit-by-the-bus"). Per lo meno in assoluto ha bisogno di documentare il suo codice, altrimenti potrebbe anche sbarazzarsi di lui ora. Ricorda che non scrivi codice per il computer. Scrivi il codice in modo che altri programmatori possano leggerlo e capirlo. Il computer può essere alimentato con un flusso di byte compilato, non interessa i linguaggi di programmazione o la sintassi o altro.