In passato ho lavorato con designer, BA e project manager, tutti quelli che producono regolarmente artefatti di progetti, eppure davvero capiscono il concetto di versioning. Quando provo a spiegarglielo (anche nella sua forma più semplice di file con più nomi diversi) sembrano avere qualche tipo di blocco mentale. Perché pensi che sia?
Questo perché l'umano ha difficoltà a proiettarsi nel tempo.
Usa l'analogia della macchina del tempo. La tua vita è versionnata. Ogni giorno hai una nuova versione della tua vita: cose nuove e cose perdute. Speriamo che più risorse, meno debiti, ... ma più grassi, meno peli, ... speriamo più conoscenza, meno dubbi ....
Quindi dovrai spiegare la ramificazione;) E lì speri che siano fan di Fringe;)
Puoi usare l'analogia del libro.
Quando scrivi un libro, per prima cosa scrivi una bozza di versione. Poi lo leggi, apporta alcune modifiche e rileggilo. Finché non lo dai a qualcun altro da leggere. E naturalmente hanno anche delle osservazioni.
Ogni modifica fa una nuova versione. E sebbene tu di solito usi l'ultima versione, a volte, rimpiangi una modifica e vuoi eseguire il rollback. Forse l'intero libro, forse un singolo capitolo. Il controllo delle versioni ti offre questa opportunità.
Quindi l'oggetto della ramificazione.
Il libro è quasi finito e deve essere tradotto in francese. Quindi fai una copia del libro e invialo al traduttore. Nel frattempo, apporti alcune modifiche al libro originale. Alcuni di questi sono aggiunti alla traduzione francese e altri non ce la fanno mai.
Perché, nel mondo non programmato, cambiare un prodotto in competizione è molto difficile. I cambiamenti intenzionali, che sono pensati attraverso, non sono facili da prendere, per esempio. E una volta apportate le modifiche, è difficile "ripristinare" la versione precedente.
Contrariamente a ciò, cambiare il software è molto semplice (più facile persino di altri prodotti multimediali, per esempio un film), e "controllare una versione precedente" è un compito comune nel mondo del software.
Quindi, la nozione di versioning contraddice l'esperienza quotidiana, che di solito conferma che esiste solo una versione corrente di una cosa (per software non è vero). Ecco perché è difficile.
Nella mia esperienza, si accorgono piuttosto rapidamente.
Versione 1.0 - Vendiamo per soldi.
Versione 1.1 - Piccoli miglioramenti per alcuni clienti: vendiamo per una piccola quantità di denaro.
Versione 2.0 - Grandi miglioramenti. Vendiamo per un sacco di soldi.
Versione 2.1 - Piccoli miglioramenti per alcuni clienti: noi ... "Aspetta un minuto" dice PM / BA "Rinominare quello a 2.5 e faremo pagare 5 volte tanto". Nessuna quantità di discussione di engineering le convincerà altrimenti.
Versione 2.2 3.0 etc ...
Hai detto che anche il semplice controllo delle versioni dei documenti sta dando problemi alle persone, quindi forse non lo stai spiegando bene, o il tuo team non è così brillante.
I nostri sviluppatori usano git sulla riga di comando per il controllo delle versioni e, una volta raggiunta la curva di apprendimento, sono tutti all'altezza. Non mi sono preso la briga di cercare di spiegare git a personale non tecnico perché con loro c'è molta meno collaborazione diretta su singoli documenti - per questa roba usiamo DropBox, e non ho visto nessuno lottare ancora.
Devono essere consapevoli dei vari scenari del "giorno del giudizio". Computer, server, disco rigido, qualsiasi cosa, interruzioni, non è bello avere un backup? Se non riesci a metterli d'accordo su questo concetto, non puoi andare avanti.
Ora, cosa succede se è stato chiesto loro di fare una presentazione, ma nella terza pagina, il cliente vorrebbe vederlo con e senza il grafico. Cosa faresti? Fai una seconda copia con le modifiche. Se ti dicessero che non volevano il grafico, butti via la 'versione' con il grafico? Probabilmente no perché non lo sai mai. Se non riesci a metterli d'accordo su questo concetto, non puoi andare avanti.
Hai mai inviato un file per la revisione solo per far cambiare la persona? Hai mantenuto la tua versione? Hai dovuto dare al file che hai inviato loro un nome diverso perché sai quando apportano modifiche è troppo difficile capire la differenza o salvarli nella stessa cartella? E questi nomi non stanno finendo? Se non riesci a metterli d'accordo su questo concetto, non puoi andare avanti.
Non sarebbe bello se avessimo qualcosa che sarebbe solo tenere traccia di tutto questo per noi? Non è più necessario inviare allegati di posta elettronica. Non mi chiedevo più quale dei due abbia fatto quel cambiamento, ma ho fatto un altro cambiamento e ora non riusciamo a metterli insieme. Niente più nomi di file lunghi che cercano di spiegare su quale "versione" ci troviamo. Se non riesci a metterli d'accordo su questo concetto, avrai solo bisogno di andare avanti.
Ho scoperto che gli ingegneri (elec / mech ecc.) non iniziano a capire la gestione della configurazione, ma vi crescono (o fanno impazzire tutti.)
Gli sviluppatori di software potrebbero comprendere il controllo delle versioni.
Le persone non tecniche in generale non capiscono nulla da questo spazio. È tecnico.
Fa parte della disciplina ingegneristica che non hanno mai dovuto imparare.
Possono scegliere di non farlo. Così molti di loro lo faranno.
L'unica soluzione è quella di lavorare da qualche parte con supporto gestionale per un processo disciplinato. La conformità al CMMI di livello 2 è del 400% più produttiva in termini di tempo e denaro, ma la gente lo evita.
Vuoi dire versioning o branching / merging?
Penso che sia abbastanza semplice capire il controllo delle versioni. "Abbiamo salvato la versione da martedì, poi abbiamo fatto più lavoro, ora è mercoledì, possiamo tornare alla versione di martedì".
La ramificazione e la fusione sono molto più difficili da spiegare. "Beh, Bob ha apportato delle modifiche in 1.1 che sono in conflitto con la vista di Alice 1.1 e presentate per prime, quindi 1.2 ha le modifiche di Bob, ma 1.3 ha anche le modifiche di Alice tranne alcune di Bob sono state integrate più tardi, quindi ..."
Bene, Alice scrive un blah. Poi Bob ottiene il blah e fa alcune modifiche, e Carol ottiene il blah e fa alcune modifiche. Queste sono versioni. Poi arriva Dan e dice ad Alice di fare un sacco di cambiamenti. Questa è un'altra versione. Il giorno dopo, Dan ritorna e dice che tutto quello che ha detto ieri è una bugia, e che la direzione vuole la versione di bols di Carols da martedì. Avere la versione di Carols ed essere in grado di trovarlo facilmente si chiama controllo della versione.
La mia ipotesi è che la maggior parte delle persone abbia un certo numero di cose a cui preoccuparsi, quindi il versioning non è in cima alla lista. È come l'assicurazione, il rimborso è di bassa probabilità e non è gratuito.
Per gli artefatti del progetto che hai delineato, se c'è una sola persona coinvolta (ad esempio un documento di BA che descrive un calcolo), possono abbastanza ragionevolmente valutare il recupero dell'investimento delle versioni precedenti a zero.
Richiedere un controllo delle versioni più accurato di questo tipo di cose può introdurre un elemento ostile nell'atmosfera di un progetto, poiché le ragioni per farlo potrebbero essere contraddittorie, vale a dire che le persone si aspettano di avere argomenti su versioni vecchie o nuove, quindi vuoi che le vecchie versioni siano disponibili come prova.
Leggi altre domande sui tag development-process versioning