Come posso convincere i programmatori di cowboy a usare il controllo del codice sorgente?

AGGIORNAMENTO
Lavoro su una piccola squadra di sviluppatori, 4 ragazzi. Hanno usato tutti il ​​controllo del codice sorgente. La maggior parte di loro non sopporta il controllo del codice sorgente e preferisce invece non utilizzarlo. Credo fermamente che il controllo delle fonti sia una parte necessaria dello sviluppo professionale. Numerosi problemi rendono molto difficile convincerli a utilizzare il controllo del codice sorgente:

• Il team non è abituato a utilizzare TFS . Ho avuto 2 sessioni di allenamento, ma mi è stata assegnata solo 1 ora, il che è insufficiente.
• I membri del team modificano direttamente il codice sul server. Ciò mantiene il codice non sincronizzato. Richiede un confronto solo per essere sicuri di lavorare con l'ultimo codice. E sorgono complessi problemi di unione
• Le stime dei tempi offerte dagli sviluppatori escludono il tempo necessario per risolvere questi problemi. Quindi, se dico che non ci vorrà 10 volte di più ... Devo spiegare costantemente questi problemi e rischiare me stesso perché ora il management può percepirmi come "lento".
• I file fisici sul server differiscono in modo sconosciuto per ~ 100 file. La fusione richiede la conoscenza del progetto in corso e, quindi, la cooperazione con gli sviluppatori che non sono in grado di ottenere.
• Altri progetti non sono sincronizzati. Gli sviluppatori continuano a non fidarsi del controllo del codice sorgente e quindi aggravano il problema non utilizzando il controllo del codice sorgente.
• Gli sviluppatori sostengono che l'utilizzo del controllo del codice sorgente è dispendioso perché la fusione è soggetta a errori e difficile. Questo è un punto difficile da argomentare, perché quando il controllo del codice sorgente viene utilizzato in modo così errato e il controllo del codice sorgente viene continuamente bypassato, è effettivamente soggetto a errori. Pertanto, l'evidenza "parla da sé" a loro avviso.
• Gli sviluppatori sostengono che la modifica diretta del codice del server, bypassando TFS, consente di risparmiare tempo. Anche questo è difficile da discutere. Perché l'unione richiesta per sincronizzare il codice con cui iniziare richiede molto tempo. Moltiplicalo per i 10+ progetti che gestiamo.
• I file permanenti sono spesso memorizzati nella stessa directory del progetto Web. Quindi la pubblicazione (pubblicazione completa) cancella questi file che non sono nel controllo del codice sorgente. Ciò inoltre diffonde sfiducia nel controllo del codice sorgente. Perché "la pubblicazione rompe il progetto". Risolvere questo problema (spostare i file memorizzati dalle sottocartelle della soluzione) richiede molto tempo e debug poiché queste posizioni non sono impostate in web.config e spesso esistono su più punti di codice.

Quindi, la cultura persiste. Le cattive pratiche generano altre cattive pratiche. Le cattive soluzioni spingono i nuovi hack a "risolvere" problemi molto più profondi e molto più lunghi. Server, spazio sul disco rigido sono estremamente difficili da trovare. Tuttavia, le aspettative degli utenti sono in aumento.

Cosa si può fare in questa situazione?

Non è un problema di formazione, è un problema di fattori umani. Non vogliono e stanno creando blocchi stradali. Affronta le dinamiche di gruppo rotte, qual è la causa principale della loro obiezione - di solito la paura, è solo la paura del cambiamento o è più sinistra.

Nessuno sviluppatore professionista oggi, o negli ultimi 20 anni, ha resistito al controllo del codice sorgente. Una volta, circa 30 o 40 anni fa, quando i computer erano lenti, il controllo del codice sorgente era ancora più lento e i programmi consistevano in un file da 500 righe, era una seccatura e c'erano validi motivi per non usarlo. Queste obiezioni possono provenire solo dal peggior tipo di cowboy che mi viene in mente.

