Linee guida per il controllo della buona versione da una prospettiva di sviluppo / collaborazione?

Question

Linee guida per il controllo della buona versione da una prospettiva di sviluppo / collaborazione?

#1 da (15 voti)
#2 da (9 voti)

3

Nella nostra azienda abbiamo iniziato a esternalizzare alcuni dei nostri sviluppi.

Questo ha funzionato abbastanza bene. Tuttavia, stiamo avendo difficoltà a convincerli a utilizzare correttamente il controllo della versione. Hanno familiarità con SVN e sanno come usarlo. Tuttavia, per qualche ragione, non si impegnano regolarmente, ma lavorano simultaneamente con 16 cose e fanno un enorme commit ogni 2 settimane, se siamo fortunati magari con qualche commento. Il che rende molto difficile seguire e rivedere il proprio lavoro, collaborare e anche correggere bug. Ho cercato di spiegare loro di fare il loro lavoro come un piccolo compito alla volta e di impegnare regolarmente ciascuno di questi con commenti appropriati. Senza molto successo, o non capiscono il concetto o sono pigri.

La mia domanda è, quali sarebbero le buone linee guida che descrivono come si dovrebbe lavorare con il controllo della versione, non da una prospettiva tecnica (loro conoscono SVN), che sembra essere l'unica cosa che sto trovando online, ma da uno sviluppo / prospettiva collaborazione / progetto?

teamwork version-control project-management agile

posta ronag 12.04.2013 - 10:36

fonte

2 risposte

Leggi altre domande sui tag teamwork version-control project-management agile

In che modo i datori di lavoro misurano "una conoscenza strong o solida del linguaggio di programmazione"? [chiuso] Come praticare l'ATDD se il design non è ancora emerso da TDD?

score 15 · Answer 1

L'azienda è una società esterna, quindi non puoi davvero imporre che seguono una certa filosofia, flusso di lavoro, ecc. internamente.

Tuttavia, li hai assunti, quindi ciò che puoi controllare sono i requisiti per ciò che producono. Non è necessario convincerli "questo è un buon processo per la programmazione"; tutto ciò che devi dire è "questo è il processo della nostra azienda, e ci aspettiamo che ciò che tu fornisci per conformarti ad esso".

Mostra chiaramente le tue aspettative, ad esempio:

La frequenza dei commit richiesti.
Limitazioni sul numero di modifiche in un singolo commit.
Il modo in cui le modifiche devono essere documentate.

Non devi davvero giustificare il motivo per cui vuoi fare queste cose. Tuttavia, è probabile che scopriranno i vantaggi di queste pratiche una volta che inizieranno a utilizzarle.

Aggiornamento Penso che Karl Bielefeldt abbia dei buoni punti di forza. In definitiva, dipende dal tipo di ruolo che gli sviluppatori esterni stanno giocando. C'è un continuum: dagli appaltatori che lavorano sul posto e sono praticamente indistinguibili dai dipendenti, a un'azienda esterna che consegna semplicemente un prodotto finito alle specifiche.

score 9 · Answer 2

In effetti chiedi loro di condividere lavori in corso incompleti con te, i loro clienti. Questo non è molto comune negli accordi di outsourcing, e si presenta come microgestione . Anche se si tratta solo di esternalizzazione parziale, come se fossero considerati dipendenti della vostra azienda, ma si trovano in un altro paese, i siti remoti di solito hanno molta autonomia con lavori in corso. Inoltre, alcune culture sono particolarmente sensibili nel presentare un buon volto.

D'altra parte, i commit più piccoli sono più facili da utilizzare dopo il fatto. Potresti avere più fortuna con un modello di ramificazione diverso. Con un DVCS, il team remoto può avere il proprio ramo privato per impegnare tutto il proprio lavoro in corso, ma possono scegliere di non unire quel ramo finché l'attività non è presentabile, cioè alla fine dell'iterazione. Quindi ottieni tutta la cronologia, ma salvano la faccia non dovendo condividere il lavoro incompleto. Non so se questo sia tecnicamente fattibile con svn o no.