Finora deve essere una combinazione ragionevole di tutte le risposte. Alla fine, quando parli di un gruppo di persone intelligenti (sviluppatori), devi dare loro ragioni per cui il comportamento è importante e dare loro un controllo sufficiente su come quel comportamento viene implementato da essere investito nel farlo nel modo giusto. I mandati dall'alto sono generalmente sciolti con le persone intelligenti, perché se non hanno concordato che il problema è un problema, è probabile che trascorrano più tempo a lavorare attorno al mandato che a seguire la regola.
Ecco alcune delle mie tattiche:
Commettere modifiche:
Innanzitutto, il team deve concordare quando impegnarsi e cosa impegnare. Assolutamente essenziale è un'impostazione di costruzione che abbia un senso, in modo che le persone non resistano solo perché non sanno dove mettere qualcosa. E un consenso su quando / quanto spesso effettuare il check-in. "Non interrompere la build" è una buona regola ovvia, ma come viene verificato e chi viene informato? Un'altra linea di base è "non viene eseguita se non è stata effettuata la registrazione".
La maggior parte degli sviluppatori che conosco sono più che felici di controllare il codice IF:
- Il processo di check-in è semplice
- Il processo di sincronizzazione è semplice (factoring nelle modifiche di altri sviluppatori)
- Vedere le modifiche e spostarsi tra le versioni è facile
Una cosa che ho notato di recente è che i check-in sono diventati più frequenti e meno dolorosi quando siamo passati a un nuovo strumento CM. Il nostro team è pionieristico al Rational Team Concert dopo aver usato Clearcase. Non intendo pubblicizzare strumenti, ma la nuova ondata (per me) di check-in in streaming con un sacco di piccole e veloci fusioni rende molto più allettante il check-in anticipato e spesso.
Lasciare che gli sviluppatori si occupino dell'eliminazione del dolore da CM generalmente aumenta la quantità di check-in che accade.
Aderendo all'architettura - Non scrivere i problemi del modello in viste e controller
Lo sto mettendo nel gruppo di "fare l'architettura correttamente". Sono d'accordo con chiunque abbia detto recensioni dei pari - la pressione dei pari è ottima per questo. Uno dei modi in cui generalmente vedo le persone entrare in gioco per le migliori pratiche in quest'area è quando i loro colleghi chiedono loro perché l'hanno fatto nell'altro modo (il modo non così giusto). Generalmente la domanda "perché" condurrà le persone lungo il percorso di rendersi conto da sole perché avrebbero dovuto farlo diversamente. Quando le persone hanno una ragione ben compresa per la migliore pratica, è molto più facile aderirvi.
Inoltre, se c'è una qualche formalità che collega una persona a una decisione, allora può essere più facile assegnare bug in quella zona ... quindi se una persona è responsabile per la correzione di bug in un'area di progettazione difettosa, la necessità di ottenere qualcosa prima possono passare a qualcosa di nuovo ed eccitante può essere un grande motivatore.
Evitare l'hardcoding
Comincerei con chiari standard di codifica e integrando una revisione standard di codifica nelle revisioni tra pari. La codifica hardware è una di quelle cose che possono essere facilmente una casella di spunta in un'agenda di peer review.
Temo che questo genere di cose sia l'unica cosa in cui l'ho visto diventare il ruolo del team che ha portato all'applicazione della regola. Nei team che ho gestito, generalmente non permetteremo a qualcuno di andare avanti fino a quando non avranno corretto i commenti da una revisione tra pari del loro codice. E "no hard coding" è un commento frequente di peer review.
In generale
Con quasi tutte le migliori pratiche, penso che devi scegliere le tue battaglie. Nessuna squadra diventerà assolutamente perfetta. Ma puoi tenere d'occhio i tuoi principali punti di dolore e iniziare ad affrontarli in gruppi. Penso che diventi il ruolo del leader sapere davvero qual è il punto dolente per la squadra rispetto a una seccatura fastidiosa di un particolare individuo.
Se la tua squadra si sta perdendo nel fare una buona pratica particolare, penso che la prima domanda debba essere "quanti danni sta causando?" se la risposta è "minima", probabilmente non vale la pena. Alcune buone pratiche sono più rilevanti per specifici tipi di sistemi - sebbene siano nel complesso buone, potrebbero non valere la pena di combattere per sistemi in cui la pratica non è un evento frequente o una parte importante del sistema.
Se la risposta a "quanto danno?" è "MOLTO !!!", quindi puoi iniziare a costruire un caso per mostrare alla squadra che tutto questo dolore e sofferenza potrebbero essere rimossi fissando questo punto debole nelle migliori pratiche. Molte persone sono felici di evitare il dolore e la sofferenza e cambia il dialogo da "fai questo perché te l'ho detto", a "abbiamo deciso di farlo perché è meglio".