Il sistema è costretto a renderli in qualche modo difficili? Scopri di cosa si tratta e modifica il sistema per invalidare l'obiezione. Ripeti fino al termine.

Suggerisco di guardare GIT o Mercurial. Puoi creare un repository in ogni albero del codice sorgente, non se ne accorgeranno nemmeno e potranno continuare a hackerare come fanno ora. Puoi tenere traccia delle modifiche che hanno hackerato nella base di codice, effettuare commit, unirle in altri alberi dei sorgenti, ecc. Quando ti vedono fare una fusione di settimane di sforzi in un altro prodotto in pochi secondi, potrebbero cambiare le loro idee. Quando tiri indietro una delle loro cazzate con un comando e salvi il culo, potrebbero persino ringraziarti (non contare su di esso). Nel peggiore dei casi, hai un bell'aspetto di fronte al capo e, per un bonus, li fai sembrare i cowboy che sono.

La fusione richiederebbe non solo una grande conoscenza del progetto

In quel caso, temo che tu sia nel proverbiale torrente senza pagaia. Se l'unione non è un'opzione, né la sta implementando, quindi stai dicendo che non puoi più aggiungere funzionalità che hai già in un ramo (termine usato in modo approssimativo) a un altro.

Se fossi in te riconsidererei le mie prospettive di carriera ...

A volte, i problemi del mondo reale lo rendono poco pratico da usare.

Falso.

Se il team non è abituato a utilizzare il controllo del codice sorgente, possono sorgere problemi di allenamento

Ciò non ha nulla a che fare con il controllo del codice sorgente e tutto ciò che riguarda la formazione. La formazione è facile, economica, efficiente e eseguita nel giro di poche ore. Non utilizzare il controllo del codice sorgente è costoso, rischioso, inefficiente e i problemi persistono per sempre .

Se un membro del team modifica direttamente il codice sul server, possono sorgere vari problemi.

Questo è il problema della formazione. Ancora. Niente a che fare con il controllo del codice sorgente e tutto a che fare con la formazione.

Gli sviluppatori continuano a non fidarsi del controllo del codice sorgente e quindi aggravano il problema non utilizzando il controllo del codice sorgente

Devono essere addestrati su come utilizzare il controllo del codice sorgente. Riduce i costi, riduce i rischi, semplifica le cose ed è più efficiente. È un investimento una tantum che paga dividendi in ogni momento.

Cosa si può fare in questo tipo di situazione?

Inizia a formare tutti su come utilizzare il controllo del codice sorgente.

Aggiornare

Gli sviluppatori sostengono che la modifica diretta del controllo del codice sorgente consente di risparmiare tempo.

Poiché hanno torto, è importante raccogliere dati per dimostrare con precisione quanto sia sbagliato.

Purtroppo, tuttavia, il management sembra premiare una risposta immediata che è costosa a lungo termine.

L'unico modo per superare questo sistema di ricompensa è farlo

A) Identificare che il costo a lungo termine è superiore al valore apparente a breve termine.

B) Identificare i premi effettivi che sono effettivamente in atto che fanno apparire la corruzione a breve termine (cioè i cambiamenti diretti) più preziosi del controllo del codice sorgente corretto a lungo termine. Chi ottiene una pacca sulla testa per aver fatto la cosa sbagliata? Che tipo di pacca sulla testa ottengono? Chi lo dà? Al fine di risolvere le cose, è necessario nominare le cose che sono sbagliate e il / i manager / i specifico / i che sta (stanno) effettivamente incoraggiando la gente.

C) Raccomandare un sistema di ricompensa rivisto che valorizzi il valore a lungo termine anziché la risposta rapida a breve termine. Diverse carezze sulla testa per diversi motivi.

D) Addestra la gente nelle ricompense che hai trovato per un valore a lungo termine; valore che è chiaramente maggiore della risposta rapida a breve termine.

Gli sviluppatori che rifiutano di utilizzare il controllo del codice sorgente / versione dovrebbero essere licenziati, così semplice. Come hai già sottolineato, i rischi e i costi intrinseci di NON utilizzarlo superano qualsiasi sovraccarico che incorre in molti, molti ordini di grandezza. Chiunque cerchi di argomentare contro questo semplicemente non dovrebbe essere coinvolto nello sviluppo di software e rifiuterei categoricamente di lavorare con queste persone.

