Sono sicuro che ormai hai visto i miei commenti e i miei altri post, quindi non farò finta di conoscere effettivamente la risposta. Il meglio che posso offrire è un riassunto di ciò che ho sentito / letto da altri e aggiungere un po 'della mia esperienza nel mix.
In primo luogo, voglio dire che poco fa mi sono imbattuto in un blog che appartiene a uno dei nostri membri programmatori SE, Martin Blore e IMO, questo post specifico sull'autorealizzazione di TDD è molto accurato. TDD è l'ultimo, il più alto livello che lega tutto, ma senza i livelli precedenti, in particolare il più grande, i principi e le pratiche di produzione di codice chiaro e leggibile, sarà molto difficile se non impossibile far funzionare TDD.
Nella mia azienda, sia l'Agile che il TDD ci sono stati imposti dal management, e all'inizio li abbiamo semplicemente fatti perché ci hanno detto (che è il contrario di Agile). Abbiamo provato TDD due volte e mentre sono un grande sostenitore dell'utilizzo di test automatizzati, ho personalmente eliminato tutti quelli che il team ha dato uno schiaffo nell'ultima versione. Erano fragili, giganteschi, copiati / incollati nel wazoo e pieni di dichiarazioni sul sonno che li facevano correre molto lentamente e imprevedibilmente. Il mio consiglio per la tua squadra: NON FARE TDD ... ancora.
Non so quale sia la tua situazione perché hai detto che sei stato con l'azienda per soli 6 mesi e che sei un appaltatore. I tuoi obiettivi a lungo termine sono di rimanere con questa azienda o il contratto sta per scadere? Sto chiedendo perché anche se fai qualcosa, potrebbe volerci un po 'di tempo per vedere effettivamente i risultati.
Inoltre, quando ti unisci a un team, di solito ci vuole tempo prima che tu abbia abbastanza credibilità e rispetto per il tuo team in cui loro (sviluppatori e management) prenderebbero in considerazione qualsiasi cosa tu proponga. Nella mia esperienza, aiuta se spegni pochi fuochi e dimostri di avere abilità e conoscenze su cui gli altri possono fare affidamento. Non sono sicuro che siano sufficienti 6 mesi. Abbastanza spesso una persona nuova e ambiziosa si unirebbe al team, quindi fare un post qui chiedendo come possono cambiare il mondo. La triste realtà è che semplicemente non possono.
Quindi supponendo che tu abbia il rispetto e l'attenzione della tua squadra. E adesso?
Innanzitutto, sia il management che gli sviluppatori devono essere consapevoli che esiste un problema. I risultati delle misure di gestione in termini di lavoro svolto. Se sono soddisfatti dell'attuale quantità e qualità delle funzionalità, la triste realtà è che non ascolteranno. Come altri hanno sottolineato, senza il supporto della direzione, sarà estremamente difficile introdurre qualsiasi tipo di cambiamento.
Una volta ottenuto il supporto di gestione, il passo successivo è quello di scavare in profondità e identificare le cause alla radice del perché il team opera in questo modo. Il prossimo argomento è qualcosa che è stata una mia ricerca personale per un po 'di tempo ormai. Finora questo è stato il mio viaggio:
- Una volta che hai il supporto della direzione. Puoi iniziare a introdurre molte pratiche / processi dettati centralmente che MainMa ha suggerito in risposta alla mia domanda . Ne abbiamo fatti molti (ad eccezione della programmazione abbinata) e sicuramente ne vedrai i benefici. Le revisioni del codice hanno contribuito in particolare a standardizzare lo stile, la documentazione e ci hanno anche permesso di condividere conoscenze / tecniche tra il team. Anche se le revisioni del codice sono state dettate, al team piacciono davvero e esaminiamo ogni funzionalità che viene archiviata. Tuttavia ...
- Si nota che il codice generalmente scritto è ancora troppo accoppiato, il design è errato o manca del tutto. Le recensioni del codice ne prendono parte, ma c'è solo così tanto che puoi riscrivere. Perché il design è cattivo in primo luogo? - Molti sviluppatori non sono mai stati introdotti alle buone pratiche e non sono mai stati istruiti formalmente su OOD in primo luogo. Molte persone "hanno semplicemente codificato" qualunque compito loro sia stato assegnato.
- Con il supporto della direzione è possibile introdurre più processi, ad esempio discutere della progettazione prima che avvenga qualsiasi codifica. Ma sei solo una persona e sembra che non prestando attenzione, il team ritorna a ciò che ha sempre fatto. Perché?
- È possibile introdurre e insegnare pratiche o abitudini migliori in modo da non doverle monitorare costantemente? - Sembra che questa parte non sia così semplice.
- Perché gli altri membri del team sono riluttanti ad apprendere e raccogliere nuove pratiche e perché sono così resistenti a SOLID o DRY quando è stato scritto così tanto nella moderna letteratura sulla metodologia del software? Con tutti i cambiamenti positivi che abbiamo avuto nella mia squadra, 2 settimane fa ho avuto una discussione erano ho refactoring 2 funzioni che hanno avuto identiche 15 righe di codice e il recensore ha chiamato eroica, uno sforzo inutile perché non c'è niente di sbagliato con copia / incolla di solo 15 righe. Non sono assolutamente d'accordo con tali opinioni, ma per ora abbiamo deciso di accettare di non essere d'accordo. -- E ora? Ora abbiamo raggiunto l'argomento del mio altro post .
- Come maple_shaft e nikie hanno sottolineato nelle loro risposte (scusate, MainMa , hai ottenuto il maggior numero di voti, ma sei così 5 passi indietro :)), hai raggiunto un punto in cui il "processo" non può più aiutare te e nessuno in questo forum posso dirti qual è la "correzione". Il prossimo passo è avvicinarsi agli individui, forse uno contro uno, forse come una squadra, probabilmente sia una volta che l'altra e parlare con loro. Chiedi loro, cosa funziona e cosa no. L'unico modo per identificare la causa principale di ciò che li spinge ora è parlare con loro individualmente e scoprirlo. Come parte di questo passaggio, di recente ho riscontrato un problema di squadra completamente diverso, ma penso che la risposta di Joel qui, che è molto dettagliato e approfondito, si applicherebbe anche a questo caso. In sintesi, mentre usare la gestione come "guinzaglio corto" è un possibile approccio a qualsiasi cosa, dobbiamo ricordare che abbiamo a che fare con gli esseri umani in modo da comprendere veramente le motivazioni che dobbiamo attraversare più nella psicoanalisi che nella gestione pura o nella leadership tecnica.
- Quindi adesso stai parlando con i tuoi compagni di squadra? Cosa chiedi loro? Non sono sicuro di questa prossima parte perché non sono mai stato qui. Ecco uno scenario possibile: D: Come mai nessun SOLID? A: Non ne ho bisogno. D: Potrebbe essere d'aiuto. A: Faccio bene così com'è. - in qualche modo devi generare una serie di suoni che lascerebbero la tua bocca e indurre l'ascoltatore a riconoscere che le cose potrebbero andare meglio se danno a qualsiasi cosa tu stia offrendo. Se fallisci qui, non saranno mai convinti che qualunque "processo" li faccia fare effettivamente ha alcun valore. D'altra parte, se superi questo punto, probabilmente scoprirai che non hai nemmeno più bisogno del "processo".
- Alla radice dell'IMO, i tuoi compagni di squadra non impareranno se non vedono nulla di sbagliato nelle loro attuali abitudini / pratiche. Quindi forse il prossimo passo in tutto questo è trovare un modo per illustrare, evidenziare i problemi e renderli ovvi. Dopotutto, non stiamo scrivendo codice leggibile, usando i principi SOLID / DRY o mantenendo la documentazione solo perché ci dà una sensazione calda e confusa. Lo facciamo perché produce un codice di qualità migliore e francamente ci rende il codice più veloce. Può essere misurato? Forse è qui che entrano in gioco le metriche del software?
- Ecco un'idea folle e non ho idea se funzionerebbe davvero (potrebbe essere una pratica standard del settore, o forse completamente non valida. L'ho appena inventato nelle ultime 24 ore), ma sono molto tentato di portarlo al tavolo non appena inizia il prossimo anno:
- Contro le opinioni di molti altri , introdurre l'idea di autore / proprietario per tutti i file di origine. Come suggerisce il programmatore pragmatico, questo darà un senso di proprietà e responsabilità a una singola persona che sarà responsabile di un pezzo di codice sorgente. Ciò non significa che altre persone non possano modificare il codice, stiamo tutti lavorando come una squadra, ma alla fine della giornata, la persona che possiede il codice è responsabile della revisione delle modifiche.
- Crea un trigger di repository di origine che monitora tutti i check-in e cerca specificamente quelli che sono correzioni di bug. Trasformalo in un processo in modo che ogni correzione di bug abbia un identificatore di riferimento nella descrizione del check-in. Ora scrivi uno script che analizzerebbe un elenco di file che sono stati modificati e rimuovendo "Autore" dal blocco di commenti dell'intestazione del file. Creare un database SQL che traccia il numero di difetti registrati per file / per progetto / per autore.
- Una volta che hai abbastanza statistiche, si spera che noterai che il tuo codice ha meno difetti / modifiche rispetto ad alcuni degli altri codici. Questi sono dati concreti che puoi usare. Se un singolo progetto ha un tasso di difetti significativamente superiore alla media, presentalo come candidato per il prossimo sforzo di pulizia / refactoring per ripagare alcuni debiti tecnici.
- Se un progetto o un file ha una percentuale di difetti significativamente superiore alla media e ha un proprietario, parla uno contro uno con quella persona. Chiedi loro, in modo molto educato, non conflittuale cosa possono fare per affrontare questo problema. Dal momento che sono il proprietario, dovrebbero guidare il cambiamento, ma offrire qualsiasi aiuto dalla tua parte. Si spera che il proprietario rintraccierà molte delle cause nel proprio codice spaghetti e non appena chiederà aiuto, sarà allora che entrerai in azione e metti del SOLIDO.