Come può un manager assicurare che gli sviluppatori spingano fino all'origine ogni giorno?

Più occhi sono impostati su un determinato processo, più è probabile che migliori.

Utilizza uno strumento integrazione continua come Jenkins . Sapranno che stai guardando un rapporto web che mostra le loro spinte, la quantità di lavoro svolto e la qualità del loro codice.

Spazzi sotto il tappeto solo quando nessuno sta guardando.

In primo luogo, lasciatemi dire che provare a costringere gli sviluppatori di software ad adottare qualsiasi pratica rischia di ritorcersi contro. Gli sviluppatori di software come gruppo sono persone intelligenti e istruite che amano essere trattati come professionisti e rispondono molto meglio alle tecniche di gestione che rispettano questo aspetto e li considerano come validi collaboratori.

Quindi la chiave è convincere i tuoi sviluppatori, con argomenti logici, che spingere il codice al rialzo quotidianamente è una buona pratica e ne trarrà beneficio. Per fare questo, adottare processi che facilitino il push-up quotidiano e convincere i propri sviluppatori a essere i loro sostenitori più forti dimostrando i loro vantaggi. È stata citata l'integrazione continua ed è una buona pratica da adottare. Alcuni dei principali vantaggi per gli sviluppatori sono:

• Migliore integrazione al momento del rilascio. Se la base del codice è continuamente integrato, il rischio di un big-bang stressante integrazione al momento del rilascio, con una pletora di bug introdotti dato che più rami sono integrati freneticamente, è molto ridotto.

• Cattura e corregge bug subito dopo l'introduzione. Se un nuovo la revisione ha introdotto un'unità guasta o un test di regressione o un nuovo bug non coperto da questi test, può essere risolto prima, non più tardi quando lo fa arriva il momento di rilasciare, quando sarà molto più difficile da trovare e più stressante sul sviluppatori. E i test di unità e di regressione dovrebbero anche essere continuamente perfezionati e migliorati con lo sviluppo procede.

• Miglioramento della collaborazione con gli sviluppatori. Come hai sottolineato, se tutti si impegna quotidianamente, è più facile sapere quale sviluppatore ha eseguito il commit codice più recente a un modulo specifico. Quello che vuoi fare è ottenere il sviluppatori che collaborano l'uno con l'altro sul miglioramento e sul fissaggio di ciascuno altro codice.

• I commit giornalieri creano piccoli commit. Meno codice è impegnato, il meno probabile che contenga una grande quantità di bug.

Ovviamente per l'integrazione continua, non è solo una questione di strumenti. È una questione di processi che ci sono dei prerequisiti che devono essere implementati come una buona suite di test di unità e di regressione, e una cultura di revisioni tra pari di progettazione e codice da parte degli sviluppatori. Se la tua organizzazione ha punti deboli in una di queste aree, è a tuo vantaggio cercare una formazione per te stesso e per il team in Integrazione continua e / o processi che lo supportano, come lo sviluppo Agile.

Ciò che si vuole fare per avere successo è portare gli sviluppatori con Continuous Integration al punto in cui l'applicazione peer di pratiche come il commit / build / unità e il test di regressione giornalieri prendono piede e l'intervento di gestione è appena necessario. A tal fine, come manager, devi:

• Convinci i benefici a loro stessi - in modo che lo facciano la cosa giusta per un interesse personale illuminato.

• Coinvolgili direttamente nell'applicazione del processo - questo significa revisioni paritarie di progettazione, costruzione e test, sempre e continuamente.

• Ottieni loro gli strumenti e la formazione necessari per supportare Continuous Integrazione.

• Guida con l'esempio. Se sei coinvolto in progettazione e sviluppo a tutto, assicurati di seguire i processi e di essere visibile a proposito. Fai notare come i processi riducono il tuo lavoro stressante e incoraggia costantemente i tuoi sviluppatori a seguire l'esempio.

TBH se hai un sistema centralizzato quando è necessario spingere verso l'origine, allora stai veramente usando git come se fosse SVN / TFS (cioè un sistema centralizzato) in primo luogo. Faresti meglio a tornare a un tale SCM.

Tuttavia, puoi eseguire la migrazione a Fossil che è centralizzato SCM decentralizzato e penso sia la next-gen dei sistemi SCM.

Dovresti anche avere CI implementato in ogni caso, se non vuoi forzare il processo sugli sviluppatori, la prossima cosa migliore è incoraggiarli ad impegnarsi con il processo - e il modo migliore per farlo per molti sviluppatori è quello di gamificarlo. Quindi hai le classifiche di commit, build, correzioni di bug e fallimenti di build. Le persone spesso vogliono essere al vertice di una tale classifica e gareggeranno per arrivarci (vedi il sistema di reputazione di SO per un esempio!)

Ma ciò può funzionare solo in alcuni casi, nella maggior parte dei lavori professionali, il capo deve semplicemente mandare i risultati che vuole e dice allo staff di farlo accadere. In questo caso, i commit giornalieri servono a scopi di backup e collaborazione, quindi le spinte quotidiane devono iniziare a verificarsi. Immagino che la maggior parte delle persone semplicemente non lo faccia perché dimentica quando si tratta del tempo di casa (il fossile risolverebbe questo dato che sincronizza continuamente i cambiamenti con l'origine).