Per prima cosa abbiamo risolto il problema, configurando un server di integrazione continua per sviluppare il nostro controllo del codice sorgente in sviluppo. In secondo luogo, bloccare l'accesso alle cartelle in sola lettura, per impedire alle persone di eludere il controllo del codice sorgente e modificare direttamente i file.

È un PITA nei giorni in cui non è possibile riprodurre il bug localmente, ma a parte questo è più bello poter lavorare, archiviare e andare avanti, sapendo che verrà spinto a svilupparsi automaticamente dal server CI.

Sento il tuo dolore. Sono entrato in un paio di posti di lavoro per scoprire che "controllo del codice sorgente" era una cartella condivisa su un'unità di rete. Il problema generalmente non è perché credono che l'approccio sia superiore a qualsiasi altra cosa, semplicemente funziona e non sono mai stati introdotti in un flusso di lavoro che integri con successo il controllo del codice sorgente.

Con la struttura della squadra di terra piatta che hai spiegato, ottenere il cambiamento dall'alto in basso potrebbe non essere il modo migliore per affrontare la situazione. Un metodo che vale la pena provare è quello di acquistare direttamente da uno o due degli altri sviluppatori per consentire al concetto di acquisire slancio. Una volta che hai anche un altro sviluppatore a bordo, sarà molto più facile diffonderlo al resto della squadra. Introducili lentamente al concetto, ad esempio inizia a lavorare su un piccolo progetto laterale, mettilo in pratica in Git o addirittura dirama qualcosa ospitato su GitHub .

