Quantificazione dei vantaggi di un moderno sistema di controllo versione [chiuso]

Sono stato in situazioni molto simili (nell'industria aerospaziale e automobilistica). Non aspettarti di progredire molto in questo o in altri incontri. Entrambe queste situazioni hanno superato il mio desiderio di continuare a lottare per migliorare, ma qui è la migliore tattica che ho visto finora ...

Dici "questo processo ha funzionato per 20 anni", ma ha davvero? Inizia a delineare cosa intendi con "il nostro processo di rilascio della produzione è un incubo". Crea un elenco di problemi con il processo / strumento corrente che è il più agevole possibile di ClearCase.

Quindi, crea un elenco di "soluzioni" di processo / strumento che sono agnostiche di Git il più possibile (sebbene Git o qualsiasi DVCS moderno apprezzeranno esattamente la fattura). Spiegare perché Git è migliore di ClearCase significa niente per i non utenti.

Consentire al team dell'infrastruttura di confermare che l'approccio attuale presenta i problemi identificati. Questo probabilmente li porterà a cercare supporto da IBM per "risolvere" questi problemi. Rimanere connessi per garantire che IBM non affronti i problemi. Poiché ClearCase non ha le proprietà di base della nostra moderna comprensione del controllo della versione, la maggior parte di questi problemi non può essere risolta o richiederà una modifica sostanziale dell'infrastruttura.

Si spera che a questo punto il team dell'infrastruttura vedrà questo come un problema aziendale, ma senza una soluzione facile. A questo punto, offri di confrontare soluzioni aggiuntive con costi stimati. Poiché molti dei tuoi team stanno già utilizzando Git, dovresti essere in grado di rimuovere la formazione a titolo di spesa.

Buona fortuna!

Our production release process is a nightmare because it revolves around Clearcase. We have a change management group who executes all releases and who will only allow code into production that was taken from it.

No, il tuo processo è un "incubo" a causa del tuo gruppo di gestione delle modifiche e delle procedure di rilascio. Vai avanti e sostituisci Clearcase per SVN o git o Fossil. Avrai gli stessi stessi problemi . (Penso che lo stiano facendo bene, TBH, i controlli di rilascio sono essenziali)

Questo è ciò su cui devi concentrarti, non le credenziali geek di git (che sono irrilevanti per tutti tranne che per gli sviluppatori), è necessario concentrarsi sul business case per cambiare il processo per renderlo meno oneroso. Probabilmente puoi farlo usando Clearcase, ma ti dà l'opportunità di svelare l'idea di usare git in ogni caso.

Se non guardi la "immagine più grande" qui, il caso migliore ti farà usare git con le stesse restrizioni richieste dal gruppo di rilascio. Se consideri gli aspetti più ampi di cosa sia il controllo dei cambiamenti, allora apprezzerai le restrizioni che dovrai implementare per rendere git utile nel tipo di processo di rilascio strongmente controllato di cui l'org ha bisogno.

Alcune idee per te: falli vedere i problemi di produttività con il sistema attuale dal punto di vista dello sviluppatore. Fai questo come parte 1 di 2. Parte 2, vai e lavora con loro su una versione in modo da poter vedere i problemi di controllo che gli sviluppatori devono capire. Trattalo come un esercizio di apprendimento per entrambe le parti per visualizzare la vista dell'altro lato, e quindi dovresti essere in grado di trovare una soluzione che risolva ancora i principali requisiti di entrambe le parti. Nota che i rilasci sono più importanti di dev, quindi dovresti essere quello pronto a dare terreno più di quanto ti aspetti.

Una volta acquisita la conoscenza di ciò che è richiesto per le versioni, dovresti accettare di redigere un documento di processo dettagliato (con i dettagli dei passaggi da seguire) che puoi mostrare loro dando loro ciò di cui hanno bisogno. Come puoi massaggiare questo in modo che il lato sviluppo sia migliore per te dipende da te. Immagino che a loro non importa quanto dev dev dev, a patto che la fonte sia gestita correttamente e rilasciata correttamente organizzata - questo significa che dovrai mostrare come possono essere legate le modifiche al codice per cambiare i biglietti, come prendere il codice che ha fatto una versione per patch, compilazione e nuova versione.

Gli esempi specifici impressioneranno più dei vantaggi astratti. Penso che troverai maggior successo se puoi documentare particolari esempi in cui (a) Clearcase ha causato problemi che hanno richiesto tempo per risolverlo e (b) Git risolve questi problemi. Ricorda che non è necessario entrare nei dettagli tecnici di perché è così (a meno che non venga richiesto) semplicemente mostrare che lo è; la gestione non ha bisogno di conoscere i dettagli tecnici, questo è quello per cui sei pagato.

Se è possibile allegare scadenze e date specifiche a questi esempi tanto meglio. Potresti anche essere in grado di completare questa operazione mostrando che l'attività X che fai molto prende Y minuti in Clearcase e Z minuti in Git.

Ricorda che il tempo è denaro, quindi se puoi dimostrare che lavorare con Git è più veloce puoi dimostrare che avrà anche un senso finanziario.

Ecco un tentativo di come provarlo.

Può sembrare stupido per uno sviluppatore, ma per la gestione, i cambiamenti tecnologici sono considerati rischiosi.

"Se la cosa magica funziona già, perché rischiare di romperla?"

Quindi, devi girare il tavolo. Rendi più rischioso non fare il passaggio a git. A tutti i costi, non farlo sembrare un nuovo giocattolo.

Vorrei iniziare dicendo che git è ora ampiamente utilizzato. Utilizza i numeri, come quelli: link

Per un manager, questo implica che dovrebbero essere in grado di trovare molti sviluppatori che usano git. E un intero ecosistema di strumenti di terze parti (ho sentito persino Microsoft che integra git con Visual Studio ora).

Anche un manager non può essere biasimato per aver seguito le cose tradizionali, vero? Al contrario, chi usa $ other_cvs qui?

Metti in risalto il modo in cui i grandi progetti lo utilizzano, perché è semplice, veloce, flessibile, potente ... Trova grandi progetti con grandi nomi collegati (GNU / Linux, Google, Microsoft ...) che usano git .

Avendo dimostrato che non può essere una brutta mossa, potresti continuare a migliorare le cose nel tuo caso.

Vuoi che la compagnia rimanga competitiva e non essere battuta da squadre più veloci e agili, giusto? Vorrei provare a trovare alcune stime interne (scritte) su come la produttività è cambiata usando Clearcase vs Git. Potresti usare l'aiuto dei tuoi colleghi sviluppatori lì. Quindi estrapola per l'intera azienda (ad esempio tutti gli sviluppatori di software), con i numeri e il costo stimato di stare con Clearcase.

Vorrei anche, se del caso, ricapitolare l'intera faccenda in una e-mail scritta dopo l'incontro (includi le persone giuste).

What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument.

Questo è un argomento non valido (i carri trainati da cavalli hanno "lavorato per secoli", ma probabilmente vorrai comprare una macchina).

Ho sentito la stessa argomentazione su svn vs. mercurial (io ero quello che usava mercurial sul mio sistema di sviluppo).

Questo problema non riguarda la sostituzione di ciò che funziona; Non cercare di esprimerlo come tale, e se questa è la domanda che devi "sconfiggere", dovresti iniziare sottolineando che non è una questione di ciò che funziona o meno - ma una questione di quali vantaggi hai con git , quando funzionano entrambi (e perché git funziona meglio).

Buoni argomenti per l'utilizzo di git:

• git è il changeset centric invece del file centric. Ciò significa che le modifiche sono più facili da tracciare tra i file (tracciabilità attraverso il progetto).

• git è distribuito invece che centralizzato; Ciò significa che il check-in non è limitato dalla velocità della rete, risparmiando un sacco di tempo, ancora una volta. Significa anche che non hai un singolo punto di errore nel caso in cui il tuo server ClearCase non funzioni.

• a causa del suo sistema di ramificazione, git riduce al minimo la necessità di unire (cioè non unisci i file ad ogni check-in, ma su ogni funzione completata). Passi da risolvere conflitti di fusione (se ce ne sono) alcune volte al giorno (su ogni commit) a una o due volte a settimana (su ogni funzione completata). Ciò significa più tempo di sviluppo per i tuoi sviluppatori (qualcosa che i manager vorranno massimizzare).

I think that the fact the other teams have started using Git internally is a meaningful sign, but it's still not strong enough because it can still be dismissed as personal preference.

Puoi notare che la differenza qualitativa è così grande , che gli sviluppatori di tutta la tua azienda preferiscono le complicazioni dell'installazione, della configurazione e dell'uso di git, in cima a Clearcase, per le sue funzionalità extra. In realtà è un argomento strong (se non fornisse un'esperienza utente e un set di funzionalità complessivamente migliori, la gente non farebbe il possibile per utilizzarla - specialmente perché è qualcosa non richiesto dal società).

So I have a meeting this week with the SVP in change of infrastructure who specifically wants me to explain to her the merits of Git.

Disegna un grafico che rappresenti i commit con i due sistemi e mostra lo snellimento ottenuto dagli sviluppatori che non pubblicano pubblicamente (ad esempio se bork un file, il resto del team non viene bloccato e non è in grado di completarlo finché non lo risolvi). Spiega anche i controlli di qualità extra che puoi eseguire quando puoi effettuare commit con l'intermediario senza influire su nessun altro, il fatto che puoi ottenere delle differenze di per funzione (essenziale per le revisioni del codice).

What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument.

È difficile giudicare veramente quale sarebbe una buona argomentazione senza essere un testimone della scena. Ma cercherò di aiutarti a inquadrare i tuoi argomenti in modo che possano essere ascoltati.

Presumo che il tuo pubblico abbia un livello di conoscenza non esperto sull'argomento e che abbia interesse a rimanere nel corso corrente. Hanno preoccupazioni e responsabilità diverse e potrebbero subire gravi conseguenze se qualcosa va storto, quindi dovrai lavorare da quella mentalità. Anticipa alcune delle domande o preoccupazioni che potrebbero avere:

• Quali nuove funzionalità porterebbe? C'è qualcosa che attualmente non possiamo fare, che vorremmo fare e che questa nuova cosa ci permetterebbe di fare? Inizia con una nota positiva.

• Qual è l'impatto sulle pianificazioni dei rilasci? Qual è il costo di implementazione di questa modifica verso la versione immediatamente successiva? Quali sono i costi e i benefici delle seguenti versioni?

• Ciò comporterà una modifica del processo? A differenza del programma di rilascio, questo cambiamento richiederà che le persone nel processo di rilascio cambino modo? Sarà trasparente per loro o dovranno adattarsi? Dovrai cooperare con altri dipartimenti? Le persone sono resistenti al cambiamento.

• Ci sono pericoli imminenti da attaccare al sistema attuale? Il processo attuale ha dipendenze software o hardware che sono andate o andranno a finire vita presto? Si basa su conoscenze specialistiche di individui che aumentano i costi di assunzione? Ha un potenziale buco di sicurezza che il nuovo sistema inserisce (punti bonus se questo buco può portare a un'azione legale)? Non agitare a mano o "forse" o "probabilmente" questo: il senso è che ha funzionato bene per 20 anni, quindi l'onere della prova è sul difensore del cambiamento.

Inoltre, sii specifico su problemi e soluzioni . Se non riesci a trovare esempi specifici, utilizza stime oneste dalla tua posizione di esperto. Esempi di altre società / dipartimenti / entità che adottano tale cambiamento, preferibilmente dal proprio settore, e la loro valutazione di tale cambiamento, vi aiuteranno. (Non raccogliere esempi che hanno avuto qualche tipo di problema IT pubblicizzato negli ultimi anni, o l'onere sarà su di te per dimostrare che questo cambiamento non era la causa.)

Potresti trovare questa risposta a Convinci la società che lavoro per implementare il controllo della versione? utile.