Come incoraggiare l'adozione del controllo versione

Di recente ho iniziato a lavorare in un team in cui non esiste alcun controllo della versione. La maggior parte dei membri del team non è abituata a nessun tipo di controllo di versione. Ho usato mercurial privatamente per tracciare il mio lavoro. Vorrei incoraggiare gli altri ad adottarlo e quantomeno iniziare a versioni il loro codice mentre sviluppano le modifiche. Qualcuno può darmi consigli su come posso incoraggiare l'adozione di un controllo di versione distribuita come mercurial. Qualche consiglio su come conquistare persone, inclusi i manager del DVCS, sarebbe molto apprezzato.

È necessario presentare un caso per l'uso del controllo di versione e prima provare a venderlo ai colleghi e, in caso contrario, salire sulla catena per proiettare la leadership e superiore.

Per i colleghi ingegneri del software, il tuo caso dovrebbe essere focalizzato su come fa risparmiare tempo e mal di testa a lungo termine. Trova i momenti del tuo passato o storie pubblicate (blog, articoli su riviste, white paper) su come l'uso del controllo delle versioni ti semplifichi la vita. Se sei stato masterizzato non avendo il controllo della versione, rendilo personale. Se i tuoi colleghi sviluppatori si sono trovati nella stessa situazione, dovrebbero vedere la luce e come questi strumenti possono aiutarli.

Questa è la tua scommessa migliore. Anche se non riesco a trovare le fonti in questo momento, ho letto (in un paio di punti) che le modifiche più efficaci al processo provengono dagli sviluppatori, che devono gestire le modifiche. Se riesci a coinvolgere gli sviluppatori, otterrai due cose. Innanzitutto, hai già il buy-in da parte delle persone che saranno influenzate dal cambio di processo. In secondo luogo, c'è un gruppo di persone per convincere il management che questo è uno sforzo utile e migliorerà il prodotto e il progetto.

Tuttavia, se non riesci a ottenere il supporto del team di sviluppo e ti senti ancora incredibilmente fortemente impegnato nella distribuzione del controllo versione, puoi passare alla gestione. Ma diventa più rischioso se vai da solo, poiché non devi solo preoccuparti di vendere il miglioramento, ma anche di gestire i contraccolpi dei tuoi colleghi.

Per la gestione di progetti, programmi e organizzazioni, il caso deve riguardare il modo in cui la distribuzione del controllo versione può far risparmiare tempo e denaro all'organizzazione. Le persone a questo livello si preoccupano di quanto costa il progetto, 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 ha consentito ad altre organizzazioni di risparmiare tempo e denaro nel lungo periodo. Puoi anche introdurre una prospettiva di qualità qui, se la tua organizzazione è interessata alla qualità del software.

Hai espressamente indicato che desideri utilizzare un sistema di controllo della versione distribuito. Non forzarlo nella gola della squadra o dell'organizzazione. Presentali al controllo versione e alle loro opzioni. Sebbene tu possa preferire personalmente l'uso di un DVCS (come Mercurial), potrebbe non essere la soluzione migliore per il tuo team e la tua organizzazione. L'uso di uno strumento che si adatta in modo errato non farà che peggiorare le cose con il thrashing.

Inoltre, prestare attenzione ai rischi derivanti dall'introduzione del processo in ritardo . Sebbene l'uso del controllo versione sia una best practice comunemente accettata, potrebbe essere troppo tardi per introdurlo efficacemente nel progetto corrente senza un rischio enorme per il completamento del progetto. Raccomanderei invece di concentrarsi sul miglioramento dello status quo per progetti e team futuri.

Inoltre, si tratta di un approccio generale che è possibile seguire per eseguire miglioramenti di processo o tecnologici.

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

Il punto principale qui è, se hanno un modo di lavorare pseudo-SCM, forse archiviando la versione corrente su un server da qualche parte, quindi è necessario determinare se un DVCS o un CVS è più appropriato, non provare a venderli Mercurial se SVN si adatta meglio.

Il modo più rapido è convincere il management che è necessario.

Fai alcuni calcoli:

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

Costo per non implementare il controllo versione:

Nel migliore dei casi - giorni persi a causa di modifiche mancanti, sovrascrivendo ogni altro cambiamento ecc., Bug ricorrenti e così via.
Peggior caso, per quanto molti anni di lavoro siano stati compiuti finora dalla tua squadra.

Quest'ultima cifra è lo scenario peggiore in cui perdi tutto il tuo lavoro a causa di un errore del server, ecc. Ma anche gli scenari "nel migliore dei casi" dovrebbero far capire loro perché è necessario. Il costo dei bug ricorrenti potrebbe essere maggiore in quanto potrebbe portare alla perdita di clienti.

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

La gestione di solito si preoccupa maggiormente del risparmio di denaro. Sottolinea in che modo il controllo della versione può apportare vantaggi finanziari al team e otterrai subito la loro attenzione!

C'è un aspetto che altre persone qui non hanno toccato che penso che tu abbia nel tuo angolo - stai parlando del controllo della versione distribuita - per sua stessa natura, puoi introdurlo di fatto in una pratica, uno sviluppatore Al tempo. Con un controllo della versione più complicato, come quello che usiamo nel mio ufficio (MS Visual SourceSafe), faresti fatica ad andare dal 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 vedi se ti piace. Ti mostrerò le corde e sarei felice di rispondere a qualsiasi domanda, accompagnarti, blah blah bla". In questo modo, non hai bisogno di un "processo" dall'alto, puoi costruire un mandato di base, una persona alla volta.

Basandosi sulla risposta di gbjbaanb.

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

Personalmente favorisco anche Mercurial, ma non vorrei necessariamente spingerlo verso persone non abituate al controllo della versione perché è un po 'più difficile da comprendere rispetto a un vecchio sistema di controllo della versione di blocco basato su server. Detto questo, se si tratta di un vero sito di campi verdi, potrebbe essere meglio andare su tutto il maiale, saltare gli anni '80 e '90 e andare con Mercurial. Guarderei anche alcune delle cose del ciclo di vita del software di terze parti costruite attorno a Mercurial: sono sicuro che ce ne sia una ma il suo nome mi sfugge;)

Immagino che lavori per una piccola azienda e che tu sia relativamente nuovo per il team, quindi potrebbe essere una vendita difficile, specialmente se il resto del team è radicato e ha la fiducia della direzione. Potrebbe essere meglio lasciare che facciano qualcosa di male e poi vengano in soccorso. Ciò non significa sabotaggio, aspetta solo l'inevitabile.