Inizia in modo semplice, introduci i concetti lentamente e separatamente dal loro flusso di lavoro quotidiano. Gli esseri umani sono bravi nell'apprendimento delle cose e nell'adattarsi al cambiamento, specialmente quando quel cambiamento fornisce loro benefici diretti (pensa all'evoluzione). Tuttavia, quando viene presentato con un sacco di piccoli cambiamenti contemporaneamente diventa alienante. Una volta che hanno capito come funziona il controllo del codice sorgente e i vantaggi che offre, allora prova a integrarlo in uno dei tuoi progetti interni (se avvii un nuovo progetto, questo è un momento malvagio per introdurlo). Lascia che anche gli altri progetti funzionino nel modo esistente, se lo desideri, questo sarà particolarmente efficace per evidenziare i vantaggi del controllo del codice decente.

Se fallisce, corri.

Ovviamente hai le capacità tecniche per identificare e risolvere la tua situazione, i tuoi problemi sono umani e legati al processo.

Le persone tendono a rispondere molto meglio all'esempio che alla visione, quindi suggerirei di "aggiustarlo" da solo:

Prendi una copia dell'ultima fonte, ristrutturala per renderla compatibile con il controllo della versione, crea un nuovo progetto con una struttura utile e orientata al futuro (scopri come gestirai i rami, dove metti dipendenze di terze parti ecc.). Probabilmente dovrai farlo nel tuo tempo libero.

Quindi trascina i tuoi colleghi e i tuoi dirigenti in una stanza e mostra loro come si presenta lo sviluppo del software nel 21 ° secolo. Illustra i guasti con il tuo sistema attuale e mostra come vengono eliminati con la tua nuova struttura.

Dovrai anche impostarti come Custode della Sorgente - poiché sembri essere l'unico a cui importa, spetta a te costringere le persone (con qualsiasi mezzo tecnico o psicologico a tua disposizione) a cui attenersi il piano. Assicurati che l' unica cosa che va a un cliente provenga da una macchina di generazione fuori dal controllo del codice sorgente. Umilia ritualmente le persone che infrangono le regole e causano il caos. Corrompili con le ciambelle ... qualunque cosa funzioni.

Se tutto ciò sembra troppo sforzo (come è stato detto in quasi tutte le altre risposte) - ottenere un altro lavoro. Non valgono il tuo tempo.

Passaggio 1: licenzia il manager incompetente!

Se non è possibile eseguire il passaggio 1, provare a convincere il gestore a limitare la distribuzione per produrre solo script presi dal controllo del codice sorgente. Se gli sviluppatori (che non dovrebbero avere diritti di produzione su prod, vedere il passaggio 1 se lo fanno) vogliono che i loro contenuti vengano distribuiti, devono provenire dal controllo del codice sorgente. Ciò ha risolto il nostro problema di non utilizzare il controllo del codice sorgente abbastanza bene quando abbiamo iniziato a usarlo per roba di database e codice C #.

Come può qualcuno non desiderare versioni diverse dei propri file e la possibilità di vedere le differenze? Dimentica la ramificazione e tutte le cose complesse. Non capiscono nemmeno le basi. La modifica diretta di un file di produzione senza apportare le modifiche più rudimentali in un ambiente di test è folle. Ho lavorato con alcune persone e per fortuna non abbiamo mai lavorato agli stessi progetti.

I tuoi colleghi sono troppo stupidi per essere pigri. È una perdita di tempo. Tutto quello che puoi sperare di fare è formare il tuo manager. Alla gestione dovrebbe piacere il controllo del codice sorgente perché a loro piacciono tutte le forme di controllo. Li fa sentire importanti. Vite gli altri; riparare il leader è la tua unica speranza poiché non puoi sostituirlo. Inizia a lavorare in rete con altri sviluppatori competenti e cerca di farli unire al tuo team quando hai un'apertura o farli assumere nel loro negozio.

Questo è un buon esempio di un progetto in cui le cattive pratiche sono state utilizzate in modo così pervasivo che diventa praticamente impossibile risolverlo. Ripararlo richiederebbe un blocco, quindi tutto può essere ripulito senza interruzioni. Sfortunatamente, tali progetti di solito sono (per ovvi motivi) troppo buggy per essere congelati per diversi mesi, i bug critici devono essere corretti a giorni alterni.

Potresti essere tentato di fork il progetto per creare una versione pulita mentre la versione sporca viene trattata con quelle correzioni quotidiane; ma il risultato più probabile è che dopo diversi mesi, quando la versione "pulita" è terminata, nessuno può dirti quali correzioni e modifiche sono state incorporate dopo il fork (perché la stessa mentalità che consente alle persone di scivolare in tali pratiche rende improbabile che tengono un registro delle modifiche apportate). La versione pulita è obsoleta, la versione sporca funziona ancora, quindi cosa succede? La versione pulita viene scaricata, i giorni dimostrati giusti.

Oltre all'ovvio Trova un nuovo lavoro, penso che la risposta sia più di tutto quanto sopra.

Per prima cosa, vai alla direzione per coinvolgerli nel passaggio e nell'applicazione del controllo del codice sorgente. Quindi vai a quello che deve essere fatto per mantenere le cose in esecuzione, anche se ciò significa lavorare direttamente sul server. Inizia il processo per ottenere tutto nel controllo del codice sorgente.

Un'altra opzione è assicurarsi che l'ultimo sia sul server (cosa che devi fare indipendentemente) e avviare un nuovo repository dal più recente. Perderai la storia, ma a questo punto sono piccole patate.

Dalla tua descrizione sembra che ci siano uno o più problemi con la situazione: o il team di sviluppo è fuori controllo o è stata implementata una soluzione di controllo del codice sorgente errata. In entrambi i casi, spetta al team di sviluppo utilizzare una soluzione di controllo del codice sorgente: la modifica diretta del codice sorgente nel servizio di produzione richiede solo che si verifichino problemi.

Dalla mia esperienza, il primo passo che deve avvenire immediatamente è sincronizzare il controllo del codice sorgente con il server di produzione. Questo passaggio può essere semplice come prendere una copia del codice di produzione e controllarlo: il codice di produzione è presumibilmente la base che il tuo team sta sviluppando. Potrebbe essere necessario aumentare questo passaggio di un'unione con il codice che fluttua nel sistema di controllo del codice sorgente esistente. Il codice dovrebbe fluire dallo sviluppatore all'integrazione / QA (o entrambi) e quindi allo stadio o allo stadio / produzione.

Successivamente, la direzione deve imporre l'uso del controllo del codice sorgente. Molto semplicemente, se la build non proveniva dal sistema di controllo del codice sorgente, il codice non dovrebbe essere distribuito alla produzione. L'accesso alla produzione deve essere limitato al solo team di supporto, con un accesso limitato concesso agli sviluppatori per risolvere i problemi di produzione. Gli sviluppatori in genere non dovrebbero mai effettuare distribuzioni a caldo del codice per la produzione - i problemi di produzione potrebbero sicuramente verificarsi, in particolare se gli sviluppatori sono sotto pressione.

Il management ha sicuramente bisogno di avere una migliore gestione dei problemi qui - sarà quasi impossibile sostenere lo sviluppo se il codice viene applicato per produrre direttamente (e non entrare nel controllo del codice sorgente).

Il vero problema non è che i programmatori di cowboy non usano il controllo di versione. Il vero problema è che hanno già scelto un modo di fare le cose e tu stai cercando di cambiare il loro processo. Il processo scelto non include il controllo della versione. Tutte le modifiche al processo sono difficili, a meno che i programmatori stessi non notino un problema. Se si ha la sensazione che il sistema esistente sia abbastanza buono, cercare di imporre un sistema diverso è semplicemente inutile. Noi siamo i borg, sarai assimilato. Ovviamente stanno cercando di combattere diventando borg.

Per la tua sanità mentale, suggerirei di configurare Git o un altro DVCS sul tuo computer in modo da poter tenere traccia delle modifiche. Importa spesso le modifiche dei tuoi colleghi nel tuo repository. Risolvi i conflitti nel miglior modo possibile. Questo ti proteggerà parzialmente dalla follia dei tuoi colleghi.

Hai detto che la direzione ha affermato che gli sviluppatori dovrebbero usare il controllo del codice sorgente. Se vuoi essere cattivo, puoi applicarlo controllando le modifiche in TFS e pubblicando periodicamente il repository, bloccando in tal modo eventuali modifiche che non sono in TFS. (Se stai anche mantenendo il tuo DVCS, dovresti mantenere i due sincronizzati.) La tua giustificazione per farlo è che stai seguendo gli ordini dalla direzione. Se i tuoi colleghi si stancano di sovrascrivere i loro cambiamenti, invitali a usare TFS. E continua ad alterare le modifiche che non sono state registrate. Continua fino a quando i tuoi colleghi non si sono ritirati o non vieni licenziato.

Bloccare qualsiasi server diverso dal loro sviluppo. Usa un gestore della configurazione. Esegui build identificabili regolari (rispetto ai tag). Contrassegna ogni set di modifiche (ovvero 1 set di modifiche per bug). Mettiamo anche un tag su ogni build. Avere un sistema di tipo QA tra sviluppo e produzione (almeno). Crea build per il sistema di controllo qualità utilizzando il tag build corretto. Dai loro dolore per "aver rotto la build".

Non ho mai incontrato una situazione in cui non potevo ricreare / risolvere un problema (che mostra solo sulla produzione). Sì, ho impiegato ore a far ricreare il problema su un sistema di sviluppo (inoltre quando lo capisci puoi aggiungerlo al test di regressione).

Abbiamo fatto un progetto con un gruppo di appaltatori di cowboy che hanno fatto tutte quelle cose cattive. Dopodiché trascorro 4 settimane a ripulire e poi metto in atto le pratiche di cui sopra. Da allora il progetto non ha avuto problemi con nessuna di queste cose.

Citazione:

Il team non è abituato a utilizzare TFS

TFS risulta essere Microsoft Team Foundation Server.

Il mio primo istinto dice: "questa è l'ultima versione di Microsoft Visual SourceSafe"

Sarei dalla parte di voi colleghi e andrei davvero contro questo.