Come incoraggiare l'adozione del controllo di versione

Devi creare un caso per l'uso del controllo della versione e provare prima a venderlo ai tuoi colleghi di lavoro, e se ciò fallisce, vai avanti per proiettare la leadership e più in alto.

Per gli altri ingegneri del software, il tuo caso dovrebbe concentrarsi su come risparmiare tempo e mal di testa a lungo termine. Trova le ore del tuo passato o delle storie pubblicate (blog, articoli su riviste, libri bianchi) su come l'uso del controllo della versione ti semplifica la vita. Se sei stato bruciato non avendo il controllo della versione, renderlo personale. Se i tuoi colleghi sviluppatori si trovano nella stessa situazione, dovrebbero vedere la luce e come questi strumenti possono aiutarli.

Questa è la soluzione migliore. Anche se non riesco a trovare la fonte (s) in questo momento, ho letto (in un paio di punti) che i cambiamenti più efficaci da elaborare provengono dagli sviluppatori, che devono affrontare le modifiche. Se riesci a portare gli sviluppatori a bordo, ottieni due cose. Primo, hai già il buy-in da parte delle persone che saranno interessate dal cambiamento del processo. Secondo, c'è un gruppo di persone per convincere il management che questo è uno sforzo proficuo e migliorerà il prodotto e il progetto.

Tuttavia, se non riesci a ottenere il supporto del team di sviluppo e ancora ti senti incredibilmente a favore dell'implementazione del controllo di versione, puoi passare alla gestione. Ma diventa più rischioso se stai andando da solo, dal momento che non devi solo preoccuparti di vendere il miglioramento, ma anche di gestire i contraccolpi dei tuoi colleghi.

Per la gestione del progetto, del programma e dell'organizzazione, il caso deve essere il modo in cui la distribuzione del controllo della versione può far risparmiare tempo e denaro all'organizzazione. Le persone a questo livello si preoccupano di quanti soldi il progetto stia costando, dove si trova rispetto alle stime e così via. Cerca white paper, libri, articoli e altri documenti e pubblicazioni professionali che spieghino come la distribuzione del controllo delle versioni abbia salvato tempo e denaro in altre organizzazioni nel lungo periodo. Puoi anche introdurre una prospettiva di qualità qui, se la tua organizzazione è interessata alla qualità del software.

Hai specificamente menzionato che vuoi usare un sistema di controllo della versione distribuito. Non forzarlo in fondo alla squadra o all'organizzazione. Introdurli al controllo della versione e alle loro opzioni. Sebbene tu personalmente preferisci usare un DVCS (come Mercurial), potrebbe non essere la soluzione migliore per il tuo team e la tua organizzazione. L'uso di uno strumento inadatto potrebbe peggiorare le cose solo attraverso il thrashing.

Inoltre, tieni presente i rischi di introduzione del processo in ritardo . Anche se l'uso del controllo della versione è una best practice comunemente accettata, potrebbe essere troppo tardi per introdurla in modo efficace sul progetto corrente senza un enorme rischio di completamento del progetto. Invece, consiglierei di concentrarsi sul miglioramento dello status quo per progetti e team futuri.

Inoltre, questo è un approccio generale che puoi seguire per portare a termine qualsiasi processo o miglioramento tecnologico.

La prima domanda è: cosa fanno attualmente? Sicuramente ogni sviluppatore non ha il codice sorgente bloccato sulla propria scatola che cambia a piacimento. Una volta che hai seguito il processo che seguono, puoi suggerire alcuni strumenti che migliorano questo processo - solitamente un SCM è l'ideale per aiutarli con questo, piuttosto che fargli seguire un processo diverso.

Il punto principale qui è che se hanno un modo pseudo-SCM di funzionare, magari memorizzano la versione corrente su un server da qualche parte, allora devi determinare se un DVCS o un CVS è più appropriato, non provare a vendili Mercurial se SVN è più adatto.

Il modo più rapido è convincere la direzione che è necessario.

Fai alcuni calcoli:

Costo del software di controllo della versione - gratuito.
Costo dell'hardware per supportare il repository - un server.
Costo del software di implementazione: un paio di giorni per una piccola squadra, in aumento per team più grandi.

Costo di non implementazione del controllo della versione:

Best case - giorni persi a causa di modifiche mancanti, sovrascrittura delle modifiche, ecc., errori ricorrenti e così via.
Il caso peggiore - comunque molti anni di sforzi che la tua squadra ha speso finora.

Quest'ultima cifra è la peggiore delle ipotesi in cui perdi tutto il lavoro a causa di un errore del server, ecc., ma anche gli scenari del "caso migliore" dovrebbero portarli a casa perché è necessario. Il costo dei bug ricorrenti potrebbe essere maggiore in quanto potrebbe portare a clienti persi.

Il team di sviluppo dovrebbe anche comprendere questi costi e dato che la maggior parte (se non tutti) il software di controllo della versione si integra perfettamente con gli IDE in questi giorni non si accorgeranno nemmeno che è lì la maggior parte del tempo.

Di solito la gestione si occupa soprattutto del risparmio di denaro. Enfatizza il modo in cui il controllo della versione può avvantaggiare finanziariamente il team e riceverai subito la loro attenzione!

C'è un aspetto che altre persone qui non hanno toccato che penso che tu abbia nel tuo angolo - parli del controllo della versione distribuito - per sua stessa natura, puoi introdurlo di nascosto in una pratica de facto, uno sviluppatore alla volta. Con un controllo di versione più rozzo, come quello che usiamo nel mio ufficio (MS Visual SourceSafe), avresti difficoltà a raggiungere il ragazzo nel cubo di fronte al mio e venderlo, uno contro uno nel merito di controllo della versione. Tuttavia, con (qualsiasi) DVCS, puoi semplicemente dire "hey, prova questo, e guarda se ti piace. Ti mostrerò le corde, e sarei felice di rispondere a qualsiasi domanda, ti guiderò, blah blah bla". In questo modo, non hai bisogno di un "processo" dall'alto verso il basso, puoi costruire un mandato di base, una persona alla volta.

Basarsi sulla risposta di gbjbaanb.

La cosa fondamentale qui è che dovresti adattare il processo di controllo della versione a qualunque processo esistente esista e mostrare come si risparmia il resto dello sforzo del team.

Personalmente preferisco anche Mercurial, ma non voglio necessariamente impilarlo su persone che non sono abituate al controllo di versione perché è un po 'più difficile da comprendere rispetto a un sistema di controllo delle versioni di blocco basato su server vecchio stile. Detto questo, se si tratta di un vero sito di greenfield, potrebbe essere meglio andare su tutte le furie, saltare gli anni '80 & Anni '90 e vai con Mercurial. Guarderei anche parte del ciclo di vita del software di terze parti costruito attorno a Mercurial - sono sicuro che ce n'è uno ma il suo 'nome mi sfugge;)

Immagino che tu lavori per una piccola azienda & che sei relativamente nuovo per il team, quindi potrebbe essere una vendita difficile, soprattutto se il resto del team è trincerato e ha fiducia nella gestione. Potrebbe essere meglio lasciare che facciano qualcosa di male, poi vieni in soccorso. Ciò non significa sabotaggio, aspetta solo l'inevitabile.